Snort configuration



  • Hello, I wish that Snort blocks positive traffic and not false positives. I have enabled some rules of emerging-rules and openappid. I am novice in snort and I am pretty quickly lost.
    I managed to unlock google and youtube. For now nothing is blocked but I have feedback in the LAN with, for example "https", "http", "chrome" …

    I do not know what I have to check for the false positives do not go back but the real positives yes.

    Thank you for your answers.



  • To be honest, OpenAppID has very limited usefulness in a home network setup.  It is really for enforcing/policing computer acceptable use policies in corporate neworks.  For example, monitoring and alerting if employees are using Facebook, BitTorrent or such things during working hours.  Usually that is of no concern on a home network.  I don't use OpenAppID on my home network.

    With only the ET-Open rules, your options as a beginner are limited.  Those rules don't offer any pre-defined protection policies to choose from like the Snort Subscriber Rules do.  My recommendation is to do this –

    1.  Sign up for the Snort Subscriber rules at www.snort.org.  You can choose the free version or pay $29.99 US per year for the subscriber version.  The difference in the two is the free version rules are 30 days old.  That means each time a new rule for a new threat is added to the subscriber package, it will not show up in the free package until 30 days after it first debuted in the subscriber package.

    2.  Enable the Snort Subscriber Rules download on the GLOBAL tab and enter the Oinkcode you received from step #1 above.  Save the changes.

    3.  Go to the UPDATES tab and click Update to trigger the download of the Snort rules.  Wait for it to finish and the modal dialog to close.  Leaving the page prematurely will kill the download.  It might take a couple of minutes on a slow connection.

    4.  Go to the CATEGORIES tab and click the checkbox to enable IPS Policy, then choose "Connectivity" in the drop-down selector.  Click Save, then go to the INTERFACES tab.

    5.  Click to edit the interface you run Snort on (I strongly suggest you run it on the LAN only).  Uncheck the "Block Offenders" box for now and save the change.  You need to gain some experience with the kinds of alerts it is going to generate on your network before enabling blocking.  If you turn on blocking before you have a good handle on what types of alerts you will receive, then you are going to be frustrated quickly by the blocking.

    6.  Back on the INTERFACES tab, either start Snort (or restart it if it was already running).

    Watch the ALERTS tab for a few days and notice the kinds of alerts you get on your network.  Each alert you see would have been a block, and that connection and traffic would have been shutdown.  Examine the alerts and use Google and some of the old thread resources in this forum to figure out which alerts are false positives.  For those that are false positive, either disable those rules by clicking the red X in the GID:SID column, or click one of the plus icons in the SRC or DST address columns to suppress that alert by IP.

    Once you gain confidence in your knowledge of the process and have your rules tuned by weeding out false positives, then you are ready to go turn "Block Offenders" back on.

    You can do a search on the IDS/IPS forum here for "Suppress List" or "Suppression List" and that should pop up a long thread about various suppress list rules other users have found useful.

    Bill



  • Hello, thank you for your answers. I forgot to mention that 'was in a corporate network. I did all the manipulations that you advise me. However, I saw that Nmap (Zenmap under Windows) had to be done on the WAN. But it does not remind me of any alerts from this port reading. And I do not know if I configured my Snort correctly.



  • @Noisette:

    Hello, thank you for your answers. I forgot to mention that 'was in a corporate network. I did all the manipulations that you advise me. However, I saw that Nmap (Zenmap under Windows) had to be done on the WAN. But it does not remind me of any alerts from this port reading. And I do not know if I configured my Snort correctly.

    So did you perform the nmap scan from outside your network or from within your LAN?  Also, which interface had Snort running when you did the scan (LAN or WAN)?

    One final thing is that not every nmap scan will trigger Snort.  It depends on the specific rules you have enabled and which types of nmap scans you run.  Snort rules are also configured for only certain flow directions and also they assume that the HOME_NET and EXTERNAL_NET variables are set correctly.  Snort takes care of this pretty well with the defaults, but if you have customized either variable that can have the side effect of rendering some rules unable to trigger.

    When I want to reliably trigger Snort or Suricata, I enable the ET-Scan rules category and then I do a "service scan" with nmap.  I'm remembering this off the top of my head, so I may have it wrong, but I think the nmap command is "nmap -vS [target_ip}".  You can double-check me though and use the help option with nmap (or Zenmap).  I may have the argument incorrect.

    Bill



  • Thank you for your reply. My problem has been solved by updating snort rules. The scan appears in the LAN interface.