This is the old SliTaz forum - Please use the main

IPtables question ...
  • DarjeelingDarjeeling October 2010
    A couple of months ago I created a nice SliTaz 3.0 Live CD for a friend. Among many customizations I also changed the default iptables rules in /etc/firewall.conf by commenting out the last 6 rules as they seemed unnecessary and caused the Shields UP stealth test to fail.

    My current /etc/firewall.conf file looks like this ...

    # Network interface.

    # Enable/disable kernel security.

    # Enable/disable iptables rules (iptables package must be installed).

    # Netfilter/iptables rules. This shell function is included in
    # /etc/init.d/ to start iptables rules ...

    # Drop all input connections.
    iptables -P INPUT DROP

    # Drop all output connections.
    iptables -P OUTPUT DROP

    # Drop all forward connections.
    iptables -P FORWARD DROP

    # Accept input on localhost (
    iptables -A INPUT -i lo -j ACCEPT

    # Accept input on the local network (
    iptables -A INPUT -s -j ACCEPT

    # Accept near all output traffic.
    iptables -A OUTPUT -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT

    # Accept input trafic only for connections initialized by user.
    iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT

    Today I wanted to further improve my self-made 'SliTaz distro' by adding a short script that would allow my friend to temporarily open (and close again) a specific port for incoming TCP traffic, so she could use the BitTorrent client in Opera. I thought that something like this ...

    Open Port : iptables -I INPUT -p tcp --dport 18768 -j ACCEPT
    Close Port: iptables -D INPUT -p tcp --dport 18768 -j ACCEPT

    ... in combination with a token and swapping two .desktop files in /usr/share/applications (with red and green icons) would be an elegant solution to the problem. But when I made my first experiments with the iptables commands I noticed that none of this was necessary as the Opera BitTorrent client worked without having to open a dedicated port ... and I guess that the last of the above iptables rules ...

    # Accept input trafic only for connections initialized by user.
    iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT

    ... is responsible for this. But I'm wondering whether this is safe? Isn't it possible that by simply clicking on some sort of malicious link a user initiates a session where the opposite end can request any port to be opened up? Wouldn't it be much better to individually open standard ports like 20, 21, 23, 25, 143 etc. when they are needed?

  • GokhlayehGokhlayeh October 2010

    I added thesis line in iptable before stable release.

    In fact it's very secure, and was a security improvement in SliTaz. I explain how it works :
    When you use something like :
    iptables -I INPUT -p tcp --dport 18768 -j ACCEPT
    You open just a port, but this port is open to all input, so everyone can test the port and eventually does something malicious with it. If we talk about port 18768, it's not really a problem - I don't remember what range is dangerous, but I can tell that some hundreds of first port are more open to system attack.
    If we talk about port 80, or ping port -I don't remember the number-, it can be a real problem :
    * Everybody can use your ping port to know if you are here or not
    * Everybody can send stuff to your http port and your system will receive it, it includes send false answer from server you are trying to contact and malicious javascript/flash code etc... So there's a security hole here.

    When you use :
    iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT

    It use a special module of iptables (state). This module only allow input which is related to a connection you have previously open (RELATED,ESTABLISHED). It handle case where you send something trough a port and you're contact answer on another (like in some ftp/bitorrent case). But if someone want to test on of you're port, but you havn't previously established connection with him, iptable will only ignore his request : i.e. : he can't ping you.

    So it's a great -very secure and easy to use as it works with all ports- feature of iptable. When you use it, you don't have to open individually ports for input, except if you own a server, because server must wait for a connection established by client then answer to them.

    So... some port are completely open for input in default SliTaz iptables rules, like http and ping. It's not really secure, but team don't want to block people who are setting servers on their slitaz -it's one of the purpose of our distro. If you don't use server, you can use an even more secure iptable rule set, you can find an example of this here :

    (Edit) I just realize that it's what you did on your own iptable config :)

    Hope all is clear now.
  • DarjeelingDarjeeling October 2010
    Thanks very much for your reply, Gokhlayeh. Remembering what a major pain in the a.. it used to be under Windows to temporarily punch a hole in a (Comodo) firewall for P2P apps, BitTorrent and all that, I was surprised and a little shocked when I saw that my supposedly bomb-proof iptables FW was apparently wide open and "ready-for-use" by the Opera BitTorrent client. I'm glad you've explained that non-existing problem away. The "--state" option makes such an iptables command indeed a lot more secure and flexible than simply opening up a port. Thanks again, that was very helpful.
  • slicelslicel March 2011
    Gokhlayeh, how does yours compare with the handbook's?

    # Drop all connections.
    iptables -P INPUT DROP
    iptables -P OUTPUT DROP

    # Accept all on localhost (
    iptables -A INPUT -i lo -j ACCEPT
    iptables -A OUTPUT -o lo -j ACCEPT

    # Accept all on the local network (
    iptables -A INPUT -s -j ACCEPT
    iptables -A OUTPUT -d -j ACCEPT

    # Accept port 80 for the HTTP server.
    iptables -A INPUT -i $INTERFACE -p tcp --sport 80 -j ACCEPT
    iptables -A OUTPUT -o $INTERFACE -p tcp --dport 80 -j ACCEPT

    # Accept port 22 for SSH.
    iptables -A INPUT -i $INTERFACE -p tcp --dport 22 -j ACCEPT
    iptables -A OUTPUT -o $INTERFACE -tcp --sport 22 -j ACCEPT

    # Accept port 21 for active FTP connections.
    iptables -A INPUT -i $INTERFACE -p tcp --dport 21 -j ACCEPT
    iptables -A OUTPUT -i $INTERFACE -p tcp --sport 21 -j ACCEPT

    Firewall.conf only lists eth0.  Does that mean a user loses the firewall when switching to wifi or dialup?

    Thank you

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Sign In Apply for Membership

SliTaz Social