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

    Pfsense: Snort configuration advice wanted

    Scheduled Pinned Locked Moved pfSense Packages
    3 Posts 3 Posters 1.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.
    • ?
      A Former User
      last edited by

      Hi,

      I have setup snort on my pfsense router, and could do with some advice of which rules to apply on which interfaces.  I am using the registered VRT package, as well as ET Open.

      I have a WAN and several VLANs for: network administration, network DMZ, internal servers + NAS, wired devices, and 4 wireless networks (includes guests).

      At first I thought to enable all rules and switch off where needed, however that naturally duplicates the rules between the WAN and the VLANs, as well as slowing down the performance of the network.

      Which rulesets are best enabled given my goal of preventing malware/bots or intrusion?

      My initial thinking had been to enable rules as follows:

      • WAN: Enable rules for protecting against inbound attacks.

      • VLAN (network administration): Enable all rules anyway.  There's not much traffic on this VLAN, so low CPU cost, and although the memory cost is high, as this is supposed to be a secure VLAN, anything on this VLAN that triggers any rule should probably be alerted on.

      • VLAN (network DMZ): This is a tricky one, since there could be both inbound and outbound traffic of a customised nature (e.g. web services) that we don't want to hit with a performance issue, yet we want to protect the servers.

      • VLAN (internal servers): Enable only the rules pertaining to intrusion.  Internet connectivity should be outbound only for software updates, so I thought less rules would be needed.

      • VLAN (wired devices): These are mostly desktop PCs.  I don't want to inhibit productivity in accessing the web, but at the same time web browsing by end-users that are "trusted" on the network is a prime vulnerability for malware.

      • VLAN (non-guest wireless): Same as above, in effect.  Although the two VLANs are separated, the devices are "trusted users".

      • VLAN (guest wireless): Not sure what to do here; on the one hand you could argue it's an untrusted network so don't apply any rules and allow all traffic, or on the otherhand its a network going to have any number of unknown devices, should it have some rules even if only to protect those devices.

      Opinions welcome.

      Regards,
      Rob.

      1 Reply Last reply Reply Quote 0
      • W
        Wolf666
        last edited by

        Depends on your network. For home networks, since you have a firewall that deny all unsolicited inbound connection, practically you don't need to run Snort on WAN. You want Snort to run on LAN and VLAN to identify clients activity, blocking/rejecting as needed.
        It is my personal view, driven by what bmeeks suggested in some posts.

        Modem Draytek Vigor 130
        pfSense 2.4 Supermicro A1SRi-2558 - 8GB ECC RAM - Intel S3500 SSD 80GB - M350 Case
        Switch Cisco SG350-10
        AP Netgear R7000 (Stock FW)
        HTPC Intel NUC5i3RYH
        NAS Synology DS1515+
        NAS Synology DS213+

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

          I agree with Wolf666.  Enabling Snort on the LAN for a home firewall is the best choice.  You don't usually have any unsolicited inbound traffic allowed on a home setup, so Snort on the WAN does not really help any more than having it just on the LAN.  What you are more worried about is an internal machine picking up malware and/or that malware calling home to the mother ship for additional instructions.  Snort on the LAN would see this and alert you.  Plus, if you configure the blocking IP to BOTH on the SETTINGS tab for the interface, then the far-end of the conversation will be blocked but the LAN end will not be as it is generally in the default PASS LIST unless you change something.  However, you will see the local IP address as well as the far-end IP in the alert.

          Bill

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