I would like to block all DNS queries that come from one particular ip address. I used TCPdump to verify that the queries were in fact, coming from this IP:
[scarolan@server:~]$ sudo tcpdump -n udp port 53 and src 10.100.1.1 tcpdump: listening on eth0 11:12:17.162100 10.100.1.1.19233 > 10.100.1.61.domain: 14270+ A? server.domain.com. (32) (DF)
Could someone help with the proper syntax for an IPtables rule to block port 53 udp traffic from this IP? I tried this rule but it doesn't work:
-A RH-Firewall-1-INPUT -s 10.100.1.1 -m udp -p udp --dport 53 -j REJECT
Sean Carolan wrote:
I would like to block all DNS queries that come from one particular ip address. I used TCPdump to verify that the queries were in fact, coming from this IP:
[scarolan@server:~]$ sudo tcpdump -n udp port 53 and src 10.100.1.1 tcpdump: listening on eth0 11:12:17.162100 10.100.1.1.19233 > 10.100.1.61.domain: 14270+ A? server.domain.com. (32) (DF)
Looks to me that you have a larger problem. Is this an rfc1918 address coming from the outside? You should be blocking ALL rfc1918 addresses from the Internet, as they are by definition an attack.
If this is from an internal source, go to that source and figure out what it is doing.
rfc1918 defines PRIVATE ipv4 addresses. These are not routed over the Internet. A packet with a source address in 'Net1' will never route out back to the sender. It is intended to attack (in some way) the destination.
Could someone help with the proper syntax for an IPtables rule to block port 53 udp traffic from this IP? I tried this rule but it doesn't work:
-A RH-Firewall-1-INPUT -s 10.100.1.1 -m udp -p udp --dport 53 -j REJECT _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Looks to me that you have a larger problem. Is this an rfc1918 address coming from the outside? You should be blocking ALL rfc1918 addresses from the Internet, as they are by definition an attack.
Hi Robert, thanks for the reply. This is in fact what I am trying to do. We have a load-balancing device in front of this DNS server. It is configured so that all Internet traffic that comes through appears to originate from 10.100.1.1.
rfc1918 defines PRIVATE ipv4 addresses. These are not routed over the Internet. A packet with a source address in 'Net1' will never route out back to the sender. It is intended to attack (in some way) the destination.
Yep, these are internal DNS servers that were mis-configured by the previous admin. I'm trying to do some cleanup and make sure that they are not available to the public internet.
What is confusing me is why my iptables rule is not working correctly. TCPdump shows that the source is correct. Any ideas?
Sean Carolan wrote:
What is confusing me is why my iptables rule is not working correctly. TCPdump shows that the source is correct. Any ideas?
try blocking tcp as well, most name servers listen on both tcp and udp.
portal:~# netstat -anp | grep :53 | grep named tcp 0 0 10.10.10.1:53 0.0.0.0:* LISTEN 12978/named tcp 0 0 127.0.0.1:53 0.0.0.0:* LISTEN 12978/named tcp 0 0 216.39.174.24:53 0.0.0.0:* LISTEN 12976/named udp 0 0 10.10.10.1:53 0.0.0.0:* 12978/named udp 0 0 127.0.0.1:53 0.0.0.0:* 12978/named udp 0 0 216.39.174.24:53 0.0.0.0:* 12976/named
nate
On Tue, Jul 15, 2008 at 11:55 AM, nate centos@linuxpowered.net wrote:
Sean Carolan wrote:
What is confusing me is why my iptables rule is not working correctly. TCPdump shows that the source is correct. Any ideas?
try blocking tcp as well, most name servers listen on both tcp and udp.
I do have a rule for blocking TCP, forgot to mention that. You can see from my tcpdump output above that the inbound packet is UDP though. I wonder why iptables doesn't block it even with this rule?
I do have a rule for blocking TCP, forgot to mention that. You can see from my tcpdump output above that the inbound packet is UDP though. I wonder why iptables doesn't block it even with this rule?
The really strange part about this is, if I remove the ACCEPT rules that are further down in my iptables config, NO dns traffic gets through at all, due to the final REJECT rule:
ACCEPT tcp -- anywhere anywhere tcp dpt:domain state NEW ACCEPT udp -- anywhere anywhere udp dpt:domain state NEW ... ... REJECT all -- anywhere anywhere reject-with icmp-host-prohibited
So iptables does seem to be able to properly recognize udp port 53 traffic, it's just not filtering correctly against the source IP address.
Sean Carolan wrote:
I do have a rule for blocking TCP, forgot to mention that. You can see from my tcpdump output above that the inbound packet is UDP though. I wonder why iptables doesn't block it even with this rule?
Try to insert the rule (-I) instead of append (-A). I recall encountering weirdness between using the two different methods for adding a rule. I don't know why, but it seems to make a difference in some cases. The man page doesn't make it clear to me what the difference is and why it (might) cause a change of behavior.
I'm not an iptables expert, for my real firewalls I use OpenBSD.
nate
On Tue, Jul 15, 2008 at 1:43 PM, nate centos@linuxpowered.net wrote:
Sean Carolan wrote:
I do have a rule for blocking TCP, forgot to mention that. You can see from my tcpdump output above that the inbound packet is UDP though. I wonder why iptables doesn't block it even with this rule?
Try to insert the rule (-I) instead of append (-A). I recall encountering weirdness between using the two different methods for adding a rule. I don't know why, but it seems to make a difference in some cases. The man page doesn't make it clear to me what the difference is and why it (might) cause a change of behavior.
I might try this on a dev box, but I'm actually happy with the new DROP rule. It may be better just to drop the traffic and not let the world know a DNS server even exists at this address.
On Tuesday 15 July 2008 14:43, nate wrote:
Try to insert the rule (-I) instead of append (-A). I recall encountering weirdness between using the two different methods for adding a rule. I don't know why, but it seems to make a difference in some cases. The man page doesn't make it clear to me what the difference is and why it (might) cause a change of behavior.
(-A) Appends the new rule at the end of the chain.
(-I) will insert it at the beginning when no line number is given.
Man iptables for this information
-A, --append chain rule-specification Append one or more rules to the end of the selected chain. When the source and/or destination names resolve to more than one address, a rule will be added for each possible address combination.
-I, --insert chain [rulenum] rule-specification Insert one or more rules in the selected chain as the given rule number. So, if the rule number is 1, the rule or rules are inserted at the head of the chain. This is also the default if no rule number is specified.
Robert Spangler wrote:
(-A) Appends the new rule at the end of the chain.
(-I) will insert it at the beginning when no line number is given.
Man iptables for this information
I read the man page and it didn't make sense I guess because my rules aren't setup the standard way, I have no idea what line number my rules are at. My firewall scripts call iptables explicitly, and in some cases the rules are dynamic. Just adapted the same scripts over the years from ipfwadm to ipchains to iptables.
in any case it doesn't matter, packet filter is more friendly for me.
nate
On Tuesday 15 July 2008 16:57, nate wrote:
(-A) Appends the new rule at the end of the chain.
(-I) will insert it at the beginning when no line number is given.
Man iptables for this information
I read the man page and it didn't make sense I guess because my rules aren't setup the standard way, I have no idea what line number my rules are at. My firewall scripts call iptables explicitly, and in some cases the rules are dynamic. Just adapted the same scripts over the years from ipfwadm to ipchains to iptables.
While a lot of people use scripts to setup their firewalls I cannot understand why they do not commit them to the normal config file and use the normal setup to start/reset/stop their firewall. And I have a reason for saying this.
If you use the system way to start and stop your firewall and use a script to setup/test new settings you could save yourself a lot of headaches if you mess something up in the script and it stops working. You simply restart the firewall and the original rules are applied from the last time you saved them.
But everyone has their own way of doing things. What is easy for one seems like a daunting task.
Sean Carolan wrote:
I would like to block all DNS queries that come from one particular ip address. I used TCPdump to verify that the queries were in fact, coming from this IP:
[scarolan@server:~]$ sudo tcpdump -n udp port 53 and src 10.100.1.1 tcpdump: listening on eth0 11:12:17.162100 10.100.1.1.19233 > 10.100.1.61.domain: 14270+ A? server.domain.com. (32) (DF)
Could someone help with the proper syntax for an IPtables rule to block port 53 udp traffic from this IP? I tried this rule but it doesn't work:
-A RH-Firewall-1-INPUT -s 10.100.1.1 -m udp -p udp --dport 53 -j REJECT
Strange...your rule seems ok to me. Try with DROP instead of REJECT ?
-
kfx -
nate -
Robert Moskowitz -
Robert Spangler -
Sean Carolan