botnet ddos attack
-
- New to forums
- Posts: 13
- https://www.youtube.com/channel/UC40BgXanDqOYoVCYFDSTfHA
- Joined: Mon Jan 05, 2015 2:05 pm
botnet ddos attack
Hello to anyone that can help. I submitted a trouble ticket to NFO and they said they can't help and to use this forum. This is what they said.
--------------------------------------------------
Your log definitely shows that you're seeing a small DDoS attack
and that it's causing problems for you because of the way that
you've configured your firewall. In a case like this, where a
botnet is acting like a set of real clients, we can't see and
filter it for you on this end, but a few settings adjustments
on your side should eliminate the effects. Please make a post
about your software configuration question here:
http://www.nfoservers.com/forums/viewforum.php?f=44
-----------------------------------------------------
So I do not know what to do now they can see I'm being attacked but can't help becasue they can't see the settings or something I really don't understand but OK I'll go with the flow.
I'm using WHM/Cpanel and I have CSF firewall installed so where do I need to look or what do I need to do to stop this botnet ddos attack? Here is just a few lines from the logs.
The log file is too long to post the whole thing and 95% of it looks the same as this and this has been going on for 3 or 4 days now.
Jan 5 14:22:17 server1 kernel: __ratelimit: 1726 callbacks suppressed
Jan 5 14:22:17 server1 kernel: nf_conntrack: table full, dropping packet.
Jan 5 14:22:17 server1 kernel: nf_conntrack: table full, dropping packet.
Jan 5 14:22:17 server1 kernel: nf_conntrack: table full, dropping packet.
Jan 5 14:22:17 server1 kernel: nf_conntrack: table full, dropping packet.
Jan 5 14:22:17 server1 kernel: nf_conntrack: table full, dropping packet.
Jan 5 14:22:17 server1 kernel: nf_conntrack: table full, dropping packet.
Jan 5 14:22:17 server1 kernel: nf_conntrack: table full, dropping packet.
Jan 5 14:22:17 server1 kernel: nf_conntrack: table full, dropping packet.
Jan 5 14:22:17 server1 kernel: nf_conntrack: table full, dropping packet.
Jan 5 14:22:17 server1 kernel: nf_conntrack: table full, dropping packet.
Jan 5 14:22:22 server1 kernel: __ratelimit: 1605 callbacks suppressed
Jan 5 14:22:22 server1 kernel: nf_conntrack: table full, dropping packet.
Jan 5 14:22:22 server1 kernel: nf_conntrack: table full, dropping packet.
Jan 5 14:22:22 server1 kernel: nf_conntrack: table full, dropping packet.
Jan 5 14:22:22 server1 kernel: nf_conntrack: table full, dropping packet.
Jan 5 14:22:22 server1 kernel: nf_conntrack: table full, dropping packet.
Jan 5 14:22:22 server1 kernel: nf_conntrack: table full, dropping packet.
Jan 5 14:22:22 server1 kernel: nf_conntrack: table full, dropping packet.
Jan 5 14:22:22 server1 kernel: nf_conntrack: table full, dropping packet.
Jan 5 14:22:22 server1 kernel: nf_conntrack: table full, dropping packet.
Jan 5 14:22:22 server1 kernel: nf_conntrack: table full, dropping packet.
Jan 5 14:22:27 server1 kernel: __ratelimit: 1416 callbacks suppressed
Jan 5 14:22:27 server1 kernel: nf_conntrack: table full, dropping packet.
Jan 5 14:22:27 server1 kernel: nf_conntrack: table full, dropping packet.
Jan 5 14:22:27 server1 kernel: nf_conntrack: table full, dropping packet.
Jan 5 14:22:27 server1 kernel: nf_conntrack: table full, dropping packet.
Jan 5 14:22:27 server1 kernel: nf_conntrack: table full, dropping packet.
Jan 5 14:22:27 server1 kernel: nf_conntrack: table full, dropping packet.
Jan 5 14:22:27 server1 kernel: nf_conntrack: table full, dropping packet.
Jan 5 14:22:27 server1 kernel: nf_conntrack: table full, dropping packet.
Jan 5 14:22:27 server1 kernel: nf_conntrack: table full, dropping packet.
Jan 5 14:22:27 server1 kernel: nf_conntrack: table full, dropping packet.
Thanks for any help from anyone.
Chuck
--------------------------------------------------
Your log definitely shows that you're seeing a small DDoS attack
and that it's causing problems for you because of the way that
you've configured your firewall. In a case like this, where a
botnet is acting like a set of real clients, we can't see and
filter it for you on this end, but a few settings adjustments
on your side should eliminate the effects. Please make a post
about your software configuration question here:
http://www.nfoservers.com/forums/viewforum.php?f=44
-----------------------------------------------------
So I do not know what to do now they can see I'm being attacked but can't help becasue they can't see the settings or something I really don't understand but OK I'll go with the flow.
I'm using WHM/Cpanel and I have CSF firewall installed so where do I need to look or what do I need to do to stop this botnet ddos attack? Here is just a few lines from the logs.
The log file is too long to post the whole thing and 95% of it looks the same as this and this has been going on for 3 or 4 days now.
Jan 5 14:22:17 server1 kernel: __ratelimit: 1726 callbacks suppressed
Jan 5 14:22:17 server1 kernel: nf_conntrack: table full, dropping packet.
Jan 5 14:22:17 server1 kernel: nf_conntrack: table full, dropping packet.
Jan 5 14:22:17 server1 kernel: nf_conntrack: table full, dropping packet.
Jan 5 14:22:17 server1 kernel: nf_conntrack: table full, dropping packet.
Jan 5 14:22:17 server1 kernel: nf_conntrack: table full, dropping packet.
Jan 5 14:22:17 server1 kernel: nf_conntrack: table full, dropping packet.
Jan 5 14:22:17 server1 kernel: nf_conntrack: table full, dropping packet.
Jan 5 14:22:17 server1 kernel: nf_conntrack: table full, dropping packet.
Jan 5 14:22:17 server1 kernel: nf_conntrack: table full, dropping packet.
Jan 5 14:22:17 server1 kernel: nf_conntrack: table full, dropping packet.
Jan 5 14:22:22 server1 kernel: __ratelimit: 1605 callbacks suppressed
Jan 5 14:22:22 server1 kernel: nf_conntrack: table full, dropping packet.
Jan 5 14:22:22 server1 kernel: nf_conntrack: table full, dropping packet.
Jan 5 14:22:22 server1 kernel: nf_conntrack: table full, dropping packet.
Jan 5 14:22:22 server1 kernel: nf_conntrack: table full, dropping packet.
Jan 5 14:22:22 server1 kernel: nf_conntrack: table full, dropping packet.
Jan 5 14:22:22 server1 kernel: nf_conntrack: table full, dropping packet.
Jan 5 14:22:22 server1 kernel: nf_conntrack: table full, dropping packet.
Jan 5 14:22:22 server1 kernel: nf_conntrack: table full, dropping packet.
Jan 5 14:22:22 server1 kernel: nf_conntrack: table full, dropping packet.
Jan 5 14:22:22 server1 kernel: nf_conntrack: table full, dropping packet.
Jan 5 14:22:27 server1 kernel: __ratelimit: 1416 callbacks suppressed
Jan 5 14:22:27 server1 kernel: nf_conntrack: table full, dropping packet.
Jan 5 14:22:27 server1 kernel: nf_conntrack: table full, dropping packet.
Jan 5 14:22:27 server1 kernel: nf_conntrack: table full, dropping packet.
Jan 5 14:22:27 server1 kernel: nf_conntrack: table full, dropping packet.
Jan 5 14:22:27 server1 kernel: nf_conntrack: table full, dropping packet.
Jan 5 14:22:27 server1 kernel: nf_conntrack: table full, dropping packet.
Jan 5 14:22:27 server1 kernel: nf_conntrack: table full, dropping packet.
Jan 5 14:22:27 server1 kernel: nf_conntrack: table full, dropping packet.
Jan 5 14:22:27 server1 kernel: nf_conntrack: table full, dropping packet.
Jan 5 14:22:27 server1 kernel: nf_conntrack: table full, dropping packet.
Thanks for any help from anyone.
Chuck
Re: botnet ddos attack
Are you using conntrack for a specific purpose? If you don't have a good reason for running it, the first thing to try would be disabling it. If you have a good reason for running it, then you should try bumping up its table size.
You should also restrict the number of simultaneous connections allowed from each external IP address, since botnets usually try to open many at once from each compromised host.
Finally, look at your Apache logs and see which IP addresses are making the junk requests. You can block large lists of IP addresses efficiently with another iptables rule and the "ipset" module.
You should also restrict the number of simultaneous connections allowed from each external IP address, since botnets usually try to open many at once from each compromised host.
Finally, look at your Apache logs and see which IP addresses are making the junk requests. You can block large lists of IP addresses efficiently with another iptables rule and the "ipset" module.
Re: botnet ddos attack
Thanks Edge100x for the reply and the help I really truly appreciate it.
You asked me if I was using conntrack for a reason. Well to be honest I have no idea what that even is. I use this VDS to run CS 1.6 and I host my own personal domains on this server 3 or 4 of them I think off hand. If I do not need it then how would I disable it. This server is a Linux server running centos 6 I believe.
When talking about "iptables" is that the samething as the "Quick Deny" to the block IP thing in the CSF firewall?
Sorry I'm still kind of new at this stuff.
Thanks
You asked me if I was using conntrack for a reason. Well to be honest I have no idea what that even is. I use this VDS to run CS 1.6 and I host my own personal domains on this server 3 or 4 of them I think off hand. If I do not need it then how would I disable it. This server is a Linux server running centos 6 I believe.
When talking about "iptables" is that the samething as the "Quick Deny" to the block IP thing in the CSF firewall?
Sorry I'm still kind of new at this stuff.
Thanks
Re: botnet ddos attack
ip_tables is a component of the main Linux kernel filtering framework (and is accessed via the command line through the "iptables" command). conntrack is another component of that framework and one of its modules; its purpose is to keep track of established connections so that you can implement rules that treat new connections and existing connections differently (for instance, by allowing all existing connections through, while applying more rigorous filters to others).
The "CSF firewall" that you're mentioning appears to be another layer on top of iptables -- a GUI, basically. I'm not familiar with its configuration, as I have not used it before. Our "Firewall" page is another example of an interface to iptables.
Try increasing ip_conntrack_max first. If that takes care of it, you'll be done, and you can put off digging into how the firewall works further. Something like:
The "CSF firewall" that you're mentioning appears to be another layer on top of iptables -- a GUI, basically. I'm not familiar with its configuration, as I have not used it before. Our "Firewall" page is another example of an interface to iptables.
Try increasing ip_conntrack_max first. If that takes care of it, you'll be done, and you can put off digging into how the firewall works further. Something like:
Code: Select all
echo 2000000 > /proc/sys/net/ipv4/netfilter/ip_conntrack_max
Re: botnet ddos attack
Ok thanks what is ip_conntrack default size?
Re: botnet ddos attack
I believe it defaults to 64k. You can check the value with "cat" --
Code: Select all
cat /proc/sys/net/ipv4/netfilter/ip_conntrack_max
Re: botnet ddos attack
Humm :O(
root@server1 [~]# cat /proc/sys/net/ipv4/netfilter/ip_conntrack_max
cat: /proc/sys/net/ipv4/netfilter/ip_conntrack_max: No such file or directory
root@server1 [~]#
said "No such file or directory"
I'll do some more searching on google and a big thanks again.
This only happens in the mornings for some reason I would say 12 hours of the day it looks like.
root@server1 [~]# cat /proc/sys/net/ipv4/netfilter/ip_conntrack_max
cat: /proc/sys/net/ipv4/netfilter/ip_conntrack_max: No such file or directory
root@server1 [~]#
said "No such file or directory"
I'll do some more searching on google and a big thanks again.
This only happens in the mornings for some reason I would say 12 hours of the day it looks like.
Re: botnet ddos attack
This error suggests that the module was not loaded at the time. You may need to explore the options in your GUI, or turn it off.
Re: botnet ddos attack
I'm using csf firewall if that is what you mean on top of iptables.
This only had been happening in the mornings mid afternoon it seems to stop then starts over
again but the last few days it has been getting worse and so band today I couldn't even SSH in or even login though WHM/cpanel to look at anything.
Thanks
This only had been happening in the mornings mid afternoon it seems to stop then starts over
again but the last few days it has been getting worse and so band today I couldn't even SSH in or even login though WHM/cpanel to look at anything.
Thanks
Re: botnet ddos attack
Yes, when I refer to the GUI, I mean the CSF firewall utility that you mentioned. I recommend turning off or adjusting its settings. I am not familiar with its configuration -- I am only familiar with real iptables -- so I can't provide further guidance on it.
Re: botnet ddos attack
Well thanks for trying to help. I just wish NFO had real support for their servers. I had to contact my other VPS company and asked them to help me with NFO servers which they gladly did and for now it seems to be working what ever they did.
But it would be nice if NFO had experienced working on their servers.
But thanks for the help you were able to give.
But it would be nice if NFO had experienced working on their servers.
But thanks for the help you were able to give.
Re: botnet ddos attack
Yes, the nature of an unmanaged VDS is that it is unmanaged. Which leads the end-user responsible for configuring and diagnosing problems. While we can do our best to point users in the correct direction and provide additional outlets for support(these forums) but it's not feasible for us to support software related inquiries as there is just so much we cannot see nor access to be able to successfully do it via our standard help system.chuck316 wrote:Well thanks for trying to help. I just wish NFO had real support for their servers. I had to contact my other VPS company and asked them to help me with NFO servers which they gladly did and for now it seems to be working what ever they did.
But it would be nice if NFO had experienced working on their servers.
But thanks for the help you were able to give.
@Kraze^NFo> Juski has a very valid point
@Juski> Got my new signature, thanks!
@Kraze^NFo> Out of context!
@Juski> Doesn't matter!
@Juski> You said I had a valid point! You can't take it back now! It's out there!
@Juski> Got my new signature, thanks!
@Kraze^NFo> Out of context!
@Juski> Doesn't matter!
@Juski> You said I had a valid point! You can't take it back now! It's out there!
Re: botnet ddos attack
I understand it is unmanaged but that's all NFO offers. I have talked to them before about managed and they just don't offer it. There reason they do not understand linux. Which is understandable to not offer managed.
Well they say they offer but if you take them up on it you loose SSH and you basically loose control of the server and have to ask them do do everything for you and then if they don't know how then they won't so it really isn't managed. So as the person that answered my ticket months ago said it would be a waste for me sine they couldn't managed the server.
So to keep saying well you have a unmanaged server is why is not exactly the real reason. The real reason is not enough experienced techs. So the best way to not get into trouble is to have it setup the way NFO has it setup and I understand this.
All I was saying was I wish they did have support that could help to maintain at least the servers.
I could be mistaken but I thought I red about DDOS protection somewhere on the site but since this was a small as they put it they couldn't do anything. A DDOS attack is a DDOS attack as far as I'm concerned how big or small shouldn't matter if a server became's unusable.
Anyway I still appreciate the help you tried giving me on this problem I'm just glad my other host helped me on NFO servers. Sad but true having another company come in and support me on NFO servers. (Humm maybe a new business venture for me.) lol
Thanks no need to reply
Well they say they offer but if you take them up on it you loose SSH and you basically loose control of the server and have to ask them do do everything for you and then if they don't know how then they won't so it really isn't managed. So as the person that answered my ticket months ago said it would be a waste for me sine they couldn't managed the server.
So to keep saying well you have a unmanaged server is why is not exactly the real reason. The real reason is not enough experienced techs. So the best way to not get into trouble is to have it setup the way NFO has it setup and I understand this.
All I was saying was I wish they did have support that could help to maintain at least the servers.
I could be mistaken but I thought I red about DDOS protection somewhere on the site but since this was a small as they put it they couldn't do anything. A DDOS attack is a DDOS attack as far as I'm concerned how big or small shouldn't matter if a server became's unusable.
Anyway I still appreciate the help you tried giving me on this problem I'm just glad my other host helped me on NFO servers. Sad but true having another company come in and support me on NFO servers. (Humm maybe a new business venture for me.) lol
Thanks no need to reply
Re: botnet ddos attack
It has to do with it just being an unmanaged configuration. Experience or skill level doesn't really come into play here. We market it as unmanaged because we know what it would take to support software related inquiries and that's not a rabbit hole we're willing to go down at the moment. Anyone who's fixed a computer for a friend or removed a virus from a family members computers will immediately understand why.
We're not a mitigation provider and don't sell protection or mention being able to protect customers on our site. Though, we do have an extensive amount of it. Generally a DDoS question would be capable of being answered in our standard request system due to us having an extensive firewall built into the control panel.I could be mistaken but I thought I red about DDOS protection somewhere on the site but since this was a small as they put it they couldn't do anything. A DDOS attack is a DDOS attack as far as I'm concerned how big or small shouldn't matter if a server became's unusable.
It's more likely they didn't know it was for a competitors service as it wouldn't make sense for a legitimate company to use their resources on doing so. Though, if they did I'm glad!Anyway I still appreciate the help you tried giving me on this problem I'm just glad my other host helped me on NFO servers. Sad but true having another company come in and support me on NFO servers. (Humm maybe a new business venture for me.) lol
@Kraze^NFo> Juski has a very valid point
@Juski> Got my new signature, thanks!
@Kraze^NFo> Out of context!
@Juski> Doesn't matter!
@Juski> You said I had a valid point! You can't take it back now! It's out there!
@Juski> Got my new signature, thanks!
@Kraze^NFo> Out of context!
@Juski> Doesn't matter!
@Juski> You said I had a valid point! You can't take it back now! It's out there!
Re: botnet ddos attack
Unmanaged services are by their very nature unmanaged, and that means they don't come with software support. They have a low price point as a result. What it sounds like you want is to be able to come to us with any software question and have us guarantee to you that we will research and resolve it; to be able to afford that, we would have to have a much larger staff and much higher price points.
Your question here is likely a simple one for someone who knows that particular software package. Perhaps you found such a person at your other host. I personally have deep knowledge about Linux, and I shared some of it that in my previous posts (guiding you in the right areas to investigate further), but I don't know "CSF firewall" specifically.
If you expect to have software questions again and aren't prepared to do your own research, then I recommend that you consider a reputable host with fully managed support. These are expensive, but the cost may be justified in saving you from having to learn the technologies.
Your question here is likely a simple one for someone who knows that particular software package. Perhaps you found such a person at your other host. I personally have deep knowledge about Linux, and I shared some of it that in my previous posts (guiding you in the right areas to investigate further), but I don't know "CSF firewall" specifically.
If you expect to have software questions again and aren't prepared to do your own research, then I recommend that you consider a reputable host with fully managed support. These are expensive, but the cost may be justified in saving you from having to learn the technologies.