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

    Snort on LAN, WAN or DMZ?

    Scheduled Pinned Locked Moved IDS/IPS
    6 Posts 4 Posters 1.7k 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.
    • H
      Hin
      last edited by

      Hey, I am new to IDS/IPS.

      I want to know if it is better to place snort on LAN, WAN or DMZ.
      By researching I think an optimal solution is to placing snort on LAN, because one can identify the IP addresses of the Hosts. But I am not sure about DMZ.

      Thanks.

      T 1 Reply Last reply Reply Quote 0
      • T
        tsmalmbe @Hin
        last edited by

        @hin on all interfaces. Use different profiles for each, based on threat model ( or assumptions of such)

        Security Consultant at Mint Security Ltd - www.mintsecurity.fi

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

          The LAN is the place I recommend, mainly for the reason you listed -- local hosts show up with their actual IP addresses instead of everything having the WAN's public IP due to NAT.

          If you have Internet-facing hosts in the DMZ, then an IDS/IPS instance there can be useful running rules specific to any exposed risks in the DMZ. For example, if you run web hosts, then you would run Snort's web server and similar rules on the DMZ instance. If you have public-facing DNS or mail servers, then you would run Snort's DNS and mail server rules, and so forth.

          There is usually never a good reason to put Snort on your WAN. First, a properly configured firewall is going to drop a lot of unsolicited inbound traffic anyway. So why waste CPU cycles analyzing traffic that your firewall rules are going to drop? If a packet is destined for your LAN or DMZ, then the Snort rules running there will catch and inspect it. So again, having it inspected on the WAN does next to nothing. pfSense itself is pretty well secured. Having Snort on the WAN does nothing for pfSense itself. If you think the firewall is insecure enough that you need an IDS/IPS on your WAN to protect the firewall, then you need a new firewall ... 🙂.

          J 1 Reply Last reply Reply Quote 1
          • J
            jdeloach @bmeeks
            last edited by

            @bmeeks
            Bill, I agree with you that LAN is the interface that Snort should be run on for the reasons that you state. It would save a lot of confusion for new users if YOU ALL (not sure who YOU ALL is) would update the documentation, help tips in the package and defaults to state this. Right now, all the documentation, help tips and defaults state to configure Snort to run on the WAN interface.

            The same should be updated for the Suricata package as well.

            bmeeksB 1 Reply Last reply Reply Quote 0
            • H
              Hin
              last edited by

              Thanks for the replies !

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

                @jdeloach said in Snort on LAN, WAN or DMZ?:

                @bmeeks
                Bill, I agree with you that LAN is the interface that Snort should be run on for the reasons that you state. It would save a lot of confusion for new users if YOU ALL (not sure who YOU ALL is) would update the documentation, help tips in the package and defaults to state this. Right now, all the documentation, help tips and defaults state to configure Snort to run on the WAN interface.

                The same should be updated for the Suricata package as well.

                You can open Redmine requests to have the documentation updated if desired.

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