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

    Snort cant Detection Allert

    Scheduled Pinned Locked Moved IDS/IPS
    23 Posts 3 Posters 2.4k 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.
    • E
      ezvink
      last edited by

      this is an example of suricata that can detect attack alerts

      c6f1b8de-aa23-4562-a445-bc0dbbb181ff-image.png

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

        @ezvink said in Snort cant Detection Allert:

        this is an example of suricata that can detect attack alerts

        c6f1b8de-aa23-4562-a445-bc0dbbb181ff-image.png

        These are not true "attack alerts". They are simple protocol anomaly alerts likely caused by running the interface in promiscuous mode within a VM host. The Suricata engine is seeing a portion of the three-way TCP handshake but not all of it, and since it only sees one side of the conversation, it flags it. Snort does not have rules such as this, thus you don't see the same protocol anomaly alerts with Snort.

        And notice that with these alerts from Suricata the direction is reversed from your Snort test. Your screenshot for Snort indicates 172.16.120.5 is the SRC and 192.168.12.5 is the DST. But looking at the Suricata alert log entries above, the SRC and DST are reversed. So it was not the same traffic that triggered the rule.

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

          @ezvink said in Snort cant Detection Allert:

          I have a problem with the snort that I installed, the snort that I installed could not detect the attack that I did.

          even though I did the same thing on suricata it worked, the rules set for portforward, the rules, and the rules on suricata/snort were all the same.

          but in contrast to suricata it worked whereas i did in snort it failed.

          can anyone help to solve this problem?
          ea41d344-a5ed-43af-967a-193c5231c16d-image.png
          675be788-55f9-4d2e-8197-1caaa105335f-image.png
          b59392a7-a3eb-49f4-8ef3-1f3dca9bd483-image.png
          989a4eb7-9455-470d-8535-e0074635b7f1-image.png
          6fa0c77f-2663-4227-8b6c-d3e6b412d968-image.png
          31ad513d-c268-48af-b017-d09646d75dc8-image.png
          84b0e3de-d70e-47d5-9f24-3947c5520b07-image.png

          What specific Snort rule are you expecting to fire with this test?

          Have you checked the rule or rules you are testing to see how the HOME_NET and EXTERNAL_NET variables might come into play? The majority of Snort rules make use of HOME_NET and EXTERNAL_NET as conditionals that determine whether a given rule will fire or not. If the traffic direction and IP subnet does not match up with what the HOME_NET and EXTERNAL_NET variables are set for, then the rule will not fire.

          My suspicion, based on the screen captures you posted from Snort and Suricata, is that you are not taking HOME_NET and EXTERNAL_NET into account when testing. And you should also identify which exact rule you expect to trigger with your hping3 test. Once you know that rule, check how it expects HOME_NET and EXTERNAL_NET to be configured.

          johnpozJ E 2 Replies Last reply Reply Quote 0
          • johnpozJ
            johnpoz LAYER 8 Global Moderator @bmeeks
            last edited by

            @bmeeks where is this 192.168.66.5 - that is not even listed as network on pfsense..

            Those alerts look like acks back to 172.16.120.5 where he was sending the syns from - but but why is where he sent them 192.168.12.5 sending them back from 192.168.66?

            An intelligent man is sometimes forced to be drunk to spend time with his fools
            If you get confused: Listen to the Music Play
            Please don't Chat/PM me for help, unless mod related
            SG-4860 24.11 | Lab VMs 2.8, 24.11

            bmeeksB E 2 Replies Last reply Reply Quote 0
            • bmeeksB
              bmeeks @johnpoz
              last edited by

              @johnpoz said in Snort cant Detection Allert:

              @bmeeks where is this 192.168.66.5 - that is not even listed as network on pfsense..

              Those alerts look like acks back to 172.16.120.5 where he was sending the syns from - but but why is where he sent them 192.168.12.5 sending them back from 192.168.66?

              Oops! You're right. I misread that 192.168.66.x as a 192.168.12.x. Did not pay close enough attention.

              johnpozJ 1 Reply Last reply Reply Quote 0
              • johnpozJ
                johnpoz LAYER 8 Global Moderator @bmeeks
                last edited by

                @bmeeks Something really odd with this whole setup.

                He has something all messed up with vm, natting etc.. I believe this is the same poster that couldn't get anything to even talk to each other, etc.

                So who knows what mess he has.. But i agree with you - out of state traffic isn't something snort would be alerting on, etc.

                An intelligent man is sometimes forced to be drunk to spend time with his fools
                If you get confused: Listen to the Music Play
                Please don't Chat/PM me for help, unless mod related
                SG-4860 24.11 | Lab VMs 2.8, 24.11

                1 Reply Last reply Reply Quote 0
                • E
                  ezvink @johnpoz
                  last edited by

                  @johnpoz
                  IP 192.168.66.5 that is the IP for the web server sir, I distinguish the IP.
                  for snort : IP web server : 192.168.12.5
                  Attacker IP : 172.16.120.5
                  for suricata : IP web server : 192.168.66.5
                  Attacker IP : 172.16.120.5

                  1 Reply Last reply Reply Quote 0
                  • E
                    ezvink @bmeeks
                    last edited by

                    @bmeeks
                    then what kind of configuration sir so that my snort can detect attacks? I've tried following the tutorial on youtube and it didn't work.
                    I followed this video tutorial https://www.youtube.com/watch?v=eDbNVSVoVQM&t=1737s

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

                      @ezvink said in Snort cant Detection Allert:

                      @bmeeks
                      then what kind of configuration sir so that my snort can detect attacks? I've tried following the tutorial on youtube and it didn't work.
                      I followed this video tutorial https://www.youtube.com/watch?v=eDbNVSVoVQM&t=1737s

                      I can't tell you what configuration you need because I did not configure your current setup. I don't know what you have connected to what.

                      You also did not tell me which Snort rule you expected to trigger with your attacker traffic. Do you know what rule you expected to fire?

                      E 2 Replies Last reply Reply Quote 0
                      • E
                        ezvink @bmeeks
                        last edited by

                        @bmeeks
                        this is the topology i use sir.

                        39aa2df2-e139-4314-993b-ab6909ffa2ba-image.png

                        johnpozJ 1 Reply Last reply Reply Quote 0
                        • E
                          ezvink @bmeeks
                          last edited by

                          @bmeeks
                          I will attack the web server, sir, using VM Attacker.

                          the web server can be accessed by the attacker, and the attack has been successful but snort does not detect the attack.

                          I want to activate the DDOS, PORTSCANNING, BRUTEFORCE rules sir

                          bmeeksB 1 Reply Last reply Reply Quote 0
                          • johnpozJ
                            johnpoz LAYER 8 Global Moderator @ezvink
                            last edited by johnpoz

                            @ezvink If that is your config - where did 192.168.66.5 come from??

                            66.jpg

                            Clearly that is NOT your setup..

                            That alert is not a syn flood which is what you were sending, it is saying its seeing out of state ack.

                            An intelligent man is sometimes forced to be drunk to spend time with his fools
                            If you get confused: Listen to the Music Play
                            Please don't Chat/PM me for help, unless mod related
                            SG-4860 24.11 | Lab VMs 2.8, 24.11

                            E 1 Reply Last reply Reply Quote 1
                            • bmeeksB
                              bmeeks @ezvink
                              last edited by

                              @ezvink said in Snort cant Detection Allert:

                              @bmeeks
                              I will attack the web server, sir, using VM Attacker.

                              the web server can be accessed by the attacker, and the attack has been successful but snort does not detect the attack.

                              I want to activate the DDOS, PORTSCANNING, BRUTEFORCE rules sir

                              Looking at your posted diagram, if you used the default settings for the HOME_NET and EXTERNAL_NET variables, then most likely the rules are not going to trigger because one of their main conditionals will not be true -- the location and direction of the attack traffic does not satisfy the HOME_NET / EXTERNAL_NET condition. Most rules of the sort you want to trigger have the following main conditional:

                              $EXTERNAL_NET --> $HOME_NET

                              This means the attacking address sourcing the traffic must be on a network that is included in EXTERNAL_NET. In the default setup, EXTERNAL_NET is defined as as !HOME_NET (which means all addresses NOT included in HOME_NET). HOME_NET automatically includes all subnets defined on the firewall's local interfaces. So your attacker is within HOME_NET and thus the condition of the rule is not satisfied and it will not trigger.

                              Since you are a student and this is your class assignment (according to what you have posted in the past), take some time and research on Google how IDS/IPS works paying particular attention to the variables HOME_NET and EXTERNAL_NET in Snort and Suricata. Learn what they mean and what they are used for. Then look at the actual rule text and notice how in most of the rules $HOME_NET and $EXTERNAL_NET are present as conditions that are part of the rule's triggering logic.

                              The Suricata alerts you posted are not attack detections. They are simply from protocol anomalies and come from the built-in stream events rules packaged with Suricata. Those rules do not use HOME_NET and EXTERNAL_NET as conditionals. They simply look for anomalies in all traffic. Thus they will alert no matter if the addresses are in HOME_NET or EXTERNAL_NET.

                              As a student you need to actually learn how all this works and understand the underlying theory in order to be effective as an IDS/IPS admin. Simply finding some step-by-step guide like a YouTube video telling you exactly what to click and type is not going to do that.

                              E 1 Reply Last reply Reply Quote 1
                              • E
                                ezvink
                                last edited by

                                I've added this rule, but still, Mr. Snort doesn't detect the attack I'm doing.

                                alert tcp $HOME_NET any -> $HOME_NET any (flags: S; msg:" Manual rule DoS flood"; flow:established; detection_filter: track by_src, count 60, seconds 10; sid:99901; rev:1;)

                                1 Reply Last reply Reply Quote 0
                                • E
                                  ezvink @bmeeks
                                  last edited by

                                  @bmeeks
                                  can you help me to finish this project sir? please give me a way to complete this project so that both can detect attacks correctly, I've read articles about HOME_NET and EXTERNAL_NET but it doesn't help sir.
                                  In my learning method, I have to find the right examples before I can explore the material.

                                  I hope you can help me to finish this project sir

                                  1 Reply Last reply Reply Quote 0
                                  • E
                                    ezvink @johnpoz
                                    last edited by

                                    @johnpoz
                                    IP 192.168.66.5 is the IP of the web server sir, I just differentiated it but it's still the same VM

                                    1 Reply Last reply Reply Quote 0
                                    • E
                                      ezvink @bmeeks
                                      last edited by

                                      @bmeeks
                                      when I did nmap it worked sir, IP 192.168.12.5 web server IP 172.16.120.5 Attacker

                                      so what's wrong?
                                      a8f18c38-5166-48f8-ab58-659a9592a080-image.png

                                      johnpozJ bmeeksB 2 Replies Last reply Reply Quote 0
                                      • johnpozJ
                                        johnpoz LAYER 8 Global Moderator @ezvink
                                        last edited by

                                        @ezvink what is wrong with what? For your ips/ids to detect a flood of syn packets you sent.. For starters a rule that triggers on whatever your sending has to be enabled, and it has to be enabled on whatever interface your sending the traffic thru, and to what your destination is, etc.

                                        You show some rules categories you selected - but is anything in there, were they in your policy you set, were they activated, etc.

                                        What specific rule did you think your syn flood sent using hping3 was going to trigger?

                                        An intelligent man is sometimes forced to be drunk to spend time with his fools
                                        If you get confused: Listen to the Music Play
                                        Please don't Chat/PM me for help, unless mod related
                                        SG-4860 24.11 | Lab VMs 2.8, 24.11

                                        1 Reply Last reply Reply Quote 1
                                        • bmeeksB
                                          bmeeks @ezvink
                                          last edited by

                                          @ezvink said in Snort cant Detection Allert:

                                          @bmeeks
                                          when I did nmap it worked sir, IP 192.168.12.5 web server IP 172.16.120.5 Attacker

                                          so what's wrong?
                                          a8f18c38-5166-48f8-ab58-659a9592a080-image.png

                                          What specific nmap command did you execute to generate the above alerts?

                                          You must have a good idea of which specific rule or rules you want your "attack" to trigger. So as @johnpoz asked, which specific rules are you targeting with your hping3 command? Put the GID:SID and text of that rule in your post so we can examine the conditions the rule expects. Perhaps the traffic you are generating does not match all of the conditions in the rule.

                                          E 1 Reply Last reply Reply Quote 0
                                          • E
                                            ezvink
                                            last edited by

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