Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

    Snort does not show trojan traffic

    Scheduled Pinned Locked Moved pfSense Packages
    16 Posts 5 Posters 3.1k Views
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • P
      pfs.malte
      last edited by

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

      Regards
      Malte

      1 Reply Last reply Reply Quote 0
      • F
        fragged
        last edited by

        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.

        1 Reply Last reply Reply Quote 0
        • P
          pfs.malte
          last edited by

          I am aware of that, thanks. ;-)

          1 Reply Last reply Reply Quote 0
          • ?
            A Former User
            last edited by

            If you are talking about the conficker encrypted udp alerts, they are known false positive rules.

            1 Reply Last reply Reply Quote 0
            • F
              fsansfil
              last edited by

              Can you paste the rule hitting on WAN, we will adapt/modify it to make sure it hits on LAN.

              F.

              1 Reply Last reply Reply Quote 0
              • ?
                A Former User
                last edited by

                @fsansfil see my post above.

                1 Reply Last reply Reply Quote 0
                • F
                  fsansfil
                  last edited by

                  But what if they are not FP ?

                  A guy is allowed to be due diligent and double check ;)

                  F.

                  1 Reply Last reply Reply Quote 0
                  • P
                    pfs.malte
                    last edited by

                    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 reporting

                    And 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

                    1 Reply Last reply Reply Quote 0
                    • ?
                      A Former User
                      last edited by

                      @fsansfil:

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

                      1 Reply Last reply Reply Quote 0
                      • P
                        pfs.malte
                        last edited by

                        Let me clear some things up:

                        1. I'm not running FreeBSD behind the pfSense but Windows
                        2. I got a notification from my ISP that stated that my network was generating conficker traffic at a specific time stamp
                        3. My Snort had an alert on the WAN-Interface (see above) at the exact same time stamp
                        4. There is NO corresponding alert on my two internal interfaces at that time stamp
                        5. 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
                        6. 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.

                        1 Reply Last reply Reply Quote 0
                        • bmeeksB
                          bmeeks
                          last edited by

                          @pfs.malte:

                          Let me clear some things up:

                          1. I'm not running FreeBSD behind the pfSense but Windows
                          2. I got a notification from my ISP that stated that my network was generating conficker traffic at a specific time stamp
                          3. My Snort had an alert on the WAN-Interface (see above) at the exact same time stamp
                          4. There is NO corresponding alert on my two internal interfaces at that time stamp
                          5. 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
                          6. 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

                          1 Reply Last reply Reply Quote 0
                          • F
                            fsansfil
                            last edited by

                            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.

                            1 Reply Last reply Reply Quote 0
                            • P
                              pfs.malte
                              last edited by

                              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.

                              1 Reply Last reply Reply Quote 0
                              • bmeeksB
                                bmeeks
                                last edited by

                                @pfs.malte:

                                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

                                1 Reply Last reply Reply Quote 0
                                • P
                                  pfs.malte
                                  last edited by

                                  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

                                  1 Reply Last reply Reply Quote 0
                                  • P
                                    pfs.malte
                                    last edited by

                                    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

                                    1 Reply Last reply Reply Quote 0
                                    • First post
                                      Last post
                                    Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.