Hi,

I'm trying to write the following rule in the iptable
but I receive the message

What I would like to do is to block all the request from wootwoot that its ip address change continuously

Thanks in advance

output of
please.

Hi the output of what you asked is:

I think that you have the syntax of the -I option wrong. It is iptables -I 'table' 'number' 'rule'.

So you have specified the 'table' as INPUT, which should be fine and dandy, but the rule number as '-d', which is probably less so. (And the rule to be inserted as 'myipaddres -p tcp --dport 80 -m string --to 70 --algo bm --string '/w00tw00t.' -j DROP', which would also be not what you wanted).

Just one question; rather than rejecting based on the string "/w00tw00t." might you not be better using the stateful features just to reject anything unsolicited?

What I have in my /var/log/httpd/error_log is:

I found in link1 and link2 that to get rid of these entries I could use the iptables.

So the correcty syntax what would be? Do you have anyother suggestions on how I should handle it?

Isn't w00tw00t a Plesk/Virtuozo exploit?

I'm not so sure for that. I do have though plesk installed.

It seems to work on my system, or at least outputs no errors. Perhaps you don't have the module for that function for iptables loaded? Or other kernel settings that influence it. /proc/sys/net/..... Otherwise try double quotes instead of single quotes. Both worked for me, but iptables -L outputted double quotes "" for both additions.

$ lsmod

Is the myipaddress ipv4 or ipv6? If it's a VAR you might prefix it with $. Otherwise I don't know. Check the bugreports, as it could be your iptables version. I had to revamp the syntax of my aging firewall not too long ago because of changes in the iptables syntax / reserved words list. I don't recall exactly, but ctstate instead of state and conntrack instead of track. It's been a while, and I'm more of an app guy than a network one.

When I type lsmod I just receive
This means that the iptables are not installed in the linux kernel?

Hope it's current.

Do you mean that Plesk creates this error or there are others trying to exploit a bug of Plesk?

Wrong question (well, unless you can't find LQs search function that is ;-p)
https://www.linuxquestions.org/quest...6/#post4899149

Well, looking at the two links, link 2 has the syntax right, link 1, which has copied from link 2, has made a modification, and it hasn't.

link 2 uses -A which adds the succeeding rule, and that's fine, but link 1 uses -I which inserts the rule and, as it inserts, it needs to know where to insert the rule (well, they both need to know which table you are working on, but that part doesn't change and isn't the issue).

That 'where' part is the position (rule number) at which the insert is to take place, so you could fix this by specifying the appropriate number for your rule set, or, if this works within your rule set, you could just add (-A) the rule, to put this rule as the last rule in this particular table.

I still don't recommend that you do this, but that would be how to avoid the syntax error.

The rule that you are trying to add has a significant overhead in kernel memory use and (probably) in processor cycles. That's because there is all sorts of packet re-asssembly going on behind the scenes, and doing that makes your server vulnerable to all sorts of attacks that, while currently rare, aren't exactly difficult to implement. And, while you could argue that 'nobody knows', that's 'security by obscurity' and eventually someone will come along and just try this kind of attack 'because they can'.

You seem to be doing this, as far as I can tell, to keep your log files clean. That isn't a worthwhile objective. Log files are for logging stuff, and while it can easily be worth rate-limiting entries into log files, just to protect against someone trying to overload logging, a clean log file isn't security. Just let log files accumulate data (and look at the data at appropriate intervals, of course); that's what log files are for.

@salasi. So you are suggesting me to ignore this "w00tw00t" scanning in my server? From the log file it's pretty obvious that the server has already reject it...but it was a little bit weard, and thut's why I started looking at it. Some suggest things as you did and others to put the entry in the iptable. If there is a load in the cpu by this entry, then I don't think it's worth of it. It's going to consume more power checking all packages than to have a few errors...I think

If the server has already rejected it, isn't that the biggest part of the battle? You should worry if you thought that there was, for example, an new version of this that might not be rejected by the current measures or if you thought that you might suddenly get hit by millions of them and that might cause a problem, but otherwise I don't see that its worth getting excited about. Certainly not worth taking any new risks in order to keep this from the log files...

Some of the 'fancier' options for iptables can consume (relatively) lots of resources - the 'plain and simple' ones don't, and are really pretty efficient, and getting excited about a few 'plain and simple' rules either way is usually, in practice, pointless (but may still be appealing from the point of view of 'neatness', and neatness and comprehensibility do have a value, even if the advantage is difficult to quantify).

The potential problem I see with this specific rule is that, while packet fragmentation is possible, iptables has to buffer fragmented packets to rebuild them and then do some kind of 'best match' scan against the re-assembled packets. Firstly, if you think of the 'slow_loris' type of attack, an evildoer could force you to keep open a massive number of buffers and that could, eventually, be unfortunate. Secondly, the best match scan could use a lot of resources (although that's more of a hypothetical issue, in that, never having used it, I just worry that it could) and that could be unfortunate too.

For the 'scan resources' attack, the evildoer would need to create packets coming in at a high rate while for the 'buffer resources' attack lots of fragmented packets, keeping connections open for as long as possible, would be necessary. So, these would be different attacks, but both difficult to block (ok, it would be easy if the evildoer used a single IP or small number of IPs to attack, but they probably wouldn't).

So, for me, I'd want a pretty clear advantage from doing it to feel that it was worth the risks. And, at the moment, I haven't seen what that advantage might be.

The other way of approaching this might be to use the rule and subject the server to all sorts of stress testing to assure yourself that it wasn't going to be a problem, even under the most extreme loads that you could contrive. To me, this seems to be getting all extreme over something of a non-issue, but, if you want to do that (you never know...you might show up some unrelated issue) it would also be a valid way forward.

1 members found this post helpful.