Snort 2.9.4.1 pkg v.2.5.8


  • Banned

    Nope



  • @bmeeks:

    P.S. – while you can do it, it would be sort of pointless and a waste of resources to run a duplicate set of rules on both the WAN and LAN interfaces in a scenario like I described.  I prefer the setup where known bad hosts are blocked right away at the perimeter (the WAN).  I get this from those ET-CIARMY and RBN rules.  Then my LAN side interface is the next layer of protection and contains the richer rule set.

    Bill

    Hi Bill, could you please give me a close hint how to configure the WAN and LAN iface with different rules, especially where to get and how to enable this lists.

    Thanks!



  • @sensemann:

    Hi Bill, could you please give me a close hint how to configure the WAN and LAN iface with different rules, especially where to get and how to enable this lists.

    Thanks!

    First, make sure you are running the latest version of the Snort package.  That is 2.9.7.0 pkg v3.1.3.  I highly recommend you also upgrade to pfSense 2.2 if you have not already.

    Have you checked out this sticky thread?  https://forum.pfsense.org/index.php?topic=61018.0

    There are instructions within that thread on how to obtain and configure rules.  If you still need help after reading the sticky post, then please start a new message thread in the Packages sub-forum.  This particular thread is quite old.

    Bill



  • Hi Bill, I don't see the purpose of running snort on the WAN interface if I already have Snort running on the LAN interface.  Assuming i don't have any services port forwarded, doesn't pfsense default firewall already prevent all incoming connections to the WAN interface anyway?  And if I do have port forwarded rules setup on the WAN interface, won't Snort on the LAN interface take care of this as well?

    Thanks



  • @choodee:

    Hi Bill, I don't see the purpose of running snort on the WAN interface if I already have Snort running on the LAN interface.  Assuming i don't have any services port forwarded, doesn't pfsense default firewall already prevent all incoming connections to the WAN interface anyway?  And if I do have port forwarded rules setup on the WAN interface, won't Snort on the LAN interface take care of this as well?

    Thanks

    You are correct.  With no running services (open ports) on the WAN side, Snort will prove more useful on the LAN interface (and DMZ interface if you have one of those).

    Bill



  • @shinzo:

    @bmeeks:

    @shinzo:

    I also wanted to ask something about what i read the other day. 
    Would it be better to have 1 wan interface with the wan ip and lan address or separate them and have 1 wan and then 1 lan?  and thanks again

    If we are talking about a typical home network with NAT, then it depends on whether or not you want to identify specific hosts on the LAN side.  Here's what I mean.  When you have NAT, then Snort sees everything on the WAN in terms of your WAN IP address and then whatever Internet hosts are being contacted.  Snort does not see the internal LAN private IPs.  It will still block offending traffic by blocking the SRC (assuming you have that configured for the WAN interface).  But the logs will show everything in the local network as having the WAN IP address.

    So if you want to see your LAN private IP addresses in the logs and thus be able to identify which specific LAN host might contain the latest nasty online banking Trojan, then you would run an instance of Snort on your LAN interface.  This is what I do.  I have Snort on the WAN configured with some basic ET-CIARMY and ET-RBN rules, then run the Snort VRT IPS-Balanced policy on my LAN interface.  I configured my LAN interface to block BOTH (source and destination).  The auto-whitelisting feature that adds the LAN to the whitelist means my LAN IPs never get blocked, but if any LAN IP tries to "phone home" to a BOT C-n-C server on the web, then the DST would get blocked because of the BOTH setting.  So I am protected either way (whether my LAN host initiates the conversation or the far-end host does).  Plus, my logs now show me the internal LAN private IP of the infected or potentially infected host.

    P.S. – while you can do it, it would be sort of pointless and a waste of resources to run a duplicate set of rules on both the WAN and LAN interfaces in a scenario like I described.  I prefer the setup where known bad hosts are blocked right away at the perimeter (the WAN).  I get this from those ET-CIARMY and RBN rules.  Then my LAN side interface is the next layer of protection and contains the richer rule set.

    Bill

    Can you help me with this? This is the exact setup I need to emulate. Even down to the single WAN and single LAN interface. Seems easy enough to just set up the LAN interface with VRT configs but it seems you have a specific config on the WAN interface? I don't even know what ET-CIARMY and RBN are.  :(



  • OK I did some digging and figured that out. Your post now makes sense to me now that I know what emerging threats is.

    I did notice this post is kind of old and when I take a look at the RBN rules and it appears they are no longer updated. http://doc.emergingthreats.net/bin/view/Main/RussianBusinessNetwork


  • Moderator

    @NetDefense:

    OK I did some digging and figured that out. Your post now makes sense to me now that I know what emerging threats is.

    I did notice this post is kind of old and when I take a look at the RBN rules and it appears they are no longer updated. http://doc.emergingthreats.net/bin/view/Main/RussianBusinessNetwork

    The RBN list has been discontinued for awhile now… The only two free lists available from Emerging Threats (now Proofpoint) is ET Compromised and ET Block....  With the ET IQRisk suite (Paid subscription) they have an IPRep list available...


Log in to reply