Pfsense has 40 percent free ram and 10 percent swap usage



  • Quick question.  I'm not sure if this is the right category to post in.  Anyway.

    I have a small VM with only about 1.25GB Ram allocated and only added package is Suricata.

    It is running wonderfully and not showing any ill effects at all but for some reason it shows between 8% and 10% swap usage even though its not acting like any machine I've ever seen using swap.  No problems at all.  Just wondering if this is something weird or often seen?  I'm not used to seeing swap usage when nearly half the RAM is free on a machine.  Not complaining at all.  Its running fine.

    last pid: 34413;  load averages:  1.01,  0.86,  0.72  up 0+02:00:17    11:43:12
    41 processes:  1 running, 40 sleeping

    Mem: 156M Active, 386M Inact, 82M Laundry, 486M Wired, 77M Buf, 94M Free
    Swap: 410M Total, 30M Used, 380M Free, 7% Inuse

    PID USERNAME    THR PRI NICE  SIZE    RES STATE  C  TIME    WCPU COMMAND
    77375 root          7  21    0  1000M  539M nanslp  0  8:20  1.86% suricata
    7123 root          1  27    0  263M 30064K piperd  0  0:00  1.86% php-fpm
    14329 root          1  20    0 20348K  5308K select  1  2:10  0.00% openvpn
      306 root          1  20    0  261M 18460K kqread  1  0:10  0.00% php-fpm
    43365 root          1  52  20 13084K  968K wait    0  0:08  0.00% sh
    22324 root          5  24    0 13028K  2240K uwait  1  0:07  0.00% dpinger
    31128 root          1  20    0 37704K  7644K kqread  0  0:06  0.00% nginx
    17601 root          1  20    0 12696K  1996K bpf    0  0:04  0.00% filterlog
    30837 root          1  20    0 37704K  4872K kqread  0  0:03  0.00% nginx
    32150 root          1  20    0 24604K 12424K select  1  0:02  0.00% ntpd
    16644 root          1  20    0 20348K  5252K select  0  0:02  0.00% openvpn
    87639 root          1  20    0 10472K  2512K select  0  0:01  0.00% syslogd
    92561 dhcpd        1  20    0 16648K  7696K select  1  0:01  0.00% dhcpd
    10824 _dhcp        1  20    0 10528K  2052K select  1  0:01  0.00% dhclient
    31597 root          1  52    0 12496K  664K nanslp  1  0:01  0.00% cron
    23110 nobody        1  20    0 31868K  2860K select  1  0:00  0.00% dnsmasq
    11435 root          1  52    0 39432K    0K wait    1  0:00  0.00% <login>320 root          1  40  20 19436K  1144K kqread  0  0:00  0.00% check_reload_status</login>



  • @kejianshi:

    Quick question.  I'm not sure if this is the right category to post in.  Anyway.

    I have a small VM with only about 1.25GB Ram allocated and only added package is Suricata.

    It is running wonderfully and not showing any ill effects at all but for some reason it shows between 8% and 10% swap usage even though its not acting like any machine I've ever seen using swap.  No problems at all.  Just wondering if this is something weird or often seen?  I'm not used to seeing swap usage when nearly half the RAM is free on a machine.  Not complaining at all.  Its running fine.

    last pid: 34413;  load averages:  1.01,  0.86,  0.72  up 0+02:00:17    11:43:12
    41 processes:  1 running, 40 sleeping

    Mem: 156M Active, 386M Inact, 82M Laundry, 486M Wired, 77M Buf, 94M Free
    Swap: 410M Total, 30M Used, 380M Free, 7% Inuse

    PID USERNAME    THR PRI NICE  SIZE    RES STATE  C  TIME    WCPU COMMAND
    77375 root          7  21    0  1000M  539M nanslp  0  8:20  1.86% suricata
    7123 root          1  27    0  263M 30064K piperd  0  0:00  1.86% php-fpm
    14329 root          1  20    0 20348K  5308K select  1  2:10  0.00% openvpn
      306 root          1  20    0  261M 18460K kqread  1  0:10  0.00% php-fpm
    43365 root          1  52  20 13084K  968K wait    0  0:08  0.00% sh
    22324 root          5  24    0 13028K  2240K uwait  1  0:07  0.00% dpinger
    31128 root          1  20    0 37704K  7644K kqread  0  0:06  0.00% nginx
    17601 root          1  20    0 12696K  1996K bpf    0  0:04  0.00% filterlog
    30837 root          1  20    0 37704K  4872K kqread  0  0:03  0.00% nginx
    32150 root          1  20    0 24604K 12424K select  1  0:02  0.00% ntpd
    16644 root          1  20    0 20348K  5252K select  0  0:02  0.00% openvpn
    87639 root          1  20    0 10472K  2512K select  0  0:01  0.00% syslogd
    92561 dhcpd        1  20    0 16648K  7696K select  1  0:01  0.00% dhcpd
    10824 _dhcp        1  20    0 10528K  2052K select  1  0:01  0.00% dhclient
    31597 root          1  52    0 12496K  664K nanslp  1  0:01  0.00% cron
    23110 nobody        1  20    0 31868K  2860K select  1  0:00  0.00% dnsmasq
    11435 root          1  52    0 39432K    0K wait    1  0:00  0.00% <login>320 root          1  40  20 19436K  1144K kqread  0  0:00  0.00% check_reload_status</login>

    Suricata can be a bit RAM hungry, especially during rule updates when it basically loads two copies of the rules in memory (the current set and the new set) and then switches over to using the newest set and dumps the old ones from RAM.  Not saying that is definitely the cause here, but it is a suspect.  1.25 GB is really not what I would consider ideal for Suricata unless you are running a very limited rule set.  I would want at least 2 GB, and really more like 4 GB for most cases.

    Bill



  • I think what you said makes perfect sense.  If it gets anywhere near 1.25gb its only for the tinyest split fraction of a second because I've never seen it exhaust memory.

    So, it seems that whatever gets into that swap is very very very temporary.  Thanks for the Hypothesis.

    I'm going to keep running it this way unless I actually experience some ill effects.

    The inline IPS is working very well by the way.  I've had no hangs, drops or slow-downs.



  • BTW - I have a lot of rules…  I'm not worried about the fraction of a second pause that might occur every 12 or 24 hours, just as long as 99.99% of the time it is humming along fine.  The only thing I don't like about inline mode so far is I can't tell easily what is dropped and what is just alerted.

    I know that things that generate a drop should turn red in the alerts.

    I also know that I told it to drop anything that generated an alert, so I'm wondering which of those two things it isn't doing / showing me.


  • Rebel Alliance Developer Netgate

    In general that also isn't anything to worry about. One of the common BSD mantras is "Free RAM is wasted RAM". The OS will swap things that are not in use so it can use RAM to speed up other processes, for caching, etc. It will reallocate things as needed when the requirements shift.

    Now if you see no free RAM and your swap space is also nearly/completely full, then it's time to worry.



  • Yep - Thats also my mantra.  And free cycles are wasted cycles…  I'm actually experimenting to see how small I can make it and have it work well.  I think I'm there already.

    Still wondering if those alerts are getting blocked since thats what I told it to do.  No red in the alerts so far.





  • @kejianshi:

    Mem: 156M Active, 386M Inact, 82M Laundry, 486M Wired, 77M Buf, 94M Free
    Swap: 410M Total, 30M Used, 380M Free, 7% Inuse

    PID USERNAME    THR PRI NICE  SIZE    RES STATE  C  TIME    WCPU COMMAND
    77375 root          7  21    0  1000M  539M nanslp  0  8:20  1.86% suricata

    Looks like suricata is trying to use nearly 1GiB of memory. Your total memory usage may be low right now, but most OS's only page in data when the data is requested and only page out when there is not enough free space. If at any moment there was not enough memory, some of the data would get paged out, and assuming the data never got referenced again, it would forever live in swap.



  • Yep - Saw that.  But throughput seems fine and its definitely throwing all the alerts you would expect.

    Still if anyone can enlighten me.  Is the alerted traffic being dropped like it should be?



  • @kejianshi:

    Yep - Saw that.  But throughput seems fine and its definitely throwing all the alerts you would expect.

    Still if anyone can enlighten me.  Is the alerted traffic being dropped like it should be?

    If it's red on the ALERTS tab, then it was dropped.  If you look at the Suricata alerts log for the interface you will see the word "[drop]" as the first word of the alert message.  The Suricata binary does not log drops unless you enable the drop log in the EVE JSON output options.  However, those options are for exporting to an external log collector and the Suricata GUI package does not use them for display.

    Bill



  • OK, I guess I'm a little slow.

    So, when something like this appears in my lalerts ist:

    Date Pri Proto Class Src SPort Dst DPort GID:SID Description
    11/14/2017
    22:19:57 2 TCP Misc Attack 46.17.46.77
      57669 192.168.10.14
      7777 1:2403325
      ET CINS Active Threat Intelligence Poor Reputation IP group 26
    11/14/2017
    22:19:57 2 TCP Misc Attack 46.17.46.77
      57669 192.168.10.14
      7777 1:2402000
      ET DROP Dshield Block Listed Source group 1
    11/14/2017
    22:01:53 2 TCP Misc Attack 109.248.9.241
      58625 192.168.10.14
      7777 1:2402000
      ET DROP Dshield Block Listed Source group 1

    Its not dropped?  Even Though its on the "Block List"?

    And even though this block is check?

    OK - I mean, if its not dropping packets under those conditions, what must one do to get a packet dropped?



  • Now, the very instant I take it out of "Inline" mode, it starts dropping that very same traffic that was listed in my alerts previously, but not highlighted in red.

    So I guess my question is now, in inline mode is it dropping the packets and simply not showing them in red?

    Or

    Is it not dropping the packets in inline mode because there is some difference between inline and legacy mode that makes legacy mode work better?

    Basically, it seems that legacy mode is blocking and inline mode isn't.  No crashes, no hangs, no weird symptoms.  No stopped suricata services.  I'm just not seeing the blocks in inline mode.



  • I notice that when you are in legacy mode, you have a choice to drop source, destination or both.

    In inline mode you don't have that choice apparently.  Anyway.  Am I missing something?

    Clearly inline mode would be the way to go, but without seeing some indication of drops somewhere, how can I feel confident with it?

    I expected crashes and hangs and stopped suricata process if there is a problem.  Didn't expect it to just ignore the rules and settings.



  • I'm assuming there is a way to get expected results in inline mode with suricada.  That 1 check box is the only difference between a config that seems to block well and one that doesn't.

    I've seen this work and I've seen this stop the suricata process on other physical machines.

    This is a VM and detection seems fine.  Just nothing is being blocked.

    Could it be that in inline mode that the packet is only getting dropped if the rule specifically includes drop?

    I see that "Block on Drop" option disappears when inline mode is enabled.

    "Checking this option will insert blocks only when rule signatures having the DROP action are triggered."

    Does this get automagically and invisibly applied in inline mode?  If so, that would explain alot.



  • I suspect you have a severe misconfiguration of your Suricata package when using Inline IPS Mode.  I believe you have a misunderstanding of rule names versus rule actions and the steps you must take as an admin to properly configure Inline IPS Mode.  If you have it configured like I think you do based on what you've posted, then you are in fact blocking nothing when using Inline IPS Mode.  Let me explain below.

    Rules have a particular syntax they are written in.  The very first word of the rule text is the "action" keyword and it can have one of four possible values.  Those four values are "pass, drop, reject or alert".  The default value for all rules from the vendors is "alert".  Here is an actual rule from the Emerging Threats rule set –

    
    alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS (msg:"ET MALWARE 180solutions (Zango) Spyware Local Stats Post"; flow:to_server,established; content:"/php/rpc_uci.php"; nocase; http_uri; reference:url,securityresponse.symantec.com/avcenter/venc/data/pf/adware.180search.html; reference:url,doc.emergingthreats.net/bin/view/Main/2003060; classtype:trojan-activity; sid:2003060; rev:5; metadata:created_at 2010_07_30, updated_at 2010_07_30;)
    
    

    Notice the very first word of the rule is "alert".  This means this rule will generate alerts.  When you use Inline IPS Mode and you want rules to drop or "block" traffic, you must change the action keyword from "alert" to "drop".  You can do this manually, but most folks use the tools on the SID MGMT tab to accomplish that automatically in batches.  You would put the rules (either by SID or category name) you want to drop traffic in the dropsid.conf file.

    Legacy Mode is totally different.  It is really a sort of kluge that leverages the pfSense firewall packet engine (pf) to block traffic.  It uses a custom plugin I wrote to insert offending IP addresses into a special firewall table.  More on that can be found here:  https://forum.pfsense.org/index.php?topic=135331.0.  Review the section describing how Legacy Mode and Inline IPS Mode operate.

    So in Legacy Mode, every single alert will always generate a block.  Legacy Mode never looks at the rule action keyword.  With Inline IPS Mode, only rules where you have changed the action keyword from "alert" to "drop" will actually block traffic.  Decoder rules (the ones in your list of stream alerts) only generate alerts (by default).  So using Inline IPS Mode they will alert but not block.  However, using Legacy Mode, since every alert equals a block, those decoder rules generate blocks.

    In your provided example you seem to imply that because you enabled the "ET DROP" rules category that those rules will generate drops.  They default to "alert" from the vendor.  You will need to put that category name in a dropsid.conf file on the SID MGMT tab, enable SID MGMT, and restart Suricata to have them actually drop traffic.

    Bill

    Edit:  fixed some typos



  • You are 100% correct that I believed I should be getting drops, but its because I was abit misled by the
    "Checking this option will automatically block hosts that generate a Suricata alert"

    If I'm understanding you correctly, that only applies to legacy mode?  If so, a note on the GUI would save lots of bewilderment.

    I was sort of hoping to avoid changing all those actions.  I knew they were there but thought it wouldn't matter because anything generating an alert was dropped.

    I'm clear on that now.  So, I'm going to head over to SIDS management and see if I can get this working inline.  Thanks for the enlightment.



  • Just for testing purposes, I'd love to know is there any short context I could enter in my drop file at sids management that would result in all rules causing dropped traffic?



  • ok - I really wanted to achieve the same behavior with suricata inline as I got with legacy mode, but without the possibility of leaks.

    bmeeks - Obviously a super expert.  Thanks so much for the tips.  Helped alot.

    So, in my SID management drop file I just put:

    pcre:"a"*
    pcre:"A"*
    pcre:"1"*

    all 26 lower case, then all 26 upper case, then all 10 digits…

    Now, every active  rule drops as expected.  All 20k of them.

    Not what Jesus would do, I know, but it is the behavior I was expecting to begin with.

    I will disable any rules that cause unwanted drops.

    Later, when I have time I will get rid of those wildcards, sit with it 15 hours a day for a month to tune it.

    Today, I just needed blocking working about the same as it did in inline mode.



  • @kejianshi:

    ok - I really wanted to achieve the same behavior with suricata inline as I got with legacy mode, but without the possibility of leaks.

    bmeeks - Obviously a super expert.  Thanks so much for the tips.  Helped alot.

    So, in my SID management drop file I just put:

    pcre:"a"*
    pcre:"A"*
    pcre:"1"*

    all 26 lower case, then all 26 upper case, then all 10 digits…

    Now, every active  rule drops as expected.  All 20k of them.

    Not what Jesus would do, I know, but it is the behavior I was expecting to begin with.

    I will disable any rules that cause unwanted drops.

    Later, when I have time I will get rid of those wildcards, sit with it 15 hours a day for a month to tune it.

    Today, I just needed blocking working about the same as it did in inline mode.

    This will work, abeit perhaps a little extreme …  :).  Glad to help.  I will add some hints text to the GUI in the blocking configuration section to clarify the difference in behavior between Legacy Mode and Inline IPS Mode.

    Bill



  • It is working extremely well for a day now.  Not much noise.  With very minimal work in terms of suppressing a few alerts, seems to be great.

    Now, as far as I can tell, every alert (There aren't many) and every drop is the result of someone doing something they shouldn't, so I like it.



  • OK - I have another dumb question.

    Under global settings for general settings, there is an option for remove blocked hosts.  I set it at 15 minutes just for now.

    My question is are IPs blocked for a length of time using inline mode?  Does this setting apply to inline mode?

    The reason I asked is because I kept noticing differences in behavior that makes me believe IPs don't get blocked for any length of time.

    Not saying that is a bad thing.  Suricata inline mode seems to block every instance of a rule violation.  It just doesn't seem to ban the IP for any defined period of time.

    So, just wondered if that setting will apply to inline mode.



  • @kejianshi:

    OK - I have another dumb question.

    Under global settings for general settings, there is an option for remove blocked hosts.  I set it at 15 minutes just for now.

    My question is are IPs blocked for a length of time using inline mode?  Does this setting apply to inline mode?

    The reason I asked is because I kept noticing differences in behavior that makes me believe IPs don't get blocked for any length of time.

    Not saying that is a bad thing.  Suricata inline mode seems to block every instance of a rule violation.  It just doesn't seem to ban the IP for any defined period of time.

    So, just wondered if that setting will apply to inline mode.

    A drop is not a block.  Go back and read that post I gave a link to in one of my earlier posts in this thread.  Your questions indicate you still do not understand how Inline IPS Mode works versus Legacy Mode.  The two mechanisms are completely different in implementation and result.  If you truly understood Inline IPS Mode, then the answer to this question would be self-evident –

    The reason I asked is because I kept noticing differences in behavior that makes me believe IPs don't get blocked for any length of time.

    Inline IPS Mode does not use the firewall engine at all, thus there is no "block" to remember.  The packet is simply discarded on its way from the NIC driver to the kernel's network stack.  This happens before the firewall engine has even seen the packet.  Consequently, there are no blocks to clear.  There is nothing to remember.  The only thing Suricata tracks is the current TCP session (if we're talking TCP packets).  Once a drop happens on a session, that session will continue to be dropped.  If another session attempts to fire up later, the same rule will detect it and drop it again.  With Inline IPS Mode, it is instructive to think of the drops as being like a little guy inside the RJ45 jack unplugging the network cable and stopping the packet from getting in when a drop rule fires.  The cable is then immediately plugged back in to let the next packet come in for inspection.

    Legacy Mode uses the packet filter firewall engine to do all the blocking.  It puts IP addresses in the special snort2c table and then pf (the pfSense packet filter firewall) blocks them.  When you look at IP addresses on the BLOCKED tab what you are really seeing is the contents of that snort2c table being displayed.  When a Legacy Mode block is cleared, that simply means the IP address (or all of them, if clearing all blocks) is removed from the snort2c table maintained by the pf packet filter.  To continue my "little guy" analogy from Inline IPS Mode above, in Legacy Mode the little guy calls up the Firewall Rules interface and inserts a new firewall rule to block the IP addresses pulled from the packet that caused a Suricata rule to fire.  Technically he just puts the IP address or addresses in that snort2c table, but it's still instructive to think of a custom firewall rule being created. That rule will stay there in the firewall until either the next reboot of the box, the admin clears the block manually on the GUI tabs in Suricata, or the cron job runs (configured in GLOBAL SETTINGS) and automatically removes the rule (again, by actually removing the IP address from the snort2c table).

    Bill



  • I get it.  I'm just trying to keep the language simple.  For my purposes, dropped is same as discarded, although I like your explanation.

    So, the answer then is that setting only impacts legacy mode.  OK.  I know you are going to note things in the GUI eventually.

    Specifically I was initially worried to see the same IPs showing up in alerts again in less than 15 minutes, but now I understand.

    So, inline is actually a bit less severe and less of a blunt instrument since it doesn't kill an IP for a while but rather evaluates every new packet against the rules?

    Very cool.  Thanks again.

    Since I've never had this working properly on hardware I am still getting used to what to expect.  So far so good.



  • The most immediate benefit I noticed right away in terms of differences between inline and legacy is that inline doesn't totally kill a machines ability to work just because it did one thing wrong, where as with legacy you would be offline for 15 minutes for every alarm triggered.  Less PITA.



  • So, when I built my private hardware pfsense years ago I insisted on using Intel Server nics.  So, After playing for a few days with my VM network (which is an actual every day used set of small servers), I felt confident to turn it on in the remote hardware pfsense I use pretty much 24/7 for VPN and file storage etc.  Works perfectly.  I'm very glad I installed those "overkill" network cards now.  Other than sucking down half the ram on the box, and finally pushing the cpu above idle, I've noticed nothing odd.  Its watching 3 LAN NICs and has no problem maxing out the ISPs bandwidth.

    I've heard lots of chatter here and there about how pfsense doesn't work with suricata well.  At this point, I can say for sure it works.  I think its just a matter of having compatible hardware.  Its not even breaking on my pitiful little VM I starved for resources.  Working like a champ.



  • @kejianshi:

    I get it.  I'm just trying to keep the language simple.  For my purposes, dropped is same as discarded, although I like your explanation.

    So, the answer then is that setting only impacts legacy mode.  OK.  I know you are going to note things in the GUI eventually.

    Specifically I was initially worried to see the same IPs showing up in alerts again in less than 15 minutes, but now I understand.

    So, inline is actually a bit less severe and less of a blunt instrument since it doesn't kill an IP for a while but rather evaluates every new packet against the rules?

    Very cool.  Thanks again.

    Since I've never had this working properly on hardware I am still getting used to what to expect.  So far so good.

    You have it now.  Inline is like a surgeon's scapel evaluating each packet and either passing that one packet or discarding it (a drop).  Legacy is more blunt, it simply puts the offending IP address in a pre-configured pf firewall table and that's it.  From that point on, all traffic from that IP is blocked until the IP is removed from the pf firewall table.

    The key benefit of Inline IPS Mode is that no packet leakage occurs.  Suricata will queue up and buffer the session until it has enough packets to analyze against the rule, and if the rule triggers and the action is drop, the whole queued up session is just dropped from Suricata's memory like it never happened.  The firewall and the rest of pfSense never see it.  Legacy Mode, on the other hand, is getting only copies of those packets as they exit the NIC on the way to the kernel.  So the original packets continue on to the firewall and the target host.  Only later, after Suricata evaulatues enough traffic, will the firewall block be added and the existing states cleared (if you enable that option when turning on Legacy Mode blocking).

    Bill



  • @kejianshi:

    I get it.  I'm just trying to keep the language simple.  For my purposes, dropped is same as discarded, although I like your explanation.

    So, the answer then is that setting only impacts legacy mode.  OK.  I know you are going to note things in the GUI eventually.

    I have some of the controls within the Blocking Configuration section on the INTERFACE SETTINGS tab hide themselves depending on what is selected in the blocking mode drop down.  I probably do need to put something on the GLOBAL SETTINGS tab in the help hint text for the Clear Blocked Hosts control.  I can't hide that setting, though, because folks may have different blocking configurations on different interfaces (like WAN using Inline IPS but LAN using Legacy, or some other variation).

    Bill



  • I find it to be much more forgiving to use than legacy mode so far.  It causes so little trouble I wasn't sure it was working!

    However, I've checked it by doing things I shouldn't and its working.  Pinging tor exit nodes, for instance, is a very simple way for me to be sure that not only does it seem to be working, but it is in fact working.  I was very happy to see it play nice with intel NICs that were not even very expensive on real hardware vs virtual.

    I think this is going to become "standard" for any decent firewall.

    I think you are on the right track with the "hints".  Just something for us not-experts so that we know what to expect.



  • @kejianshi:

    The most immediate benefit I noticed right away in terms of differences between inline and legacy is that inline doesn't totally kill a machines ability to work just because it did one thing wrong, where as with legacy you would be offline for 15 minutes for every alarm triggered.  Less PITA.

    The time before blocks are cleared in Legacy Mode is configurable to one of several intervals all the way up to NEVER.  I recommend something between 15 minutes and 1 hour, but there some users here who think NEVER is good.  I don't agree with that for the very reason you described.  One mistake in configuration by enabling a "too sensitive rule" and you are locked out of the firewall perhaps until you reboot it!  Shorter blocks clearing intervals help you recover painlessly from shooting yourself in the foot.

    Bill



  • When using legacy mode, my thinking was that 15 minutes is enough to make doing something bad to my servers so inconvenient and slow that the person would just give up and move on to easier targets.  Now, with inline mode I've had to rethink that.  The way its working now is much less "all or nothing".  Much less of me DDOSing myself.  A major improvement.



  • It is still running great, but as I run this I realize there is a small feature that would be nice to have.

    Right now you can suppress rules, which gets the noise off your alerts page, but also causes the rule to not drop anything.

    For things that really do need to be dropped, but at the same time are so constant that you don't want to look at them all the time in your log, it would be nice to be able to supress the alert, but not supress the "drop".

    That way, I could see if something new was chewing on the firewall without it being lost in a zillion alerts you know to expect already.

    An example of this is my son has a Chinese phone, and it is forever trying to contact Chinese servers and Chinese servers are forever trying to ping it.

    Its locked down.  I want it to keep doing its thing and dropping those packets, but I want that alert out of my face.

    Maybe a bridge too far?  Not sure.

    However, it is working great.



  • @kejianshi:

    It is still running great, but as I run this I realize there is a small feature that would be nice to have.

    Right now you can suppress rules, which gets the noise off your alerts page, but also causes the rule to not drop anything.

    For things that really do need to be dropped, but at the same time are so constant that you don't want to look at them all the time in your log, it would be nice to be able to supress the alert, but not supress the "drop".

    That way, I could see if something new was chewing on the firewall without it being lost in a zillion alerts you know to expect already.

    An example of this is my son has a Chinese phone, and it is forever trying to contact Chinese servers and Chinese servers are forever trying to ping it.

    Its locked down.  I want it to keep doing its thing and dropping those packets, but I want that alert out of my face.

    Maybe a bridge too far?  Not sure.

    However, it is working great.

    Unfortunately that's not a feature supported by the underlying binary source code of Suricata (dropping but not alerting).  To most folks that would be counter-intuitive any way.  You would have traffic being blocked but have no idea why it was blocked or by what if it was not logged.

    If you want to do detailed log analysis and have a high traffic network, you should consider one of the third-party open source tools out there that can accept EVE JSON logs from Suricata.  The alerts/drops get stored in a MySQL or equivalent database on a separate server and then analytics packages are run against the data to produce nice charts and reports with all sorts of filtering options available.

    Bill



  • I could probably filter out a list of known offenders to see what is new with a simple script.  Thanks.


 

© Copyright 2002 - 2018 Rubicon Communications, LLC | Privacy Policy