LinuxQuestions.org - [SOLVED] Why is my iptables configuration not allowing traffic on localhost?

- Linux - Networking (https://www.linuxquestions.org/questions/linux-networking-3/)

- - Why is my iptables configuration not allowing traffic on localhost? (https://www.linuxquestions.org/questions/linux-networking-3/why-is-my-iptables-configuration-not-allowing-traffic-on-localhost-4175500081/)

Why is my iptables configuration not allowing traffic on localhost?

My iptables config is preventing munin from generating graphs. munin needs TCP port 4949 open on loopback. I don't understand WHY my iptables config isn't working as I explicitly ACCEPT INPUT and OUTPUT on the loopback. Can anyone tell me what's wrong here? I know that I can use: "A INPUT -p tcp -m tcp -s 127.0.0.1 -d 127.0.0.1 --dport 4949 -j ACCEPT" but I want ALL traffic on loopback to pass through.

Code:

*filter

 

# Drop everything by default

:INPUT DROP [0:0]

 

# We are not routing packets

:FORWARD DROP [0:0]

 

# Don't filter output

:OUTPUT ACCEPT [0:0]

 

# Add the fail2ban chain

:fail2ban-SSH - [0:0]

 

# Drop NULL packets

-A INPUT -p tcp --tcp-flags ALL NONE -j DROP

 

# Reject a syn-flood attack

-A INPUT -p tcp ! --syn -m state --state NEW -j DROP

 

# Drop XMAS packets

-A INPUT -p tcp --tcp-flags ALL ALL -j DROP

 

# We want our response packets...

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

 

# Anything over the Loopback is OK

-A INPUT -i lo -j ACCEPT

-A OUTPUT -o lo -j ACCEPT

 

# Send packets for port 22 to fail2ban, it may drop them

-A INPUT -p tcp -m tcp --dport 22 -j fail2ban-SSH

-A fail2ban-SSH -j RETURN

 

# If fail2ban didn't drop it let it on through

-A INPUT -p tcp -m tcp --dport 22 -j ACCEPT

 

# Open Web server

-A INPUT -p tcp -m tcp --dport 80 -j ACCEPT

-A INPUT -p tcp -m tcp --dport 443 -j ACCEPT



COMMIT

Quote:

Originally Posted by action_owl (Post 5144263)

Loopback traffic can come from (and be directed towards) any address in the 127.0.0.0/8 network, but you're right; an interface match ("-i lo") is better.

Are you saying that with your current setup, telnet 127.0.0.1 4949 fails to connect to the service? And that it works once you add a specific rule for incoming traffic to 127.0.0.1?

I can't find anything in your ruleset that would block loopback traffic in general, although there are some minor errors and the ordering is less than optimal. Your INPUT and FORWARD policies are DROP;

Code:

:INPUT DROP [0:0]

:FORWARD DROP [0:0]

In the filter ruleset, you first drop all TCP packets with no flags, which should be OK:

Code:

# Drop NULL packets

-A INPUT -p tcp --tcp-flags ALL NONE -j DROP

Then you have an impossible rule blocking non-SYN TCP packets which state is "NEW". The problem is, no TCP packet without the SYN flag set will ever match the "NEW" state, so while this rule doesn't do any damage, it's pointless and should be removed:

Code:

# Reject a syn-flood attack

-A INPUT -p tcp ! --syn -m state --state NEW -j DROP

Then TCP packets with every flag set are dropped:

Code:

# Drop XMAS packets

-A INPUT -p tcp --tcp-flags ALL ALL -j DROP

...and only NOW do you handle "ESTABLISHED" and "RELATED" packets, which means all these packets have to go through the above tests for no reason:

Code:

# We want our response packets...

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

Same goes for the loopback rules; they should have been much closer to the top of the ruleset. Having said that, the rules should still work:

Code:

# Anything over the Loopback is OK

-A INPUT -i lo -j ACCEPT

-A OUTPUT -o lo -j ACCEPT

Try the telnet test, and experiment by re-ordering the rules and perhaps try a minimal ruleset with only the "lo" and ESTABLISHED/RELATED state rules.

Thanks Ser, I really appreciate the detailed explanation I have really been trying to figure out how to to this as correctly as possible. I will make your suggestions and try the telnet test.

*update

port 4949 passed the telnet test so something else must be wrong. In my haste to try and fix the issue I must have fixed the issue by some other means and thought that it was the firewall. So my rules are indeed OK, thanks for helping me confirm that!