suricata/snort vs antivirus
-
Hey folks..
REEEaaaaally stupid question...
what's the difference between what snort/suricata do, versus an AV?
I know clamav leaves much to be desired, getting that out of the way... but just for the sake of argument, say clamAV was actually really REALLY good.. and i were to set up a proxy with squid and the whole ssl-thing to decrypt everything at my recursive firewall for MITM detection with clamav.. what's the difference?
Lastly, if ones web traffic is encrypted, say via DoH, isn't MITM detection impossible at the firewall? how does suricata/snort detect malware and viruses etc in the data stream?
i know.. noob question.. but it's one of those situations where understanding that one tiny, insignificant detail brings it all together..
thanks for your patience
-
@jc1976 Snort and Suricata look for specific things in packets, for example a malicious command (SQL injection, etc.) directed at a web server, or an IP address. It depends on the rulesets chosen.
If you were to manage to scan everything with clamAV I would think it would be geared more towards viruses. I would suggest running a/v on the devices on the network and IDS on the router.
DoH just encrypts DNS, but yes if a connection is encrypted IDS software can't see into the packets.
-
So you're saying that suricata really can't do anything for https traffic unless it's decrypted via proxy?
i'm trying to understand how suricata generates alerts for my traffic if the traffic is over https.. i understand if it was http traffic.. but my financial stuff, email, etc..., that's all 'supposed' to be encrypted. and it seems to me that 99+% traffic is https these days, so how does suricata scan it if it can't see into the packets?
i do run clamav.. i know it's pretty much worthless.. but even a little is better than nothing.. it's detected a couple of bugs..
-
@jc1976 said in suricata/snort vs antivirus:
how does suricata scan it if it can't see into the packets
It can't. Package maintainer BMeeks posts about that from time to time in threads.
In my mind IDS is more useful when protecting a server, like a web server or mail server.
-
@steveits
interesting...thanks for your time!
-
The IDS/IPS packages are, by and large, useless when used on encrypted traffic unless you have MITM proxying with full decryption and then re-encryption occurring on the firewall. The IDS/IPS can't make heads or tails of encrypted packet data.
By the way, the same thing goes for ClamAV running on the firewall. Totally useless unless you have MITM proxying so it can examine the unencrypted data. One thousand times better (and more efficient) to put AV on the endpoints (servers and workstations on your network).
What an IDS/IPS can do is inspect certain header info in encrypted traffic, perform pattern matching, and make educated guesses/decisions from there. It can also examine source and destination IP addresses and ports. But it is nowhere near as effective as it was years ago before HTTPS, encrypted DNS, and POP3S and IMAPS email became so common.
-
Hello!
Almost all of my pfsense sites run some services that are accessible via the wan, so I run snort on those interfaces. I run a very basic set of rules with categories that target the services that are running - web, email, dns, etc...
Here is a daily snort report from a very simple site :
1027 (spp_reputation) packets block-list 14 (spp_sip) Content length mismatch 11 ET DOS DNS Amplification Attack Inbound 7 ET DOS Possible NTP DDoS Inbound Frequent Un-Authed MON_LIST Requests IMPL 0x03 6 MALWARE-CNC Torpig bot sinkhole server DNS lookup 5 FILE-MULTIMEDIA RealNetworks RealPlayer wav chunk string overflow attempt 3 ET WEB_SERVER WGET Command Specifying Output in HTTP Headers 3 ET DOS DNS Amplification Attack Possible Outbound Windows Non-Recursive Root Hint Reserved Port 2 ET WEB_SERVER Possible D-Link Router HNAP Protocol Security Bypass Attempt 1 SERVER-WEBAPP MVPower DVR Shell arbitrary command execution attempt 1 ET EXPLOIT MVPower DVR Shell UCE
This report is pretty typical for the site. If I am interpreting the snort alerts correctly, the vast majority of the blocks have nothing to do with what is inside the packets. I would guess there is some overlap between the snort rep and the pfB ip/geoip blocking, but I dont know how much.
John
-
@serbus said in suricata/snort vs antivirus:
Hello!
Almost all of my pfsense sites run some services that are accessible via the wan, so I run snort on those interfaces. I run a very basic set of rules with categories that target the services that are running - web, email, dns, etc...
Here is a daily snort report from a very simple site :
1027 (spp_reputation) packets block-list 14 (spp_sip) Content length mismatch 11 ET DOS DNS Amplification Attack Inbound 7 ET DOS Possible NTP DDoS Inbound Frequent Un-Authed MON_LIST Requests IMPL 0x03 6 MALWARE-CNC Torpig bot sinkhole server DNS lookup 5 FILE-MULTIMEDIA RealNetworks RealPlayer wav chunk string overflow attempt 3 ET WEB_SERVER WGET Command Specifying Output in HTTP Headers 3 ET DOS DNS Amplification Attack Possible Outbound Windows Non-Recursive Root Hint Reserved Port 2 ET WEB_SERVER Possible D-Link Router HNAP Protocol Security Bypass Attempt 1 SERVER-WEBAPP MVPower DVR Shell arbitrary command execution attempt 1 ET EXPLOIT MVPower DVR Shell UCE
This report is pretty typical for the site. If I am interpreting the snort alerts correctly, the vast majority of the blocks have nothing to do with what is inside the packets. I would guess there is some overlap between the snort rep and the pfB ip/geoip blocking, but I dont know how much.
John
Yes, the alerts you listed are what Snort can discern from the unencrypted portions of the packet. This is basic IP header stuff, and for some HTTPS/TLS application traffic, the SNI (Server Name Indication) header info. At the moment that piece of info is not encrypted, but there is a move afoot to do so in the future.
There will be overlap potentially between the Snort IP Reputation lists and some lists used by pfBlockerNG or pfBlockerNG-devel. It depends on the exact lists chosen for each.
So to sum this up, IDS/IPS can still do a few useful things, but the widespread use of encryption at the transport layer has severely limited what it can do now compared to the early years of the Internet. And true DPI (deep packet inspection) is not really happening unless you do the MITM thing.
-
@bmeeks so what do you make of the whole DPI on commercial products if a customer chooses not to do MITM?
ClamAV and IDPS round out a security product but correctly stated, if you’re not breaking the TLS session you are not protecting any asset. -
@michmoor said in suricata/snort vs antivirus:
@bmeeks so what do you make of the whole DPI on commercial products if a customer chooses not to do MITM?
ClamAV and IDPS round out a security product but correctly stated, if you’re not breaking the TLS session you are not protecting any asset.See my reply to @serbus immediately above this one. IDS/IPS can do a few useful things, but it is just not as capable as it was in the earlier days now that encryption is everywhere. You simply can't do anything useful with encrypted data (in terms of scanning it for harmful content).
Now if you do MITM to break the encryption so the IDS/IPS can examine cleartext data, then most certainly it can be a huge security boosting asset. But doing MITM is complex, and it is prone to bumps along the way as various software vendors are working overtime on improving privacy within their applications (think DoH, WhatsApp, Signal, etc., for example).
So if a client on your network is sending encrypted data that is then encrypted again via TLS/SSL, you still can't see the true payloads. While you can use your MITM to break the TLS/SSL encryption, you still have the encryption done by the app itself to keep out prying eyes. I expect this back and forth war of whack-a-mole between the MITM security appliance vendors and third-party software developers to continue to intensify, but ultimately the third-party software vendors have the upper hand here as end-to-end encryption wins the war.
-
there's the option of having the dns resolver Respond to incoming SSL/TLS queries from local clients.
I could be stating the obvious, i could have it completely wrong..
that tells me that the connection from my workstation to the proxy is encrypted.. then it's decrypted for processing (cached, scanned clamav, suricata, pfblockerng (not in that particular order)), and then before being sent on its way to the destination, it's re-encrypted again.
In this scenario, would it help with ad-blocking as well? because, if the data is decrypted, pfblocker would be able to scan into the depths of the packets.
i wonder if it would make pfblocker more effective, especially now that shallist is gone. it seems since they closed up shop, pfblocker is barely functioning.
-
@jc1976 said in suricata/snort vs antivirus:
there's the option of having the dns resolver Respond to incoming SSL/TLS queries from local clients.
I could be stating the obvious, i could have it completely wrong..
that tells me that the connection from my workstation to the proxy is encrypted.. then it's decrypted for processing (cached, scanned clamav, suricata, pfblockerng (not in that particular order)), and then before being sent on its way to the destination, it's re-encrypted again.
In this scenario, would it help with ad-blocking as well? because, if the data is decrypted, pfblocker would be able to scan into the depths of the packets.
i wonder if it would make pfblocker more effective, especially now that shallist is gone. it seems since they closed up shop, pfblocker is barely functioning.
Is the proxy in your example doing MITM using a certificate it provided to the client? If not, then you scenario is incorrect. The data is never decrypted for anything on the firewall to see it.
For encrypted DNS (DoT, for example), the session is encrypted between the client and the
unbound
resolver daemon itself. Theunbound
resolver can see the DNS request, but nothing else on the firewall can see it. Most especially the IDS/IPS because it lives on the extreme outside of the firewall. I've posted the diagrams below several times over the last year to help folks understand where the IDS/IPS sits on the packet path.Notice in both operating modes (Legacy and Inline IPS), packets coming into the firewall first hit the IDS/IPS engine, and then proceed on to the firewall itself. Legacy Mode is a bit strange as the packet in that mode hits both the IDS/IPS and the firewall engine at the same time. But if the IDS/IPS decides to block the stream, then it pulls out the offending IP addresses and sends them via a system call to the firewall over that control path shown. The firewall is then responsible for the actual block of subsequent packets from that stream.
-
@bmeeks I don't have a proxy set up yet because there's a lot about its configuration that i'm unsure about.
I run suricata in inline mode on the lan interface. I also run unbound with full DoT to cloudflare 1.1.1.2 for dns. i have nat rules and blocks set up so that, unless a client is running a vpn from there device, dns is handled by unbound.
i'm not accessing anything yet from the outside, so.. (still learning this stuff.. babysteps)
My goal is to be able to perform a full-on mitm setup, however i'm still confused with the whole cert thing, wpad, transparent proxy thing.. (the more i read up, the more questions i have).i thought it was supposed to work as follows: there are basically 2 certs (for simplicity sake i'll refer to the certs as follows):
-A WAN-side cert, so pfsense can de-encrypt/re-encrypt traffic as it receives/sends client data with the outside world,
and
-A LAN-side cert so that it could de-encrypt/re-encrypt traffic as it receives/sends data with the clients on the lan-side for https traffic.
that way, the moment my data hits pfsense on the lan-side, it is decrypted.. pfsense in all it's glory can process all packets to its fullest capability, and then before sending the data out to the internet, re-encrypts it.. and reverse (obviously) when it receives data.
Normally, i'd leave it as is, however as i fill my head with all this 'stuff', i realize that these packages really aren't doing much any more because of the encryption. and since it's just me and my family on my home network, i'd like to be able to use these facets..
also, this stuff is kinda fun! frustrating at times.. but fun..
Also i realize that email is the means of most attack vectors, and it's all basically double-encrypted, such that even with a full-on mitm proxy, email and certain apps can't be de-encrypted, and im fine with that. however regular web traffic i'd like to have scanned and processed. yeah, it's a lot, and those who know would say it's complete overkill and not serving a purpose, however it's all learning to me.. experience that i can take with me where ever i go..