iptables - using ! to allow multiple ports

win32sux · 07-02-2006, 10:20 PM

Quote:

Originally Posted by chibi

Win32Sux,

Ah for whatever reason, I missed that reply. Denno why. I will post my entire script below.

hehe, no problem, i figured something like that happened... i'm gonna go through your iptables scripts in a few minutes and i'll post back with my contribution... i just need to make some coffee first and go to the pharmacy to get something for my splitting headache... BRB...

win32sux · 07-02-2006, 10:46 PM

i'm back... quick question: what's the *general* connection requirements on your server?? in other words, forget about the bad guys for a second - what ports/protocols are the services on your server running on??

win32sux · 07-03-2006, 12:17 AM

well, i have finished rebuilding your script...

i just need you to answer the above question and then i'll post it...

chibi · 07-03-2006, 05:24 AM

Hello there. Several ports are opened for services. Usually in the 10000 - 40000 range. When I start another gameserver for someone they pick a port of choice. They use both udp and tcp. udp for gameplay, and tcp for remote admin and map downloading etc.

I am not sure about imcp or other protocols. I am sure we would both agree syn packets would be used...

Then theres the regular stuff like apache, ftp and ssh n things which are used regularly.

And my question about the DROP policy??

Thanks ^^

win32sux · 07-03-2006, 08:00 AM

Quote:

Originally Posted by chibi

If I set my INPUT policy to DROP. If I have absolutely no entries in the chain at all, will iptables DROP -everything- that tries to connect to the box? Or only in relation to the entries in there?

setting your policy to DROP makes sure that unless a packet matches a rule in your chain, it will be sent to DROP... this is exactly how you want your firewall to work... you do not under any circumstances want packets to get sent to ACCEPT when you haven't matched them against a rule... this is the essence of iptables...

Quote:

And, if I want to make sure someone is dropped, but the policy is already DROP, adding a regular iptables -A INPUT -s 4.4.4.4 -j DROP would still work correct?

yes, but in a case like that, you'd need to use a "-I", because if you don't then the packet might get sent to ACCEPT by a rule above, before it hits your DROP rule...

win32sux · 07-03-2006, 08:32 AM

sorry, i've deleted the scripts i posted here, because in retrospect they might confuse you even further and they'd also probably veer the thread WAY off-topic... i'll try to put together a more simplified solution, and if i do, i'll post it... in the meantime, keep those questions coming...

chibi · 07-03-2006, 11:59 AM

Well I am still not clear on this. If my INPUT policy is DROP and there are no iptable entries, does that mean no one can connect? yes or no?

If my INPUT policy is DROP, and I have 2 iptable entries for INPUT. Are these entries the only two connections that would or would not be able to connect to the server depending if they had -j ACCEPT or not? yes or no?

I just can't grasp whether or not the entries in the INPUT chain are the only ones affected. Because if the INPUT policy is ACCEPT, then the server will accept connections.. and these gameservers are public, random people from around the world will connect to them. It would be impossible for me to know who they were before hand.

This also is not a local machine. I moderate everything remotely with ssh, I think I should have said that. I don't want to block myself out -_- .

Also, what is wrong with this (i forget the error it gave me, I have sinced removed it from the script):

iptables -A INPUT -p udp -m multiport --destination-port ! 25000,10500 -j DROP

Shouldnt that block all udp accept for 25000,10500 ? It seems to work without the ! in that its saying to only block 25000 and 10500 .

Thanks for your continuied assistance.

win32sux · 07-04-2006, 03:48 AM

Quote:

Originally Posted by chibi

Well I am still not clear on this. If my INPUT policy is DROP and there are no iptable entries, does that mean no one can connect? yes or no?

yes... in fact, without any rules, the box wouldn't even be able to connect to *itself* via loopback interface...

Quote:

If my INPUT policy is DROP, and I have 2 iptable entries for INPUT. Are these entries the only two connections that would or would not be able to connect to the server depending if they had -j ACCEPT or not? yes or no?

i think the basis of your confusion is that you are thinking that iptables rules need to have a source IP address - they don't...

Quote:

I just can't grasp whether or not the entries in the INPUT chain are the only ones affected. Because if the INPUT policy is ACCEPT, then the server will accept connections.. and these gameservers are public, random people from around the world will connect to them. It would be impossible for me to know who they were before hand.

i know... you're not supposed to know the IPs for any of them (unless you wanna blacklist them, limit them, or give them special treatment)... that's what i meant above...

i think the best thing is to provide you with an example of how this is actually done...

here is a small example of what the rules might look like for somebody running a server with HTTP, HTTPS, FTP, and SSH... this person wants anybody to be able to connect to the HTTP, HTTPS, and FTP services, but only wants two of his friends in Russia and the USA (each with his own static IP) to be able to connect to the SSH daemon... he also wants to blacklist a Siberian script-kiddie's IP address, preventing him from getting ANY packets into the server:

Code:

iptables -P INPUT DROP

# Script-kiddie from Siberia who keeps probing our Apache:
iptables -A INPUT -i eth0 -s 166.164.241.274 -j DROP

iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

iptables -A INPUT -i lo -j ACCEPT

iptables -A INPUT -i eth0 -p TCP -m multiport --dports \
80,443,21 -m state --state NEW -j ACCEPT

# Let Sergei connect via SSH from his home in Moscow:
iptables -A INPUT -i eth0 -p TCP --dport 22 -s 200.201.202.111 \
-m state --state NEW -j ACCEPT

# Let Alison connect via SSH from her office in Miami:
iptables -A INPUT -i eth0 -p TCP --dport 22 -s 100.154.222.221 \
-m state --state NEW -j ACCEPT

iptables -A INPUT -j LOG --log-prefix "INPUT DROP: "

see how we only needed to use three IP addresses to achieve our objective??

nobody will be able to connect to the SSH daemon except Sergei and Alison...

the script-kiddie in Siberia doesn't stand a chance with anything...

yet all users (except the script-kiddie) will be able to use the HTTP, HTTPS, and FTP services... if anyone tries to use something else, they will be sent to LOG right before hitting our policy of DROP...

let's say that our friend John, in Vancouver, tries to establish a connection to the SSH daemon (TCP port 22)... because his IP is different from Sergei's and Alison's, it will not match against those rules, and his packet will continue traversing the chain... since there are no more rules, he will run smack into the chain's policy - which is set to DROP... of course, before hitting the policy, his packet will get logged, so we can know exactly what is getting sent to DROP...

Quote:

This also is not a local machine. I moderate everything remotely with ssh, I think I should have said that. I don't want to block myself out -_- .

cool...

Quote:

Also, what is wrong with this (i forget the error it gave me, I have sinced removed it from the script):

iptables -A INPUT -p udp -m multiport --destination-port ! 25000,10500 -j DROP

Shouldnt that block all udp accept for 25000,10500 ? It seems to work without the ! in that its saying to only block 25000 and 10500 .

apparently, the multiport match doesn't support invert... having said that, hopefully by now you are starting to understand why rules like that aren't a good idea either way...

Quote:

Thanks for your continuied assistance.

you bet...

no_good_at_xnix · 07-04-2006, 04:42 AM

wow, all of you make me foolish, I dont understand all. Any one, please, conclude it and write down all. Thanks