# [SOLVED] Log flooded with DHCP entries

## libertytrek

Hello,

Ever since yesterday at 3:00pm - within a minute after the hourly cron job ran - my log is being flooded with the following entries, over and over and over again:

Oct 19 13:23:00 myhost IPTABLES-IN Default Drop: IN=eth0 OUT= MAC=ff:ff:ff:ff:ff:ff:00:1c:c0:69:16:89:08:00 SRC=0.0.0.0 DST=255.255.255.255 LEN=328 TOS=0x00 PREC=0x00 TTL=128 ID=62723 PROTO=UDP SPT=68 DPT=67 LEN=308

Oct 19 13:23:00 myhost IPTABLES-IN Default Drop: IN=eth0 OUT= MAC=ff:ff:ff:ff:ff:ff:00:04:5a:8f:d6:11:08:00 SRC=192.168.1.250 DST=255.255.255.255 LEN=347 TOS=0x00 PREC=0x00 TTL=128 ID=28908 PROTO=UDP SPT=67 DPT=68 LEN=327

Oct 19 13:23:00 myhost IPTABLES-IN Default Drop: IN=eth0 OUT= MAC=ff:ff:ff:ff:ff:ff:00:1c:c0:69:16:89:08:00 SRC=0.0.0.0 DST=255.255.255.255 LEN=360 TOS=0x00 PREC=0x00 TTL=128 ID=62724 PROTO=UDP SPT=68 DPT=67 LEN=340

Oct 19 13:23:00 myhost IPTABLES-IN Default Drop: IN=eth0 OUT= MAC=ff:ff:ff:ff:ff:ff:00:04:5a:8f:d6:11:08:00 SRC=192.168.1.250 DST=255.255.255.255 LEN=328 TOS=0x00 PREC=0x00 TTL=128 ID=28909 PROTO=UDP SPT=67 DPT=68 LEN=308

Oct 19 13:23:01 myhost IPTABLES-IN Default Drop: IN=eth0 OUT= MAC=ff:ff:ff:ff:ff:ff:00:1c:c0:69:16:89:08:00 SRC=0.0.0.0 DST=255.255.255.255 LEN=328 TOS=0x00 PREC=0x00 TTL=128 ID=62725 PROTO=UDP SPT=68 DPT=67 LEN=308

I have had intermittent log entries for similar things, and I've been meaning to figure out how to make these just be silently dropped, instead of logged...

This is on a production server, which has been kept up to date and running for over 3 years, with only a few minor hiccups when major updates were applied.

I'm ok with just silently dropping these, but I'm also concerned with why all of a sudden these are flooding my logs non-stop, no breaks, just continuously.

The only things I did on Saturday were update libpcre and udev, and installed the new kernel sources (2.6.25-r7) - but this was done earlier in the day (around 10:30am), and I didn't reboot or switch to the new kernel.

This morning I came in to finish that up, and discovered these in my logs. I reviewed the logs and discovered that it started almost immediately (within 2 mnutes) of the hourly cron job at 3:00pm:

Oct 18 15:00:01 myhost cron[22911]: (root) CMD (rm -f /var/spool/cron/lastrun/cron.hourly)

Oct 18 15:00:01 myhost cron[22912]: (root) CMD (test -x /usr/sbin/run-crons && /usr/sbin/run-crons )

Oct 18 15:00:51 myhost IPTABLES-IN Default Drop: IN=eth0 OUT=MAC=ff:ff:ff:ff:ff:ff:00:11:2f:36:c6:4c:08:00 SRC=192.168.1.47 DST=255.255.255.255 LEN=328 TOS=0x00 PREC=0x00 TTL=128 ID=18229 PROTO=UDP SPT=68 DPT=67

LEN=308

Oct 18 15:01:38 myhost IPTABLES-IN Default Drop: IN=eth0 OUT=MAC=ff:ff:ff:ff:ff:ff:00:1c:c0:69:16:89:08:00 SRC=0.0.0.0

DST=255.255.255.255 LEN=328 TOS=0x00 PREC=0x00 TTL=128 ID=351 PROTO=UDP SPT=68 DPT=67 LEN=308

Oct 18 15:01:38 myhost IPTABLES-IN Default Drop: IN=eth0 OUT=MAC=ff:ff:ff:ff:ff:ff:00:04:5a:8f:d6:11:08:00 SRC=192.168.1.250 DST=255.255.255.255 LEN=347 TOS=0x00 PREC=0x00 TTL=128 ID=12140 PROTO=UDP SPT=67 DPT=68

LEN=327

Oct 18 15:01:38 myhost IPTABLES-IN Default Drop: IN=eth0 OUT=MAC=ff:ff:ff:ff:ff:ff:00:1c:c0:69:16:89:08:00 SRC=0.0.0.0

DST=255.255.255.255 LEN=360 TOS=0x00 PREC=0x00 TTL=128 ID=352 PROTO=UDP SPT=68 DPT=67 LEN=340

I tried rebooting and switching to the new kernel, but no matter what I do the flood persists...Last edited by libertytrek on Sat Oct 25, 2008 7:05 pm; edited 1 time in total

----------

## Hu

Unless the cron job changed your firewall rules, the cron job is a red herring.  Your problem is that you are not using a -m limit match on your logging rule, so it is recording every DHCP broadcast.  See man iptables or post back for more details if you need help limiting the frequency of the logging match.

Systems on your network, with alleged MAC addresses of 00:1c:c0:69:16:89, 00:04:5a:8f:d6:11, and 00:11:2f:36:c6:4c, are broadcasting for DHCP leases and not receiving them.  It seems odd that they would broadcast so frequently, though with the information shown, and taking into account that there are three of them, it may not be as frequent as you thought.  If it helps, the net-analyzer/nmap MAC prefixes database says those addresses belong to Intel Corporate, The Linksys Group, and Asustek Computer, respectively.  It is possible for MAC addresses to be spoofed, but it seems unlikely anyone would bother with spoofing MAC addresses for DHCP lease requests.  Also, be aware that those groups are the ones that made the NIC, not the whole computer.

----------

## libertytrek

> Unless the cron job changed your firewall rules, the cron job is a red herring.

> Your problem is that you are not using a -m limit match on your logging rule,

> so it is recording every DHCP broadcast. See man iptables or post back for more

> details if you need help limiting the frequency of the logging match.

Hi Hu,

Thanks for the reply...

Yes, I've been getting these intermittently in the logs for a long time, but what I'm concerned about is why, all of a sudden, they are happening every single second, non-stop, since yesterday at 3:01pm... it has never even been *remotely* this bad.

Anyway, I would very much appreciate a way to suppress these in the log... but I am an absolute idiot when it comes to firewall rules...

Here's a dump (iptables-save) of the current rules... and someone else helped me with these, so if you see anything else that jumps out at you that should be changed, please don't hesitate...  :Wink: 

Thanks a lot for your help!

********************** iptables

# Generated by iptables-save v1.3.8 on Sat Oct 18 16:11:52 2008

*raw

:PREROUTING ACCEPT [222633286:130337506706]

:OUTPUT ACCEPT [186475744:266358392165]

COMMIT

# Completed on Sat Oct 18 16:11:52 2008

# Generated by iptables-save v1.3.8 on Sat Oct 18 16:11:52 2008

*nat

:PREROUTING ACCEPT [3310784:561609823]

:POSTROUTING ACCEPT [289167:19127565]

:OUTPUT ACCEPT [300907:21670186]

COMMIT

# Completed on Sat Oct 18 16:11:52 2008

# Generated by iptables-save v1.3.8 on Sat Oct 18 16:11:52 2008

*mangle

:PREROUTING ACCEPT [621778831:356231181731]

:INPUT ACCEPT [621741184:356222148032]

:FORWARD ACCEPT [0:0]

:OUTPUT ACCEPT [510767123:743977057165]

:POSTROUTING ACCEPT [510654750:743968032926]

-A PREROUTING -p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG FIN,PSH,URG -j DROP

-A PREROUTING -p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG NONE -j DROP

-A PREROUTING -p tcp -m tcp --tcp-flags SYN,RST SYN,RST -j DROP

-A PREROUTING -p tcp -m tcp --tcp-flags FIN,SYN FIN,SYN -j DROP

COMMIT

# Completed on Sat Oct 18 16:11:52 2008

# Generated by iptables-save v1.3.8 on Sat Oct 18 16:11:52 2008

*filter

:INPUT DROP [1492298:264275398]

:FORWARD DROP [0:0]

:OUTPUT ACCEPT [21460:2536934]

-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT

-A INPUT -p tcp -m tcp --dport 22 -j ACCEPT

-A INPUT -p tcp -m tcp --dport 25 -j ACCEPT

-A INPUT -p tcp -m tcp --dport 80 -j ACCEPT

-A INPUT -p udp -m udp --dport 123 -j ACCEPT

-A INPUT -p udp -m udp --dport 138 -j ACCEPT

-A INPUT -p tcp -m tcp --dport 443 -j ACCEPT

-A INPUT -p tcp -m tcp --dport 993 -j ACCEPT

-A INPUT -p tcp -m tcp --dport 20000 -j ACCEPT

-A INPUT -s 127.0.0.1 -j ACCEPT

-A INPUT -j LOG --log-prefix "IPTABLES-IN Default Drop: " --log-level 7

-A INPUT -p tcp -m tcp --dport 22 -m state --state RELATED,ESTABLISHED -j ACCEPT

-A INPUT -i eth0 -p tcp -m tcp --dport 587 -j ACCEPT

-A INPUT -p tcp -m state --state NEW -m tcp --dport 873 -j ACCEPT

-A OUTPUT -m state --state RELATED,ESTABLISHED -j ACCEPT

-A OUTPUT -p tcp -m tcp --dport 20 -j ACCEPT

-A OUTPUT -p tcp -m tcp --dport 21 -j ACCEPT

-A OUTPUT -p tcp -m tcp --dport 22 -j ACCEPT

-A OUTPUT -p tcp -m tcp --dport 23 -j ACCEPT

-A OUTPUT -p tcp -m tcp --dport 25 -j ACCEPT

-A OUTPUT -p tcp -m tcp --dport 43 -j ACCEPT

-A OUTPUT -p udp -m udp --dport 53 -j ACCEPT

-A OUTPUT -p tcp -m tcp --dport 80 -j ACCEPT

-A OUTPUT -p tcp -m tcp --dport 110 -j ACCEPT

-A OUTPUT -p udp -m udp --dport 123 -j ACCEPT

-A OUTPUT -p tcp -m tcp --dport 143 -j ACCEPT

-A OUTPUT -p tcp -m tcp --dport 443 -j ACCEPT

-A OUTPUT -p tcp -m tcp --dport 783 -j ACCEPT

-A OUTPUT -p tcp -m tcp --dport 873 -j ACCEPT

-A OUTPUT -p tcp -m tcp --dport 993 -j ACCEPT

-A OUTPUT -d 127.0.0.1 -j ACCEPT

-A OUTPUT -j LOG --log-prefix "IPTABLES-OUT Default Drop: " --log-level 7

COMMIT

# Completed on Sat Oct 18 16:11:52 2008

----------

## libertytrek

Whew...

Ok, after your comment about those MAC addresses, I went and examined the dhcp server config closely (it is a windows 2000 server), and discovered a problem with 3 of the leases... deleted/recreated them, and the flood of messages has stopped.

Thanks a lot for the pointer... I was focused too much on  the fact that this started right after the cron job, and didn't even consider anything else...

----------

## Hu

 *libertytrek wrote:*   

> 
> 
> Yes, I've been getting these intermittently in the logs for a long time, but what I'm concerned about is why, all of a sudden, they are happening every single second, non-stop, since yesterday at 3:01pm... it has never even been *remotely* this bad.

 

Most likely, their old leases expired.  Based on your later post about finding a problem with the DHCP server, once the leases expired, havoc ensued.  I am not sure why those clients would behave so badly in response to any problem with the DHCP server, though.

 *libertytrek wrote:*   

> Anyway, I would very much appreciate a way to suppress these in the log... but I am an absolute idiot when it comes to firewall rules...
> 
> Here's a dump (iptables-save) of the current rules... and someone else helped me with these, so if you see anything else that jumps out at you that should be changed, please don't hesitate... 
> 
> 

 

```

     1   # Generated by iptables-save v1.3.8 on Sat Oct 18 16:11:52 2008

     2   *raw

     3   :PREROUTING ACCEPT [222633286:130337506706]

     4   :OUTPUT ACCEPT [186475744:266358392165]

     5   COMMIT

     6   # Completed on Sat Oct 18 16:11:52 2008

     7   # Generated by iptables-save v1.3.8 on Sat Oct 18 16:11:52 2008

     8   *nat

     9   :PREROUTING ACCEPT [3310784:561609823]

    10   :POSTROUTING ACCEPT [289167:19127565]

    11   :OUTPUT ACCEPT [300907:21670186]

    12   COMMIT

    13   # Completed on Sat Oct 18 16:11:52 2008

    14   # Generated by iptables-save v1.3.8 on Sat Oct 18 16:11:52 2008

    15   *mangle

    16   :PREROUTING ACCEPT [621778831:356231181731]

    17   :INPUT ACCEPT [621741184:356222148032]

    18   :FORWARD ACCEPT [0:0]

    19   :OUTPUT ACCEPT [510767123:743977057165]

    20   :POSTROUTING ACCEPT [510654750:743968032926]

    21   -A PREROUTING -p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG FIN,PSH,URG -j DROP

    22   -A PREROUTING -p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG NONE -j DROP

    23   -A PREROUTING -p tcp -m tcp --tcp-flags SYN,RST SYN,RST -j DROP

    24   -A PREROUTING -p tcp -m tcp --tcp-flags FIN,SYN FIN,SYN -j DROP

    25   COMMIT

    26   # Completed on Sat Oct 18 16:11:52 2008

    27   # Generated by iptables-save v1.3.8 on Sat Oct 18 16:11:52 2008

    28   *filter

    29   :INPUT DROP [1492298:264275398]

    30   :FORWARD DROP [0:0]

    31   :OUTPUT ACCEPT [21460:2536934]

    32   -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT

    33   -A INPUT -p tcp -m tcp --dport 22 -j ACCEPT

    34   -A INPUT -p tcp -m tcp --dport 25 -j ACCEPT

    35   -A INPUT -p tcp -m tcp --dport 80 -j ACCEPT

    36   -A INPUT -p udp -m udp --dport 123 -j ACCEPT

    37   -A INPUT -p udp -m udp --dport 138 -j ACCEPT

    38   -A INPUT -p tcp -m tcp --dport 443 -j ACCEPT

    39   -A INPUT -p tcp -m tcp --dport 993 -j ACCEPT

    40   -A INPUT -p tcp -m tcp --dport 20000 -j ACCEPT

    41   -A INPUT -s 127.0.0.1 -j ACCEPT

    42   -A INPUT -j LOG --log-prefix "IPTABLES-IN Default Drop: " --log-level 7

    43   -A INPUT -p tcp -m tcp --dport 22 -m state --state RELATED,ESTABLISHED -j ACCEPT

    44   -A INPUT -i eth0 -p tcp -m tcp --dport 587 -j ACCEPT

    45   -A INPUT -p tcp -m state --state NEW -m tcp --dport 873 -j ACCEPT

    46   -A OUTPUT -m state --state RELATED,ESTABLISHED -j ACCEPT

    47   -A OUTPUT -p tcp -m tcp --dport 20 -j ACCEPT

    48   -A OUTPUT -p tcp -m tcp --dport 21 -j ACCEPT

    49   -A OUTPUT -p tcp -m tcp --dport 22 -j ACCEPT

    50   -A OUTPUT -p tcp -m tcp --dport 23 -j ACCEPT

    51   -A OUTPUT -p tcp -m tcp --dport 25 -j ACCEPT

    52   -A OUTPUT -p tcp -m tcp --dport 43 -j ACCEPT

    53   -A OUTPUT -p udp -m udp --dport 53 -j ACCEPT

    54   -A OUTPUT -p tcp -m tcp --dport 80 -j ACCEPT

    55   -A OUTPUT -p tcp -m tcp --dport 110 -j ACCEPT

    56   -A OUTPUT -p udp -m udp --dport 123 -j ACCEPT

    57   -A OUTPUT -p tcp -m tcp --dport 143 -j ACCEPT

    58   -A OUTPUT -p tcp -m tcp --dport 443 -j ACCEPT

    59   -A OUTPUT -p tcp -m tcp --dport 783 -j ACCEPT

    60   -A OUTPUT -p tcp -m tcp --dport 873 -j ACCEPT

    61   -A OUTPUT -p tcp -m tcp --dport 993 -j ACCEPT

    62   -A OUTPUT -d 127.0.0.1 -j ACCEPT

    63   -A OUTPUT -j LOG --log-prefix "IPTABLES-OUT Default Drop: " --log-level 7

    64   COMMIT

    65   # Completed on Sat Oct 18 16:11:52 2008

```

For convenience, I filtered your firewall rules through nl so that I can refer to them by line number.

Without knowing more about the services you intend to offer, I cannot comment on the appropriateness of lines 33-40, but they are correct assuming you intend to expose those ports to all peers.

Line 41 is a common mistake.  Instead of using -s 127.0.0.1, you should use -i lo.  The latter matches locally generated traffic even when that traffic specifies an IP address other than the loopback address.

Line 42 should be extended to include -m limit --limit N1/min --limit-burst N2 for suitable integers N1 and N2.  As a general rule, smaller numbers for N1 and N2 will reduce the amount of traffic logged.  You may also wish to introduce rules on a preceding line that explicitly match and drop certain types of traffic, such as broadcast, multicast, and Windows system browsing queries.  All three types constitute noise that is rarely a threat to your system, and thus not worth logging unless you need an exact picture of what is on the network.

Line 43 is redundant, since it matches a strict subset of what is matched by line 32.

Lines 44-45 should be moved above the logging line.  As written, the kernel will write a line claiming to have dropped the traffic, then proceed to allow it.

Lines 46-61 are correct.  Again, I cannot comment on whether they are appropriate for your installation.

Line 62 is the OUTPUT chain counterpart to the mistake on line 41.  Fix it by using -o lo.

Line 63 is wrong.  It logs a message indicating the traffic was dropped, but your default policy on OUTPUT is ACCEPT.  You should either change the message or change the policy.  Also, as with your input logger, you may wish to restrict the frequency of log messages.

----------

## libertytrek

 *Hu wrote:*   

>  *libertytrek wrote:*   
> 
> Yes, I've been getting these intermittently in the logs for a long time, but what I'm concerned about is why, all of a sudden, they are happening every single second, non-stop, since yesterday at 3:01pm... it has never even been *remotely* this bad. 
> 
> Most likely, their old leases expired.  Based on your later post about finding a problem with the DHCP server, once the leases expired, havoc ensued.  I am not sure why those clients would behave so badly in response to any problem with the DHCP server, though.

 

Actually, now that you mention it, this was probably the result of my habit of using DHCP reservations for permanent clients, but assigning them after the fact...

I add a new workstation, it gets an IP address from the general pool, then I assign it a different one via a reservation, so the next time it asks, it gets the reserved address. I do recall doing that for a couple of new workstations a day or two before this started, but this is the first time anything like this has happened, and I've been doing it this way for years - something weird must have happened this time...

Anyway... *Quote:*   

> For convenience, I filtered your firewall rules through nl so that I can refer to them by line number.

 

Cool... didn't know about nl... thanks! That can be really useful for things like this...

 *Quote:*   

> Without knowing more about the services you intend to offer, I cannot comment on the appropriateness of lines 33-40, but they are correct assuming you intend to expose those ports to all peers.

 

Ok...

This server is only used for EMail (Secure IMAP (993) only, no POP) and basic web services... so the ports I use are...

22 (ssh for me)

25 (only receive traffic from certain IP blocks)

80 (a couple of simple web sites)

443 (our webserver is redirected to secure port for webmail access)

587 (for SASLAUTH relay service for our employees)

993 (secure IMAP for email access for our employees)

We use an outsourced anti-spam service (webroot), so I could lock down port 25 to only specific IP blocks here too, but obviously don't know how. I do that in postfix anyway, so figuring out how to do it at the firewall level didn't seem to be really important.

 *Quote:*   

> Line 41 is a common mistake.  Instead of using -s 127.0.0.1, you should use -i lo.  The latter matches locally generated traffic even when that traffic specifies an IP address other than the loopback address.

 

Ok... am I correct that I can simply edit the rules file I saved, then just restore it? If so, can I also add comments that will 'stick'? That would make working with/changing these rules a lot simpler for me, and easy to undo something if needed...  :Wink: 

 *Quote:*   

> Line 42 should be extended to include -m limit --limit N1/min --limit-burst N2 for suitable integers N1 and N2.  As a general rule, smaller numbers for N1 and N2 will reduce the amount of traffic logged.

 

Ok, but I'm not sure what to use for the values, because I'm not sure of the purpose - what exactly does this do?  :Wink: 

By the way... I really appreciate your willingness to help, but if you know of a forum/mail list for firewall newbies that has knowledgeable people who don't mind questions like these, by all means, point me there...

 *Quote:*   

>  You may also wish to introduce rules on a preceding line that explicitly match and drop certain types of traffic, such as broadcast, multicast, and Windows system browsing queries.  All three types constitute noise that is rarely a threat to your system, and thus not worth logging unless you need an exact picture of what is on the network.

 

I would *love* to do this for all of them! I get those all the time interspersed throughout the logs... ok, after some googling, I came up with:

# block DHCP

-A INPUT -p udp --sport 68 --dport 67 -j DROP

And then the same line for the other ports: 137, 138, 

Is this right?

Hmmm... I see on line 37 that I am currently ACCEPTing traffic on UDP port 138... isn't this also windows related traffic? And can I safely DROP it with a similar rule as above?

 *Quote:*   

> Line 43 is redundant, since it matches a strict subset of what is matched by line 32.

 

Deleted...

 *Quote:*   

> Lines 44-45 should be moved above the logging line.  As written, the kernel will write a line claiming to have dropped the traffic, then proceed to allow it.

 

Assuming you meant above Line 42 - done...

 *Quote:*   

> Lines 46-61 are correct.  Again, I cannot comment on whether they are appropriate for your installation.

 

Was my description above detailed enough?

 *Quote:*   

> Line 62 is the OUTPUT chain counterpart to the mistake on line 41.  Fix it by using -o lo.

 

Fixed...

 *Quote:*   

> Line 63 is wrong.  It logs a message indicating the traffic was dropped, but your default policy on OUTPUT is ACCEPT.

 

Is that (default policy) line 46?

 *Quote:*   

> You should either change the message or change the policy.  Also, as with your input logger, you may wish to restrict the frequency of log messages.

 

Should I even have a default OUTPUT policy of ACCEPT?

As for restricting the frequency of logging messages... I'm not sure I understand... do you mean 'Log occasional, don't log floods'? Because I'd prefer the other way around - silently DROP occasional, LOG floods (so I'll know if there's a problem)...

Lastly... a few more log entries I'd like to clear up...

1. I also occasionally get a whole bunch of the following (130 or so), all are identical (same DATE/TIME stamp too), except for the  'ID=' entry which increments by one for each entry:

Aug  7 07:39:11 myhost IPTABLES-IN Default Drop: IN=eth0 OUT= MAC=00:e0:81:54:9c:8a:00:20:78:cd:bd:2e:08:00 SRC=194.116.199.83 DST=192.168.1.252 LEN=64 TOS=0x00 PREC=0x00 TTL=52 ID=34102 DF PROTO=TCP SPT=25 DPT=42851 WINDOW=5827 RES=0x00 ACK URGP=0

194.116.199.83 = one of webroots servers that I accept mail from.

2. I get these occasionally:

Oct 22 07:57:39 myhost IPTABLES-OUT Default Drop: IN= OUT=eth0 SRC=192.168.1.252 DST=216.34.91.250 LEN=137 TOS=0x00 PREC=0x00 TTL=64 ID=29326 DF PROTO=TCP SPT=993 DPT=11132 WINDOW=54 RES=0x00 ACK PSH URGP=0

Could this possibly be IDLE traffic, since it is outbound on 993? If so, I'm guessing I should be allowing it?

And lastly...

3. I get quite a few of these (port 587):

Oct 22 07:57:39 myhost IPTABLES-OUT Default Drop: IN= OUT=eth0 SRC=192.168.1.252 DST=216.34.91.250 LEN=137 TOS=0x00 PREC=0x00 TTL=64 ID=29326 DF PROTO=TCP SPT=993 DPT=11132 WINDOW=54 RES=0x00 ACK PSH URGP=0

No idea on these...

Again, many thanks Hu for your patience and willingness to help...

Charles

----------

## Hu

 *libertytrek wrote:*   

> 
> 
>  *Quote:*   Without knowing more about the services you intend to offer, I cannot comment on the appropriateness of lines 33-40, but they are correct assuming you intend to expose those ports to all peers. 
> 
> Ok...
> ...

 

That leaves ntp, 138, and 20000 unexplained.  :Smile: 

 *libertytrek wrote:*   

> We use an outsourced anti-spam service (webroot), so I could lock down port 25 to only specific IP blocks here too, but obviously don't know how. I do that in postfix anyway, so figuring out how to do it at the firewall level didn't seem to be really important.

 

Use a -s address/mask modifier to make the rule apply only to a particular group of addresses.  If you need to use many unrelated addresses, it may be more efficient to create a new chain and use it like so:

```

iptables -N filter_port_25

iptables -A INPUT -p tcp -m tcp --dport 25 -j filter_port_25

iptables -A filter_port_25 -s first-allowed-block -j ACCEPT

iptables -A filter_port_25 -s second-allowed-block -j ACCEPT

# Repeat as necessary for other allowed blocks
```

This allows the kernel to skip checking the individual addresses if the packet is not TCP or the destination port is not 25.  Since the chain is purely for traffic on TCP/25, it would be wasteful to check the source addresses for other types of traffic.

 *libertytrek wrote:*   

>  *Quote:*   Line 41 is a common mistake.  Instead of using -s 127.0.0.1, you should use -i lo.  The latter matches locally generated traffic even when that traffic specifies an IP address other than the loopback address. 
> 
> Ok... am I correct that I can simply edit the rules file I saved, then just restore it? If so, can I also add comments that will 'stick'? That would make working with/changing these rules a lot simpler for me, and easy to undo something if needed... 

 

Yes, with one caveat.  If you have SAVE_ON_STOP="yes" in /etc/conf.d/iptables and you are writing your commented rules to the same location that iptables uses, then it will overwrite your rules with an uncommented copy when you reboot.

 *libertytrek wrote:*   

>  *Quote:*   Line 42 should be extended to include -m limit --limit N1/min --limit-burst N2 for suitable integers N1 and N2.  As a general rule, smaller numbers for N1 and N2 will reduce the amount of traffic logged. 
> 
> Ok, but I'm not sure what to use for the values, because I'm not sure of the purpose - what exactly does this do? 
> 
> By the way... I really appreciate your willingness to help, but if you know of a forum/mail list for firewall newbies that has knowledgeable people who don't mind questions like these, by all means, point me there...

 

I do not mind helping, but it would be faster for you to refer to man iptables for some of the more basic questions.  Per that document, N1 is the number of packets per time unit, in this minute, that are allowed to match.  N2 is the "burst" rate, which allows a rule that has not matched recently to temporarily surge beyond its normal limit.  This may be useful for rules that permit traffic on heavily loaded servers, but for your situation, I would set N2 to a small value.  For chatty networks, single digit values are often appropriate for both N1 and N2.

 *libertytrek wrote:*   

> I would *love* to do this for all of them! I get those all the time interspersed throughout the logs... ok, after some googling, I came up with:
> 
> # block DHCP
> 
> -A INPUT -p udp --sport 68 --dport 67 -j DROP
> ...

 

Yes.

 *libertytrek wrote:*   

> Hmmm... I see on line 37 that I am currently ACCEPTing traffic on UDP port 138... isn't this also windows related traffic? And can I safely DROP it with a similar rule as above?

 

According to /etc/services, this is NETBIOS Datagram Service.  That sounds Windows-related to me, and safe to drop.

 *libertytrek wrote:*   

>  *Quote:*   Lines 44-45 should be moved above the logging line.  As written, the kernel will write a line claiming to have dropped the traffic, then proceed to allow it. 
> 
> Assuming you meant above Line 42 - done...

 

Yes.

 *libertytrek wrote:*   

>  *Quote:*   Lines 46-61 are correct.  Again, I cannot comment on whether they are appropriate for your installation. 
> 
> Was my description above detailed enough?

 

Yes, for your INPUT requirements.  You do not need separate per-port rules to permit traffic from an established connection, so unless you intend to allow people to connect out to all the ports listed in your OUTPUT chain, you can prune it a bit.  It is safe to leave as-is, though.

 *libertytrek wrote:*   

>  *Quote:*   Line 63 is wrong.  It logs a message indicating the traffic was dropped, but your default policy on OUTPUT is ACCEPT. 
> 
> Is that (default policy) line 46?

 

No, line 31.  Lines 29-31 set the default policy for the three built-in chains.  Any packet which reaches the end of a chain without matching a terminating rule will have the default policy applied.

 *libertytrek wrote:*   

>  *Quote:*   You should either change the message or change the policy.  Also, as with your input logger, you may wish to restrict the frequency of log messages. 
> 
> Should I even have a default OUTPUT policy of ACCEPT?

 

For servers where I trust all the daemons on it, and all the users who have access to run network enabled programs, I leave OUTPUT set to ACCEPT for convenience.  If you have reason to believe someone may try to make outbound connections from the machine in a manner that you do not want or in a manner that could violate company policy, then change the chain policy to DROP.  As a side note, OUTPUT applies only to locally generated traffic.  For a device performing IP forwarding, restriction of unwanted traffic should be done in the FORWARD chain.

 *libertytrek wrote:*   

> As for restricting the frequency of logging messages... I'm not sure I understand... do you mean 'Log occasional, don't log floods'? Because I'd prefer the other way around - silently DROP occasional, LOG floods (so I'll know if there's a problem)...

 

I meant log occasionally and drop floods, but you could do it the other way.  That will, of course, open up the potential for malicious users to flood your logs by performing unauthorized connections.  As a trivial attack, consider while true; do cat </dev/tcp/prohibited-address/prohibited-port >/dev/null 2>&1; done 2>/dev/null.  This will initiate TCP connections to prohibited-address:prohibited-port as fast as the shell can go.  They will fail, but they will be logged.  You could guard against this with some cleverness in the rules, but it is something to keep in mind.

I suggest you try to compose some rules for this, and post the results here for review.  I think I ought to give you a chance to do a little bit on your own.  :Wink: 

 *libertytrek wrote:*   

> Lastly... a few more log entries I'd like to clear up...
> 
> 1. I also occasionally get a whole bunch of the following (130 or so), all are identical (same DATE/TIME stamp too), except for the  'ID=' entry which increments by one for each entry:
> 
> Aug  7 07:39:11 myhost IPTABLES-IN Default Drop: IN=eth0 OUT= MAC=00:e0:81:54:9c:8a:00:20:78:cd:bd:2e:08:00 SRC=194.116.199.83 DST=192.168.1.252 LEN=64 TOS=0x00 PREC=0x00 TTL=52 ID=34102 DF PROTO=TCP SPT=25 DPT=42851 WINDOW=5827 RES=0x00 ACK URGP=0
> ...

 

The most likely cause is that the webroot server sent a FIN or RST to close the connection, but additional data packets arrived after the connection was removed from the local kernel's state tracking table.  It is odd that so many packets would arrive like that, though.

 *libertytrek wrote:*   

> 2. I get these occasionally:
> 
> Oct 22 07:57:39 myhost IPTABLES-OUT Default Drop: IN= OUT=eth0 SRC=192.168.1.252 DST=216.34.91.250 LEN=137 TOS=0x00 PREC=0x00 TTL=64 ID=29326 DF PROTO=TCP SPT=993 DPT=11132 WINDOW=54 RES=0x00 ACK PSH URGP=0
> 
> Could this possibly be IDLE traffic, since it is outbound on 993? If so, I'm guessing I should be allowing it?

 

Probably.  Fortunately, you already are allowing it.

 *libertytrek wrote:*   

> And lastly...
> 
> 3. I get quite a few of these (port 587):
> 
> Oct 22 07:57:39 myhost IPTABLES-OUT Default Drop: IN= OUT=eth0 SRC=192.168.1.252 DST=216.34.91.250 LEN=137 TOS=0x00 PREC=0x00 TTL=64 ID=29326 DF PROTO=TCP SPT=993 DPT=11132 WINDOW=54 RES=0x00 ACK PSH URGP=0
> ...

 

You repasted the line from your second question, so I am not sure what you are truly receiving here.

----------

## libertytrek

Hi Hu,

I'd like to start implementing and testing these changes, but before I go shooting myself in the foot:

I have read that it is important to be sure the tables are clear/flushed, and reading man iptables-restore says that it will flush the table automatically (as long as I don't specify -n), so, am I right that the safe way to make these changes a little at a time is to:

~ # iptables-save current-rules

~ # cp current-rules experimental-rules

~ # nano -wc experimental-rules (make changes)

~ # iptables-restore experimental-rules

and then if something goes whacked, I can revert with a quick

~ # iptables-restore current-rules

?

----------

## libertytrek

Ok... I made most of the changes we've been discussing, but before I actually implement them, would you mind a final check to make sure I didn't do something stupid/obvious?

This doesn't include the lines that will only allow port 25 traffic to webroot's ip blocks yet:

```

# Generated by iptables-save v1.3.8 on Sat Oct 18 16:11:52 2008

*mangle

:PREROUTING ACCEPT [621778831:356231181731]

:INPUT ACCEPT [621741184:356222148032]

:FORWARD ACCEPT [0:0]

:OUTPUT ACCEPT [510767123:743977057165]

:POSTROUTING ACCEPT [510654750:743968032926]

-A PREROUTING -p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG FIN,PSH,URG -j DROP

-A PREROUTING -p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG NONE -j DROP

-A PREROUTING -p tcp -m tcp --tcp-flags SYN,RST SYN,RST -j DROP

-A PREROUTING -p tcp -m tcp --tcp-flags FIN,SYN FIN,SYN -j DROP

COMMIT

# Completed on Sat Oct 18 16:11:52 2008

# Generated by iptables-save v1.3.8 on Sat Oct 18 16:11:52 2008

*filter

:INPUT DROP [1492298:264275398]

:FORWARD DROP [0:0]

:OUTPUT ACCEPT [21460:2536934]

-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT

-A INPUT -p tcp -m tcp --dport 22 -j ACCEPT

-A INPUT -p tcp -m tcp --dport 25 -j ACCEPT

-A INPUT -p udp --sport 68 --dport 67 -j DROP

-A INPUT -p tcp -m tcp --dport 80 -j ACCEPT

-A INPUT -p udp -m udp --dport 123 -j ACCEPT

-A INPUT -p udp --sport 137 --dport 137 -j DROP

-A INPUT -p udp --sport 138 --dport 138 -j DROP

-A INPUT -p tcp -m tcp --dport 443 -j ACCEPT

-A INPUT -i eth0 -p tcp -m tcp --dport 587 -j ACCEPT

-A INPUT -p tcp -m state --state NEW -m tcp --dport 873 -j ACCEPT

-A INPUT -p tcp -m tcp --dport 993 -j ACCEPT

-A INPUT -p tcp -m tcp --dport 20000 -j ACCEPT

-A INPUT -i lo -j ACCEPT

-A INPUT -j -mLOG --log-prefix "IPTABLES-IN Default Drop: " --log-level 7

-A OUTPUT -m state --state RELATED,ESTABLISHED -j ACCEPT

-A OUTPUT -p tcp -m tcp --dport 20 -j ACCEPT

-A OUTPUT -p tcp -m tcp --dport 21 -j ACCEPT

-A OUTPUT -p tcp -m tcp --dport 23 -j ACCEPT

-A OUTPUT -p tcp -m tcp --dport 43 -j ACCEPT

-A OUTPUT -p udp -m udp --dport 53 -j ACCEPT

-A OUTPUT -p tcp -m tcp --dport 873 -j ACCEPT

-A OUTPUT -j LOG --log-prefix "IPTABLES-OUT Default Drop: " --log-level 7

COMMIT

# Completed on Sat Oct 18 16:11:52 2008

```

----------

## libertytrek

 *Hu wrote:*   

>  *libertytrek wrote:*   
> 
> This server is only used for EMail (Secure IMAP (993) only, no POP) and basic web services... so the ports I use are...
> 
> 22 (ssh for me)
> ...

 

Ack... forgot about ntp (yes, it is running, of course)...

20000 was for usermin, which I was playing with at one point, but decided I liked doing things manually, with the exception of postfixadmin...

So, that only leaves 138... windows/netbios traffic that I'd prefer not to see in the logs unless there's a major flood occurring...

 *Quote:*   

> Use a -s address/mask modifier to make the rule apply only to a particular group of addresses.  If you need to use many unrelated addresses, it may be more efficient to create a new chain and use it like so:
> 
> ```
> 
> iptables -N filter_port_25
> ...

 

Perfect, thanks! But since I'm so unfamiliar/uncomfortable with iptables, I'm gonna wait until this weekend before I do that, to minimize any potential fat-finger problems...

 *Quote:*   

> If you have SAVE_ON_STOP="yes" in /etc/conf.d/iptables and you are writing your commented rules to the same location that iptables uses, then it will overwrite your rules with an uncommented copy when you reboot.

 

Thanks for the heads up, that may very well have bit me... but no problem, I'll just keep a commented copy available elsewhere that I use to make/apply changes.

 *Quote:*   

> Line 42 should be extended to include -m limit --limit N1/min --limit-burst N2 for suitable integers N1 and N2.  As a general rule, smaller numbers for N1 and N2 will reduce the amount of traffic logged.

 

Ok, so change that line to something like:

-A INPUT -j -m limit --limit 15/min --limit-burst 2 LOG --log-prefix "IPTABLES-IN Default Drop: " --log-level 7

?

 *Quote:*   

> You do not need separate per-port rules to permit traffic from an established connection, so unless you intend to allow people to connect out to all the ports listed in your OUTPUT chain, you can prune it a bit.

 

I deleted only the lines that had INPUT lines for the same ports, so:

```

-A OUTPUT -m state --state RELATED,ESTABLISHED -j ACCEPT

-A OUTPUT -p tcp -m tcp --dport 20 -j ACCEPT

-A OUTPUT -p tcp -m tcp --dport 21 -j ACCEPT

-A OUTPUT -p tcp -m tcp --dport 23 -j ACCEPT

-A OUTPUT -p tcp -m tcp --dport 43 -j ACCEPT

-A OUTPUT -p udp -m udp --dport 53 -j ACCEPT

-A OUTPUT -p udp -m udp --dport 123 -j ACCEPT

-A OUTPUT -p tcp -m tcp --dport 873 -d 192.168.1.75 -j ACCEPT

-A OUTPUT -j LOG --log-prefix "IPTABLES-OUT Default Drop: " --log-level 7

```

I'm guessing the above are necessary?

 *Quote:*   

> Line 63 is wrong.  It logs a message indicating the traffic was dropped, but your default policy on OUTPUT is ACCEPT. You should either change the message or change the policy.

 

Ok, changed the default policy to DROP (I'm a better safe than sorry kind of guy)...

 *Quote:*   

> Lines 29-31 set the default policy for the three built-in chains.  Any packet which reaches the end of a chain without matching a terminating rule will have the default policy applied.

 

Ah, ok... this is starting to make more sense now... thanks a lot...

 *Quote:*   

>  *libertytrek wrote:*   As for restricting the frequency of logging messages... I'm not sure I understand... do you mean 'Log occasional, don't log floods'? Because I'd prefer the other way around - silently DROP occasional, LOG floods (so I'll know if there's a problem)... 
> 
> I meant log occasionally and drop floods, but you could do it the other way.  That will, of course, open up the potential for malicious users to flood your logs by performing unauthorized connections.  As a trivial attack, consider while true; do cat </dev/tcp/prohibited-address/prohibited-port >/dev/null 2>&1; done 2>/dev/null.  This will initiate TCP connections to prohibited-address:prohibited-port as fast as the shell can go.  They will fail, but they will be logged.

 

Hmmm, good point...

 *Quote:*   

> You could guard against this with some cleverness in the rules, but it is something to keep in mind. I suggest you try to compose some rules for this, and post the results here for review.  I think I ought to give you a chance to do a little bit on your own. 

 

Heh, no worries... but be prepared for a good laugh...  :Wink: 

Ok, lets see if I can be clever... what I'd really like to do is set these two rules (both INPUT and OUTPUT) to catch floods and log them in one of two ways:

1. If -m limit --limit N/sec, log a single line '%Protocol% Flood Detected' once for every N matches until the flood stops,

and

2. If -m limit --limit N/min, log a single line '%Protocol% Excessive Entries Detected' once for every N matches until the number of matches falls below the threshold

Is it possible to use variables in logging details like this? Hmmm... what if the entries were not all the same protocol? Is there a way to tell it to group matches by protocol? Am I nuts for even woryying about this? My head is starting to hurt...

That would leave the logs uncluttered, but would let me know if I was having a similar problem to what started this thread... I'll pursue this in a separate thread, when I have spent more time researching/reading...

 *Quote:*   

>  *libertytrek wrote:*   Lastly... a few more log entries I'd like to clear up...
> 
> 1. I also occasionally get a whole bunch of the following (130 or so), all are identical (same DATE/TIME stamp too), except for the  'ID=' entry which increments by one for each entry:
> 
> Aug  7 07:39:11 myhost IPTABLES-IN Default Drop: IN=eth0 OUT= MAC=00:e0:81:54:9c:8a:00:20:78:cd:bd:2e:08:00 SRC=194.116.199.83 DST=192.168.1.252 LEN=64 TOS=0x00 PREC=0x00 TTL=52 ID=34102 DF PROTO=TCP SPT=25 DPT=42851 WINDOW=5827 RES=0x00 ACK URGP=0
> ...

 

Ok, this one will have to wait then... I'll open up a new thread once I'm done getting the rest of these changes implemented.

 *Quote:*   

>  *libertytrek wrote:*   2. I get these occasionally:
> 
> Oct 22 07:57:39 myhost IPTABLES-OUT Default Drop: IN= OUT=eth0 SRC=192.168.1.252 DST=216.34.91.250 LEN=137 TOS=0x00 PREC=0x00 TTL=64 ID=29326 DF PROTO=TCP SPT=993 DPT=11132 WINDOW=54 RES=0x00 ACK PSH URGP=0
> 
> Could this possibly be IDLE traffic, since it is outbound on 993? If so, I'm guessing I should be allowing it? 
> ...

 

Right, but I think we already took care of this by moving the line up above the logging line, right?

 *Quote:*   

> [quote="libertytrek"]And lastly...
> 
> 3. I get quite a few of these (port 587):
> 
> You repasted the line from your second question, so I am not sure what you are truly receiving here.

 

Oops... fat-fingers... that should have been:

Aug  7 08:42:18 moria IPTABLES-IN Default Drop: IN=eth0 OUT= MAC=00:e0:81:54:9c:8a:00:20:78:cd:bd:2e:08:00 SRC=68.158.171.176 DST=192.168.1.252 LEN=48 TOS=0x00 PREC=0x00 TTL=111 ID=21151 DF PROTO=TCP SPT=50531 DPT=587 WINDOW=65535 RES=0x00 SYN URGP=0

----------

## Hu

 *libertytrek wrote:*   

> 
> 
> I have read that it is important to be sure the tables are clear/flushed, and reading man iptables-restore says that it will flush the table automatically (as long as I don't specify -n), so, am I right that the safe way to make these changes a little at a time is to:
> 
> ~ # iptables-save current-rules
> ...

 

Yes, that should work.  Take into account that neither iptables-save nor iptables-restore take a filename, so you would need to use shell I/O redirection to save and restore the rules.  The principle is sound, though.

 *libertytrek wrote:*   

> Ok... I made most of the changes we've been discussing, but before I actually implement them, would you mind a final check to make sure I didn't do something stupid/obvious?
> 
> 

 

You may need to add a -m udp modifier to the UDP rules that match by port.  I recall seeing some scenarios where it would be guessed, but it is better to specify it.

I see a new INPUT rule for port 873 (rsync).  Your prior remarks did not specify what this covers, so I am not sure whether you need or want this rule.

If you only intend to use port 20000 from the local machine, there is no need to list it here.  The ACCEPT for -i lo will allow all loopback traffic.

Your INPUT logging rule has a typographical error that will probably make the load fail.  You wrote -mLOG where you meant to use just LOG.

Your OUTPUT logging rule still says drop, but your policy is still ACCEPT.

Aside from those issues, your new rules look good.

 *libertytrek wrote:*   

> 
> 
> So, that only leaves 138... windows/netbios traffic that I'd prefer not to see in the logs unless there's a major flood occurring...

 

Understandable.  If you do not provide service on that port, you could just DROP it instead.

 *libertytrek wrote:*   

> 
> 
> Ok, so change that line to something like:
> 
> -A INPUT -j -m limit --limit 15/min --limit-burst 2 LOG --log-prefix "IPTABLES-IN Default Drop: " --log-level 7
> ...

 

That should work.

 *libertytrek wrote:*   

> 
> 
> I deleted only the lines that had INPUT lines for the same ports, so:
> 
> ```
> ...

 

Maybe, but I see you added a rule to allow outbound whois access via port 43.

 *libertytrek wrote:*   

> 
> 
> Ok, changed the default policy to DROP (I'm a better safe than sorry kind of guy)...

 

Your last full rule list does not show this change.

 *libertytrek wrote:*   

> 
> 
> Ok, lets see if I can be clever... what I'd really like to do is set these two rules (both INPUT and OUTPUT) to catch floods and log them in one of two ways:
> 
> 1. If -m limit --limit N/sec, log a single line '%Protocol% Flood Detected' once for every N matches until the flood stops,
> ...

 

You can print the matches in great detail using the --log-ip-options and --log-tcp-options modifiers.  To the best of my knowledge, you cannot have it do intelligent tracking of individual protocols.  You would need to instead write rules for each protocol individually, so that they were matched or unmatched independent of one another.

This is probably not worth worrying about.  If you have someone causing you that much grief, they are malicious and should be dealt with through social means, rather than technical means.

 *libertytrek wrote:*   

> 
> 
> Right, but I think we already took care of this by moving the line up above the logging line, right?
> 
> 

 

This is an OUTPUT message.  Your OUTPUT chain always had the LOG target in the correct place.

 *libertytrek wrote:*   

> 
> 
> Aug  7 08:42:18 moria IPTABLES-IN Default Drop: IN=eth0 OUT= MAC=00:e0:81:54:9c:8a:00:20:78:cd:bd:2e:08:00 SRC=68.158.171.176 DST=192.168.1.252 LEN=48 TOS=0x00 PREC=0x00 TTL=111 ID=21151 DF PROTO=TCP SPT=50531 DPT=587 WINDOW=65535 RES=0x00 SYN URGP=0

 

This should be silenced by moving the ACCEPT lines above the LOG line.

----------

## libertytrek

 *Hu wrote:*   

> Take into account that neither iptables-save nor iptables-restore take a filename, so you would need to use shell I/O redirection to save and restore the rules.  The principle is sound, though.

 

Right, thanks (I actually knew that one)  :Wink: 

 *Quote:*   

> I see a new INPUT rule for port 873 (rsync).  Your prior remarks did not specify what this covers, so I am not sure whether you need or want this rule.

 

Yeah, I had one in the OUTPUT table, and I am planning on doing some 'pull' rsync backups, so figured I'd go ahead and add it now...

 *Quote:*   

> If you only intend to use port 20000 from the local machine, there is no need to list it here.  The ACCEPT for -i lo will allow all loopback traffic.

 

I'd be accessing it from my workstation, so the rule should allow traffic from there... except I'm not using it now, so will comment that line out completely, but...

Assuming my workstation IP is 10.0.0.100 and I want to limit remote connections to only that workstation (in addition to lo), would the appropriate line be:

-A INPUT -p tcp -m tcp -s 10.0.0.100 --dport 20000 -j ACCEPT ?

Or, if I had multiple IPs, I could do it the way you suggested for filtering port 25...

 *Quote:*   

> Your INPUT logging rule has a typographical error that will probably make the load fail.  You wrote -mLOG where you meant to use just LOG.

 

Yep, fixed... that actually was in the rule, too <blush>...

 *Quote:*   

> Your OUTPUT logging rule still says drop, but your policy is still ACCEPT.

 

Hmmm. weird, it was DROP in the rule when I just looked... must have copied/pasted before I made that change...

 *Quote:*   

> I see you added a rule to allow outbound whois access via port 43.

 

No, that was in the original rules... but a quick google shows I do want it - I do whois and nslookups fairly often.

 *Quote:*   

>  *libertytrek wrote:*   Ok, lets see if I can be clever... what I'd really like to do is set these two rules (both INPUT and OUTPUT) to catch floods and log them in one of two ways:
> 
> 1. If -m limit --limit N/sec, log a single line '%Protocol% Flood Detected' once for every N matches until the flood stops,
> 
> and
> ...

 

Yeah, I brought in a baseball bat today with precisely that in mind...  :Wink: 

But seriously, I'm just thinking in terms of 'what if', and if I can set up the firewall to minimize the irrelevant entries, but to also let me know if something weird is going on, I would like to do that, if for no other reason than as an exercise in learning how this stuff works... but like I said, thats a subject for a new thread, I do want to go ahead and apply these other changes this weekend, and again, I really appreciate your help...

 *Hu wrote:*   

>  *libertytrek wrote:*    *Hu wrote:*    *libertytrek wrote:*   2. I get these occasionally:
> 
> Oct 22 07:57:39 myhost IPTABLES-OUT Default Drop: IN= OUT=eth0 SRC=192.168.1.252 DST=216.34.91.250 LEN=137 TOS=0x00 PREC=0x00 TTL=64 ID=29326 DF PROTO=TCP SPT=993 DPT=11132 WINDOW=54 RES=0x00 ACK PSH URGP=0
> 
> Could this possibly be IDLE traffic, since it is outbound on 993? If so, I'm guessing I should be allowing it? 
> ...

 

Oh... right... so, would I be right that changing the default POLICY for OUTPUT to DROP should silence these then?

Now, for one last look at the new rules I'm planning on using (with a few last questions at the bottom):

```

     1  *mangle

     2  :PREROUTING ACCEPT [626859138:358950795971]

     3  :INPUT ACCEPT [626821398:358941749639]

     4  :FORWARD ACCEPT [0:0]

     5  :OUTPUT ACCEPT [514805573:749980609178]

     6  :POSTROUTING ACCEPT [514693200:749971584939]

     7  -A PREROUTING -p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG FIN,PSH,URG -j DROP

     8  -A PREROUTING -p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG NONE -j DROP

     9  -A PREROUTING -p tcp -m tcp --tcp-flags SYN,RST SYN,RST -j DROP

    10  -A PREROUTING -p tcp -m tcp --tcp-flags FIN,SYN FIN,SYN -j DROP

    11  COMMIT

    12  *filter

    13  :INPUT DROP [1768948:356707811]

    14  :FORWARD DROP [0:0]

    15  :OUTPUT DROP [22258:2630081]

    16  -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT

    17  -A INPUT -i lo -j ACCEPT

    18  -A INPUT -p tcp -m tcp --dport 22 -j ACCEPT

    19  -A INPUT -p tcp -m tcp --dport 25 -j ACCEPT

    20  -A INPUT -p udp -m udp --dport 67 -j DROP

    21  -A INPUT -p tcp -m tcp --dport 80 -j ACCEPT

    22  -A INPUT -p udp -m udp --dport 123 -j ACCEPT

    23  -A INPUT -p udp -m udp --dport 137 -j DROP

    24  -A INPUT -p udp -m udp --dport 138 -j DROP

    25  -A INPUT -p tcp -m tcp --dport 443 -j ACCEPT

    26  -A INPUT -i eth0 -p tcp -m tcp --dport 587 -j ACCEPT

    27  -A INPUT -p tcp -m state --state NEW -m tcp --dport 873 -j ACCEPT

    28  -A INPUT -p tcp -m tcp --dport 993 -j ACCEPT

#  29  -A INPUT -p tcp -m tcp -s 10.0.0.100 --dport 20000 -j ACCEPT

#  30  -A INPUT -j LOG --log-prefix "IPTABLES-IN Default Drop: " --log-level 7

    31  -A INPUT -j -m limit --limit 15/min --limit-burst 2 LOG --log-prefix "IPTABLES-IN Default Drop: " --log-level 7

    32  -A OUTPUT -m state --state RELATED,ESTABLISHED -j ACCEPT

    33  -A OUTPUT -o lo -j ACCEPT

    34  -A OUTPUT -p tcp -m tcp --dport 20 -j ACCEPT

    35  -A OUTPUT -p tcp -m tcp --dport 21 -j ACCEPT

    36  -A OUTPUT -p tcp -m tcp --dport 23 -j ACCEPT

    37  -A OUTPUT -p tcp -m tcp --dport 43 -j ACCEPT

    38  -A OUTPUT -p udp -m udp --dport 53 -j ACCEPT

    39  -A OUTPUT -p tcp -m tcp --dport 873 -j ACCEPT

#  40  -A OUTPUT -j LOG --log-prefix "IPTABLES-OUT Default Drop: " --log-level 7

    41  -A OUTPUT -j -m limit --limit 15/min --limit-burst 2 LOG --log-prefix "IPTABLES-OUT Default Drop: " --log-level 7

    42  COMMIT

```

Now, hopefully the last questions about these changes:

Lines 20, 23 and 24 all had --sport designations when I was proposing adding them... but none of the other entries have --sport designations, only the --dport - so is it safe/good to remove the --sport designations?

Line 26 - why does this have the -i eth0 designation?

Line 27 - what is the significance of the '-m state --state NEW' designation? If it provides better security, should I add that to Line 18 (for SSH access)?

Thanks so much Hu for taking all of this time with me on this.. I've really learned a lot, and am no longer 'terrified' of iptables... although I'm sure I'll end up shooting myself in the foot a few [dozen] times now that I'm willing to attempt changing them myself...  :Wink: 

----------

## Hu

 *libertytrek wrote:*   

> 
> 
>  *Quote:*   If you only intend to use port 20000 from the local machine, there is no need to list it here.  The ACCEPT for -i lo will allow all loopback traffic. I'd be accessing it from my workstation, so the rule should allow traffic from there... except I'm not using it now, so will comment that line out completely, but...
> 
> Assuming my workstation IP is 10.0.0.100 and I want to limit remote connections to only that workstation (in addition to lo), would the appropriate line be:
> ...

 Correct on both counts.

 *libertytrek wrote:*   

>  *Quote:*   I see you added a rule to allow outbound whois access via port 43. No, that was in the original rules... but a quick google shows I do want it - I do whois and nslookups fairly often.

 So it was.  I must have misread.

 *libertytrek wrote:*   

> Oh... right... so, would I be right that changing the default POLICY for OUTPUT to DROP should silence these then?

 

It will disallow them, but it will not silence them.  The policy only applies after traversing all rules and failing to match any terminating rules.  Thus, the logging rule will be hit before the policy drops the packet.  If you want to avoid the log message, you need a rule which applies a terminating action, such as ACCEPT, DROP, or RETURN, to match before the logging rule is reached.

 *libertytrek wrote:*   

> 
> 
> Now, for one last look at the new rules I'm planning on using (with a few last questions at the bottom):
> 
> ```
> ...

 

For DROP actions, it should be safe to be less precise, since a mistake will break wanted functionality rather than allowing unwanted functionality.  If your goal is to drop exactly that which is known to be uninteresting and allow everything else to be logged, I would restore the --sport qualifier for line 20, and omit it for line 23 and line 24.

 *libertytrek wrote:*   

> Line 26 - why does this have the -i eth0 designation?

 

Ask your consultant.  :Wink:   That modifier has been there in every rules listing that you posted, so I cannot explain the original rationale for its presence.  The effect is that it applies only to traffic coming in on eth0, which presumably means that only eth0 is connected to a network that you trust to use port 587 correctly.  If your machine is not multi-homed, it is somewhat pointless to have it there.  Note that machines which run virtual machines or which participate in some types of VPN are considered multi-homed even if they only have one physical NIC.

 *libertytrek wrote:*   

> Line 27 - what is the significance of the '-m state --state NEW' designation? If it provides better security, should I add that to Line 18 (for SSH access)?

 

That qualifier does not appear to be useful.  A preceding rule already allowed RELATED,ESTABLISHED traffic, so the only type not covered is INVALID.  In my opinion, the qualifier neither enhances nor reduces security in this context.  I see no reason to attach it to the ssh rule, nor to retain it in the rsync rule.

 *libertytrek wrote:*   

> 
> 
> Thanks so much Hu for taking all of this time with me on this.. I've really learned a lot, and am no longer 'terrified' of iptables... although I'm sure I'll end up shooting myself in the foot a few [dozen] times now that I'm willing to attempt changing them myself... 

 

Glad to help.

----------

## libertytrek

 *Hu wrote:*   

> If you want to avoid the log message, you need a rule which applies a terminating action, such as ACCEPT, DROP, or RETURN, to match before the logging rule is reached.

 

Oh, right... makes perfect sense...  :Smile: 

 *Hu wrote:*   

>  *libertytrek wrote:*   Now, for one last look at the new rules I'm planning on using (with a few last questions at the bottom):
> 
> ```
> 
>     20  -A INPUT -p udp -m udp --dport 67 -j DROP
> ...

 

Hmmm... ok, I give up... why restore it to line 20? This machine is neither a DHCP server OR client... so, what is 'potentially interesting' about random DHCP packets?

 *Hu wrote:*   

>  *libertytrek wrote:*   Line 26 - why does this have the -i eth0 designation? 
> 
> Ask your consultant.   That modifier has been there in every rules listing that you posted, so I cannot explain the original rationale for its presence.  The effect is that it applies only to traffic coming in on eth0, which presumably means that only eth0 is connected to a network that you trust to use port 587 correctly.  If your machine is not multi-homed, it is somewhat pointless to have it there.  Note that machines which run virtual machines or which participate in some types of VPN are considered multi-homed even if they only have one physical NIC.

 

Hah... dang consultants... thats what I thought, just making sure...

 *Hu wrote:*   

>  *libertytrek wrote:*   Line 27 - what is the significance of the '-m state --state NEW' designation? If it provides better security, should I add that to Line 18 (for SSH access)? 
> 
> That qualifier does not appear to be useful.  A preceding rule already allowed RELATED,ESTABLISHED traffic, so the only type not covered is INVALID.  In my opinion, the qualifier neither enhances nor reduces security in this context.  I see no reason to attach it to the ssh rule, nor to retain it in the rsync rule.

 

Okey dokey, its outta here...

Thanks again!

----------

## Hu

 *libertytrek wrote:*   

> 
> 
>  *Hu wrote:*    *libertytrek wrote:*   Now, for one last look at the new rules I'm planning on using (with a few last questions at the bottom):
> 
> ```
> ...

 

As far as I know, legitimate DHCP client packets always have the source port set to 68 and the destination port set to 67.  Thus, packets which have some other source port are in violation of the specification and are therefore interesting.  They could indicate a low quality port scan that probed the DHCP server port without setting its source port correctly.  They could also indicate a broken DHCP client on the network.  Depending on the strictness of your DHCP server, it may ignore broken DHCP clients, in which case you would want to notice that they are misbehaving.  On the other hand, given that your DHCP server is a very old Microsoft product, it is probably not very strict.  :Smile: 

----------

## libertytrek

 *Hu wrote:*   

> As far as I know, legitimate DHCP client packets always have the source port set to 68 and the destination port set to 67.  Thus, packets which have some other source port are in violation of the specification and are therefore interesting.  They could indicate a low quality port scan that probed the DHCP server port without setting its source port correctly.  They could also indicate a broken DHCP client on the network.

 

Ah, ok, makes sense then...

 *Quote:*   

> Depending on the strictness of your DHCP server, it may ignore broken DHCP clients, in which case you would want to notice that they are misbehaving.  On the other hand, given that your DHCP server is a very old Microsoft product, it is probably not very strict. 

 

Hah! I wish I could talk the boss into replacing it with a Samba server, but it looks like he wants to update to Server 2008...   :Shocked: 

Anyway, thanks again for everything... I'm sure I'll be back...

----------

