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

MarvinFS

Dearest gurus,

Desperately need your support:

I'm fighting LAN threats so i only enable LAN interface in SNORT.
Block offenders enabled: mode DST
for "home net" var I have all my LAN subnets
"pass list" is the very same list as home nets list.
Now I realized, that SNORT doesn't respect SRC-DST pairs OR ideally SRC-DST-PORT pairs at all, what it does is simply fills snort2с table with plain IP addresses which it would block with PF...

So it depends what block mode do you use:

if it's DST block mode then you will get all your alerted destination IPs in there
if it's SRC all LAN IPs (if subnet not in pass list) will be blocked very fast and you just lock out your LAN completely
if SRC is in PASS list so absolutely nothing will be blocked in case of SRC block mode.
if BOTH mode is selected it simply puts both IPs there SRC AND DST... which is completely sucks from my understanding.

So what I have now: DST blocking mode, alerts are being raised and DST IPs being blocked - all seems to be fine, until you want to whitelist some connections i.e for VIPs, management or IT team.

I haven't found any single way to make a whitelist in such scenario:

PASS list have no effect at all (remember DST mode)
suppress list entry such as
suppress gen_id 0, sig_id 0, track by_src, ip xxx.xxx.xxx.xxx yyy.yyy.yyy.0/23 zzz.zzz.zzz.zzz
also no effect at all - because again DST block mode and even if it will have an effect, while other LAN users are accessing same gmail service for example, it's DST addresses getting into snort2c table so ALL connections to this DST will be blocked,regardless of the whitelists as this is DST block mode.

It may be just my lack of understanding though, but i'm completely confused! Please help.

Regards,
Vladimir.

bmeeks

On the INTERFACE SETTINGS page for your LAN configure Snort to block "BOTH" source and destination IP addresses. This is because bad traffic can be coming in either direction (sourced from some Internet site, or destined from your LAN host to an Internet-based CnC server). The hint text on the page suggests you use the BOTH setting for "which IP to block".

By default, your LAN hosts will not be blocked if you leave the Pass List setting on the INTERFACE SETTINGS tab set to "default".

Now things will work as follows:

A source on the Internet attempts to send a malicious payload to your LAN host. The flow is from the Internet (SRC) to your LAN host (DST). Snort detects the payload incoming and will attempt to block both IP addresses in the packet (source and destination) because the setting for which IP to block is BOTH; however, because the default Pass List says to never block LAN IP addresses, only the Internet source IP of the malicious traffic will actually get blocked. The flow of bad packets is now stopped, and that's what you wanted.
Conversely, if a LAN host is already infected via some other method (say from a USB drive), and that host attempts to talk out to some CnC bot server to download more malicious code, Snort will detect the attempt and again act to block both IP addresses in the packet. This time, though, the flow is from your LAN host (SRC) to the remote host (DST) so SRC IP is your LAN host and DST IP is the remote Internet CnC server. Snort will once again wind up only blocking the remote DST IP of the CnC server because the default Pass List says to never block LAN host IPs. The flow of bad packets is now stopped -- again what you wanted.

It really does no good to leave such blocks in place forever, so I recommend users configure the setting on the GLOBAL SETTINGS tab to remove blocked hosts on an interval. One hour, or even a shorter time, is a good setting for clearing out blocked hosts that have not seen any traffic within the time interval selected.

MarvinFS

Thank you so much for answer, I was hoping some senior expert will take the lead, after reading all your super cool blueprints and suggestions here...

Sir that's not really what I'm aimed for.. so I failed to get pfBlockerNG working properly with majority of HTTPS sites, especially where it's SSL pinning and all... (yes he claims it will be soon updated, but still not works as excepted)

The goal is to fight internal users internet misuse (especially for wifi subnets), not trojans or viruses coming from LAN, like to block social networks and telegram along with other messengers... youtube, etc.. you know... everything non work related..
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...

Me personally, I'm really not a fan of blockings.. but management insists... you know... corporate sector... gray suites and such... and with openAPP ID it's working kinda OKish (not all services i select are blocked apparently) but without SRC-DST pairs I bluntly block whole IPs, which in case of LAN IP mean user will rest without internet access, which is unacceptable.. with DST only I kinda achieve the goal, but now I can't unblock management and VIPs which also unacceptable in my case (for example HR can't work without linkedin, but it should be blocked for all others)...

PS now I have an idea if I just make a firewall rule with alias for target IPs to completely unblock them.. But how to get it processed BEFORE Snort2c kicks in...

Regards,
Vladimir.

bmeeks

I'm not sure what you mean exactly by the statement in your original post: "SNORT doesn't respect SRC-DST pairs OR ideally SRC-DST-PORT pairs at all"

What is it that you want Snort to actually do in terms of blocking? I am having a little difficulty in following your post. Perhaps English is a second language for you and something is getting a little lost in the translation ???

If you want to primarily block LAN users from visiting corporately-banned content such as porn or perhaps social media sites, then you would really need to head towards another tool. Snort and Suricata are funamentally designed to detect and block malicious content based on data signatures. OpenAppID within Snort can do some DPI (deep packet inspection) and alert based on application ID (Facebook, YouTube, Messenger, etc.), but that gets more and more dicey as all web content moves to SSL. Encrypted packets can't be inspected. Only decrypted packets can be inspected. OpenAppID works by looking for some really basic header stuff that is outside the SSL encryption wrapper. Truly guarding against offensive content requires some type of proxy with MITM (man-in-the-middle) certificates. That is not necessarily hard to accomplish in a corporate network where you rigidly control the software on machines. It is darn near impossible to administer on BYOD (bring-your-own-device) networks.

MarvinFS

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.

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..