# Understanding iptables logs SOLVED

## natosaito

I set up iptables logging today on my server and I'm concerned, when I set iptables -P INPUT DROP the log started filling up with all kinds of drops from ips that aren't on my network here's a part of it

```
Aug 12 17:54:27 babycakes UDP LOGDROP: IN=eth0 OUT= MAC=00:0f:b0:9c:46:7a:00:00:c5:c0:ba:4c:08:00 SRC=217.12.4.104 DST=20.20.12.20 LEN=298 TOS=0x00 PREC=0x00 TTL=46 ID=51271 PROTO=UDP SPT=53 DPT=6822 LEN=278

Aug 12 17:54:27 babycakes UDP LOGDROP: IN=eth0 OUT= MAC=00:0f:b0:9c:46:7a:00:00:c5:c0:ba:4c:08:00 SRC=192.42.93.30 DST=20.20.12.20 LEN=241 TOS=0x00 PREC=0x00 TTL=57 ID=0 DF PROTO=UDP SPT=53 DPT=34220 LEN=221 

Aug 12 17:54:28 babycakes UDP LOGDROP: IN=eth0 OUT= MAC=00:0f:b0:9c:46:7a:00:00:c5:c0:ba:4c:08:00 SRC=68.142.255.16 DST=20.20.12.20 LEN=298 TOS=0x00 PREC=0x00 TTL=58 ID=3732 PROTO=UDP SPT=53 DPT=4052 LEN=278 

Aug 12 17:54:28 babycakes UDP LOGDROP: IN=eth0 OUT= MAC=00:0f:b0:9c:46:7a:00:00:c5:c0:ba:4c:08:00 SRC=192.54.112.30 DST=20.20.12.20 LEN=241 TOS=0x00 PREC=0x20 TTL=52 ID=0 DF PROTO=UDP SPT=53 DPT=18617 LEN=221 

Aug 12 17:54:29 babycakes UDP LOGDROP: IN=eth0 OUT= MAC=00:0f:b0:9c:46:7a:00:00:c5:c0:ba:4c:08:00 SRC=66.218.71.63 DST=20.20.12.20 LEN=298 TOS=0x00 PREC=0x00 TTL=56 ID=50910 PROTO=UDP SPT=53 DPT=61776 LEN=278 

Aug 12 17:54:29 babycakes UDP LOGDROP: IN=eth0 OUT= MAC=00:0f:b0:9c:46:7a:00:00:c5:c0:ba:4c:08:00 SRC=192.48.79.30 DST=20.20.12.20 LEN=241 TOS=0x00 PREC=0x00 TTL=54 ID=0 DF PROTO=UDP SPT=53 DPT=33418 LEN=221 

Aug 12 17:54:30 babycakes UDP LOGDROP: IN=eth0 OUT= MAC=00:0f:b0:9c:46:7a:00:00:c5:c0:ba:4c:08:00 SRC=68.142.226.82 DST=20.20.12.20 LEN=298 TOS=0x00 PREC=0x00 TTL=56 ID=58404 PROTO=UDP SPT=53 DPT=41510 LEN=278 

Aug 12 17:54:30 babycakes UDP LOGDROP: IN=eth0 OUT= MAC=00:0f:b0:9c:46:7a:00:00:c5:c0:ba:4c:08:00 SRC=192.26.92.30 DST=20.20.12.20 LEN=241 TOS=0x00 PREC=0x00 TTL=57 ID=0 DF PROTO=UDP SPT=53 DPT=47299 LEN=221 

Aug 12 17:54:31 babycakes UDP LOGDROP: IN=eth0 OUT= MAC=00:0f:b0:9c:46:7a:00:00:c5:c0:ba:4c:08:00 SRC=217.12.4.104 DST=20.20.12.20 LEN=298 TOS=0x00 PREC=0x00 TTL=47 ID=57830 PROTO=UDP SPT=53 DPT=48695 LEN=278 

Aug 12 17:54:31 babycakes UDP LOGDROP: IN=eth0 OUT= MAC=00:0f:b0:9c:46:7a:00:00:c5:c0:ba:4c:08:00 SRC=192.52.178.30 DST=20.20.12.20 LEN=241 TOS=0x00 PREC=0x00 TTL=45 ID=0 DF PROTO=UDP SPT=53 DPT=55834 LEN=221 

Aug 12 17:54:32 babycakes UDP LOGDROP: IN=eth0 OUT= MAC=00:0f:b0:9c:46:7a:00:00:c5:c0:ba:4c:08:00 SRC=66.218.71.63 DST=20.20.12.20 LEN=298 TOS=0x00 PREC=0x00 TTL=56 ID=58121 PROTO=UDP SPT=53 DPT=39930 LEN=278 

Aug 12 17:54:32 babycakes UDP LOGDROP: IN=eth0 OUT= MAC=00:0f:b0:9c:46:7a:00:00:c5:c0:ba:4c:08:00 SRC=192.12.94.30 DST=20.20.12.20 LEN=241 TOS=0x00 PREC=0x00 TTL=56 ID=0 DF PROTO=UDP SPT=53 DPT=21307 LEN=221 

Aug 12 17:54:33 babycakes UDP LOGDROP: IN=eth0 OUT= MAC=00:0f:b0:9c:46:7a:00:00:c5:c0:ba:4c:08:00 SRC=68.142.226.82 DST=20.20.12.20 LEN=298 TOS=0x00 PREC=0x00 TTL=56 ID=59285 PROTO=UDP SPT=53 DPT=3240 LEN=278 

Aug 12 17:54:33 babycakes UDP LOGDROP: IN=eth0 OUT= MAC=00:0f:b0:9c:46:7a:00:00:c5:c0:ba:4c:08:00 SRC=192.54.112.30 DST=20.20.12.20 LEN=241 TOS=0x00 PREC=0x20 TTL=52 ID=0 DF PROTO=UDP SPT=53 DPT=13955 LEN=221 

Aug 12 17:54:34 babycakes UDP LOGDROP: IN=eth0 OUT= MAC=00:0f:b0:9c:46:7a:00:00:c5:c0:ba:4c:08:00 SRC=192.52.178.30 DST=20.20.12.20 LEN=196 TOS=0x00 PREC=0x00 TTL=235 ID=33250 DF PROTO=UDP SPT=53 DPT=12093 LEN=176 

Aug 12 17:54:34 babycakes UDP LOGDROP: IN=eth0 OUT= MAC=00:0f:b0:9c:46:7a:00:00:c5:c0:ba:4c:08:00 SRC=192.52.178.30 DST=20.20.12.20 LEN=241 TOS=0x00 PREC=0x00 TTL=44 ID=0 DF PROTO=UDP SPT=53 DPT=63431 LEN=221 

Aug 12 17:54:35 babycakes UDP LOGDROP: IN=eth0 OUT= MAC=00:0f:b0:9c:46:7a:00:00:c5:c0:ba:4c:08:00 SRC=217.12.4.104 DST=20.20.12.20 LEN=298 TOS=0x00 PREC=0x00 TTL=47 ID=19581 PROTO=UDP SPT=53 DPT=34850 LEN=278 

Aug 12 17:54:35 babycakes UDP LOGDROP: IN=eth0 OUT= MAC=00:0f:b0:9c:46:7a:00:00:c5:c0:ba:4c:08:00 SRC=192.42.93.30 DST=20.20.12.20 LEN=241 TOS=0x00 PREC=0x00 TTL=57 ID=0 DF PROTO=UDP SPT=53 DPT=28229 LEN=221 

Aug 12 17:54:36 babycakes UDP LOGDROP: IN=eth0 OUT= MAC=00:0f:b0:9c:46:7a:00:00:c5:c0:ba:4c:08:00 SRC=66.218.71.63 DST=20.20.12.20 LEN=298 TOS=0x00 PREC=0x00 TTL=56 ID=15222 PROTO=UDP SPT=53 DPT=55526 LEN=278 

Aug 12 17:54:36 babycakes UDP LOGDROP: IN=eth0 OUT= MAC=00:0f:b0:9c:46:7a:00:00:c5:c0:ba:4c:08:00 SRC=192.33.14.30 DST=20.20.12.20 LEN=241 TOS=0x00 PREC=0x00 TTL=54 ID=4577 DF PROTO=UDP SPT=53 DPT=48507 LEN=221 

Aug 12 17:54:37 babycakes UDP LOGDROP: IN=eth0 OUT= MAC=00:0f:b0:9c:46:7a:00:00:c5:c0:ba:4c:08:00 SRC=66.218.71.63 DST=20.20.12.20 LEN=298 TOS=0x00 PREC=0x00 TTL=56 ID=3278 PROTO=UDP SPT=53 DPT=35656 LEN=278 

Aug 12 17:54:37 babycakes UDP LOGDROP: IN=eth0 OUT= MAC=00:0f:b0:9c:46:7a:00:00:c5:c0:ba:4c:08:00 SRC=192.5.6.30 DST=20.20.12.20 LEN=241 TOS=0x00 PREC=0x00 TTL=47 ID=0 DF PROTO=UDP SPT=53 DPT=34443 LEN=221 

Aug 12 17:54:38 babycakes UDP LOGDROP: IN=eth0 OUT= MAC=00:0f:b0:9c:46:7a:00:00:c5:c0:ba:4c:08:00 SRC=198.41.0.4 DST=20.20.12.20 LEN=143 TOS=0x00 PREC=0x00 TTL=52 ID=0 DF PROTO=UDP SPT=53 DPT=41990 LEN=123 
```

  This concerns me because recently my brothers WOW account was hacked and he had all kinds of his stuff stolen at the same time he had some kind of a virus/trojan/malware that we beleive has been fixed now. My personal network is seperated  from the rest of my familys network by a gentoo box ( I followed the gentoo home router guide ) and they're all on windows behind a WRT54G. So it goes WRT54G==>windows network===>gentoo router===> linux network. On the server the only thing I have running on it so far is local DNS just for my network. I can tell by looking at the network activity leds that everything being dropped is coming from behind the gentoo router which baffles me because I would think it would stop there because it's set to drop everything. 

I'm just starting to learn and understand iptables so if anyone could help me out here it would be great! I'm very paranoid and concerned at the moment.Last edited by natosaito on Wed Aug 13, 2008 4:29 am; edited 1 time in total

----------

## vaguy02

Well, I can tell you that port 53 both TCP/UDP which are all of your entries that you mentioned is used for DNS "Service". Meaning I wouldn't neccessarily consider them suspicious off-hand. I'm assuming your computers IP is 20.20.12.20 and you are connected to the WAN. Then it's just other computers asking who you are.

----------

## Hu

 *vaguy02 wrote:*   

> Meaning I wouldn't neccessarily consider them suspicious off-hand. I'm assuming your computers IP is 20.20.12.20 and you are connected to the WAN. Then it's just other computers asking who you are.

 

Those logs indicate he is under a fairly heavy storm of DNS traffic from a variety of sources, all sending from the traditional DNS server port.  It is possible, although not likely, that he has enough DNS requests going out that all those responses are legitimate answers.  I think it is more likely that these are attempts to initiate a DNS cache poisoning attack.

Even if those requests are legitimate, it is not correct to say that those are other systems asking for his identity.  If they were treating him as a DNS server, then the request would have DPT=53 and SPT set to a random 16-bit number.

----------

## natosaito

This is what was happening, I set 

```
iptables -P INPUT DROP
```

 along with 

```
iptables -I INPUT -p udp --dport 53 -j ACCEPT
```

the OUTPUT policy was set to ACCEPT, then I would go to my workstation which gets DNS from my server at 20.20.12.20 and try to connect to a site and it wouldn't work. That's when my network activity would go crazy and I would start getting a mass amount of logs written so to stop the activity and logs from being written I 

```
iptables -P OUTPUT DROP
```

 from there I had to add 

```
iptables -I INPUT -p udp --sport 53 -j ACCEPT 

iptables -I OUTPUT -p udp --dport 53 -j ACCEPT

iptables -I OUTPUT -p udp --sport 53 -j ACCEPT
```

and now everything is working fine without a ton of network activity. I don't understand why I was getting so much network activty but I can recreate the problem so I imagine this isn't such a big deal as I thought it was.

 Thanks for the replys.

----------

## vaguy02

I'm not sure if opening port 53 up to the whole world is best idea either....

If you know the IP's of your DNS machines, I would open port 53 to them only, so you know who is able to send DNS traffic to your machine.

RC

----------

## Hu

natosaito: what exactly are you trying to achieve?  An input rule for dport=53 is only useful if you run a DNS server on that system.  Similarly, an output rule for sport=53 is unlikely to be used if you are not running a DNS server.  An input rule for sport=53 is overly broad, as vaguy02 notes.  Instead, you should use the netfilter connection tracking support to approve inbound UDP traffic for established virtual circuits.  This allows your DNS resolver to receive responses from DNS servers without exposing you to arbitrary individuals who sets their source port to 53.  Further, it avoids the need to anticipate your DNS servers, which is important if your DNS servers do not permit recursion.

----------

## natosaito

I'm using djbdns to give DNS to my local network. I'm completely lost at this part...

 *Hu wrote:*   

>   An input rule for sport=53 is overly broad, as vaguy02 notes.  Instead, you should use the netfilter connection tracking support to approve inbound UDP traffic for established virtual circuits.  This allows your DNS resolver to receive responses from DNS servers without exposing you to arbitrary individuals who sets their source port to 53.  Further, it avoids the need to anticipate your DNS servers, which is important if your DNS servers do not permit recursion.

 

----------

