Incoming RST-packets detecting to prevent DNS-amplification/Malicious Activity Abuse attacks
-
@Sergei_Shablovsky said in Incoming RST-packets detecting to prevent DNS-amplification/Malicious Activity Abuse attacks:
Sorry my English.
I mean in Legacy Mode, when IDS/IPS running as separate process. How much this eating from CPU and memory? 5%, 15%, 30%
There is no separate process. It's still just the same Suricata binary. The only difference is the means of blocking. My answer is the same as that for your first question. It is totally dependent on the CPU horsepower you have and the number of enabled rules. It's the Suricata packet inspection engine that consumes CPU cycles, not the blocking mechanism. The blocking mechanism is just a very, very tiny infinitesimal portion of the CPU cycles consumed by the IPS.
-
@Sergei_Shablovsky said in Incoming RST-packets detecting to prevent DNS-amplification/Malicious Activity Abuse attacks:
In topic I mean not exactly blocking this RST packets but send me some alarm about “You start receiving a RST packets from some hosts, that You never connect before, may be this is DNS-amplification attack”.
Smothering like
If (RST packets come in & the sender host is never be in destination address) then “send alarm to network security admin” :)Even an IDS could not tell you that you received an RST for a host you haven't communicated with. It wouldn't do state tracking to remember that.
You could manually make a block rule to match that -- for example:
- Action: Block
- Interface: WAN
- Protocol: TCP
- Source: Any
- Destination: Any
- Log: Checked
- Advanced Options:
- TCP Flags:
- Set: RST
- Out of: <all checked>
- TCP Flags:
That would block and log packets which only have the RST flag set (and all other flags unset)
After saving the rule, edit it again, and look at the bottom in the Rule Information section and note the tracking ID.
Setup remote syslog to an NMS or log analyzer and in there, setup an alert when you receive a log message with the tracking ID of that rule. The log analysis and alerting are not firewall tasks, but tasks performed by your NMS or log server.
Remember: Upvote with the 👍 button for any user/post you find to be helpful, informative, or deserving of recognition!
Need help fast? Netgate Global Support!
Do not Chat/PM for help!
-
Though in a DDoS situation the logging performed by that rule will likely cause a large increase in CPU usage if it's hit frequently.
A firewall is not a DDoS mitigation device, though, so if you hit that a lot you need to consider other solutions like DDoS mitigation services. Nothing you do on the firewall will really help that. It's too late by the time it has reached you.
-
@jimp Wouldn't a custom IDS rule help to alert?
-
I don't think the IDS could tell the difference between a valid and invalid RST packet on its own in this situation. It may be possible, but might not be as simple as it would appear.
Remember: Upvote with the 👍 button for any user/post you find to be helpful, informative, or deserving of recognition!
Need help fast? Netgate Global Support!
Do not Chat/PM for help!
-
@jimp is correct. The IDS would have no knowledge of any firewall state, and the inspection engine is sort of ill-suited to track such information on its own.
My question back to the OP would be "why?". The firewall is going to drop any RST packet that it has no pre-existing state for (assuming you have a logically configured firewall: nothing can protect you from security admin incompetence, though).
All this worry about DDoS at the firewall is totally misplaced and screams, to me, a basic misunderstanding of what a DOS or DDoS attack really is. It is, at its heart, totally and completely filling up the Internet connection between you and your provider. That pipe has a finite bandwith be it 1 megabits/sec or 1 terabits/sec. Once that pipe is full, it is game over for your end of the connection. Nothing else can get down the wire no matter what your firewall does. The firewall is helpless (and it really always was when talking about a typical DOS).
As far as how you detect a DOS, well, it's pretty easy. Your Internet connection essentially quits working and you can't talk "out" and nobody can talk "in" and you see on a traffic graph that your pipe is maxed out. At that point your only recourse is upstream at your provider's level or beyond.
-
@jimp said in Incoming RST-packets detecting to prevent DNS-amplification/Malicious Activity Abuse attacks:
I don't think the IDS could tell the difference between a valid and invalid RST packet on its own in this situation. It may be possible, but might not be as simple as it would appear.
I have seen that IDS/IPS systems that issue forged RST packets; however, this highlights what you said...I don't think the IDS could tell the difference between a valid and invalid RST packet.
-
@bmeeks said in Incoming RST-packets detecting to prevent DNS-amplification/Malicious Activity Abuse attacks:
@jimp is correct. The IDS would have no knowledge of any firewall state, and the inspection engine is sort of ill-suited to track such information on its own.
My question back to the OP would be "why?". The firewall is going to drop any RST packet that it has no pre-existing state for (assuming you have a logically configured firewall: nothing can protect you from security admin incompetence, though).
All this worry about DDoS at the firewall is totally misplaced and screams, to me, a basic misunderstanding of what a DOS or DDoS attack really is. It is, at its heart, totally and completely filling up the Internet connection between you and your provider. That pipe has a finite bandwith be it 1 megabits/sec or 1 terabits/sec. Once that pipe is full, it is game over for your end of the connection. Nothing else can get down the wire no matter what your firewall does. The firewall is helpless (and it really always was when talking about a typical DOS).
As far as how you detect a DOS, well, it's pretty easy. Your Internet connection essentially quits working and you can't talk "out" and nobody can talk "in" and you see on a traffic graph that your pipe is maxed out. At that point your only recourse is upstream at your provider's level or beyond.
Let's to note, that we not talking here about DDoS or RST flooding as well. Please re-read initial message, I describe the situation when attacker using legal mechanism of existed automatic detecting spam systems triggering it to automatically generate abuse message to my client hosing provider, and this abuse messages triggering the hosting provider procedure to block victim client's account.
Now @jimp describe real workaround (that I have in mind also) with log analyser to handpicking and take action by security admin.
My post here on forum - just try to find some more automated solution. But because the attacks like this are due 3-7 days long before host locked by hosting provider, may be constantly parallel task with log analyser with special trigger - are only one solution exist now to against this attack....
-
Why would you trigger your alerting system on a RST? That makes zero sense... If your going to spam yourself over noise - that is on you.. Not the firewall.
-
@johnpoz said in Incoming RST-packets detecting to prevent DNS-amplification/Malicious Activity Abuse attacks:
Why would you trigger your alerting system on a RST? That makes zero sense... If your going to spam yourself over noise - that is on you.. Not the firewall.
Please re-read initial message:
Step 1
attacker sitting everywhere in the world create a DDoS attacks on some hosts using the victim IP'sStep 2 on a DDoSed hosts this triggering the existed in any ISP automatic detecting spam systems that automatically generate abuse message to my client hosing proxy vider
Step 3
this abuse messages triggering the victims hosting provider procedure to block victim client's account.Are You understand how this exactly work?
And RST packets received by victims server from the hosts that he never initiate connect before - is only one how You able to detect that happened something strange.
-
Please reread your own freaking statements - you just stated this is NOT a ddos..
" that we not talking here about DDoS or RST flooding as well."
Your isp gives 2 shits that there is some noise..
I don't even log such noise - because it serves no purpose.. I only log syn hits to wan, because it can be interesting to what is out there from a noise point of view, of what sort of shit is common out there... Like when that modem thing was happening and seeing traffic on that port, etc.
Again if your going to trigger alerts on noise - that is on you, your ISP sure and the hell is not going to care that RSTs are being sent to you IP..
