Navigation

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

    Snort and blocking IPs

    pfSense Packages
    4
    9
    9875
    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.
    • M
      mdima last edited by

      Hi,
          I am wondering I didn't realize it before, but it happens that the Snort package is blocking only and always the SRC IP, in all cases, no matter what.

      For example, there are some rules that intercept the answer of an attack, in this case the DST should be blocked, not the SRC.

      A concrete example is (from alert log):
      1:3273:6 - SQL sa brute force failed login unicode attempt - SRC: (wan ip address), DST: XXX.XXX.XXX.XXX
      I expect that the DST IP is blocked, not the SRC (that of course is in white-list, so it's not gonna be blocked anyway).

      In the rule definition, there is:

      alert tcp $SQL_SERVERS 1433 -> $EXTERNAL_NET any (msg:"SQL sa brute force failed login unicode attempt"; flow:from_server,established; content:"L|00|o|00|g|00|i|00|n|00| |00|f|00|a|00|i|00|l|00|e|00|d|00| |00|f|00|o|00|r|00| |00|u|00|s|00|e|00|r|00| |00|'|00|s|00|a|00|'|00|"; detection_filter:track by_src, count 5, seconds 2; reference:bugtraq,4797; reference:cve,2000-1209; reference:nessus,10673; classtype:unsuccessful-user; sid:3273; rev:6;)

      I think that in this case, the "flow:from_server" would mean that the attacker is on the other end of the communication, means that the offender is the destination, not the source.

      What do you think about it? Is there any way that the procedure that defines the blocks consider this parameter and in this case blocks the destination IP, not the source?

      Thanks,
      Michele

      1 Reply Last reply Reply Quote 0
      • marcelloc
        marcelloc last edited by

        Fill server info(web, dns, smtp,etc) at snort gui.
        This should prevent snort from blocking servers ip.

        If not, put your servers ip on whitelist.

        Treinamentos de Elite: http://sys-squad.com

        Help a community developer! ;D

        1 Reply Last reply Reply Quote 0
        • M
          mdima last edited by

          @marcelloc:

          Fill server info(web, dns, smtp,etc) at snort gui.
          This should prevent snort from blocking servers ip.
          If not, put your servers ip on whitelist.

          Marcello, the problem is not about snort blocking my own ip addresses (as I wrote, they are already in white-list), the problem is snort not blocking an offender ip!

          1 Reply Last reply Reply Quote 0
          • J
            Jonb last edited by

            I would presume you have but to check you have switched on the block offenders in the interface.

            Hosted desktops and servers with support without complication.
            www.blueskysystems.co.uk

            1 Reply Last reply Reply Quote 0
            • M
              mdima last edited by

              @Jonb:

              I would presume you have but to check you have switched on the block offenders in the interface.

              of course…

              I think it is a limit of "snort2c" (the plug-in used to block offending IPs). Looking at the source code of snort2c, it looks it only blocks the source IP, while in some rules (flow: from_server) it should block the destination IP.

              Unfortunately in the snort2c code I see that the rule generating the alert is not "parsed" in any way to understand which is the IP to block, it just goes straight to block the source ip.

              Maybe it would have sense to change the snort2c code in order to block the source and the destination IP at the same time, because anyway the local addresses are in whitelist by default. In this case it should be easy to add just 3-4 lines of code in the snort2c source.

              What do you think about it?

              Thanks,
              Michele

              1 Reply Last reply Reply Quote 0
              • M
                mdima last edited by

                I was investigating a little more. The plugin used by the Snort package is spoink.
                In the file spo_pf.c, function AlertPf, it would be easy to duplicate the same algorithm used for the source IP also for the destination IP.
                This algorithm:

                1. Tries to get the source IP
                2. See if the IP is not in white list
                3. If not, blocks the IP

                if this would be applied to both source and destination IP (5 lines of code) it would solve the problem. I think, but better to ask it should not have side effects.

                What you all think about that?

                1 Reply Last reply Reply Quote 0
                • marcelloc
                  marcelloc last edited by

                  An easier way is to fill src and dst on rule.

                  Last century ;) I wrote a perl script that 'tails -f snort logs' and block offenders based on categories and ip.

                  If whe are looking to change alert_pf whe may include a feature to block hard attacks and not all alerts/logs

                  Treinamentos de Elite: http://sys-squad.com

                  Help a community developer! ;D

                  1 Reply Last reply Reply Quote 0
                  • M
                    mdima last edited by

                    @marcelloc:

                    An easier way is to fill src and dst on rule.

                    Last century ;) I wrote a perl script that 'tails -f snort logs' and block offenders based on categories and ip.

                    If whe are looking to change alert_pf whe may include a feature to block hard attacks and not all alerts/logs

                    hehe! Yes, me too… when I had a different firewall I was saving the Snort alerts on a SQLServer, then I made a program that was parsing the alerts and insert the "ban list" for the firewall. But this is a complex system and actually I don't know how to do that on FreeBSD.

                    I try to post a task in redmine, I see what the guys tell me!

                    1 Reply Last reply Reply Quote 0
                    • D
                      digdug3 last edited by

                      I too have the same problem.

                      Isn't it possible to allways block the destination ip on one interface? So I can block destination ip-s on my LAN and source ip-s on the WAN interface…

                      1 Reply Last reply Reply Quote 0
                      • First post
                        Last post