1

Error

As you can see, the only difference between the working and the not working configuration is -m conntrack --ctstate NEW,ESTABLISHED,RELATED. If I use -m conntrack --ctstate NEW,ESTABLISHED it does not work either... But Why?!

After few tests, I have noticed that every rules using conntrack does not work... Can you explain me why is SSH blocked by iptables only when I use conntrack?

Thanks :-)

Working configuration

#!/bin/bash

SERVER_IP="X.X.X.X"

iptables -F
iptables -X

# Setting default filter policy
iptables -P INPUT DROP
iptables -P OUTPUT ACCEPT
iptables -P FORWARD DROP

# Allow previous connections
iptables -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
iptables -A OUTPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT

# Allow unlimited traffic on loopback
iptables -A INPUT -i lo -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT

# Allow incoming ssh only
iptables -A INPUT -p tcp -s 0/0 -d ${SERVER_IP} --dport 22 -j ACCEPT
iptables -A INPUT -p tcp -s 0/0 -d ${SERVER_IP} --dport 22 -j LOG --log-prefix "[ACCEPT INPUT][SSH] "


# make sure nothing comes or goes out of this box
iptables -A INPUT -j LOG --log-prefix "[DROP INPUT][DEFAULT] "
iptables -A INPUT -j DROP

Not working configuration

#!/bin/bash

SERVER_IP="X.X.X.X"

iptables -F
iptables -X

# Setting default filter policy
iptables -P INPUT DROP
iptables -P OUTPUT ACCEPT
iptables -P FORWARD DROP

# Allow previous connections
iptables -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
iptables -A OUTPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT

# Allow unlimited traffic on loopback
iptables -A INPUT -i lo -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT

# Allow incoming ssh only
iptables -A INPUT -p tcp -s 0/0 -d ${SERVER_IP} --dport 22 -m conntrack --ctstate NEW,ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -p tcp -s 0/0 -d ${SERVER_IP} --dport 22 -m conntrack --ctstate NEW,ESTABLISHED,RELATED -j LOG --log-prefix "[ACCEPT INPUT][SSH] "


# make sure nothing comes or goes out of this box
iptables -A INPUT -j LOG --log-prefix "[DROP INPUT][DEFAULT] "
iptables -A INPUT -j DROP

[EDIT]

How am I sure that conntrack is involved?

Because in the log file I can see something like this :

[DROP][INPUT] IN=eth0 OUT= MAC=0c:c4:...:00 SRC=X.X.X.X DST=X.X.X.X LEN=67 TOS=0x08 PREC=0x20 TTL=41 ID=39550 DF PROTO=TCP SPT=51093 DPT=22 WINDOW=229 RES=0x00 ACK PSH URGP

[DROP][INPUT] is the last rule in my iptables configuration file.

Improve this question
9
  • And how do you recognize that the rules with -m conntrack do not work? Because you do not see log entry? Your rules are built in a way that you WILL NOT reach logging entries which follow -j ACCEPT rules (as it terminates processing).
    – Tomek
    Dec 15, 2018 at 15:18
  • That's right, this is an error. But I recognize that the rules with -m conntrack do not work because logs are only [DROP][INPUT], so this is my default rule.
    – flexbrane
    Dec 15, 2018 at 15:22
  • Does the DST=X.X.X.X from log file match with your ${SERVER_IP}?
    – Tomek
    Dec 15, 2018 at 15:48
  • The log entry you posted doesn't correspond to any of the iptables rules you posted. What is the real log entry and real iptables rules?
    – Michael Hampton
    Dec 15, 2018 at 16:15
  • @Tomek : yes DST=<My Server IP>
    – flexbrane
    Dec 15, 2018 at 16:36

2 Answers 2

Reset to default
1

This time I know how to make it work, without knowing why this is not working. Restarting iptables service make my script working: systemctl restart iptables.

Before working on this simple script, I was trying to implement another one, much more longer. It apply new rules in other CHAINS like PREROUTING and other customs. This script must have forced iptables to stop working with cstate or conntrack, maybe by filling a table to it maximum?

Improve this answer
0

Thank you all for your answers! I finally figured it out, when I have removed firewalld in favor of iptables it seems that I have remove also some dependencies. After removing and then installing again iptables my configuration became fonctionnal.

[EDIT] Actualy this is still not working :-(

In logs I noticed that "SYN" and "ACK SYN" paquets are dropped by iptables:


Dec 17 08:03:38 loki kernel: [DROP][INPUT][DEFAULT] IN=eth0 OUT= MAC=0c:c4:...:00 SRC=myIP DST=serverIP LEN=52 TOS=0x00 PREC=0x00 TTL=120 ID=12527 DF PROTO=TCP SPT=51942 DPT=22 WINDOW=64240 RES=0x00 SYN URGP=0
Dec 17 08:03:38 loki kernel: [DROP][OUTPUT][DEFAULT] IN= OUT=eth0 SRC=serverIP DST=myIP LEN=52 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=TCP SPT=22 DPT=51942 WINDOW=29200 RES=0x00 ACK SYN URGP=0
Dec 17 08:03:38 loki kernel: [INPUT][DROP][NOT SYN] IN=eth0 OUT= MAC=0c:c4:...:00 SRC=myIP DST=serverIP LEN=40 TOS=0x00 PREC=0x00 TTL=120 ID=12528 DF PROTO=TCP SPT=51942 DPT=22 WINDOW=256 RES=0x00 ACK URGP=0
Dec 17 08:03:38 loki kernel: [ACCEPT][INPUT][SSH] IN=eth0 OUT= MAC=0c:c4:...:00 SRC=myIP DST=serverIP LEN=40 TOS=0x00 PREC=0x00 TTL=120 ID=12528 DF PROTO=TCP SPT=51942 DPT=22 WINDOW=256 RES=0x00 ACK URGP=0
Dec 17 08:03:38 loki sshd[5074]: Connection from myIP port 51942 on serverIP port 22
Dec 17 08:03:39 loki sshd[5074]: Accepted password for myUSER from myIP port 51942 ssh2
Dec 17 08:03:39 loki systemd-logind: New session 307 of user myUSER.
Dec 17 08:03:39 loki systemd: Started Session 307 of user myUSER.

As you will see in my rules, I did not drop paquets for real for my tests, to keep connected to my server. Here the script used:


    #!/bin/bash

    #
    # =========
    # Reset ALL
    # =========
    #
    iptables="iptables"
    ip6tables="ip6tables"

    # HARD RESET
    $iptables -P INPUT ACCEPT
    $iptables -P FORWARD ACCEPT
    $iptables -P OUTPUT ACCEPT
    $iptables -F
    $iptables -X
    # $iptables -t nat -F
    # $iptables -t mangle -F


    ## Drop broadcast (without log)
    $iptables -A INPUT -m pkttype --pkt-type broadcast -j DROP
    $iptables -A FORWARD -m pkttype --pkt-type broadcast -j DROP
    $iptables -A INPUT -d 255.255.255.255 -j DROP
    $iptables -A FORWARD -d 255.255.255.255 -j DROP

    # Keep connections opened
    # DO NOT USE RELATED? https://gist.github.com/azlux/6a70bd38bb7c525ab26efe7e3a7ea8ac
    $iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
    $iptables -A OUTPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

    #
    # ===============
    # Allow localhost
    # ===============
    #
    $iptables -A INPUT -i lo -j ACCEPT
    $iptables -A OUTPUT -o lo -j ACCEPT

    #
    # ====
    # IPv6
    # ====
    #
    $ip6tables -P INPUT DROP
    $ip6tables -A OUTPUT -j REJECT
    $ip6tables -P FORWARD DROP

    #
    # ===========
    # Allow ports
    # ===========
    #

    ## NEW NOT SYNC
    $iptables -A INPUT -p tcp ! --syn -m conntrack --ctstate NEW -j LOG --log-prefix "[INPUT][DROP][NOT SYN] "

    ## DNS (no logs)
    $iptables -A OUTPUT -p udp -s 0/0 --dport 53 -m conntrack --ctstate NEW,RELATED,ESTABLISHED -j ACCEPT
    $iptables -A INPUT -p udp --sport 53 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT


    ## SSH
    $iptables -A INPUT -p tcp -s 0/0 --dport 22 -m conntrack --ctstate NEW,RELATED,ESTABLISHED -j LOG --log-prefix "[ACCEPT][INPUT][SSH] "
    $iptables -A INPUT -p tcp -s 0/0 --dport 22 -m conntrack --ctstate NEW,RELATED,ESTABLISHED -j ACCEPT
    $iptables -A OUTPUT -p tcp --sport 22 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT

    #
    # =================
    # Logs DROP paquets
    # =================
    #
    $iptables -A INPUT -j LOG --log-prefix="[DROP][INPUT][DEFAULT] "
    $iptables -A FORWARD -j LOG --log-prefix="[DROP][FORWARD][DEFAULT] "
    $iptables -A OUTPUT -j LOG --log-prefix="[DROP][OUTPUT][DEFAULT] "

    exit 0
Improve this answer
3
  • 1
    I still suspect that conntrack or ctstate is involved. Is there some prerequisites or something to check?
    – flexbrane
    Dec 17, 2018 at 7:43
  • I recently have encountered this problem. It happened after a server upgrade which required a reinstall. I used my long working iptables scripts and then I've had firewall problems. I have noticed it's the conntrack ctstate that is causing a problem. It's bizarre. I should be able to check for state NEW and that there's a SYN flag. Even having just ctstate NEW without the SYN it fails. Add a rule that doesn't check state and it's fine! It makes no sense at all. I even tested my RAM I was so at odds. I asked a long time friend who I thought might have an answer and he doesn't either!
    – Pryftan
    Dec 11, 2019 at 17:01
  • And given that it worked before I don't think there is a prerequisite here unless there was some change made that I'm unaware of. I don't know why that would only show itself on a new install though. I was considering nftables but it's at the point I just want the thing to work and CentOS 7 doesn't have the translation tool (though I have access to it I don't know if there are any compatibility issues from Fedora to CentOS 7).
    – Pryftan
    Dec 11, 2019 at 17:03

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .