I'm getting the message "line 32 failed" after applying those last two changes. Does that indicate some problem with this iptables text, or is it fine and I should just use that other method of activating the iptables file from your last post?

The only thing missing are "-i eth0" items in lines below the ESTABLISHED,RELATED rule. Try adding it similar to that line.

Still "iptables-restore: line 32 failed."

And this is the FIRST step? I'm grateful that you're helping me, but YIKES.

OK, this is taking too long. Save as appropriate and run it like this standalone shell script:

It froze on the fifth line and I can no longer log into my server via ssh.

Not back up yet? No access to port 80 (meaning it's inaccessible completely)?

How do I access port 80? Through my ssh client, just change port 22 to 80?

I need to stress that you're dealing with a noob here.

EDIT: That's not working.

OK, that plainly sucks. Just to be sure: the iptables rule set is really simple and unless your VPS doesn't come with the most basic of modules ('grep -i iptables /etc/vz/vz.conf'), or used an ethernet device other than eth0, I can't see why it wouldn't have worked. Anyway, since it remains inaccessible the only alternative is to ask your provider to either log in and fix things for you if they can or gracefully shut down and reboot it. After that you'll have to find out if iptables is enabled by your provider and if so which modules are offered.



No, use a browser for port 80.


Thanks, I sometimes tend to forget that.

Okay, apf firewall is set up and configured. I did have help with this (I'm sorry for not following your advice via email, but I'm also trying to maintain my job and it was either pay someone to set that up for me or shut down my gaming server.) My current iptables contents are below.

Unfortunately, the attack I described previously is still happening multiple times per day.

I have some more information about what is going on when the attack happens. The targeted application actually continues to run... it even continues producing log files. But it is dead to the outside world. Apparently this attack causes the application's socket to terminate.

I read that this is an exploit for attacking some other games as well. An oversized udp packet is sent, and it causes the application's socket to terminate. That seems to be what is happening here. So I had a rule added to the firewall:

-A INPUT -p udp -m length --length 2001:65535 -j DROP

(2000 is the number the game developer recommended, saying anything over that could be dropped.)

This rule is not stopping the attack. But wouldn't an oversized packet mean one which is larger than 65535 anyway? However, I can't enter any number higher than that, or I get an error when I restart iptables. So, can this be reversed and changed to ACCEPT with a criteria of 0-2000, so that ANY packet over 2000 (no matter HOW large) is automatically not accepted? If so, what is the syntax for that, and if not, do I have any other options?

I also noticed when I first looked at this configuration that there is no LIMIT rule for the rate of udp packets. What should I put for that kind of rule, so that if more than a certain number of udp packets come per second from the same IP address, they are automatically ignored and the DOS attack fails while the IP address is added to the deny hosts list?

I'm not an iptables guy by any means. However, shouldn't the "-A INPUT -p udp -m length --length 2001:65535 -j DROP" go before the below rules that permit traffic to the port your game service listens on?

Thanks, I changed that. Hopefully it helps.

It's really hard to find qualified people to work on this stuff. The same person who did that also had logging set to 0 so that it was not logging dropped packets, even though I explicitly said I needed that. At least I'm starting to understand things in the process, but still, that's pretty annoying.

No problem, I hope it works out for you. But as I said, I'm by no means an iptables guy. My post was a question. I'm a bit rusty since I've been focusing on other areas of security so you may want to wait for verification or double check yourself.

In general, there are two major philosophies with IP tables that are helpful to keep in mind when working with the rules. One, is that the rules are process in order from top to bottom and if a match is found, it stops comparing. As Ol'Roy pointed out, placing a drop rule based upon packet size beneath one that accepts traffic to that port won't work, because the length check won't even get analyzed. The second philosophy is to set your firewall so that traffic is dropped by default and only accepted when it meets certain parameters. The syntax for the rules is almost identical to your drop rules, but instead of -j DROP, use -j ACCEPT. This practice is commonly referred to as white-listing versus black-listing and it gives you a real leg up on the would be attacker, who can adapt to get around your reject lists. There are two ways to achieve this, one is to set the policy to DROP and then add the rules that you want to accept, the other is to set the policy to ACCEPT, add the rules you want to ACCEPT and then at the end put a catch all DROP rule. The primary difference is in how the filter will behave when the rules have been flushed, in which case it will act according to the policy. If you don't have physical access to the machine, setting the policy to accept is safer in that if the rules get cleared, you can still get at the machine via SSH.

So as an example of how this would impact your rules, instead of having 20+ rules to drop specified ports, you could have three or four rules to only accept the ports, or port ranges you wish to accept. You can also get creative to enhance your security on your SSH port or other management interface. Say for example, that you have either a static IP or you can identify the network+mask that identifies the range that YOU will be using, you can restrict access to only these source IP addresses, effectively cutting off traffic from everyone else. I also noticed that you have duplicate rules for TCP and UDP on the same port, you should be able to simplify your rules by just specifying the port without the protocol. For example, your three rules:
The 3rd rule is really superfluous because traffic will be dropped by one of the two rules, but you could also eliminate the first two and just use the 3rd.

There are some really great tutorials on IPTables, that might help you with these rules. It looks like you have or are getting a grasp of the basic syntax and are starting to get into the art of rule writing. Once you get past the initial learning curve, writing iptables rules is actually enjoyable.

To address your other question about rate limiting: a quantitative suggestion is hard to provide. You might want to ask the developer for some guidance. Otherwise you will need to do some trial and error and expect to fine tune it for a while as a balance can be difficult to achieve.

You might find this link interesting: http://blog.bodhizazen.net/linux/pre...with-iptables/ It is an IPTables tutorial specifically geared towards preventing attacks and it discusses both length and limit functions. While somewhat cursory, it might at least be a good common reference point for refining the discussion.

Thanks for the help, Noway2. I'm looking through the information you linked to and trying to wrap my head around it.

I think unSpawn may have written me off due to the fact that I paid someone to do the initial configuration on my server.

UnSpawn, if that is the case, please understand where I'm coming from.

I realize that it's not apparent here, but I do have a love for knowledge, and I spend a lot of time each week learning how to do new things. I make my living on the internet, and I'm no stranger to spending days figuring out why X, Y, or Z isn't working.

Paying for someone to do the initial setup on my firewall, however, was logistically unavoidable. I did not have days to spend going through the entire process as a newb, and I also did not want to give up and shut down my gaming server. That only left me with one option. Please try not to think poorly of me. I'm still here trying to finish the job.

I don't think anyone, unSpawn included, will look down upon you for paying to have someone perform a service for you. For that matter, we all have day jobs too. Sometimes expediency is the biggest priority and hired hands can bring that to the table. I do think that most here appreciate making an effort to learn, which you are doing, and I don't think that we could ask any more of you. Sometimes, especially for those who have been using Linux for a long time, we lose sight of the new user perspective. This causes us to forget to include things that have become obvious to us. Please have patience with us in this regard.

Once you have had a chance to read up on iptables and look over some of the tutorial pages, please ask questions and don't be afraid to ask.