Find the answer to your Linux question:
Results 1 to 10 of 10
I'm doing a lot of reading and I stumbled upon something that I didn't understand. While I completely understand the command and what rules are being set up, I'm not ...
Enjoy an ad free experience by logging in. Not a member yet? Register.
  1. #1
    Linux Engineer
    Join Date
    Nov 2002
    Location
    Queens, NY
    Posts
    1,319

    more iptables


    I'm doing a lot of reading and I stumbled upon something that I didn't understand. While I completely understand the command and what rules are being set up, I'm not understanding why it has to be done.
    Code:
    # First, set a rule that allows ssh within the network on the INPUT chain.
    iptables -A INPUT -s 198.168.0.0 -p tcp --destination-port ssh -j ACCEPT 
    
    # Next, block any connections from outside your internal network
    iptables -A INPUT -s ! 198.168.0.0 -p tcp --destination-port ssh -j DROP
    If I have one network 192.168.0.0/24, why do I need the first rule? I can see that the second rule blocks out any IP ranges from 192.168.0.0/24 using TCP, with port 22 but the first rule is unclear to me. Furthrmore, is the notation 192.168.0.0 a valid one? As far as I understand, isn't that the wire?
    The best things in life are free.

  2. #2
    Linux Guru
    Join Date
    Oct 2001
    Location
    Täby, Sweden
    Posts
    7,578
    I believe that it should be 192.168.0.0/24, which specifies a 24-bit netmask as well. However, I guess that if you don't specify the netmask, it will be determined automatically from the address. Since you specify the network address (address & ~netmask == 0) and 192 is 11000000 (begins with two ones), iptables might assume it to be a class C net, which has a 24-bit netmask.

    I agree with you that the first might be unnecessary, but only under the provision that your INPUT chain has ACCEPT as its default policy. Otherwise, it's good to have there.
    On the other hand, I don't see why it should be necessary at all. SSH should certainly be secure enough to expose to the internet.

  3. #3
    Linux Engineer
    Join Date
    Nov 2002
    Location
    Queens, NY
    Posts
    1,319

    more questions

    OK, thanks for clearing that up. I'm going to be asking a lot more questions so I hope you can bear with me. Now as far as I can tell from reading, this is the impression that I get with the three chains. INPUT is anything that is trying to connect from the outside to the internal network. OUTPUT is when a packet is leaving the internal network. Which direction is FORWARD? I haven't seen too many examples with this but I'm having a difficult time grapsing this concept.
    The best things in life are free.

  4. $spacer_open
    $spacer_close
  5. #4
    Linux Engineer
    Join Date
    Nov 2002
    Location
    Queens, NY
    Posts
    1,319
    BTW, isn't the default INPUT chain ACCEPT?
    The best things in life are free.

  6. #5
    Linux Guru
    Join Date
    Oct 2001
    Location
    Täby, Sweden
    Posts
    7,578
    I think you have gotten it a bit wrong. For the normal "filter" table, it works like this:
    When a packet arrives from the outside network, it is passed through the INPUT chain to determine its fate. It has nothing to do with connecting, it just happens with every IP packet that arrives through your NIC.
    When a packet is going to be sent, it is passed through the OUTPUT chain to determine its fate.
    When a packet has arrived that is not destined for your system, but is going to be routed (providing that you have turned on IP forwarding through /proc/sys/net/ip_forward and have your routing tables set up, of course), it is passed through the FORWARD chain. It is still passed through both the INPUT and OUTPUT chains, but is also passed through FORWARD in between.

    So you see, it doesn't have anything to do with the "direction" of packets; different chains are simply called when certain events are triggered during a packet's lifetime in RAM.

  7. #6
    Linux Guru
    Join Date
    Oct 2001
    Location
    Täby, Sweden
    Posts
    7,578
    Oh, yeah, I forgot. The INPUT chain's default policy defaults to ACCEPT, but you can set it to other things. I'm not sure what targets are valid for default policies, though; it might be only ACCEPT and DROP (and possibly QUEUE).

  8. #7
    Linux Engineer
    Join Date
    Nov 2002
    Location
    Queens, NY
    Posts
    1,319
    INPUT - when packets are coming in
    OUTPUT - when packets are leaving

    Perhaps I'm not understanding this correctly but it sure seems like INPUT handles all the incoming packets (hence outside the network coming into internal network) to the firewall and OUPUT handles all packets leaving (from internal network to the outside network). Is this correct so far?

    FORWARD ... can you give me simple examples of how it uses both INPUT and OUTPUT?
    The best things in life are free.

  9. #8
    Linux Guru
    Join Date
    Oct 2001
    Location
    Täby, Sweden
    Posts
    7,578
    Well, I don't know exactly how the netfilter architecture works, so I'm not sure if all architectural aspect are 100% correct, but I'll give you three examples that should pretty well describes at least what appears to happen:

    1:
    A packet is received on an interface that is actually intended for the machine. As soon as it has traversed the first code of receiving it from the interface and verifying its MAC address, matching it with an established TCP connection (note that at this stage, this is matched against the ip_conntrack tables, not by the socket table as returned by netstat) and so on, the INPUT chain is called to check it out. The netfilter code calls each relevant match module and if they match, it passes the packet on to the match handler, or stops if the target was ACCEPT. If the packet was accepted, the netfilter code returns and the packet is passed on to the actual protocol stack, which matches it against a socket and passes it on to userspace, to the process that owned the socket (or returns an ICMP or TCP error if there was no socket that wanted the packet).

    2:
    Some process wants to send data. The protocol stack handles the packet and slaps on a TCP or UDP and an IP header on the data. After that, the netfilter code is called upon to check the packet against the OUTPUT chain. If the result is ACCEPT, then the packet is handed on to the interface device driver, which transmits it on the wire.

    3:
    The machine is a router and receives a packet which is intended for another network which the machine routes to. Again, the packet's MAC address is checked and the conntrack tables checked and so on, and the packet passed through the INPUT chain. Only this time, if the packet was ACCEPTed, it is not passed to the protocol stack, but to the forwarding code, that matches it against the routing tables (as returned by route(8) or by "ip route ls"). If it cannot match the packet against a routing entry, it returns an ICMP error to the sender. If it does match the packet, though, it sends it to the netfilter code which (here it comes =) ) passes it through the FORWARD chain. If the packet was ACCEPTed by the FORWARD chain, the forwarding code passes the packet on to the output code, which passes it through the OUTPUT chain and sends it as in example 2.

    So, you might think of something like this "pseudo-machine":
    Code:
            -----  -----  -----  -----  -----   -----  -----  -----
    1 -> ---| 2 |--| 3 |--| 4 |--| 6 |--| 7 |---| 9 |--| A |--| B |--- -> C
            -----  -----  -----  -----  -----   -----  -----  -----
                            |                     |
                          -----  -------------  -----
                          | 5 |--| Userspace |--| 8 |
                          -----  -------------  -----
    The numbering is arbitrary, I just wanted to save space so that it wouldn't wrap for those with lower vertical resolutions than what I have by not typing out the actual text.
    Anyway, think of the lines between the boxes as "pipes", through which the packets flow. Think of the boxes as small "machines" that do stuff with the packets.
    Here is what it should say instead of the numbers:
    1: Physical wire; packets come in from here.
    2: NIC device driver and initial matching code, that checks the MAC address and conntrack tables and so on.
    3: iptables INPUT chain; packets are only passed on if the final resolution of the chain is ACCEPT. Note that some iptables targets don't terminate the chain, but alter the packet and passes it on to later rules. See the iptables manpage for more on this.
    4: "IP Valve"; If the packet is intended for the system's own IP address, it is passed downwards, otherwise to the right.
    5: The protocol stack, input half; IP and TCP/UDP headers are decoded, the packet is matched against the socket table and so on.
    6: Forwarding code; checks so that /proc/sys/net/ip_forward is on, matches the packet against the routing tables, etc.
    7: iptables FORWARD chain; packets are only passed on if the final resolution is ACCEPT.
    8: The protocol stack, output half; TCP/UDP and IP headers are prepended to the packet, etc.
    9: NOOP; does nothing, just combines the packets coming from below and from the left and passes them on.
    A: iptables OUTPUT chain; packets are only passed on if the final resolution is ACCEPT.
    B: Output code and NIC device driver; build the ethernet header and sends the packet to the NIC.
    C: Physical wire; packets are transmitted here.
    Note that the Userspace box should not be considered as a "pass-through" box like the others. Packets coming into it do usually not return on the right (of course, that's not necessary, userspace processes might of course forward the packets themselves, as is the case with SOCKS servers... =) ).

    Note also, that this is extremely simplified. Not only is the IP code much more advanced, but there are also the other iptables tables: "nat" and "mangle". This only describes the workings of the "filter" table.

  10. #9
    Linux Engineer
    Join Date
    Nov 2002
    Location
    Queens, NY
    Posts
    1,319
    Suppose I have a machine set up as a router that's doing NAT and packet filtering.

    On this machine, these are the following information:
    a. eth0 - external interface
    b. eth1 - internal interface
    c. machine's internal IP - 192.168.1.1

    The external network is setup to as DHCP and internal network is 192.168.1.0/24.

    If I want to set want to set up NAT, I'm hearing that I have to use MASQUERADE since if the external network obtains it's IP by DHCP. I have found the following code on the internet.

    Code:
    iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
    
    # Turn on IP forwarding
    echo 1 > /proc/sys/net/ipv4/ip_forward
    Is that code enough to turn on NAT? I'm thinking something like the following needs to be set up.

    Code:
    # Forward all packets not destined to this machine to the external interface (eth0)
    iptables -A FORWARD -i eth1 -o eth0 -d ! 192.168.1.1
    
    iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
    
    # Turn on IP forwarding
    echo 1 > /proc/sys/net/ipv4/ip_forward
    As you can see, I've really added just one line of command. Isn't that line needed for NAT to work?
    The best things in life are free.

  11. #10
    Linux Guru
    Join Date
    Oct 2001
    Location
    Täby, Sweden
    Posts
    7,578
    No, that line that you added doesn't do anything. The -o option is a packet matcher, it doesn't specify what interface to send to packets out on. You don't specify that with iptables; that's done in the routing tables. Since the routing tables are usually set up to mostly everyone's content automagically, the code in the first block is sufficient.

    Just to let you know, the difference between MASQUERADE and SNAT is that MASQUERADE is a special case of SNAT, so to speak. When packets are NAT'ed with MASQUERADE, their source address is set to the address of the interface that they're going out on, plus that the connection tracking entries that they correspond to are flagged so that they will be purged if the interface goes down. It's far easier than having to specify the new source address to SNAT everytime the interface's IP address changes. I, on the other hand, use SNAT since I have a static IP address; if my interface would go down for any reason, I wouldn't want the conntrack entries purged.

Posting Permissions

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