Topic: iptables denylog - A question ...

[BearTM]

I've recently upgraded my server to SME8 (clean install, restore backup, apply contribs) and have been monitoring it closely to make sure it's working perfectly (again).

One things I've noticed is the following in the iptables log:

Code: [Select]

@400000004d191e242f7d574c Dec 28 12:15:38 hellcat denylog: IN=eth0 OUT= MAC=00  SRC=27.252.116.192 DST=192.168.0.88 LEN=40 TOS=08 PREC=0x00 TTL=245 ID=62233 CE DF PROTO=TCP SPT=49721 DPT=993 SEQ=3103410449 ACK=1124310915 WINDOW=0 ACK RST URGP=0
@400000004d1921bc17cd8f2c Dec 28 12:30:58 hellcat denylog: IN=eth0 OUT= MAC=00  SRC=27.252.70.141 DST=192.168.0.88 LEN=40 TOS=08 PREC=0x00 TTL=245 ID=15839 DF PROTO=TCP SPT=49722 DPT=993 SEQ=2997648674 ACK=2104880692 WINDOW=0 ACK RST URGP=0
@400000004d192973162c23cc Dec 28 13:03:53 hellcat denylog: IN=eth0 OUT= MAC=00  SRC=27.252.251.19 DST=192.168.0.88 LEN=40 TOS=08 PREC=0x00 TTL=246 ID=7448 DF PROTO=TCP SPT=49724 DPT=993 SEQ=1560173296 ACK=4163114180 WINDOW=0 ACK RST URGP=0
@400000004d192a7b293b7544 Dec 28 13:08:17 hellcat denylog: IN=eth0 OUT= MAC=00  SRC=27.252.107.108 DST=192.168.0.88 LEN=40 TOS=08 PREC=0x00 TTL=245 ID=20773 DF PROTO=TCP SPT=49723 DPT=993 SEQ=4248950134 ACK=3083465375 WINDOW=0 ACK RST URGP=0
@400000004d192d1114bbe644 Dec 28 13:19:19 hellcat denylog: IN=eth0 OUT= MAC=00  SRC=49.227.197.56 DST=192.168.0.88 LEN=40 TOS=08 PREC=0x00 TTL=246 ID=24450 DF PROTO=TCP SPT=49725 DPT=993 SEQ=2903490518 ACK=849882440 WINDOW=0 ACK RST URGP=0
@400000004d1930b21b940924 Dec 28 13:34:48 hellcat denylog: IN=eth0 OUT= MAC=00  SRC=121.90.239.72 DST=192.168.0.88 LEN=40 TOS=08 PREC=0x00 TTL=246 ID=59542 CE DF PROTO=TCP SPT=49726 DPT=993 SEQ=1711286184 ACK=1823455766 WINDOW=0 ACK RST URGP=0
@400000004d1934442f3117c4 Dec 28 13:50:02 hellcat denylog: IN=eth0 OUT= MAC=00  SRC=121.90.229.175 DST=192.168.0.88 LEN=40 TOS=08 PREC=0x00 TTL=246 ID=60524 CE DF PROTO=TCP SPT=49727 DPT=993 SEQ=1085722792 ACK=2796837760 WINDOW=0 ACK RST URGP=0
@400000004d1937d52fd95de4 Dec 28 14:05:15 hellcat denylog: IN=eth0 OUT= MAC=00  SRC=121.90.183.44 DST=192.168.0.88 LEN=40 TOS=08 PREC=0x00 TTL=246 ID=63513 CE DF PROTO=TCP SPT=49728 DPT=993 SEQ=3350844998 ACK=3759946292 WINDOW=0 ACK RST URGP=0

I was alerted to this by entries from logwatch, but note that this has nothing to do with the logwatch contrib!
This is directly from the iptables log in /var/log/iptables/current, from an otherwise default configuration of SME8 / IMAPS.

The machine in question (hellcat) is stilling behind an IPCop firewall with port-forwarding rules for the IMAPS port (993).

I've checked the IP addresses, and they are all valid, and are my own requests from my iPhone - through Vodafone 2G/3G network here in New Zealand.
Nothing dodgy happening there (no attacks/etc.), so that's not the issue.

The questions I have are as follows:

1). Why is the MAC address being reported as "00", and not a full MAC address?
2). Why are these packets being logged for port 993 (IMAPS), which is open, working and accessible?
3). Is there a way to adjust iptables to drop/handle/ignore these events?

Just looking to get the server set up 'perfectly' - so any clues/help would be appreciated.

Cheers.

[CharlieBrady]

The questions I have are as follows:

1). Why is the MAC address being reported as "00", and not a full MAC address?

Good question, and I don't know the answer. Perhaps it is a bug. You should report the problem via the bug tracker.

2). Why are these packets being logged for port 993 (IMAPS), which is open, working and accessible?

Those packets are being logged because they aren't part of an established port 993 connection, and they aren't a request to create a new  connection. I think they are a RST (reset) packet for a connection which has already completed. I don't know why those are arriving - perhaps it is something to do with IPcop.

3). Is there a way to adjust iptables to drop/handle/ignore these events?

iptables is already dropping those packets. You can also configure iptables to not log packets which it drops, but I don't think that woul dbe a good idea. You want to have logs if someone is attacking your system. Search here for 'masq' and 'logging' if you really want to change the settings.

[BearTM]

Good question, and I don't know the answer. Perhaps it is a bug. You should report the problem via the bug tracker.

After some more research I'm not certain it is a bug. Others have posted logs with truncated MAC addresses (google search), which leads me to believe it is either something in the iptables logfile parsing/generation or a result of a completely bogus MAC address in the packet (i.e. all 00:00:00:00:00:00 - Two NULLs in a row - unicode string terminator?) which is being received and thereby being incorrectly logged. It is not specific to SME Server.

Those packets are being logged because they aren't part of an established port 993 connection, and they aren't a request to create a new  connection. I think they are a RST (reset) packet for a connection which has already completed. I don't know why those are arriving - perhaps it is something to do with IPcop.

I've checked the IPCop logs and nothing untowards there ... it is just SME server reporting this problem. Maybe there is an issue in the NAT process? Maybe there is a spurious RST packet arriving after connection is closed - it is coming from a cell phone network and those networks are pretty unreliable even at the best of times. Out of order packet reception/transmission wouldn't surprise me at all.

There are no issues/errors/logged/etc. from any other IMAPS client connected to the same server.  Using the same iPhone over WiFi - no issues. It happens only from the Vodafone Network, so I'm of the opinion this is solely network related, and therefore something which Vodafone is doing incorrectly in the connection setup/teardown process.

iptables is already dropping those packets. You can also configure iptables to not log packets which it drops, but I don't think that would be a good idea. You want to have logs if someone is attacking your system. Search here for 'masq' and 'logging' if you really want to change the settings.

I think I'll just leave it as is and (manually) ignore the log noise. The ClamAV engine also generates a lot of log noise (perpetually outdated - *sigh*), so with a bit of practice/repetition/recursion? ... I'm sure I'll be able to handle the regularly appearing log issues and any problems will be very visible when they occur.

Thanks for the help/direction - I'm going to look into the RST (delayed?) packets a bit further, but I'm almost convinced it's a Vodafone ISP/Network issue which is entirely unresolvable.

Cheers!