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

    Taming the beasts… aka suricata blueprint

    Scheduled Pinned Locked Moved IDS/IPS
    504 Posts 64 Posters 299.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.
    • R
      Ramosel
      last edited by

      @fsansfil:

      Unless you are writing your own rules or you are an ISP dealing with 30k users, right now you are better with Snort than Suricata. Using ET open and Snort VRT rulesets, youll get more coverage of threat protection with Snort (All VRT rules compatible with the engine)

      There was talk (here and elsewhere) many months back that Snort as a long term product was dead… or dying... in the wake of Suricata and its resources.  Has there been a change to that thought?  New people involved?

      Just curious?

      Rick

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

        @Ramosel:

        There was talk (here and elsewhere) many months back that Snort as a long term product was dead… or dying... in the wake of Suricata and its resources.  Has there been a change to that thought?  New people involved?

        Just curious?

        Rick

        I think a couple of things have happened.  First, thus far the Cisco purchase of Snort has not resulted in the open source project side being squashed.  That was a fear early on after the purchase.  Second, Snort 3.0-BETA supports multi-threading.  So once v3.0 goes from BETA to RELEASE, the argument about Suricata's performance advantages will lose some steam.

        I think both systems are fine.  Each has its own unique features.  Suricata can grab and log a lot more information than Snort can at the moment (all the JSON stuff, TLS cert exchanges, etc.), but Snort sports the new OpenAppID functionality.

        Bill

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

          New user here, bear with me.

          Following the first post and reading it over and over, I don't understand the part about floating rules.

          Here's what I did(also see screenshots)

          1. Created new interface called DMZ(did this to test on my current system)
          2. Created Floating Rule, as described, but ONLY for the interface DMZ
          3. Created allow rule for everything on the interface tab for DMZ(started out with DNS only, but nothing went through, so I changed it to any)

          Testing with ping = failed
          Testing NSLOOKUP = failed

          When disabling the floating rule, all traffic pass, as expected.

          I'm sure it's me messing this up in some way, but I don't see how/why.

          Assistance greatly appreciated.
          BR Jim

          interface_tab.png
          interface_tab.png_thumb
          floating.png
          floating.png_thumb
          host_timeout.png
          host_timeout.png_thumb
          floating_DISABLED.png
          floating_DISABLED.png_thumb
          logs.png
          logs.png_thumb

          Best regards
          Jim

          Still learning, correct me if I'm wrong please.

          1 Reply Last reply Reply Quote 0
          • ?
            A Former User
            last edited by

            Can I see a screenshot of the floating rule in question?

            If you are talking about the "block all" floating rule, it should only apply to traffic destined for pfsense's ports (that's why there is a giant red warning under it).

            1 Reply Last reply Reply Quote 0
            • A
              awsiemieniec
              last edited by

              Thank you for the post - I've been walking through it and adjusting as necessary.  I have a server at a colo accessed via a tunnel so some adjustment is necessary.

              About that floating rule, the first one your mention where you write in large red "DON'T CHANGE DESTINATION PORT RANGE!!!".  If I follow that example EXACTLY as you write it, rule #1  :P, then I end up blocking all outgoing traffic.  Here is  the float rule: (attached)  Do you really intend to block ALL?  I'm corn-fused?!  Maybe I missed a step?

              Thx.

              Floating.png
              Floating.png_thumb

              1 Reply Last reply Reply Quote 0
              • ?
                A Former User
                last edited by

                Most common question I had to answer so far  ;D

                The rule you show will block all traffic.

                The rule you want will block all traffic destined for pfsense's ports!. That's where the "don't change ports" part comes in.

                Adjust that rule to destination pfsense's ports and it will be OK  ;)

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

                  @jflsakfja:

                  Can I see a screenshot of the floating rule in question?

                  If you are talking about the "block all" floating rule, it should only apply to traffic destined for pfsense's ports (that's why there is a giant red warning under it).

                  Thanks for your reply. I guess the post above concerns the same confusion. Don't get me wrong, but you write the following:

                  Next up Floating tab:
                  Set up a rule but make these changes:
                  Action  Block
                  Quick  TICKED!!!
                  Interface  Hold CTRL and click on all interfaces EXCEPT LAN(admin) and SYNC
                  Direction  any
                  Source  any
                  Destination  any

                  If you read this directly(as I did, since I'm absolute beginner), your rule will block everything in/out on all interfaces, except "LAN".

                  I did this, and got confused. I could not wrap my head around, how on earth a Floating block ANY ANY ANY to all interfaces would possibly allow any traffic to pass through.

                  My suggestion is to clarify(maybe more red big letters) that this floating block rule is ONLY for the ports you specify as being web interface and SSH(which makes good sense).

                  Thanks for your guide, I'm looking forward to following the next steps.

                  BR Jim

                  Best regards
                  Jim

                  Still learning, correct me if I'm wrong please.

                  1 Reply Last reply Reply Quote 0
                  • ?
                    A Former User
                    last edited by

                    I agree, the text is a bit confusing, but it was meant to say "you created the rule, now head over to the floating tab and set up an identical rule to it, making these changes".

                    It's getting changed in the next version anyways (since I can't edit old posts) when I finally find the time to finish it. Caught up with work (a LOT of it) these days, and the guide is pushed back on my priorities list.

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

                      Sounds great, thanks for the clarification. Couldn't wrap my head around that weird floating rule :)

                      Looking forward to Version2  8)

                      Best regards
                      Jim

                      Still learning, correct me if I'm wrong please.

                      1 Reply Last reply Reply Quote 0
                      • L
                        lrosenman
                        last edited by

                        Ok – reading through 28(!) pages is not my idea of fun. Is there a good summary for current (May, 2015) setups from scratch on 2.2.2 of PFSense, and using Suricata and any other helpful stuff for a colo'd LAN offering services to folks on the Internet?

                        1 Reply Last reply Reply Quote 0
                        • ?
                          A Former User
                          last edited by

                          Not currently, something is being worked on  :)

                          1 Reply Last reply Reply Quote 0
                          • S
                            SixXxShooTeR
                            last edited by

                            @jflsakfja:

                            Not currently, something is being worked on  :)

                            Cant wait!

                            1 Reply Last reply Reply Quote 0
                            • P
                              pfcode
                              last edited by

                              Hi, jflaskfja

                              Thanks for offering the ruleset settings, I got them from https://github.com/jflsakfja/suricata-rules/blob/master/list.txt,  But I have 2 questions:

                              Question1: when I go to setup (enable/disable) the rules, I saw some of them have been disabled ORIGINALLY,  Should I enable them all first before following your instructions in the list?  or Should I keep them as is then disable what were mentioned in the list?

                              Question2: I can't find some rule#, like:

                              emerging-attack_response > all except:
                              2100498 GPL ATTACK_RESPONSE id check returned root <<< Based on plaintext value. False positive on http://planet.suricata-ids.org/

                              DISABLED:1

                              is that because I used Balanced Policy?

                              Release: pfSense 2.4.3(amd64)
                              M/B: Supermicro A1SRi-2558F
                              HDD: Intel X25-M 160G
                              RAM: 2x8Gb Kingston ECC ValueRAM
                              AP: Netgear R7000 (XWRT), Unifi AC Pro

                              1 Reply Last reply Reply Quote 0
                              • ?
                                A Former User
                                last edited by

                                Apologies for the late reply, but I was involved in a double car accident. Almost snapped my neck, spent two weeks immobilized in a hospital bed.

                                @all: don't expect me to be active these days. I'm mostly in and out of bed recovering from a series of injuries throughout my body.

                                @pfcode:

                                1. Yes, enable all, even originally disabled rules. Then go through the list and disable those mentioned.

                                2. Rules that cannot be found are rules that were deleted upstream (ET). In that case, please ignore them.

                                1 Reply Last reply Reply Quote 0
                                • P
                                  pfcode
                                  last edited by

                                  @jflsakfja:

                                  Thanks much,  Sorry about your car accident,  Feel better!

                                  Release: pfSense 2.4.3(amd64)
                                  M/B: Supermicro A1SRi-2558F
                                  HDD: Intel X25-M 160G
                                  RAM: 2x8Gb Kingston ECC ValueRAM
                                  AP: Netgear R7000 (XWRT), Unifi AC Pro

                                  1 Reply Last reply Reply Quote 0
                                  • stephenw10S
                                    stephenw10 Netgate Administrator
                                    last edited by

                                    Wow, just read this.  :o

                                    I wish you a speedy recovery.

                                    Steve

                                    1 Reply Last reply Reply Quote 0
                                    • C
                                      Cino
                                      last edited by

                                      speed recovery jflsakfja!!

                                      1 Reply Last reply Reply Quote 0
                                      • SoloamS
                                        Soloam
                                        last edited by

                                        fast recovery jflsakfja!!!

                                        1 Reply Last reply Reply Quote 0
                                        • N
                                          nug
                                          last edited by

                                          Firstly to jflsakfja, sorry to hear about your accident.  I hope you're OK!

                                          So I've finally made it through the 29 pages (the first few I had to read quite a few times) and I still have a couple of noob questions.

                                          1. I'm getting quite a few "ET SCAN NMAP -sS window 1024" alerts (among others) in my logs.  It adds the IP to the block list of Suricata, which is great.  But I continue to get these scans from the same IP.  Does this mean the blocking isn't quite happening or am I just being alerted that the scan is being attempted?  I would have thought if the block was there it wouldn't be getting any packets through at all?

                                          2. Just in case, I manually added some of these IPs into an IP Alias to block on the floating tab in through WAN and out of LAN.  Is there a way of having Suricata automatically add IPs into a permanent block list Alias or something?  Even adding these rules manually I still get the alert in Suricata, which again I would have thought the firewall would block the packets way before Suricata would be seeing anything.

                                          3. The default settings are to block hosts for 1 hour within Suricata.  Is there a particular reason why you wouldn't block them permanently?

                                          Apologies if these are stupid questions!

                                          1 Reply Last reply Reply Quote 0
                                          • ?
                                            A Former User
                                            last edited by

                                            You are still seeing alerts because of the way snort/suricata work on pfsense. Follow the next steps through, and you will understand why.

                                            1. A packet comes in on your WAN interface
                                            2. A copy of that packet is immediately made, and passed on to snort/suricata
                                            3. pf decides what to do with the packet
                                            4. snort/suricata decides what to do with the copy of the packet
                                            5. If rules allow it, pf passes on the packet to your LAN interface
                                            6. If snort/suricata rules call for an alert, an alert is generated
                                            7. The original packet has likely reached its destination
                                              8 ) The offending IP is added by snort/suricata (actually no, but good enough) to the blocked table.

                                            The most important part is 2: that shows exactly how snort/suricata work, and why alerts are generated. Fast forwarding another round of that list, shows that by the time pf decides that a second packet from the offender should be blocked, snort/suricata already sees the copy of that packet, re-generating an alert. As you can see, no matter what you do, the alerts will always be generated.

                                            The only 2 ways to stop those alerts is by using an upstream router to block packets from that IP, or using BPF to tell suricata to not inspect packets from those IPs, which is not currently supported nor encouraged (last time I tried it on my 4 million permanently banned IPs, the box crashed, on smaller lists suricata start up took a day or so).

                                            You don't have to worry about the alerts being generated. That does not mean that packets are passing, they could be blocked and the alert will still be generated on the copy of the packet.

                                            I like to set up the ban time as 28 days. Offenders (including so-called "state sponsored hax0rz") being mostly script kiddies they will come again with a packet that will generate an alert within that timeframe. The bonus of having snort/suricata work the way they do now, is that once an attacker generates an alert, and he keeps on coming, he will be perpetually banned. Each time an alert is generated, the timestamp for that IP is updated, which means resetting the timer back to 28 days.

                                            Every now and then, manually inspect the snort/suricata blocked list, and decide on what to do. For example if a number of IPs from a certain /24 subnet are always there, they get added to a permanently banned list, that is used in a rule on all interfaces (block WAN side, reject LAN side). Not that it stops the alerts, but in case the blocked list is flushed (eg reboot?) the IPs are still banned.

                                            @all: thanks for the wishes. Slowly recovering :-)

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