11
Ubuntu 20.04
iptables 1.8.4-1

I experienced a situation where a remote system seemed to be able to slip through the first iptables rule of a Linux server located behind a NAT router:

-A INPUT -s <remote_ip_addresses_range> -j DROP

Despite the above rule, I was able to witness the following snapshot using pktstat -tF -i <wired_ethernet_interface>:

udp <remote_fqdn>:29937 <-> <server_fqdn>:domain
udp <remote_fqdn>:21862 <-> <server_fqdn>:domain
udp <remote_fqdn>:37097 <-> <server_fqdn>:domain
udp <remote_fqdn>:1886 <-> <server_fqdn>:domain
udp <remote_fqdn>:16824 <-> <server_fqdn>:domain
udp <remote_fqdn>:43989 <-> <server_fqdn>:domain
udp <remote_fqdn>:49939 <-> <server_fqdn>:domain
udp <remote_fqdn>:25297 <-> <server_fqdn>:domain
udp <remote_fqdn>:13319 <-> <server_fqdn>:domain
udp <remote_fqdn>:62586 <-> <server_fqdn>:domain
udp <remote_fqdn>:24825 <-> <server_fqdn>:domain
udp <remote_fqdn>:52733 <-> <server_fqdn>:domain
udp <remote_fqdn>:44866 <-> <server_fqdn>:domain
udp <remote_fqdn>:19691 <-> <server_fqdn>:domain
udp <remote_fqdn>:31634 <-> <server_fqdn>:domain
udp <remote_fqdn>:36689 <-> <server_fqdn>:domain
udp <remote_fqdn>:20213 <-> <server_fqdn>:domain
udp <remote_fqdn>:38816 <-> <server_fqdn>:domain
udp <remote_fqdn>:62049 <-> <server_fqdn>:domain
udp <remote_fqdn>:51384 <-> <server_fqdn>:domain
udp <remote_fqdn>:55557 <-> <server_fqdn>:domain
udp <remote_fqdn>:39710 <-> <server_fqdn>:domain
udp <remote_fqdn>:56031 <-> <server_fqdn>:domain
udp <remote_fqdn>:50839 <-> <server_fqdn>:domain
udp <remote_fqdn>:53202 <-> <server_fqdn>:domain
udp <remote_fqdn>:39416 <-> <server_fqdn>:domain
udp <remote_fqdn>:25693 <-> <server_fqdn>:domain
udp <remote_fqdn>:55591 <-> <server_fqdn>:domain
udp <remote_fqdn>:30182 <-> <server_fqdn>:domain

I am positive that <remote_fqdn> is within <remote_ip_addresses_range>.

I see only 2 possible explanations for that situation:

  • pktstat sniffs on packets before iptables filtering takes place, which I doubt is possible
  • there is a security flaw in iptables

The tcpdump trace shows that all rogue DNS queries are similar; the attacker tried to hijack the server with recursive DNS searches of a strange DNS domain: packet.cf (not the domain served by <server_fqdn>).

Anyone with a clue?

jean-christophe manciot
  • 233
  • 2
  • 7

1 Answers1

28

pktstat sniffs on packets before iptables filtering takes place, which I doubt is possible

This is what happens. pktstat, tcpdump etc get the unfiltered data on the interface. See also Does tcpdump bypass iptables?.

Steffen Ullrich
  • 184,332
  • 29
  • 363
  • 424
  • See also [Will tcpdump see packets that are being dropped by iptables?](https://serverfault.com/q/233302/233915) and [How can Wireshark see packets dropped by iptables?](https://unix.stackexchange.com/q/248090/73128). In both cases, being based on libpcap means they see the unfiltered (incoming) packets. – TripeHound Dec 17 '19 at 13:48
  • Is there a linux tool similar to pktstat, but able to show network traffic after iptables filtering, i.e not using libpcap? – jean-christophe manciot Dec 17 '19 at 13:57
  • 4
    @jean-christophemanciot: I don't know. And while related this would better be a new question so that it gets noticed by more. – Steffen Ullrich Dec 17 '19 at 14:08
  • @jean-christophemanciot, if you are only interested in DNS traffic, you could temporarily setup logging on your DNS server to see what queries are being processed. Here is [reference](https://kb.isc.org/docs/aa-01526) for BIND. – VL-80 Dec 18 '19 at 14:18
  • 1
    @jean-christophemanciot iptables itself can give you hit counts on the rules, so you can at least see if your DROP rule is being matched. – Paul Coccoli Dec 18 '19 at 15:39