How do you set up your iptables?

opethdisciple

opethdisciple

opethdisciple

Soldato
Joined
18 May 2010
Posts
22,892
Location
London
Do you set the default policy to accept and then include at the bottom of the rules a reject all, or is it better to set the default policy to drop but then add in your exclusions?

Leads me on to a second question which I haven't got my head round yet. We are having some issues at work with an IPS deny/blocking/dropping packets between clients and servers which makes it a tad more complex to work out what effect my iptables are having on connectivity.

Scenario is this:

I deployed a web app that has a section where you can set up LDAP authentication, which I have done and is working. It is this part that the IPS is getting fussy about and sometimes logging in takes ages/times out and others times it works.

Anyway.....

So I set up the iptables like this:

Chain INPUT (policy DROP 2 packets, 72 bytes)
pkts bytes target prot opt in out source destination
0 0 ACCEPT all -- lo any anywhere anywhere
49 5844 ACCEPT tcp -- any any anywhere anywhere tcp dpt:ssh
0 0 ACCEPT tcp -- any any anywhere anywhere tcp dpt:tproxy

Chain FORWARD (policy DROP 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination

Chain OUTPUT (policy DROP 774 packets, 55134 bytes)
pkts bytes target prot opt in out source destination
0 0 ACCEPT all -- any lo anywhere anywhere
33 5009 ACCEPT all -- any any anywhere anywhere state RELATED,ESTABLISHED

My question is, LDAP is configured to use port 389 to the Active directory. Will I need to open up these ports in the OUTPUT chain or will the fact that I have specified that any connection that is initiated first is allowed out also cover these connections?

Hard to tell if it's the firewall blocking LDAP authentication or if the IPS is the issue.
 
Last edited:
Yeah I have an explicit DROP, to be safer. On my Linux boxes I add a LOGGING chain, then i pass all of my INPUT, WEB, etc chains to LOGGING at the end, like so on my owncloud server:

Code: 
# First rules
 iptables -I INPUT 1 -s 127.0.0.1 -j ACCEPT -m comment --comment "allow anything that comes from lo"
 iptables -I INPUT 2 -d 192.168.0.55/32 -p tcp --dport 443 -j f2b-owncloud -m comment --comment "HTTPS to owncloud chain"
 iptables -I INPUT 3 -m state --state ESTABLISHED,RELATED -j ACCEPT -m comment --comment "allow anything established/related"
 iptables -I INPUT 4 -s 192.168.0.0/24 -d 192.168.0.55/32 -p tcp --dport 1022 -j ACCEPT -m comment --comment "ssh to server, keys only"
 iptables -I INPUT 5 -s 192.168.0.44/32 -d 192.168.0.55/32 -p tcp --dport 5666 -j ACCEPT -m comment --comment "Opsview Agent"
# Fail2ban for Owncloud
 iptables -N f2b-owncloud 
 iptables -I f2b-owncloud 1 -p tcp -s 192.168.0.0/24 -d 192.168.0.55/32 --dport 443 -j ACCEPT -m comment --comment "Local subnet via hosts files"
 iptables -I f2b-owncloud 2 -p tcp -s x.x.x.x/8 -d 192.168.0.55/32 --dport 443 -j ACCEPT -m comment --comment "Work Subnet"
 iptables -I f2b-owncloud 3 -p tcp -d 192.168.0.55/32 --dport 443 -m set --match-set gb src -j ACCEPT -m comment --comment "Only GB IPs allowed from WWW"
 iptables -A f2b-owncloud -j LOGGING
# Logging rules
 iptables -N LOGGING
 iptables -A INPUT -j LOGGING
 iptables -I LOGGING 1 -d 255.255.255.255/32 -j DROP -m comment --comment "Broadcast noise"
 iptables -I LOGGING 2 -d 192.168.0.255/32 -j DROP -m comment --comment "Broadcast noise"
 iptables -I LOGGING 3 -d 172.17.255.255/32 -j DROP -m comment --comment "Broadcast noise"
 iptables -A LOGGING -m limit --limit 2/min -j LOG --log-prefix "IPTables-Dropped: " --log-level 4
 iptables -A LOGGING -j DROP -m comment --comment "drop everything else after logging it"

I use ipset and a script to create an ipset rule for only GB IPs, so that anyone coming to my HTTPS interface of my server from a non-GB IP gets timeouts essentially. Documented here for interest. I also use fail2ban to only allow those coming from a GB IP address 5 failed logins before an explicit 'DROP' rule is added to the f2b-owncloud chain (howto here).

The above is a bash script I run at boot, btw, along with a lot more - i just trimmed it down for simplicity.
 
So it's been a while since I did iptables but as you are using a default policy of DROP on the OUTPUT chain, and you only have a rule that allows RELATED or ESTABLISHED connections, then I suspect you cannot initiate connections. Unless of course the connection is initated with the loopback IP?

You may need something like...

iptables -A OUTPUT -o eth0 -p tcp --dport 389 -m state --state NEW,ESTABLISHED -j ACCEPT

Assuming eth0 is the relevant interface..

If the LDAP connection is a response (i.e. it's iniated by another host), then the rule you have already will allow the return traffic
 
What I ended up doing was this:

# iptables -P INPUT ACCEPT
# iptables -F
# iptables -A INPUT -i lo -j ACCEPT
# iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
# iptables -A INPUT -p tcp --dport 22 -j ACCEPT
# iptables -A INPUT -p tcp --dport 8081 -j ACCEPT
# iptables -P INPUT DROP
# iptables -P FORWARD DROP
# iptables -P OUTPUT ACCEPT

But as an inexperienced admin not quite sure WHY this works. the web app I deployed using port 8081. I understand that part. But the LDAP connection it makes to authenticate users uses port 389. Explicitly opening UDP and TCP port 389 was unsuccessful, but the iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT statement seems to work.

The LDAP connections are not happening on the local machine but to a remote Domain Controller.

Is this because it is saying if the new incoming connection is part of an established connection already (i.e traffic already coming in on port 8081) then allow it through?

Still puzzled as I would have though the out bound connections would the one the LDAP connection is making. And that was already set to OUTPUT ACCEPT.

Anyway, it seems to work. Just don't understand why. :p
 
I pinched the following from Serverfault as it sums it up nicely and saves me some typing :p

NEW -- meaning that the packet has started a new connection, or otherwise associated with a connection which has not seen packets in both directions, and

ESTABLISHED -- meaning that the packet is associated with a connection which has seen packets in both directions,

RELATED -- meaning that the packet is starting a new connection, but is associated with an existing connection, such as an FTP data transfer, or an ICMP error.

So, while you have the OUTPUT ACCEPT rule, you'll still need that INPUT rule for ESTABLISHED to allow the return traffic from the LDAP request.

In terms of this rule:

# iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

This is making iptables stateful; i.e aware of related and established connections.

Hope this clears it up a bit :)
 
opethdisciple said:
Would you say that adding in iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT could be considered something you should do as standard?
Click to expand...

Yes, absolutely :)

Without this rule the return traffic won't be allowed, as you experienced with the LDAP connections.

As a minimum with iptables I would have something like this to allow outbound traffic only:

Code: 
# iptables -P INPUT DROP
# iptables -P FORWARD DROP
# iptables -P OUTPUT ACCEPT
# iptables -A INPUT -m state --state NEW,ESTABLISHED -j ACCEPT
# iptables -L -v -n

Check out this handy primer (where the above comes from): https://www.cyberciti.biz/tips/linux-iptables-examples.html
 
Last edited:
You must log in or register to reply here.
Back
Top Bottom