Simple IPtables :: allow ACK packets

DaveQB · 08-27-2013, 01:49 AM

Hi all,

I thought I'd try and just use a simple shell script to control my firewall on a OpenVZ server as ufw fails due to a number of expected environments not being there in an OpenVZ container.

Many sites had nice simple commands to set up iptables, but all leaves me in a state where I can not get out. Doing a tcpdump I see a distinct difference.

A successful wget to an IP address with iptable rules set.

Code:

16:22:38.440189 IP serverhub02.56732 > chicago.dward.us.http: Flags [S], seq 830131992, win 14600, options [mss 1460,sackOK,TS val 37292524 ecr 0,nop,wscale 7], length 0
16:22:38.465109 IP chicago.dward.us.http > serverhub02.56732: Flags [S.], seq 1702390871, ack 830131993, win 14480, options [mss 1460,sackOK,TS val 3753499643 ecr 37292524,nop,wscale 6], length 0
16:22:39.439209 IP serverhub02.56732 > chicago.dward.us.http: Flags [S], seq 830131992, win 14600, options [mss 1460,sackOK,TS val 37293524 ecr 0,nop,wscale 7], length 0
16:22:39.464004 IP chicago.dward.us.http > serverhub02.56732: Flags [S.], seq 1702390871, ack 830131993, win 14480, options [mss 1460,sackOK,TS val 3753500642 ecr 37292524,nop,wscale 6], length 0
16:22:39.465638 IP chicago.dward.us.http > serverhub02.56732: Flags [S.], seq 1702390871, ack 830131993, win 14480, options [mss 1460,sackOK,TS val 3753500644 ecr 37292524,nop,wscale 6], length 0
16:22:41.439226 IP serverhub02.56732 > chicago.dward.us.http: Flags [S], seq 830131992, win 14600, options [mss 1460,sackOK,TS val 37295524 ecr 0,nop,wscale 7], length 0
16:22:41.464184 IP chicago.dward.us.http > serverhub02.56732: Flags [S.], seq 1702390871, ack 830131993, win 14480, options [mss 1460,sackOK,TS val 3753502642 ecr 37292524,nop,wscale 6], length 0
16:22:41.470093 IP chicago.dward.us.http > serverhub02.56732: Flags [S.], seq 1702390871, ack 830131993, win 14480, options [mss 1460,sackOK,TS val 3753502647 ecr 37292524,nop,wscale 6], length 0
16:22:45.440208 IP serverhub02.56732 > chicago.dward.us.http: Flags [S], seq 830131992, win 14600, options [mss 1460,sackOK,TS val 37299524 ecr 0,nop,wscale 7], length 0
16:22:45.465109 IP chicago.dward.us.http > serverhub02.56732: Flags [S.], seq 1702390871, ack 830131993, win 14480, options [mss 1460,sackOK,TS val 3753506643 ecr 37292524,nop,wscale 6], length 0
16:22:45.487716 IP chicago.dward.us.http > serverhub02.56732: Flags [S.], seq 1702390871, ack 830131993, win 14480, options [mss 1460,sackOK,TS val 3753506666 ecr 37292524,nop,wscale 6], length 0
16:22:53.439209 IP serverhub02.56732 > chicago.dward.us.http: Flags [S], seq 830131992, win 14600, options [mss 1460,sackOK,TS val 37307524 ecr 0,nop,wscale 7], length 0
16:22:53.464401 IP chicago.dward.us.http > serverhub02.56732: Flags [S.], seq 1702390871, ack 830131993, win 14480, options [mss 1460,sackOK,TS val 3753514642 ecr 37292524,nop,wscale 6], length 0
16:22:53.508392 IP chicago.dward.us.http > serverhub02.56732: Flags [S.], seq 1702390871, ack 830131993, win 14480, options [mss 1460,sackOK,TS val 3753514686 ecr 37292524,nop,wscale 6], length 0

The same wget call to the same IP after applying iptable rules

Code:

16:22:21.274340 IP serverhub02.56663 > chicago.dward.us.http: Flags [S], seq 3674578861, win 14600, options [mss 1460,sackOK,TS val 37275359 ecr 0,nop,wscale 7], length 0
16:22:21.299157 IP chicago.dward.us.http > serverhub02.56663: Flags [S.], seq 493537540, ack 3674578862, win 14480, options [mss 1460,sackOK,TS val 3753482478 ecr 37275359,nop,wscale 6], length 0
16:22:21.299175 IP serverhub02.56663 > chicago.dward.us.http: Flags [.], ack 1, win 115, options [nop,nop,TS val 37275383 ecr 3753482478], length 0
16:22:21.299226 IP serverhub02.56663 > chicago.dward.us.http: Flags [P.], seq 1:115, ack 1, win 115, options [nop,nop,TS val 37275383 ecr 3753482478], length 114
16:22:21.324089 IP chicago.dward.us.http > serverhub02.56663: Flags [.], ack 115, win 227, options [nop,nop,TS val 3753482503 ecr 37275383], length 0
16:22:21.418494 IP chicago.dward.us.http > serverhub02.56663: Flags [P.], seq 1:459, ack 115, win 227, options [nop,nop,TS val 3753482594 ecr 37275383], length 458
16:22:21.418511 IP serverhub02.56663 > chicago.dward.us.http: Flags [.], ack 459, win 123, options [nop,nop,TS val 37275503 ecr 3753482594], length 0
16:22:21.419041 IP serverhub02.56663 > chicago.dward.us.http: Flags [F.], seq 115, ack 459, win 123, options [nop,nop,TS val 37275503 ecr 3753482594], length 0
16:22:21.495269 IP chicago.dward.us.http > serverhub02.56663: Flags [F.], seq 459, ack 116, win 227, options [nop,nop,TS val 3753482674 ecr 37275503], length 0
16:22:21.495288 IP serverhub02.56663 > chicago.dward.us.http: Flags [.], ack 460, win 123, options [nop,nop,TS val 37275580 ecr 3753482674], length 0

The rules I am setting aren't anything tricky.

Code:

#! /bin/bash
iptables -F
iptables -X
echo Allow ssh
iptables -A INPUT -p tcp --dport 22 -j ACCEPT
echo Allow icmp
iptables -A INPUT -p icmp -j ACCEPT
echo Allow local
iptables -A INPUT -s 127.0.0.1 -j ACCEPT
echo Allow connections already made
iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A FORWARD -i venet0 -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A OUTPUT -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT
echo Reject all other traffic
#iptables -A INPUT -j DROP
iptables -A INPUT -j DROP
iptables -A FORWARD -j DROP

The state lines I thought would allow packets to come back to a connection established from the server. But it seems not to.

I tried these rules on hardware (my desktop) and same result so I feel I am missing something.

Thanks.

kbp · 08-27-2013, 07:48 PM

I think you have the successful and unsuccessful packet traces around the wrong way and a space in your shebang but regardless, please try the rules below and see if that works, I've commented them for clarity:

Code:

#!/bin/bash

# flush rules
iptables -F

# set policies
iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT ACCEPT

# accept packets related to connections initiated by us 
iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT

# allow anything from loopback interface
iptables -A INPUT -i lo -j ACCEPT

# allow certain types of ICMP traffic 
iptables -A INPUT -p icmp --icmp-type echo-request -j ACCEPT
iptables -A INPUT -p icmp --icmp-type echo-reply -j ACCEPT
iptables -A INPUT -p icmp --icmp-type destination-unreachable -j ACCEPT
iptables -A INPUT -p icmp --icmp-type time-exceeded -j ACCEPT

# allow inbound ssh connections 
iptables -A INPUT -p tcp -m state --state NEW -m tcp --dport 22 -j ACCEPT

DaveQB · 08-27-2013, 07:53 PM

Thanks kbp
I like your succinct script there.

I have just resolved the issue. The problem was the hardware host I was on didn't have the kernel modules loaded for connection tracking.

I am glad I am not going crazy

kbp · 08-27-2013, 08:05 PM

Me too .. I couldn't see anything obviously wrong

DaveQB · 08-27-2013, 08:21 PM

Right. Thanks mate.