Iptable rule confusion.

[madu]

Hello,

I used the iptable guide given here (http://ubuntuforums.org/showthread.php?t=159661) and it works fine.

Then I allowed http and ssh in the following way:

iptables -A TRUSTED -i eth0 -p tcp -m tcp --dport 80 -j ACCEPT
iptables -A TRUSTED -i eth0 -p tcp -m tcp --dport 22 -j ACCEPT

Now this worked fine too.
Then I wanted to restrict ssh access to only my work computer domain so I did this:

iptables -A TRUSTED -i eth0 -p tcp -m tcp --dport 22 --source ! 131.0.0.0/8 -j DROP

So I expected iptable to drop all the tcp/22 packets 'except' from 131/8.
And it didnt work.

Then I did:

iptables -A TRUSTED -i eth0 -p tcp -m tcp --dport 22 --source 131.0.0.0/8 -j ACCEPT
iptables -A TRUSTED -i eth0 -p tcp -m tcp --dport 22 --source ! 131.0.0.0/8 -j DROP

ANd now it works.
I'm a little confused as to why the first rule didnt allow 131/8 and the second did. All I did was to first allow 131/8 tcp/22 to come in. But doesnt

iptables -A TRUSTED -i eth0 -p tcp -m tcp --dport 22 --source ! 131.0.0.0/8 -j DROP

do the same?

Also would appreciate if someone clarify the different between '-s' and '--source'.

Thanks guys.

[kevdog]

Did you have both rules in the ruleset? Again once a rule is matched, it does not scan the remainder of the rules in that particular chain (ie TRUSTED in your case). I noted that TRUSTED is your personal chain name. Is this being called from the input chain?

[madu]

yes.. I have both these.. in the order given.

iptables -A TRUSTED -i eth0 -p tcp -m tcp --dport 22 --source 131.0.0.0/8 -j ACCEPT
iptables -A TRUSTED -i eth0 -p tcp -m tcp --dport 22 --source ! 131.0.0.0/8 -j DROP

I dont understand why only the second rule wouldnt work. I'm sorry my understanding on the chains are minimal. I just followed the guide I mentioned.

Thanks for the reply mate.

[The Cog]

I think kevdog is probably right and that you haven't appreciated that hte rules are scanned in order, and that a particular chain ends whan a match is found. Here are some examples:

iptables -A TRUSTED -i eth0 -p tcp -m tcp --dport 22 -j ACCEPT
iptables -A TRUSTED -i eth0 -p tcp -m tcp --dport 22 --source ! 131.0.0.0/8 -j DROP

accepts ALL SSH connections. Why? because the first rule says for any ssh connection, jump to the ACCEPT target - the second rule never even gets looked at. These two though:

iptables -A TRUSTED -i eth0 -p tcp -m tcp --dport 22 --source 131.0.0.0/8 -j ACCEPT
iptables -A TRUSTED -i eth0 -p tcp -m tcp --dport 22 -j DROP

does what you want. SSH from 131 sees the first rule and jumps off to ACCEPT. SSH from anywhere else doesn't match the first rule and then looks at the second rule, which does match and sends it off to DENY.

The thing is that the rules are looked at one at a time, in order. They are not considered as an all-in-one thing. This allows you to say to allow this specific thing, that specific thing, another specific thing, and at the end just have an all-encompassing "drop everything" to sweep up what hasn't already been allowed.

And in fact if you set a default policy to drop packest where no rule is found, you may be able to get away without the second (drop) rule and allow the default drop to handle it.

[madu]

I think kevdog is probably right and that you haven't appreciated that hte rules are scanned in order, and that a particular chain ends whan a match is found. Here are some examples:

iptables -A TRUSTED -i eth0 -p tcp -m tcp --dport 22 -j ACCEPT
iptables -A TRUSTED -i eth0 -p tcp -m tcp --dport 22 --source ! 131.0.0.0/8 -j DROP

accepts ALL SSH connections. Why? because the first rule says for any ssh connection, jump to the ACCEPT target - the second rule never even gets looked at. These two though:

iptables -A TRUSTED -i eth0 -p tcp -m tcp --dport 22 --source 131.0.0.0/8 -j ACCEPT
iptables -A TRUSTED -i eth0 -p tcp -m tcp --dport 22 -j DROP

does what you want. SSH from 131 sees the first rule and jumps off to ACCEPT. SSH from anywhere else doesn't match the first rule and then looks at the second rule, which does match and sends it off to DENY.

The thing is that the rules are looked at one at a time, in order. They are not considered as an all-in-one thing. This allows you to say to allow this specific thing, that specific thing, another specific thing, and at the end just have an all-encompassing "drop everything" to sweep up what hasn't already been allowed.

And in fact if you set a default policy to drop packest where no rule is found, you may be able to get away without the second (drop) rule and allow the default drop to handle it.

Thanks a lot Cog.
But got one confusion still.
In this case:

iptables -A TRUSTED -i eth0 -p tcp -m tcp --dport 22 --source ! 131.0.0.0/8 -j DROP

why doesnt the incoming SSH from 131/8 match and go through?why do I need an explicit ACCEPT for the 131/8 ? Doesnt the above rule implicitly mean to ACCEPT 131/8?

[The Cog]

Well that depends on what other rules exist afterwards.
When you say it "didn't work", you don't say whether that was because it dropped things you wanted passed or whether it passed things you wanted to drop. But anyway, without seeing the exact ruleset it's difficult to comment on that.

You could indeed go:

iptables -A TRUSTED -i eth0 -p tcp -m tcp --dport 22 --source ! 131.0.0.0/8 -j DROP
iptables -A TRUSTED -i eth0 -p tcp -m tcp --dport 22 --source 131.0.0.0/8 -j ACCEPT

but then you have your 131 sepcification in two lines. With more complicated requirements that gets very messy and makes your head hurt. It is better to make use of the fact that rules are evaluated in order to keep things simple. Perhaps like this:

iptables -A TRUSTED -i eth0 -p tcp -m tcp --dport 22 --source ! 131.0.0.0/8 -j DROP
iptables -A TRUSTED -i eth0 -p tcp -m tcp --dport 22 -j ACCEPT

but even this gets messy. Suppose you now decide there is a second network where you want to allow access. Writing a rule that drops packets unless they are from network A or network B is probably only possible by reversing the logic and listing all the exceptions one-by-one. Which means listing separately every source you do want to accept and finally saying drop everything else.

[kevdog]

Id agree that it would probably be better to have a default drop policy or at least start a drop stance on port 22, and then specify exceptions.

madu
Are you using the script from your first link to set your iptables policy?

[madu]

Dear Cog and Kevdog,
Thank you very much for the replies. I guess the DROP everything except 131/8 doesnt really mean to ACCEPT 131/8.

# first set the default behaviour => accept connections
iptables -P INPUT ACCEPT
iptables -P OUTPUT ACCEPT
iptables -P FORWARD ACCEPT

# Create 2 chains, it allows to write a clean script
iptables -N FIREWALL
iptables -N TRUSTED

# Allow ESTABLISHED and RELATED incoming connection
iptables -A FIREWALL -i eth0 -m state --state ESTABLISHED,RELATED -j ACCEPT
# Allow loopback traffic
iptables -A FIREWALL -i lo -j ACCEPT
# Send all package to the TRUSTED chain
iptables -A FIREWALL -j TRUSTED
# DROP all other packets
iptables -A FIREWALL -j DROP

# Send all INPUT packets to the FIREWALL chain
iptables -A INPUT -j FIREWALL
# DROP all forward packets, we don't share internet connection in this example
iptables -A FORWARD -j DROP

iptables -A TRUSTED -i eth0 -p tcp -m tcp --dport 80 -j ACCEPT
iptables -A TRUSTED -i eth0 -p tcp -m tcp --dport 22 --source 131.0.0.0/8 -j ACCEPT
iptables -A TRUSTED -i eth0 -p tcp -m tcp --dport 22 --source ! 131.0.0.0/8 -j DROP

This is the iptable I'm using. This works fine. Was just wondering why I cant omit the 131/8 ACCEPT and use only 131/8 DROP statement.

Thanks heaps for the replies guys. Appreciate it.

[madu]

I would also like to know something else.
I just checked in my work machine, them machine I'm using to ssh connect to my home server, and there is no sshd_config file in /etc/ssh/.
In my home server there are both ssh_config and sshd_config.

I'm curious as to why one machine has sshd_config and one doesnt and also the difference between the two.

Also, if I want to make my machine look for the RSA private key somewhere other than the ~/.ssh/ida_rsa, how would I change it? In the ssh_config file,

# IdentityFile ~/.ssh/id_rsa

is commented out and there is no sshd_config file.

Appreciate the help guys. Thanks a lot.

Madu.

[kevdog]

Couple of things.

The sshd_config file is only for the ssh server. I'm inferring you do not have the openssh-server installed at your work machine.

In order to have the client use a different file name instead of the default id_rsa file, you can do a few things:
1. Connect via the command line specifying the name of the identity file explicity:
ssh -i another_rsa_file .... user@server.com

2. Copy the system wide ssh_config file from /etc/ssh/ssh_config to ~/.ssh/config. You are then free to alter this personal ssh_config file -- with duplicate settings the personal ssh_config file will take precedent, with different settings the system wide config file will be appended to the personal file. You can then start building a profile for your home computer such as:

Host myhomeserver
   HostName myhomeserver.com
   User username
   ForwardX11 yes
   RSAAuthentication yes
   PasswordAuthentication no
   CheckHostIP yes
   StrictHostKeyChecking ask
   IdentityFile ~/.ssh/identity
   IdentityFile ~/.ssh/NEW_FILE_NAME
   IdentityFile ~/.ssh/id_dsa
   Port 22
   Protocol 2
   Ciphers aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes2
56-cbc
   MACs hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-ripemd160
   EscapeChar ~
   PermitLocalCommand yes

You could then connect to your home computer simply by type
ssh myhomeserver

See man ssh_config for more options and thorough explanations

Does this help at all?

As far as the firewall question, I got to look something up!