Page 1 of 5 123 ... LastLast
Results 1 to 10 of 46

Thread: Iptable rule confusion.

  1. #1
    Join Date
    Jan 2006
    Location
    Japan
    Beans
    235
    Distro
    Ubuntu 9.04 Jaunty Jackalope

    Iptable rule confusion.

    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.
    Last edited by madu; June 22nd, 2008 at 08:26 AM.

  2. #2
    Join Date
    Mar 2007
    Location
    Denver, CO
    Beans
    7,726
    Distro
    Ubuntu Mate 16.04 Xenial Xerus

    Re: Iptable rule confusion.

    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?

  3. #3
    Join Date
    Jan 2006
    Location
    Japan
    Beans
    235
    Distro
    Ubuntu 9.04 Jaunty Jackalope

    Re: Iptable rule confusion.

    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.

  4. #4
    Join Date
    Nov 2007
    Location
    London, England
    Beans
    6,262
    Distro
    Xubuntu 17.10 Artful Aardvark

    Re: Iptable rule confusion.

    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:

    Code:
    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:
    Code:
    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.
    Last edited by The Cog; June 22nd, 2008 at 12:30 PM.

  5. #5
    Join Date
    Jan 2006
    Location
    Japan
    Beans
    235
    Distro
    Ubuntu 9.04 Jaunty Jackalope

    Re: Iptable rule confusion.

    Quote Originally Posted by The Cog View Post
    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:

    Code:
    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:
    Code:
    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?

  6. #6
    Join Date
    Nov 2007
    Location
    London, England
    Beans
    6,262
    Distro
    Xubuntu 17.10 Artful Aardvark

    Re: Iptable rule confusion.

    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:
    Code:
    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:
    Code:
    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.

  7. #7
    Join Date
    Mar 2007
    Location
    Denver, CO
    Beans
    7,726
    Distro
    Ubuntu Mate 16.04 Xenial Xerus

    Re: Iptable rule confusion.

    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?

  8. #8
    Join Date
    Jan 2006
    Location
    Japan
    Beans
    235
    Distro
    Ubuntu 9.04 Jaunty Jackalope

    Re: Iptable rule confusion.

    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.

  9. #9
    Join Date
    Jan 2006
    Location
    Japan
    Beans
    235
    Distro
    Ubuntu 9.04 Jaunty Jackalope

    Re: Iptable rule confusion.

    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.

  10. #10
    Join Date
    Mar 2007
    Location
    Denver, CO
    Beans
    7,726
    Distro
    Ubuntu Mate 16.04 Xenial Xerus

    Re: Iptable rule confusion.

    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:

    Code:
    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!

Page 1 of 5 123 ... LastLast

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •