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?

1 Answer 1

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?.

5
  • See also Will tcpdump see packets that are being dropped by iptables? and How can Wireshark see packets dropped by iptables?. In both cases, being based on libpcap means they see the unfiltered (incoming) packets.
    – TripeHound
    Dec 17, 2019 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? Dec 17, 2019 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. Dec 17, 2019 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 for BIND.
    – VL-80
    Dec 18, 2019 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. Dec 18, 2019 at 15:39

You must log in to answer this question.

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