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

Snort WAN/LAN NAT question

Scheduled Pinned Locked Moved IDS/IPS
8 Posts 4 Posters 3.3k 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.
  • F
    finalcountdown
    last edited by Nov 22, 2015, 11:48 AM

    Hi,

    I have been experimenting with pfSense/Snort for a week now and had a "ET TROJAN Win32.Sharik Microsoft Connectivity Check" detected. Only then I realized that I have no way to identify which computer on my network was causing this since I had been running Snort on my WAN interface (NAT entry was long gone).

    So I'm guessing I have to run Snort on internal interfaces. Since I have lots of VLANs, how would I do this in an efficient way? I don't think the GUI allows me to select multiple interfaces and have all of them use the same configuration. Keeping the settings in sync manually/through the GUI doesn't seem efficient. Are there some files I can directly edit through Diagnostics –> Edit file?

    Also, it was not my goal for Snort to inspect traffic between my internal networks (to save resources), but is there any other choice? Wouldn't it technically be possible for Snort to look up the LAN computer from the NAT table the moment it detects something and write that to the log?

    1 Reply Last reply Reply Quote 0
    • D
      doktornotor Banned
      last edited by Nov 22, 2015, 1:14 PM

      If you search here, lot of people are running larger ruleset on their LAN(s) and a very basic one on their WAN(s). For this reason, among others. And actually yes, if you really want to keep the config in sync, you can just re-configure one interface, remove the others and re-add those with the + button next to the configured interface. But - there's really no requirement to keep those in sync, in fact pretty much waste of resources with a large ruleset.

      1 Reply Last reply Reply Quote 0
      • F
        finalcountdown
        last edited by Nov 22, 2015, 7:42 PM

        In a WAN/LAN scenario where theres only two interfaces I get what you're saying, but I'm not sure I understand why I wouldn't need to keep the configuration in sync between my internal interfaces. If I want to inspect packets traveling to internet from any of my VLANs, don't I have to have all my rules enabled on them all?

        Also if I send a packet from LAN1 to LAN2 and both have Snort enabled, is the packet inspected twice, meaning twice the CPU load? This wouldn't be good, since I really wouldn't care to inspect internal traffic at all.

        1 Reply Last reply Reply Quote 0
        • B
          bmeeks
          last edited by Nov 23, 2015, 2:39 AM

          @finalcountdown:

          In a WAN/LAN scenario where theres only two interfaces I get what you're saying, but I'm not sure I understand why I wouldn't need to keep the configuration in sync between my internal interfaces. If I want to inspect packets traveling to internet from any of my VLANs, don't I have to have all my rules enabled on them all?

          Also if I send a packet from LAN1 to LAN2 and both have Snort enabled, is the packet inspected twice, meaning twice the CPU load? This wouldn't be good, since I really wouldn't care to inspect internal traffic at all.

          You are correct about the extra load and double inspection.  When NAT is involved, Snort setup can be problematic with more than one or two LAN (or VLAN) interfaces.  It's just the nature of the beast.

          Bill

          1 Reply Last reply Reply Quote 0
          • F
            finalcountdown
            last edited by Nov 23, 2015, 6:17 PM

            Thank you for the comments. It would be interesting to know what's the best practice with bigger deployments (I'm not a network professional), Snort running on a different box before NAT takes place maybe? Anyhow, I still think it would be neat if Snort logging could consult the NAT table and log the internal IP address even when it's running on the WAN interface. I'll maybe end up enabling it on internal interfaces as needed and normally keep running it on the WAN only. On the other hand, that also wastes resources by inspecting packets that would be dropped by the firewall anyway.. decisions, decisions..

            1 Reply Last reply Reply Quote 0
            • B
              bmeeks
              last edited by Nov 23, 2015, 7:53 PM

              @finalcountdown:

              … Anyhow, I still think it would be neat if Snort logging could consult the NAT table and log the internal IP address even when it's running on the WAN interface...

              This would require customizations to the underlying Snort binary (as in insert changes that are not currently in upstream).  Right now the only modification to the Snort binary on pfSense is to include a custom output plugin to implement the blocking.  That uses an established Snort API.

              Bill

              1 Reply Last reply Reply Quote 0
              • R
                rebytr
                last edited by Nov 26, 2015, 3:57 AM

                After upgrading one machine to Windows 10, I also started receiving the Sharik alerts in Snort.  After poking around on google, seems that all the IPs are owned by Microsoft.  Haven't really performed any additional analysis, but I'm guessing it's false-positives.  Would be curious if you're also having this same issue.

                1 Reply Last reply Reply Quote 0
                • F
                  finalcountdown
                  last edited by Nov 27, 2015, 4:43 PM

                  Correct, this was a Windows 10 machine. The "offending" process was svchost.exe and the IP resolved to Akamai Technologies.

                  1 Reply Last reply Reply Quote 0
                  8 out of 8
                  • First post
                    8/8
                    Last post
                  Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.
                    This community forum collects and processes your personal information.
                    consent.not_received