1

I thought my iptables' rules were working great, until I did an apt-get update, for which I get Temporary failure resolving error messages for all sites in sources.list. However, when I disable iptables apt-get update runs flawlessly.

My /etc/resolv.conf file contains:

nameserver 199.195.255.68
nameserver 199.195.255.69

My iptables rules:

*filter

-P INPUT DROP
-P FORWARD DROP
-P OUTPUT DROP

# Allows all loopback (lo0) traffic and drop all traffic to 127/8 that doesn't use lo0
-A INPUT -i lo -j ACCEPT
-A OUTPUT -o lo -j ACCEPT
-A INPUT ! -i lo -d 127.0.0.0/8 -j REJECT

# Accepts all established inbound connections
-A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
-A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

# Allows HTTP and HTTPS connections from anywhere (the normal ports for websites)
-A INPUT -p tcp -m multiport --dports 80,443 -m state --state NEW,ESTABLISHED -j ACCEPT
-A OUTPUT -p tcp -m multiport --sports 80,443 -m state --state ESTABLISHED -j ACCEPT

# THE dport NUMBER IS THE SAME ONE YOU SET UP IN THE SSHD_CONFIG FILE 642/25042
-A INPUT -p tcp --dport 642 -m state --state NEW,ESTABLISHED -j ACCEPT
-A OUTPUT -p tcp --sport 642 -m state --state ESTABLISHED -j ACCEPT

# Allow outbound DNS
-A OUTPUT -p udp -s EX_IP --sport 1024:65535 -d 199.195.255.68 --dport 53 -j ACCEPT
-A INPUT -p udp -s 199.195.255.68 --sport 53 -d EX_IP --dport 1024:65535 -j ACCEPT
-A OUTPUT -p tcp -s EX_IP --sport 1024:65535 -d 199.195.255.69 --dport 53 -j ACCEPT
-A INPUT -p tcp -s 199.195.255.69 --sport 53 -d EX_IP --dport 1024:65535 -j ACCEPT

# Help prevent DoS Attacks
-A INPUT -p tcp --dport 80 -m limit --limit 25/minute --limit-burst 100 -j ACCEPT

# Kill SYN attacks
-A INPUT -p tcp ! --syn -m state --state NEW -j DROP

# Drop fragments
-A INPUT -f -j DROP

# Drop XMAS packets
-A INPUT -p tcp --tcp-flags ALL ALL -j DROP

# Drop NULL packets
-A INPUT -p tcp --tcp-flags ALL NONE -j DROP

# Allow ping
-A INPUT -p icmp -m icmp --icmp-type 8 -j ACCEPT

# Log iptables denied calls (access via 'dmesg' command)
# Logging CHAIN
-N LOGGING
-A INPUT -j LOGGING
-A LOGGING -m limit --limit 2/min -j LOG --log-prefix "IPTABLES Dropped: " --log-level 6
-A LOGGING -j DROP

COMMIT

Where EX_IP is the server's external IP address.

And the output from iptables -vL is:

Chain INPUT (policy DROP 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         
    0     0 ACCEPT     all  --  lo     any     anywhere             anywhere            
    0     0 REJECT     all  --  !lo    any     anywhere             127.0.0.0/8          reject-with icmp-port-unreachable
  952 70158 ACCEPT     all  --  any    any     anywhere             anywhere             state RELATED,ESTABLISHED
    1    64 ACCEPT     tcp  --  any    any     anywhere             anywhere             multiport dports http,https state NEW,ESTABLISHED
    1    64 ACCEPT     tcp  --  any    any     anywhere             anywhere             tcp dpt:642 state NEW,ESTABLISHED
    0     0 ACCEPT     udp  --  any    any     199.195.255.68       copernicus           udp spt:domain dpts:1024:65535
    0     0 ACCEPT     tcp  --  any    any     199.195.255.69       copernicus           tcp spt:domain dpts:1024:65535
    0     0 ACCEPT     tcp  --  any    any     anywhere             anywhere             tcp dpt:http limit: avg 25/min burst 100
    0     0 DROP       tcp  --  any    any     anywhere             anywhere             tcpflags:! FIN,SYN,RST,ACK/SYN state NEW
    0     0 DROP       all  -f  any    any     anywhere             anywhere            
    0     0 DROP       tcp  --  any    any     anywhere             anywhere             tcpflags: FIN,SYN,RST,PSH,ACK,URG/FIN,SYN,RST,PSH,ACK,URG
    0     0 DROP       tcp  --  any    any     anywhere             anywhere             tcpflags: FIN,SYN,RST,PSH,ACK,URG/NONE
    4   160 ACCEPT     icmp --  any    any     anywhere             anywhere             icmp echo-request
   14   991 LOGGING    all  --  any    any     anywhere             anywhere            

Chain FORWARD (policy DROP 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain OUTPUT (policy DROP 72 packets, 4736 bytes)
 pkts bytes target     prot opt in     out     source               destination         
    0     0 ACCEPT     all  --  any    lo      anywhere             anywhere            
  700  325K ACCEPT     all  --  any    any     anywhere             anywhere             state RELATED,ESTABLISHED
    0     0 ACCEPT     tcp  --  any    any     anywhere             anywhere             multiport sports http,https state ESTABLISHED
    0     0 ACCEPT     tcp  --  any    any     anywhere             anywhere             tcp spt:642 state ESTABLISHED
    0     0 ACCEPT     udp  --  any    any     copernicus           199.195.255.68       udp spts:1024:65535 dpt:domain
    0     0 ACCEPT     tcp  --  any    any     copernicus           199.195.255.69       tcp spts:1024:65535 dpt:domain

Chain LOGGING (1 references)
 pkts bytes target     prot opt in     out     source               destination         
   14   991 LOG        all  --  any    any     anywhere             anywhere             limit: avg 2/min burst 5 LOG level info prefix "IPTables Packet Dropped: "
   14   991 DROP       all  --  any    any     anywhere             anywhere

Can you tell me which rule(s) is screwing things up, and why? Or which rule(s) is/are missing, and why?

Thanks

UPDATE - ADDED RULES:

-A OUTPUT -p tcp --sport 1024:65535 --dport 80 -j ACCEPT

-A OUTPUT -p udp -s EX_IP --sport 1024:65535 -d 199.195.255.68 --dport 53 -j ACCEPT
-A INPUT -p udp -s 199.195.255.68 --sport 53 -d EX_IP --dport 1024:65535 -j ACCEPT
-A OUTPUT -p tcp -s EX_IP --sport 1024:65535 -d 199.195.255.69 --dport 53 -j ACCEPT
-A INPUT -p tcp -s 199.195.255.69 --sport 53 -d EX_IP --dport 1024:65535 -j ACCEPT

LOG ENTRY ERROR:

May  7 13:03:00 hostname vmunix: IPTables Packet Dropped: IN= OUT=venet0 SRC=EX_IP DST=205.185.112.68 LEN=73 TOS=0x00 PREC=0x00 TTL=64 ID=1255 DF PROTO=UDP SPT=59037 DPT=53 LEN=53
1
  • Can you remove the fragments rule and try again?
    – gparent
    May 6, 2013 at 23:22

2 Answers 2

2

Three problems I can see with your outbound DNS rules:

  1. DNS queries sometimes have a source port of 53. Your ACCEPT rules would not match this.
  2. The first pair of rules are for UDP, the second pair are for TCP. You should have eight rules all up for DNS to cover TCP and UDP in both outbound and inbound directions for both IP addresses.
  3. The DNS rules are the only ones with an explicit source IP address. If this is not the correct address, the packets would not match the rules and your DNS queries will not work. If you have a default gateway that allows your internal address to access the internet via NAT, the source address in use may not be the external one in the rules.

To help debugging, it would be worth adding a rule to the end of the OUTPUT chain to log everything just before to policy drops the packet, as it has done 72 times in your stats above.

9
  • So you're suggesting that I add -A OUTPUT -p tcp/udp -s EX_IP --sport 53... -j ACCEPT and -A INPUT -p tcp/udp -d 198... --dport 53 -j ACCEPT entries?
    – Gus Shortz
    May 7, 2013 at 3:02
  • Yep. Although adding the LOG line at the end of your OUTPUT chain first will enable you to know which of the three problems is actually biting you rather than just guessing.
    – Ladadadada
    May 7, 2013 at 6:36
  • Oops forgot that, so that would be -A OUTPUT -j LOGGING in the logging section? Thanks I'll give it all a try this aft.
    – Gus Shortz
    May 7, 2013 at 15:55
  • The LOGGING chain only logs the first five packets and then two per minute. It could easily fail to log the packets you are after. The numbers in your output seem small enough that this probably won't cause a problem but it would in a higher traffic environment.
    – Ladadadada
    May 7, 2013 at 15:59
  • What do you suggest I set the limit to?
    – Gus Shortz
    May 7, 2013 at 16:43
1

You are not allowing outbound HTTP connections. I assume you're running a web server since you have the sport rule.

-A OUTPUT -p tcp -m multiport --dports 80,443 -m state --state NEW -j ACCEPT

You need this rule with dport instead of sport like you already have (although that rule is redundant since you already accept ESTABLISHED traffic earlier in your OUTPUT rules)

5
  • Just duplicating will not work as the outbound connection is NEW and not yet ESTABLISHED. May 7, 2013 at 0:01
  • Exactly.... It's NEW, so it's not being matched by the ESTABLISHED,RELATED rule. This will allow the NEW outbound connection.
    – fukawi2
    May 7, 2013 at 3:29
  • It won't as your answer doesn't cover the NEW state either. May 7, 2013 at 14:13
  • 1
    So you're suggesting I should change the -A OUTPUT -p tcp -m multiport --sports 80,443... to -A OUTPUT .... -m state --state NEW,ESTABLISHED -j ACCEPT?
    – Gus Shortz
    May 7, 2013 at 16:58
  • @KarmaFusebox EDIT: sorry, you are right, I completely missed that ESTABLISHED was in there :S I'll edit
    – fukawi2
    May 7, 2013 at 23:00

You must log in to answer this question.

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