New answers tagged ddos
While it is interesting that nothing is showing up in netstat, you could attack this problem from a different angle. If something is sending 300 MB/s it will most likely be chewing up a decent amount of CPU ... try running top and based on the services that are using the most CPU check logs accordingly.
You can use tcpdump or shark for capturing the filtered packets and count them as you want.
I believe netstat -s will be your friend. If you are looking for a switch level service, you can use sflow/netflow to collect data and send them to the collector.
A providers first response to a large DDoS attack is going to be damage limitation. Often that means blocking by destination IP address. If you share an IP address with other people then you are likely to be caught-up in those blocks. Shared web hosting services, especially non-https ones often use shared IP addresses. VMs and dedicated servers have their ...
I've read through lots of threads on here and stackoverflow and realised that at my own server its not worth setting anything up as the damage is already being done. That depends heavilly on the particular attack, if it's a simple UDP flood to an unused port there probablly isn't much point in doing anything. If it's something more clever and the total ...
Is Nginx overloading your CPU? Then you're being target of a sizeable DDoS attack. (Here's a nice explanation of the XML-RPC reflection attack with WordPress.) I don't think you'll get a better result than what you've already done just with Nginx. You can try using something like CloudFlare. Keep in mind, though, that you should change your IP to hide ...
It looks like we can report the IPs for NTP abuse (and hopefully, NTP patching) to http://openntpproject.org/ As for reporting networks that allow spoofed IPs, I can't find much: Our measurements show that spoofing is still prevalent among approximately 25% of the autonomous systems and netblocks we survey. More importantly, a single entry point for ...
In short: yes! But that depends a bit in the syslog daemon you're running. Syslog-ng allows that with the program() destination. Rsyslog offers actions.
Syn flood is kind of attack that is near to impossible to protect on single host. Check SynCookies cat /proc/sys/net/ipv4/tcp_syncookies and enable (set to 1) it if disabled. It help legit users keep working. Also You can try set lover /proc/sys/net/ipv4/tcp_synack_retries http://stackoverflow.com/a/26674591/205355 About IP Synflood usually use ...
I will assume you have a pipe to your ISP which terminates on your own router/firewall. Then behind that router/firewall you have your own machines. The ISP won't block the traffic so you have to deal with it yourself. You want to block the traffic at the router/firewall to stop it hitting the machines behind it while minimising load on the router/firewall. ...
Essentially, you're outta luck if the DDoS attack manages to fill whatever pipe you have to the Internet (which is the purpose of any UDP reflection attack -- to fill the pipe). If your upstream link can take 1Gbps of traffic, and there's (say) 2Gbps of traffic total to go down the link, then half of it is going to be dropped by the router or switch that's ...
As always, it depends. In theory the log on process is a one-time event and once an active session has been established the actual usage patterns of authenticated users are what really determines the load on a server. In that regard even the computational cost of calculating a hash that was deliberately selected for being slow and expensive such as PBKDF2 ...
No, it is not a good idea. You can rely on the per-IP and per-username login attempt rate limits which you have already implemented to ameliorate password guessing attacks anyway. You have implemented login attempt rate limits, haven't you?
Top 50 recent answers are included