Suricata custom rule kills all the rules during midnight rule update
-
@ecfx:
line will drop all UDP traffic that come to your external IP on low ports ( use it if you don't have a server listening for that traffic )
drop udp $EXTERNAL_NET any -> $HOME_NET [0:1023] (msg:"Golden Rule NO SERVER UDP"; classtype:network-scan; sid:9900003; rev:1;)I don't have any server listening on any udp port from 0 to 1023. But when I do live rule update (or even regular rule update) at midnight, the only rule that gets flagged in alerts tab (not blocked) is the rule above every few seconds and only way to fix it is a full restart.
The dns port gets flagged with source being 8.8.8.8 and destination being my ip address.
-
What is the point of this custom rule? The firewall will, with its default configuration, drop all unsolicited inbound UDP traffic anyway. Having this custom DROP rule on an interface is not useful and can in fact cause a lot of trouble (as you are apparently experiencing). Change this rule to ALERT instead of DROP and then check how many alerts it generates. It is going to block stuff you need to have working (like DNS for one thing). See, Suricata is not "stateful" like the firewall, so it can't understand that a query went out on say UDP port 53 for a DNS lookup so we will let the reply come back in. Suricata will just look at the port number and protocol and drop the traffic if they match with no regard for any previously established states.
Bill
-
What is the point of this custom rule? The firewall will, with its default configuration, drop all unsolicited inbound UDP traffic anyway. Having this custom DROP rule on an interface is not useful and can in fact cause a lot of trouble (as you are apparently experiencing). Change this rule to ALERT instead of DROP and then check how many alerts it generates. It is going to block stuff you need to have working (like DNS for one thing). See, Suricata is not "stateful" like the firewall, so it can't understand that a query went out on say UDP port 53 for a DNS lookup so we will let the reply come back in. Suricata will just look at the port number and protocol and drop the traffic if they match with no regard for any previously established states.
Bill
Thank you for explaining the issue to me.
What about following rules:
drop tcp $EXTERNAL_NET [0:1023] -> $HOME_NET [0:1023](msg:"Golden Rule BAD TCP"; classtype:attempted-recon; sid:9900001; rev:1;) drop udp $EXTERNAL_NET [0:1023] -> $HOME_NET [0:1023] (msg:"Golden Rule BAD UDP"; classtype:attempted-recon; sid:9900002; rev:1;)drop tcp $EXTERNAL_NET any -> $HOME_NET [0:1023,![25,443,465,993]] (msg:"Golden Rule NO SERVER TCP"; classtype:network-scan; sid:9900004; rev:2;)drop tcp $EXTERNAL_NET [1024:65535] -> $HOME_NET [3389] (msg:"Admin Rule NO SERVER RDP TCP"; classtype:network-scan; sid:990050; rev:1;) drop tcp $EXTERNAL_NET [1024:65535] -> $HOME_NET [5500] (msg:"Admin Rule NO SERVER VNC TCP"; classtype:network-scan; sid:990052; rev:1;) drop tcp $EXTERNAL_NET [1024:65535] -> $HOME_NET [5800] (msg:"Admin Rule NO SERVER VNC TCP"; classtype:network-scan; sid:990053; rev:1;) drop tcp $EXTERNAL_NET [1024:65535] -> $HOME_NET [5900] (msg:"Admin Rule NO SERVER VNC TCP"; classtype:network-scan; sid:990054; rev:1;) drop tcp $EXTERNAL_NET [1024:65535] -> $HOME_NET [4899] (msg:"Admin Rule NO SERVER RADMIN TCP"; classtype:network-scan; sid:990055; rev:1;) drop tcp $EXTERNAL_NET [1024:65535] -> $HOME_NET [1433] (msg:"Admin Rule NO SERVER MSSQL TCP"; classtype:network-scan; sid:990057; rev:1;) drop tcp $EXTERNAL_NET [1024:65535] -> $HOME_NET [5060] (msg:"Admin Rule NO SERVER SIP TCP"; classtype:network-scan; sid:990059; rev:1;) drop udp $EXTERNAL_NET [1024:65535] -> $HOME_NET [5060] (msg:"Admin Rule NO SERVER SIP UDP"; classtype:attempted-recon; sid:9900060; rev:1;) drop tcp $EXTERNAL_NET [1024:65535] -> $HOME_NET [8172] (msg:"Admin Rule NO SERVER IIS TCP"; classtype:network-scan; sid:990061; rev:1;) drop tcp $EXTERNAL_NET [1024:65535] -> $HOME_NET [31337] (msg:"Admin Rule NO SERVER Back Orifice TCP"; classtype:network-scan; sid:990063; rev:1;) drop tcp $EXTERNAL_NET [1024:65535] -> $HOME_NET [47001] (msg:"Admin Rule NO SERVER WinRM TCP"; classtype:network-scan; sid:990064; rev:1;) -
My answer to the question for those TCP rules is the same as it was for the previous UDP rules. What is the point? The firewall will drop all unsolicited TCP packets as well. I just didn't state that in my earlier response since we were specifically just talking UDP, but pfSense out of the box drops all unsolicited inbound traffic on the WAN.
If you don't open a port and specify a protocol in a firewall rule, then nothing gets in. So if you don't have an explicit firewall rule allowing MS-SQL inbound (TCP port 1433), then nothing can connect to that port. Putting a MS-SQL drop rule in Suricata does not accomplish much in my view. Instead of having Suricata munch through a bunch of rules to drop traffic the firewall is going to block anyway, I would reserve Suricata's processing to protect stuff where I have actual vulnerabilities (such as rules looking for local clients attempting communication with known malware BOT nets, various JavaScript or PDF attacks from web sites, etc.).
Bill
-
My answer to the question for those TCP rules is the same as it was for the previous UDP rules. What is the point? The firewall will drop all unsolicited TCP packets as well. I just didn't state that in my earlier response since we were specifically just talking UDP, but pfSense out of the box drops all unsolicited inbound traffic on the WAN.
If you don't open a port and specify a protocol in a firewall rule, then nothing gets in. So if you don't have an explicit firewall rule allowing MS-SQL inbound (TCP port 1433), then nothing can connect to that port. Putting a MS-SQL drop rule in Suricata does not accomplish much in my view. Instead of having Suricata munch through a bunch of rules to drop traffic the firewall is going to block anyway, I would reserve Suricata's processing to protect stuff where I have actual vulnerabilities (such as rules looking for local clients attempting communication with known malware BOT nets, various JavaScript or PDF attacks from web sites, etc.).
Bill
Thanks for clarification.
