0

I'm running an Embedded Linux system, whose kernel is 3.18.21, with some applications on top it on MIPS. When I run iptables & ip6tables on the Linux, such as the following:

iptables -A INPUT -p tcp --dport 80 -j DROP

ip6tables -A INPUT -p tcp --dport 80 -j DROP

The tcp port 80 is for http. Then I found that the http connection to this Linux server (there is a web server app running on the Linux server) doesn't work any longer.

But when I run natstat command as the following:

netstat -tuln | grep LISTEN

It shows the following: (I only extract the port80)

tcp 0 0 :::80 :::* LISTEN

Does this mean the port 80 is still open? Then why I can't use http to access the web server running on the Linux ( I checked and confirmed that the web server process is still running).

2 Answers 2

1

iptables does not prevent applications from opening TCP or UDP ports (because that could cause the applications to crash). Instead, it will prevent incoming packets from reaching the actual ports. If applied to outgoing traffic, it can stop the matching packets from being actually sent.

If you use iptables ... -j DROP, the processing of any packets matching the rule is just stopped short, effectively causing the packet to be ignored with no response whatsoever. For legitimate TCP connections, this typically causes the sender to hang until the connection times out. But since the host must still answer to ARP requests, a scanner can still detect the presence of the host and can mark the port as "firewalled".

(If the scanner is not in the same network segment, it will not be able to directly observe ARP responses, but it can deduce their presence/absence by seeing whether or not the router of the target segment responds to connection attempts with ICMP "Host unreachable" error messages.

No "Host unreachable" errors + no TCP Resets/ICMP "Port unreachable"s = port is most likely firewalled.)

If you use iptables ... -j REJECT, any packets matching the rule will be processed as if the destination port in question was never opened, regardless of the actual state of the port. This usually causes a TCP Reset or ICMP Error response packet to be sent back to the sender of the original packet, just like when attempting to connect to a closed port that has no firewall. This allows the sender to detect that the connection is being refused, so the connection attempt can fail quicker. For a scanner, such a result should be indistinguishable from a normal "closed" port.

If the sender has forged the source IP address of the original packet, the responses could be abused as part of a denial-of-service attack on another host, but modern OSs will deprioritize and/or rate-limit the sending of TCP Reset/ICMP Error packets by default, so this should not be a major concern.

1

iptables/nftables do not and cannot prevent applications from listening [on ports].

2
  • How can we prevent the port being detected by Nessus scanner?
    – li_jessen
    Nov 28, 2022 at 6:03
  • If a port is firewalled, nessus shouldn't detect anything but then it depends whether you -j DROP or -j REJECT. The latter will look like a simple closed port and shouldn't be detected as "firewalled". Anyways, ask a new question please. Nov 28, 2022 at 6:06

You must log in to answer this question.

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