Snort doesn't know about SRC-DST pairs thus unable to whitelist anything

MarvinFS

Now, back to technical, are there any method to put any custom pf firewall rules in front of SNORT's snort2c table? It would be also fine for me. I haven't found any way...

bmeeks

@marvinfs said in Snort doesn't know about SRC-DST pairs thus unable to whitelist anything:

Sorry for the confusion, yes English is totally not my primary language being Russian (i'm really really not proud of it, sorry) and yes my goal is to block LAN users from vising non-work related content.

Squid is kinda still works as MITM solution, but squidGuard doesn't nowadays as everybody knows, that's why I was looking for any solution. Tried pfBlockerNG , which is still very promising and SNORT, with appID, which seemed to be a solution also...

What I meant with : "SNORT doesn't respect SRC-DST pairs OR ideally SRC-DST-PORT pairs at all" if only SNORT would just put pf firewall rules in form of source-destination-port, it would totally be sufficient for me. Blocking single either destination or source IPs (which is usable in case you wanna block really malicious content only) does not work for me...

Regards,
Vladimir.

Ah-ha! I understand now. As you have correctly surmised, Snort works by placing IP addresses in a pre-existing pf table called snort2c. That table is created by the pfSense code at bootup and is present even when the Snort package is not installed. There are also a handful of other special tables created at bootup by pfSense. These types of firewall tables can only take IP addresses as their input parameters. They are not set up to accept port numbers.

Snort on pfSense actually blocks by use of a custom output plugin created for the Snort binary by the original package author. I inherited maintenance of the package several years ago. I have made some modifications and enhancements to that custom plugin, but I did not create it. The plugin makes FreeBSD system calls to place IP addresses into the snort2c table. The plugin does not actually create a firewall rule, though. The rule is pre-existing (created at firewall bootup) and simply uses the table IP addresses as its SRC/DST addresses. The blocking plugin simply feeds the offending IP addresses to the table.

bmeeks

@marvinfs said in Snort doesn't know about SRC-DST pairs thus unable to whitelist anything:

Now, back to technical, are there any method to put any custom pf firewall rules in front of SNORT's snort2c table? It would be also fine for me. I haven't found any way...

No, there currently is no way to do that.

boobletins

@marvinfs said in Snort doesn't know about SRC-DST pairs thus unable to whitelist anything:

So like to block services by categories: porn, messengers, social networks, video\audio streaming... And my mates with Cisco firepower seems to be doing exactly that just fine... but not in my case... In the past ages i was doing that perfectly with squid... but not nowadays...

I'm no expert, but if I wanted to block all of that traffic I would start by controlling DNS.

If the users aren't tech savvy (or lack local admin) and you have a budget, then simply set DNS resolvers to use something like OpenDNS and select your DNS block options (below are not mine -- this is the "High" policy from OpenDNS):

If users are tech savvy with local admin rights and start inputting their own DNS servers, then block all DNS traffic that isn't to your preferred DNS provider using a Snort/Suricata rule (if they are using DNSSEC or non-standard ports, then you've got a bigger issue...).

If you don't have a budget for a DNS provider, then make use of pfBlocker's DNSBL and create your own lists.

boobletins

Another low-budget option is pihole: https://pi-hole.net/

Like pfBlockerNG you would be making a lot of those lists yourself, but it's a better interface and can sit apart from pfSense in a docker container or similar

MarvinFS

@boobletins said in Snort doesn't know about SRC-DST pairs thus unable to whitelist anything:

Another low-budget option is pihole: https://pi-hole.net/
Like pfBlockerNG you would be making a lot of those lists yourself, but it's a better interface and can sit apart from pfSense in a docker container or similar

Yeah i've seen it - it's basically external pfBlockerNG. But correct me if I'm wrong:
Neither of them will really work, starting from squidguard to piHole to pfblockerNG.
In case of squidguard with SSL it's redirect CONNECT http://xxx/xxx/xxx which is not supported solution as there are no redirect in HTTPS protocol. In case of pfBlockerNG - you only have self-signed certificate on internal lighthttpd but you have to generate MITM certificates on the fly to be able show blocked page for users without certificate errors in client's browser - so currently it's kinda doesn't work. (actually that's what Squid is doing just fine, it's on the fly and without really big delays also with caching and all bells and whistles)
not sure about piHole how does it shows blocked page to the user.
Also people say ufdbGuard but it's not in PFsense and I recon it has the very same issue with showing blocked page for HTTPS sites...

bmeeks

@marvinfs said in Snort doesn't know about SRC-DST pairs thus unable to whitelist anything:

@boobletins said in Snort doesn't know about SRC-DST pairs thus unable to whitelist anything:
Another low-budget option is pihole: https://pi-hole.net/
Like pfBlockerNG you would be making a lot of those lists yourself, but it's a better interface and can sit apart from pfSense in a docker container or similar
Yeah i've seen it - it's basically external pfBlockerNG. But correct me if I'm wrong:
Neither of them will really work, starting from squidguard to piHole to pfblockerNG.
In case of squidguard with SSL it's redirect CONNECT http://xxx/xxx/xxx which is not supported solution as there are no redirect in HTTPS protocol. In case of pfBlockerNG - you only have self-signed certificate on internal lighthttpd but you have to generate MITM certificates on the fly to be able show blocked page for users without certificate errors in client's browser - so currently it's kinda doesn't work. (actually that's what Squid is doing just fine, it's on the fly and without really big delays also with caching and all bells and whistles)
not sure about piHole how does it shows blocked page to the user.
Also people say ufdbGuard but it's not in PFsense and I recon it has the very same issue with showing blocked page for HTTPS sites...

HTTPS caused a ton of problems with deep packet inspection and content policing for corporate admins. As you noted, almost every solution has various downsides, especially if you want to display a "you are blocked and here is why" page to users.

I believe most large U.S. companies implement that today by utilizing Active Directory within their Microsoft Windows infrastructure (since most large corporations have a Windows backbone and domain for their business network). In that closed world, it's very easy to create SSL certificates that will pass muster on all of the corporate network Windows clients. Then the solutions mentioned above can work and direct users to a block page with information about why they were blocked and the consequences of continuing to try and access the banned content.

With Group Policy and the other controls within a Windows Active Directory domain, it's very easy to push locally-signed certs to all of the domain machines. Of course that does not work if the client is not a member of the Active Directory domain. In that case, you are going to be stuck with a much less elegant solution.

MarvinFS

@bmeeks said in Snort doesn't know about SRC-DST pairs thus unable to whitelist anything:

With Group Policy and the other controls within a Windows Active Directory domain, it's very easy to push locally-signed certs to all of the domain machines. Of course that does not work if the client is not a member of the Active Directory domain. In that case, you are going to be stuck with a much less elegant solution.

I know that well, as I use that in all my project every day... More elegant solution would be to push your AD CA's cert to PFsense and create there a sub-CA which certificates will be instantly trusted within that AD environment, which I'm using... Despite that, it seems to be working only for Squid with its instant on-the-fly certificates issuing. So here's an example of such scenario and blocking is managed by Squid's URL ACLs only.

Notice trust path is valid and PFsense's sub-CA issues valid cert for Facebook, thus no certificate error is presented to user.

Now with PFblockerNG, there are no such option and you are stuck with it's static self-issued cert, which doesn't work at all, as when you try to show blocked service page to the user, the browser will show you a certificate error - notice that it forwards you from https://vk.com social network to blocked page distribution endpoint on 172.16.10.10 VIP, but CN for the certificate is completely wrong so even IE browser raises the question...

So I just wonder how commercial solutions as untangle works, as they are based on the same opensource solutions...

boobletins

I must be confused. My understanding is that you were not particularly concerned with security, but you are concerned with blocking non-work related content.

If that's the case, then I'm going to ignore anything having to do with Squid--you don't need it. For all but advanced users (who will always find a way). You only need to control DNS.

Set your DHCP servers to issue DNS IPs for servers you control. Set those servers to perform lookups via pihole, OpenDNS, or any number of similar services that will limit DNS responses only to work-related content.

If moderately advanced users attempt to circumvent your DNS settings using local admin rights by setting eg 8.8.8.8 as their DNS server, then block all traffic to external servers on ports 53/853 at the firewall (except traffic originating from the DNS servers you control).

Employee attempts to visit pr0n.com
Before HTTPS ever comes into play, pr0n.com must be resolved to eg 66.60.06.66
DNS request goes out to your server: ohnoyoudont.com:53
DNS server replies with NXDomain
HTTPS request fails because name resolution failed

The solution for a message to the user is only slightly more complicated -- the DNS servers you control return a standard IP for to an HTTP server you control for any blacklisted domain. That HTTP server responds to any requested URL with an error indicating the domain is blocked.

What am I missing? You must be trying to do something more than I understand?

MarvinFS

@boobletins said in Snort doesn't know about SRC-DST pairs thus unable to whitelist anything:

The solution for a message to the user is only slightly more complicated -- the DNS servers you control return a standard IP for an HTTP server you control. That HTTP server responds to any requested URL with an error indicating the domain is blocked.
What am I missing? You must be trying to do something more than I understand?

It's already heavily offtopic here i guess! :) I just asked about SNORT features and now we're discussing any possible solutions... Anyhow, you are completely right and I think i'll just end up with simple dns solution without any redirection.

As for the message to user - the process you described should have worked with pfblockerNG, but it doesn't due to modern browsers and HTTPS protocol limitations - see above message with pictures and examples.

boobletins

Ah, I didn't see that message before I posted.

If you're trying to avoid the domain certificate mismatch, then you can keep Squid (if it will perform the MITM for you -- I don't have experience with that) -- and just make the DNS servers issue the IP for your Squid that performs MITM and only issues error pages.

eg:

Employee attempts to visit pr0n.com
Before HTTPS ever comes into play, pr0n.com must be resolved to eg 66.60.06.66
DNS request goes out to your server: ohnoyoudont.com:53
DNS server replies with 10.10.10.10 (Squid Server)
Squid pretends to be facebook.com as above, and issues the error for you.

boobletins

@marvinfs said in Snort doesn't know about SRC-DST pairs thus unable to whitelist anything:

It's already heavily offtopic here i guess! :) I just asked about SNORT features and now we're discussing any possible solutions.

If you're going back to thinking about an IPS-style solution, then you can use Suricata to do what you want (which is aware of Flows and supports "Sticky" content rules), but that will not help with redirects/error messages. It will also require significantly more hardware resources than the DNS solution.

MarvinFS

@boobletins said in Snort doesn't know about SRC-DST pairs thus unable to whitelist anything:

If you're going back to thinking about an IPS-style solution, then you can use Suricata to do what you want (which is aware of Flows and supports "Sticky" content rules), but that will not help with redirects/error messages. It will also require significantly more hardware resources than the DNS solution.

Right, thank you all people for your opinions, I think currently i'll stick with piHole without error messages.
I'm just curious what @BBcan177 would invent in future versions to overcome that issue... as he's strictly against any MITM solutions for that...

PS Also piHole is kinda a home solution class, being a simple DNS blackhole, very much lacking of enterprise features, like exception\whitelists by IP and such, so case of piHole it's either filtering for everyone or no one...
So in that regard again PFblockerNG is much more preferable as it's more flexible also... but PiHole is super fast and lightweight... but again PFblockerNG is on pfsense which is my case so you don't need to maintain extra server...

BBcan177

@marvinfs

To overcome those certificate errors, create a new DNSBL Alias and add those domains to the customlist at the bottom. Then select the "Disable Logging" and set the Group Order to Primary. Then run a Force Update... This assuming that you are on pfBlockerNG-devel. This will nxdomain those domains and also disable the logging of those domains.

MarvinFS

@bbcan177 said in Snort doesn't know about SRC-DST pairs thus unable to whitelist anything:

To overcome those certificate errors, create a new DNSBL Alias and add those domains to the customlist at the bottom. Then select the "Disable Logging" and set the Group Order to Primary. Then run a Force Update... This assuming that you are on pfBlockerNG-devel. This will nxdomain those domains and also disable the logging of those domains.

I did this already, thanks, I'm following your subsection on this forum also reddit... It worked, but then again it's not very much elegant solution... Especially that you can't add ALL possible sites there obviously and this list is getting bigger and bigger every day -it's a manual only process.. So yeah, not elegant at all..