Re: Query: internet browsing logs

[Kevin Wilcox <wilcoxkm () APPSTATE EDU>]

On Thu, 11 Oct 2018 at 09:23, Roshan Harneker <roshan.harneker () uct ac za>
wrote:

We have a requirement to be able to collate internet browsing logs that
> will also be able to provide us with detail around URLs visited especially
> when forensic investigations are requested. We don’t have a requirement to
> view the website contents, just websites visited. In the past TMG was used
> as a proxy but since so much traffic is now SSL-based, I wanted to know
> what other universities are using to capture HTTP/HTTPS traffic information
> and being able to tie each URL visited to an identity.
TLS traffic is a bit of a sticky issue. Here there is no expectation of
privacy for employees on the network - we are a State university, which
means we are a State agency, which means anything (pretty much) an employee
does on the network is fair game for monitoring, especially since we tell
everyone that anything you do on the network is fair game for monitoring
(notice I'm specifically talking about employees; we are the ISP for
students and therefore take a massive "hands-off" approach beyond a bare
minimum necessary for various legal requirements). Higher Ed is one of the
few places left where full web proxying* isn't the norm and it's a clear
sign of our industry's lack of commitment to protecting institutional data
(again, I'm excluding students for whom we are an ISP).

TLS 1.2 makes up the overwhelming majority of Internet traffic these days.
TLS <= 1.2 negotiates certificate information "in the clear", meaning you
get interesting certificate information just by sniffing the wire. The
issuing body (makes it easy to look for self-signed certs), the CN for the
server, how long the cert is valid, etc., you get all of that as long as
the TLS version is less than or equal to 1.2. This is generally how various
network devices will say, "Oh look, Kevin just went to twitter.com - we
don't know whether he was checking his own tweets or whether he's
compromised with something using Twitter as a C2 but, look, twitter.com".

That changes with TLS 1.3. 1.3 cuts the 6-step process down to 4 steps,
makes connection instantiation some 30% faster and it can even "remember"
previous negotiated TLS info (huge benefit if you do lots of small HTTPS
connections; look at "fast start" and "0-RTT"). More importantly it takes
out the part of the process where we can use network monitoring to get the
certificate information *because the encryption happens before the server
responds with its certificate* - with 1.3, the client sends their keys on
connection instantiation, not after the server cert is sent to the client
like with <= 1.2.

So, with the rise of 1.3, lots of platforms that say, "we can show you the
domain your HTTPS traffic is hitting without doing TLS-decryption"...well,
let's just say they'll need to change their marketing a bit.

What does this mean...

Well, it means either we have to make the commitment to doing network
monitoring in a complete way (meaning we proxy* TLS connections) or we
accept that we don't REALLY care about knowing what leaves our networks.
Admitting the latter is probably the hardest thing to do because it causes
us to accept the level of security theatre we've built around "network
security".

"But we still get host information via DNS!!!111!1!!11"

No mate, you don't. You get what the clients *wants* you to get from DNS.
*years* ago we had commodity malware on a student machine (the student
thought something was weird so they brought the computer in for analysis).
That commodity malware would 1) change the DNS server to be a system in
Eastern Europe, 2) do lookups for google.com so it could present a fake
landing page that showed up as "google.com" and 3) in the event you were
forcing it to use your DNS servers would hijack THAT process to always
return a different static IP in Eastern Europe. DNS logs would show
requests for google.com. Passive DNS would show YOUR DNS SERVERS returning
valid Google IPs. The certificate was self-signed. Without the cert info,
you had no clue something nefarious was happening.

BIND can proxy DNS requests over stunnel (https://kb.isc.org/docs/aa-01386).
DNS over TLS is coming in a big way. Doing passive DNS collection? Enjoy it
while you can because that visibility into what may be going on with TLS
connections is coming to an end Real Soon unless you have properly
configured firewalls (meaning default-deny and all connections have to be
whitelisted) and you're proxying* TLS for those whitelisted connections.

Now, a couple of times here I've put asterisks beside the word "proxy".
There's a reason for that. "Proxying" traffic doesn't necessarily mean you
have a big device that users connect to and it decrypts all their stuff. No
no no mate, it doesn't necessarily mean that at all. It might mean you've
been working on a "remote first" or "cloud first" strategy and you have an
agent that sits on each endpoint and hooks into the system in an
interesting way - effectively turning the system's own network stack into
an organisational proxy (it's a stretch, I know, but this is sort of the
"suppose a spherical cow" version).

Instead of having <x device> that only works when someone is on your
network, and that basically acts as a choke point for web connections (but
usually nothing else...why do we not care about RDP, SSH, IRC-over-TLS,
sftp, pops/imaps, etc?!), what about an agent that says, "oh, I see a
network connection to 1.2.3.4 on port 443 and that's for
https://my.great.domain.info/some/c2/url";?

All of which is my long-winded way of getting to: if you really want to
know what's going on with your endpoints, don't try to force them into TLS
decryption - get the important bits of info from the system itself,
wherever it is in the world, with something like packetbeat or sysmon. You
aren't collecting or inspecting the contents when someone uses their Uni
laptop and Uni network to check their bank account or do that last bit of
Christmas shopping, and if a download occurs then THAT triggers further
alerts from something like sysmon. The older approaches to network security
monitoring (NSM) are useful but mostly done at this point - the networks
are too large, they're too fast, they're someone else's network, pick your
reason - so we have to look at different ways of "finding evil" (sorry,
SANS, I had to steal that).

Good luck!!

kmw

>