Taming the beasts… aka suricata blueprint
-
If non-transparent proxy is being used, there is no real point in running Snort or Suricata with blocking enabled on LAN interface - all connections will be between internal hosts and LAN interface IP where proxy is listening. By default, those are whitelisted and if you decide to block internal hosts, you will cut off them from the internet completely…
-
If non-transparent proxy is being used, there is no real point in running Snort or Suricata with blocking enabled on LAN interface - all connections will be between internal hosts and LAN interface IP where proxy is listening. By default, those are whitelisted and if you decide to block internal hosts, you will cut off them from the internet completely…
I'm not understanding this. Are you saying that they be able to alert correctly since they are going thru a proxy? I run a non-transparent proxy, using wpad.. Snort and Suricata have been alerting correctly and block external IPs when needed. During testing, ET Policy were the block of my alerts on the LAN interface..
-
When internal client goes through non-transparent proxy, Suricata will only see internal IPs on LAN interface.
If there is some alert - let's say malicious JavaScript - it will alert, but since all IPs are local (ex. 192.168.1.1:55555 -> 192.168.1.1:8080), it won't block anything. For this to block, you have to catch this connection on WAN interface. -
If non-transparent proxy is being used, there is no real point in running Snort or Suricata with blocking enabled on LAN interface - all connections will be between internal hosts and LAN interface IP where proxy is listening. By default, those are whitelisted and if you decide to block internal hosts, you will cut off them from the internet completely…
Are you talking about a transparent firewall running snort/suricata? There are uses for this, no it's not for everyone. By default snort/suricata has difficulty determining its IPs when running in transparent mode, so no hosts will be whitelisted. Ask yourself. What would you pick? System compromise or system getting cut off from the internet? If an internal server is infected somehow and starts spewing exploits here and there, the acceptable way of dealing with it is cutting off its network access. Care! There have been cases (supposedly) in the past where malware was (allegedly) designed to that if you pulled the ethernet cable it would start destroying the system's filesystem.
A transparent snort/suricata system comes in handy when you don't want hosts on the network being able to access it in any way. How will you attack the upstream gateway if you don't know there IS an upstream gateway?
-
Hmm… I thought, I clearly wrote:
If non-transparent proxy is being used…
Let me try one more time - if you do NOT run proxy (Squid or anything else) in transparent mode - which means internal machine browser have to specify proxy in the browser, which, in turn, means that internal machine will connect to proxy in order to request any web page - in this case, running Snort/Suricata riles, which check any protocols, which proxy can rely (ex. HTTP, HTTPS, FTP) is possible in alert mode only. Even if you check to block, by default connections will not be blocked, because they are only between internal machine and LAN interface IP and those IPs are whitelisted by Snort/Suricata as internal network.
See example in the attached screenshot. In there, 192.168.15.56 is the internal IP of the pfSense, which has Snort listening on port 8080 and 192.168.15.174 is the client, receiving obfuscated JavaScript in the web response. Snort will not block this because all IPs are internal.
In this case, if such blocking is required, appropriate rules should be activated on WAN interface, but you will not see internal IP in the alerts.
-
Transparent or not the proxy will still not be blocked, since it's a known IP by snort/suricata. (WAN interface).
It will block the external host though, as long as it can see inside the protocol (ie no TLS).
If you want to block internal hosts, then just change the pass list to a different one. Snort/suricata will think all systems are to be blocked (even internal IP ones) if you have it listening on an internal interface.
EDIT:brain fart :p
-
Transparent or not the proxy will still not be blocked, since it's a known IP by snort/suricata. (WAN interface).
Sorry, not sure I understand you - do you have your proxy listening on WAN interface?
If you want to block internal hosts, then just change the pass list to a different one. Snort/suricata will think all systems are to be blocked (even internal IP ones) if you have it listening on an internal interface.
What is "it" in here? Proxy?
Entire internal network is in the pass list by default.
-
Snort/suricata WAN interface. No matter what proxy you run internally, eventually it must connect to the outside to pull data in. That's when the alerts will fire up. Snort/suricata will try to ban both source+destination (if you did not set it up like that, you should) and since the destination (proxy) is listed on its (snort/suricata's) pass list, it (proxy) will not be blocked. The outside IP will though.
WRT the listening, I was talking about snort/suricata.
"Entire internal network is in the pass list by default." I am aware of that, that's why I said change the pass list. If you tell suricata these are the networks you should NOT ban, but do NOT include the private IPs in that list, suricata will notice the alert, check to see if a private IP is on the pass list, NOT see the IP there, therefore will proceed to ban the internal IP. Most likely the proxy (pfsense) will be banned as well, so that IP should be on the pass list.
If I still fail to see the point, my apologies, it was a long day.
-
Yeah, I think we speak different languages.
I am not talking about WAN interface, not sure why you brought it in.
I am talking about Snort/Suricata instance on LAN interface. In case of non-transparent proxy it does not see external IPs, period.
-
WAN is brought in because it is needed to connected to the outside world. If you have the same rules on both interfaces and an alert pops up; the WAN interface will block the the external IP. interface. Since you should have the same alert for both interfaces, you can cross reference the WAN/LAN alert logs to find the internal IP on your LAN interface. I get what you're saying now about the LAN not blocking the the internal IP since its already white-listed. I haven't had any LAN clients stumble any malicious javascript yet.
-
Yeah, I think we speak different languages.
I am not talking about WAN interface, not sure why you brought it in.
I am talking about Snort/Suricata instance on LAN interface. In case of non-transparent proxy it does not see external IPs, period.
snort/suricata interface on LAN should show the same alert that snort/suricata on the WAN will show. If you did change the pass list, then both the internal (private) IP and the external (malicious site) IP will be blocked. If you still think that pfsense will not see the internal IP because it somehow "travels through the proxy" then you are missing a critical piece of information. snort/suricata are running the interfaces as promiscuous. That means they see every single packet that hits them, even if it's not destined for them. snort/suricata will see the packets from the laptop to the proxy (assuming proxy on pfsense), the proxy's answer to the laptop (both on LAN interface) and the request from the proxy to the malicious site, and the malicious site answer to the proxy (WAN interface). Anything that flags an alert with any of that will result in an IP being blocked, even internal IPs. Period. (throwing it in there, since something clicks in my head when someone says period to me, then everything turns black).
-
If you have the same rules on both interfaces and an alert pops up; the WAN interface will block the the external IP. interface. Since you should have the same alert for both interfaces, you can cross reference the WAN/LAN alert logs to find the internal IP on your LAN interface. I get what you're saying now about the LAN not blocking the the internal IP since its already white-listed. I haven't had any LAN clients stumble any malicious javascript yet.
Yes, that is the point I am trying to make - in such case you have to have appropriate rules enabled on WAN interface and, as you said, there is a need to find which internal IP it was, on the LAN interface as well… But that is a lot of manual labor to cross-reference alert logs :( And the additional memory used for duplicate rules...
For me, Snort http preprocessor with its built-in inspection rules (like (http_inspect) HTTP RESPONSE HAS UTF CHARSET WHICH FAILED TO NORMALIZE) is too noisy and blocks normal sites often.
-
@jflsakfja:
Anything that flags an alert with any of that will result in an IP being blocked, even internal IPs.
Don't know about you, but in my setup internal IPs are in the safe list by default (did I repeat it 3rd time?).
Oh, and I am not complaining about that. -
@jflsakfja:
Anything that flags an alert with any of that will result in an IP being blocked, even internal IPs.
Don't know about you, but in my setup internal IPs are in the safe list by default (did I repeat it 3rd time?).
Oh, and I am not complaining about that.I also repeated 3 times that you can actually change the PASS list so they are not.
-
And why would I need to remove my internal network from the pass list?
What is the use case? May be for some public hotspot it may make sense, but not for the trusted network… -
There is no such thing as a trusted network. As I said somewhere else, the only thing you should trust is the little voice inside your head. Everything/everyone out there is out to get you. And no, it's not paranoia when they ARE out to get you.
NSA aside, the use case is when trying to limit a local (internal) host from spreading something nasty on the internet. Other than that, there is no use for it, since it can still spread the "nasty" to other hosts on its subnet. When each host is on a different subnet, that's a different story, it effectively blocks it from accessing the entire network, but that is a highly specialized use case (ie not something you will encounter outside of an ISP).
Another use case that pops into my mind is when providing internet access to others (free wifi anyone?). You can't tell what their systems are infected with, so to limit your liability you could block it from accessing the internet.
As you can see from the guide, most weight is put into securing the network from outside threats, with some weight given on somewhat limiting outgoing connections. My recommendation for a normal home network is to use your trusted network example. Perfectly normal paranoia aside, it's very unlikely the NSA has broken into your house/computer-while-it-was-shipped and installed a backdoor. Incoming "nasties" are blocked. Since they are blocked, and you use some common sense (a shocking truth, but that hottie that keeps sending you naked images of her, is actually trying to get your email client to parse a command obfuscated in the image, ala firefox (yes a browser) jpg code execution), your network is (mostly) safe. Yes there are other attack vectors (eg browser memory mismanagement) but those are outside the scope of this guide :D.
-
Here is a report from The Solutionary Security Engineering Research Team (SERT) Quarterly Threat Intelligence Report for Q2 2014
http://www.solutionary.com/research/threat-reports/quarterly-threat-reports/sert-threat-intelligence-q2-2014/
Key findings include:
The top 10 ISPs represented the source of 52% of the malware identified in the new period.Amazon-hosted malware nearly triples in first half of 2014.
56% of malware captured was hosted in the United States, a 12% increase from Q4’13
Malicious SSH activity continues to be a popular method to gain administrative access to target systems.
-
Not going to register to download a report that I'm responsible of producing at my work :p
Let me guess, they propagate the Chinese 1337 hackers meme?
-
@jflsakfja:
Not going to register to download a report that I'm responsible of producing at my work :p
Let me guess, they propagate the Chinese 1337 hackers meme?Its great that you are cataloging these Malicious Attempts in your network. But its important to have a well balanced Source of Threats. Some Sources are good for Mail Servers, others Malware, others SSH attack etc. By combing threat sources from a multitude of Threat Sources, you can better determine their IP Reputation.
I typically don't like to have to register for Reports also. But looking at the Solutionary Website, there are other reports available online without needing to register.
http://www.solutionary.com/research/threat-reports/monthly-threat-reports/2014/06/security-threat-report-june-2014/
Looking at my current suggested List of Blocklist Sources (See data below),
grep "98.124.198.1" pf/*
pf/ET_IPrep.txt:98.124.198.1
pf/e_tcnc:98.124.198.1
pf/e_tdrop:98.124.198.1grep "85.159.211.119" pf/*
pf/ET_IPrep.txt:85.159.211.119
pf/e_tblackhole:85.159.211.119
pf/e_tcnc:85.159.211.119grep "85.25.148.6" pf/*
pf/IBlock_BT_Spy.txt:85.25.148.6
grep "217.12.207.151" pf/*
pf/IBlock_BT_Spy.txt:217.12.207.151
grep "192.99.6.61" pf/*
no results
grep "192.99.6.0" pf/*
no results
grep "^192.99." pf/*
pf/ToastedSpam.txt:192.99.0.0/16Game Over Zeus Botnet (goz)
http://garwarner.blogspot.ca/2014/07/new-gameover-zeus-variant-uses-fastflux.html?m=1Only ET IQRisk Blocklist picks up all of these IPs.
I have seen this spam hit my Network "E-ZPass" (I forwarded them to SpamCop also)
http://garwarner.blogspot.ca/2014/07/e-zpass-spam-leads-to-location-aware.html?m=1Only ET IQRisk Blocklist picks up all of these IPs.
-
Right, I finally have a little bit more time to work on this now :P
Could I ask one more question, JFL?
This is what I am struggling with:
1. You said in one thread (I think it was your previous thread about how to set up Snort) said to ditch Snort for Suricata;
2. Some Snort rules (some 600 I believe Bill said) Suricata can not interpret.
3. Your current instructions (this thread) only deal with the ET-rules, not with the Snort rules.
4. I take it ET doesn't completely overlap the Snort (paid subscription, which is what I have) rules, so there is/might be value in using both the Suricata- and Snort rules in Suricata.What would be wisdom here? Take your old instructions about the Snort rules to know what to disable, or do you consider these instructions obsolete perhaps? If so, ditch Snort all together? (but then point 4?) If not ditch Snort, how do you cope with the rules Suricata can't handle (the Snort rules)? There are 600 it seems, so [a1] how to find out which ones and [a2] after disabling these, aren't we missing out on important protection?
Or: have both Snort and Suricata inspect the interfaces at the same time (Snort with the full subscriber rule set, Suricata with the ET rule set)?
Yes, vague and complex for a stupid economist like me, I know :-[
( ;D )
Thank you again very much :P
