Local port access blocked by iptables

Question

Although experienced with Linux, I'm new to iptables, having set it up following a Rackspace virtual server setup guide.

Using port scans and checking remote access to required ports, I can see all traffic is being blocked except for the ports I've specifically opened up.

However I can't access ports I've opened up locally (e.g. w3m http://localhost:4848).

Here are my iptables rules:

# Generated by iptables-save v1.4.12 on Tue Oct  7 20:06:11 2014
*filter
:INPUT DROP [44:3960]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [184:19472]
-A INPUT -i eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -i eth1 -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p tcp -m tcp --dport 22 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 80 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 443 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 4848 -j ACCEPT
COMMIT
# Completed on Tue Oct  7 20:06:11 2014

As dumped by sudo iptables -L -n -v

Chain INPUT (policy DROP 45 packets, 4050 bytes)
 pkts bytes target     prot opt in     out     source               destination         
  106 10697 ACCEPT     all  --  eth0   *       0.0.0.0/0            0.0.0.0/0            state RELATED,ESTABLISHED
    0     0 ACCEPT     all  --  eth1   *       0.0.0.0/0            0.0.0.0/0            state RELATED,ESTABLISHED
    1    64 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:22
    0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:80
    0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:443
    0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:4848
    0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:8080

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

Chain OUTPUT (policy ACCEPT 77 packets, 9149 bytes)
 pkts bytes target     prot opt in     out     source               destination

More output as requested in comments:

$ip link show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN 
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether XX:XX:XX:XX:XX:XX brd ff:ff:ff:ff:ff:ff
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether XX:XX:XX:XX:XX:XX brd ff:ff:ff:ff:ff:ff

$ ip addr show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN 
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether XX:XX:XX:XX:XX:XX brd ff:ff:ff:ff:ff:ff
    inet XXX.XXX.XXX.XXX/24 brd XXX.XXX.XXX.255 scope global eth0
    inet6 XXXX::XXXX:XXXX:XXXX:XX/64 scope link 
       valid_lft forever preferred_lft forever
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether XX:XX:XX:XX:XX:XX brd ff:ff:ff:ff:ff:ff
    inet XXX.XXX.XXX.XXX/19 brd XXX.XXX.XXX.255 scope global eth1
    inet6 XXXX::XXXX:XXXXX:XXXX:XXXX/64 scope link 
       valid_lft forever preferred_lft forever

I suspect the lack of local access to these ports as the underlying cause of glassfish not working properly.

So my questions are:

How can I open up local access to these ports, without compromising remote security?
Are there any other recommended changes you would make to improve security?

Could you replace the `iptables -L` output above with that of `iptables -L -n -v`? The interface information is crucial, and the packet counts it gives are also helpful in these cases. — MadHatter, Oct 09 '14 at 08:24
On which "interface" are they bound ? What's your routing table ? — Xavier Lucas, Oct 09 '14 at 08:58
also add detail on your network setings; "ip link show" "ip addr show" (or ifconfig) — tonioc, Oct 09 '14 at 09:25
Interesting. Try to add `iptables -I INPUT -i lo -j ACCEPT`. But also paste info other users have requested here. — Glueon, Oct 09 '14 at 09:27
Thanks guys - I've updated the question with the requested info. — Andrew Ebling, Oct 09 '14 at 12:38
@Glueon: `sudo iptables -I INPUT -i lo -j ACCEPT` does indeed fix it. Is that a permanent solution, or more of a diagnostic step? — Andrew Ebling, Oct 09 '14 at 12:47
No, that's a normal practice to allow connections to your loopback device via separate rule. But I am confused why your existing rules drop the connection. You can remove my rule and readd it with the `LOG` action or `iptables -A INPUT -j LOG` and have a look in `dmesg` what packets are being dropped. What criteria is missing. — Glueon, Oct 09 '14 at 12:55

score 1 · Accepted Answer · answered Oct 09 '14 at 13:02

In order to find out what rules are you missing it is convenient to set a logging rule at the end of chain.

iptables -A INPUT -j LOG

You'll see in a dmesg output all the packets that reached the end of INPUT chain a then got dropped because of your DROP policy. As I said in comments you are maybe missing a rule for your loopback device:

iptables -I INPUT -i lo -j ACCEPT

But try to add a logging rule to find out a more concrete criteria for iptables.

Local port access blocked by iptables

1 Answers1