Monitoring and filtering of arbitrary outgoing data

Question

I would like to be able to not just centrally monitor but also filter any organizational data moving out our edge routers, regardless of the sender application and regardless of the protocol/port used by the sender application.

For example, the sender application could be an ssh/sftp client, a browser (http/s), email client(??), or even a from-scratch handwritten TCP socket-based client/server program.

If the outgoing data happens to be encrypted (say, as in case of https/ssl, ssh/sftp), I would still like to be able to decode it via an MITM-like pattern (as employed by a program like Squid) and reject or allow the data to pass through based on the decoded content.

For example, if a large file was sent out by a user, I would like to be able to extract and assemble the file into a single logical unit (from the IP packets?) and then be able to run further checks on this assembled file to decide whether or not to allow it to pass through.

Given a Linux-based environment, which (FOSS) tools and techniques should I employ to achieve this? I'm new to this area, and don't know how to proceed further. Hence the question.

Answer 1

First you need to decide how you will identify this data - this is probably going to be the biggest issue and it is not necessarily technical.

• Do you aim to tag all documents and files with a rating? This works for organisations that do tag ever single piece of data, as the gateway then just looks for the tag and acts accordingly.

• Do you set a blacklist of data to block? For example sequences of 16 digits can be blocked as they may be credit card numbers. You'll get false positives, but it can work in some environments.

If you have that sorted, the gateway aspect is relatively simple - force all devices to connect through a proxy that acts as an SSL endpoint. As you stated, this is effectively a MITM. Many proxies, including squid, will let you prevent or allow traffic based upon various criteria, but in the FOSS space you may be limited in the complexity level possible. Those two options above should work though.

You may find that trying to run deep analysis of packet streams in order to do this real time may be beyond the reach of FOSS (Have a look at next gen firewalls such as Palo Alto for some options here)

Answer 2

Sounds like you're looking for Data Loss Prevention (DLP) solutions. Although there are plenty of commercial tools, I recall Google, Snort, and a few other organizations offer FOSS DLP capabilities.

Commercial DLP vendors like Symantec (Vontu) and Websense offer complete solutions. The last I checked, FOSS DLP solutions were still quite lacking in features/functionality when compared to commercial DLP solutions.

HTH

I'm not aware of any FOSS solution that provides all the features you're looking for. Even commercial DLP solutions aren't able to peek into ssh sessions (https is much easier since you can just employ a l7 proxy architecture). The challenge is building meaningful rules. Signature-based network devices operate at l3/l4 and they don't rebuild packets into conversations. Even then, network-only data-in-motion detectors are limited to seeing plaintext traffic (with the exception of an inline l7 proxy for http/https/ftp) without implementing some sort of endpoint solution as well.

Can you explain with a bit more detail what type of data you're trying to protect? Perhaps a feature rich data-in-motion FOSS network-based DLP might not be available but you may be able to apply protection to the data itself. Otherwise, your challenge becomes protecting information assets without an appropriate budget, which is almost saying the data isn't worth protecting in the first place.

Answer 3

SSL Bump, to be integrated into a Squid proxy, can decrypt outgoing SSL sessions, subject to some conditions:

• A specific CA certificate must be added to the "trust store" of clients. SSL Bump works by creating a fake certificate for the target server, and doing a man-in-the-middle attack.
• The client browsers must be convinced to use your proxy. This can be enforced at the network level, depending on the level of control you have on the firewalls and routers.
• This breaks certificate-based client authentication. Client certificates are rare on the Web, but some banks issue certificates to their clients.
• The users will be able to see it. Most human users tend to react poorly to the discovery of such filtering of their supposedly "secure" connections. You'd better warn them proactively. Transparency is a great asset for employer/employee relations.