Tag Archives: dst

Using Address Ranges and Port Ranges with Iptables

Posted on by
1

Iptables is the name of the firewall built into the Linux kernel. It is also the tool used for firewall configuration. This post explains how to use iptables with a range of IP addresses and/or ports. It could be used, for example, to allow SSH traffic from a number of systems. Or to open up a range of ports with a single firewall rule.

Note: This article is not about blacklisting. If you are looking to set up a blacklist, perhaps to protect your server from a number of unrelated IP addresses, my related procedure on how to protect your webserver with IPset might be more appropriate.

The Linux firewall (part of the Netfilter project) is important on Internet facing systems, “edge” servers and “jump” boxes. Particularly when they do not sit behind another protective network element such as a load balancer or discrete firewall. For example, standaline cloud instances that are not part of a protected VPC infrastructure. Continue reading →

Using Tcpdump to See Background DNS Requests

Posted on by
Reply

This post explains how to use tcpdump on Linux to detect and investigate DNS requests. One of our Red Hat client systems was making requests to an old DNS server, even though it had been adjusted, through a change to/etc/resolv.conf, to point to a new one.

Requests to the old server were identified as follows.

[root@pluto root]# tcpdump -i eth0 -l -vvv dst host 192.168.1.103 and dst port 53
(...waited 15 mins or so...)
tcpdump: listening on eth0
16:38:18.019703 pluto.mycompany.com.41783 > olddnsbox.mycompany.com: [bad udp cksum 48f5!]  21331+ A? somebox.mycompany.com. (42) (DF) (ttl 64, id 48623, len 70)
16:38:18.033461 pluto.mycompany.com.41783 > olddnsbox.mycompany.com: [bad udp cksum 5919!]  12099+ A? somebox.mycompany.com. (42) (DF) (ttl 64, id 48625, len 70)

192.168.1.103 is the ip address of the old DNS server. Tcpdump shows network packets sent to the standard DNS port (53) at that IP address. Requests were few so I had to wait 15 or 20 minutes to capture the above.

The client was last rebooted a year ago, many months before /etc/resolv.conf was last edited. Tcpdump shows that some application is still querying the old server. The fix was to reboot the client, restarting the erroneous application and stopping the outdated requests.