Snort does not show trojan traffic
-
Hello everybody,
I got a problem with snort on my pfSense. I have snort set up on the WAN interface aswell as the local interface. SO whenever I get an alert I see it on the Snort-WAN interface AND on the Snort-LAN interface (I have squid running on the pfsense aswell, so I always get one alert on the LAN interface with the ip from the local PC as source and the internal IP of the pfsense as destination and one alert with the external IP of my pfsense as source and the IP of the server the traffic goes to as destination).
Now I got some alerts with trojan traffic (conficker) on the WAN interface. I can see that the traffic comes from my pfsense but I don't have a corresponding alert on my LAN interface to see which PC in my local net is the source.
As long as conficker has not been ported to FreeBSD I think there is something missing in my logs.
Has anybody got an idea and is able to help me with this?
Edit:
pfSense-Version: 2.1
Snort-Version: 2.9.4.6 pkg v. 2.6.0Regards
Malte
-
I can't really comment on your issue, but you are running out of date pfSense and Snort. Your Snort version is marked EOL and will not receive rules updates.
-
I am aware of that, thanks. ;-)
-
If you are talking about the conficker encrypted udp alerts, they are known false positive rules.
-
Can you paste the rule hitting on WAN, we will adapt/modify it to make sure it hits on LAN.
F.
-
@fsansfil see my post above.
-
But what if they are not FP ?
A guy is allowed to be due diligent and double check ;)
F.
-
This is the generated log entry:
11/11/14 12:30:55 1 TCP A Network Trojan was Detected
84.167.xxx.xxx 6354
38.229.xxx.xxx 80
1:2009024
ET TROJAN Downadup/Conficker A or B Worm reportingAnd it's definitely no false positive because my ISP sent me a note that our network is generating trojan traffic with the exact timestamp of that log entry. ;-) So it's not in question if there is an infected PC in my network.
Malte
-
But what if they are not FP ?
A guy is allowed to be due diligent and double check ;)
F.
I said if they are the conficker encrypted alerts, they are FP. Nobody, not even the guy that wrote the rules can doubt that.
Since the alerts aren't the ones I said, they are either 1)legitimate alerts, 2)FP rules but nobody knows it (yet).
The next time your ISP sents you a note, tell them I said it's ok for you to slap them.
Conficker is a windows worm. The OP mentioned FreeBSD in his first post, therefore I'm assuming (correct me if I'm wrong) that the systems behind pfSense are FreeBSD systems. In this case it's NOT your network that's generating the traffic. I could explain how your IP might show up on the other side of the globe, but I wont. Yes it can be done.
If I misunderstood something and there are windows systems behind pfsense, get a packet capture from them. (diagnostics>packet capture). If you do spot the IP that the alert is firing up on, on those systems (the "foreign" IP), then yes, I'm afraid the alerts are genuine.
The "exact timestamp" could mean the ISP is also using suricata/snort with FP rules enabled, it doesn't necessarily mean that it's a confirmation of the alert.
I need packet captures from the windows network, or anti-virus/anti-malware/whatever-it-is-you-windows-blokes-use showing an infection. Until then (assuming the OP is using FreeBSD systems behind pfSense) it's another FP rule as far as I'm concerned.
If I'm wrong in my assumption that the OP is using FreeBSD exclusively, then most of my post above is invalid (the part about nobody doubting it is still valid though).
-
Let me clear some things up:
- I'm not running FreeBSD behind the pfSense but Windows
- I got a notification from my ISP that stated that my network was generating conficker traffic at a specific time stamp
- My Snort had an alert on the WAN-Interface (see above) at the exact same time stamp
- There is NO corresponding alert on my two internal interfaces at that time stamp
- There HAS been notes from my ISP before regarding that same behaviour where I had alerts from my WAN-Interface AND one of my LAN-Interfaces and where there have been infections on PCs in that local network
- My mentioning of FreeBSD was due to the fact that if there only is an alert on the WAN-Interface with the external IP of my pfSense as source it would mean that my pfSense had to be the source of the conficker traffic. That would only be possible if conficker had been ported from Windows to FreeBSD. ;-) Sorry for creating confusion with that. :)
So…it IS possible that it's a FP but I think due to the signs it's highly unlikely.
The conclusion is that there has to be a conficker infection on one or more of my PCs and that there is an alert missing on my LAN-Interface. I could scan all the ~50 PCs in my network to find the infection but I set up Snort in the first place so that I would not have to plus I don't trust the av-scanner very much (there have been several occasions where I found infections only by scanning the PCs with a Kaspersky live cd and the installed scanner (F-Secure) didn't find anything). It would be a big pain in the ass if I had to manually scan all the PCs...again! So I really hope we can figure out why Snort did not generate an alert on my LAN-Interface. :)
Malte
P.S.: Sorry if my somewhat rough english is hard to read or creates confusion. It's not my native language.
-
Let me clear some things up:
- I'm not running FreeBSD behind the pfSense but Windows
- I got a notification from my ISP that stated that my network was generating conficker traffic at a specific time stamp
- My Snort had an alert on the WAN-Interface (see above) at the exact same time stamp
- There is NO corresponding alert on my two internal interfaces at that time stamp
- There HAS been notes from my ISP before regarding that same behaviour where I had alerts from my WAN-Interface AND one of my LAN-Interfaces and where there have been infections on PCs in that local network
- My mentioning of FreeBSD was due to the fact that if there only is an alert on the WAN-Interface with the external IP of my pfSense as source it would mean that my pfSense had to be the source of the conficker traffic. That would only be possible if conficker had been ported from Windows to FreeBSD. ;-) Sorry for creating confusion with that. :)
So…it IS possible that it's a FP but I think due to the signs it's highly unlikely.
The conclusion is that there has to be a conficker infection on one or more of my PCs and that there is an alert missing on my LAN-Interface. I could scan all the ~50 PCs in my network to find the infection but I set up Snort in the first place so that I would not have to plus I don't trust the av-scanner very much (there have been several occasions where I found infections only by scanning the PCs with a Kaspersky live cd and the installed scanner (F-Secure) didn't find anything). It would be a big pain in the ass if I had to manually scan all the PCs...again! So I really hope we can figure out why Snort did not generate an alert on my LAN-Interface. :)
Malte
P.S.: Sorry if my somewhat rough english is hard to read or creates confusion. It's not my native language.
Don't forget that Snort puts interfaces it runs on in promiscuous mode. That means you will see IP traffic appearing to "come from" your WAN IP that may not actually be coming from your internal network. That could explain Snort alerting on your WAN side but not on the LAN side. However, the fact your ISP is also seeing the traffic as coming from your WAN IP makes it certainly plausible the infection is in your network.
Are you sure the exact same rules are in place on the LAN and WAN? Can you identify the same rule SID from the WAN alerts in the LAN rules? You can go to the RULES tab for the LAN interface and click the SID column to sort the list alphabetically.
Do you have the exact same preprocessors enabled with the same settings on the LAN and WAN?
Bill
-
There is some reason why the rule wouldnt not trigger on the LAN but on the WAN. Traffic just hitting the firewall, not from or for your protected hosts or $HOME_NET and direction of the rule doesnt apply…
To be sure take the rule and mod it, since you didnt give us the SID I assume this is the one
alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS (msg:"ET TROJAN Downadup/Conficker A or B Worm reporting"; flow:to_server,established; content:"/search?q="; http_uri; pcre:"//search?q=[0-9]{1,3}(&aq=7(?[0-9a-f]{8})?)?$/U"; pcre:"/\x0d\x0aHost\x3a \d+.\d+.\d+.\d+\x0d\x0a/"; reference:url,www.f-secure.com/weblog/archives/00001584.html; reference:url,doc.emergingthreats.net/bin/view/Main/2009024; classtype:trojan-activity; sid:2009024; rev:11;)
Just change the : alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS
For : alert tcp any any <> any any
So like this, you should see it on the LAN also. This is a debug rule, not optimized.
Also, depending on whats your $HOME_NET, whitelist and pass list, it could still not block it but at least it will alert.
F.
-
Don't forget that Snort puts interfaces it runs on in promiscuous mode. That means you will see IP traffic appearing to "come from" your WAN IP that may not actually be coming from your internal network. That could explain Snort alerting on your WAN side but not on the LAN side. However, the fact your ISP is also seeing the traffic as coming from your WAN IP makes it certainly plausible the infection is in your network.
Are you sure the exact same rules are in place on the LAN and WAN? Can you identify the same rule SID from the WAN alerts in the LAN rules? You can go to the RULES tab for the LAN interface and click the SID column to sort the list alphabetically.
Do you have the exact same preprocessors enabled with the same settings on the LAN and WAN?
Bill
Yes, both interfaces are set up in the same way, with the same rules, preprocessors and settings.
There is some reason why the rule wouldnt not trigger on the LAN but on the WAN. Traffic just hitting the firewall, not from or for your protected hosts or $HOME_NET and direction of the rule doesnt apply…
To be sure take the rule and mod it, since you didnt give us the SID I assume this is the one
alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS (msg:"ET TROJAN Downadup/Conficker A or B Worm reporting"; flow:to_server,established; content:"/search?q="; http_uri; pcre:"//search?q=[0-9]{1,3}(&aq=7(?[0-9a-f]{8})?)?$/U"; pcre:"/\x0d\x0aHost\x3a \d+.\d+.\d+.\d+\x0d\x0a/"; reference:url,www.f-secure.com/weblog/archives/00001584.html; reference:url,doc.emergingthreats.net/bin/view/Main/2009024; classtype:trojan-activity; sid:2009024; rev:11;)
Just change the : alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS
For : alert tcp any any <> any any
So like this, you should see it on the LAN also. This is a debug rule, not optimized.
Also, depending on whats your $HOME_NET, whitelist and pass list, it could still not block it but at least it will alert.
F.
Yes, that's the one!
How do I change rules? I found the rule viewer but it seems I'm not able to change rules there. Do I have to do it on the shell?
Yeah, the system is set up to just alert on the local net and not automatically block local PCs. I just need it to identify the infected PCs.
-
Don't forget that Snort puts interfaces it runs on in promiscuous mode. That means you will see IP traffic appearing to "come from" your WAN IP that may not actually be coming from your internal network. That could explain Snort alerting on your WAN side but not on the LAN side. However, the fact your ISP is also seeing the traffic as coming from your WAN IP makes it certainly plausible the infection is in your network.
Are you sure the exact same rules are in place on the LAN and WAN? Can you identify the same rule SID from the WAN alerts in the LAN rules? You can go to the RULES tab for the LAN interface and click the SID column to sort the list alphabetically.
Do you have the exact same preprocessors enabled with the same settings on the LAN and WAN?
Bill
Yes, both interfaces are set up in the same way, with the same rules, preprocessors and settings.
There is some reason why the rule wouldnt not trigger on the LAN but on the WAN. Traffic just hitting the firewall, not from or for your protected hosts or $HOME_NET and direction of the rule doesnt apply…
To be sure take the rule and mod it, since you didnt give us the SID I assume this is the one
alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS (msg:"ET TROJAN Downadup/Conficker A or B Worm reporting"; flow:to_server,established; content:"/search?q="; http_uri; pcre:"//search?q=[0-9]{1,3}(&aq=7(?[0-9a-f]{8})?)?$/U"; pcre:"/\x0d\x0aHost\x3a \d+.\d+.\d+.\d+\x0d\x0a/"; reference:url,www.f-secure.com/weblog/archives/00001584.html; reference:url,doc.emergingthreats.net/bin/view/Main/2009024; classtype:trojan-activity; sid:2009024; rev:11;)
Just change the : alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS
For : alert tcp any any <> any any
So like this, you should see it on the LAN also. This is a debug rule, not optimized.
Also, depending on whats your $HOME_NET, whitelist and pass list, it could still not block it but at least it will alert.
F.
Yes, that's the one!
How do I change rules? I found the rule viewer but it seems I'm not able to change rules there. Do I have to do it on the shell?
Yeah, the system is set up to just alert on the local net and not automatically block local PCs. I just need it to identify the infected PCs.
Easiest way for testing is to simply create a custom rule. Go to the RULES tab for the interface and select "Custom Rules" in the drop-down. Paste in a rule (or type it in directly) and hit SAVE. Just be sure to always include a "classtype:" keyword. If you don't, then Snort will segfault when the rule fires.
Bill
-
Easiest way for testing is to simply create a custom rule. Go to the RULES tab for the interface and select "Custom Rules" in the drop-down. Paste in a rule (or type it in directly) and hit SAVE. Just be sure to always include a "classtype:" keyword. If you don't, then Snort will segfault when the rule fires.
Bill
Ah yes. Didn't see the custom rules category. I've implemented the modified rule and will be testing now.
Thanks for the help so far, guys. It's really appreciated! :)
Malte
-
Hey guys!
Just wanted to let you know that with the modified rule I was able to get an alert on the interface I supected to be the source of the conficker traffic. I still have to investigate the PC to confirm that it actualy is infected but the whole issue seems pretty plausible now.
Thanks again for the great help!
Malte
