ConfigServer Community Forum

Posted: **16 Jan 2009, 19:33**

Guys,

I have a peculiar issue that's popped up since installing and configuring csf/lfd.

I do believe I've followed the instructions and config file directives properly, but maybe I've overlooked something obvious to you.

A little background.

CentOS 5.2-64. Opteron 1216. Physical host (not VPS or virtual guest OS). Generic csf/lfd install, I don't use any sort of control panel software on my servers.

My server has two interfaces, eth[01].

eth0 connects to a private backend network, which is protected elsewhere and needs no filters on my server. This network is lets say 10.10.10.0/30 and this interface is lets say 10.10.10.2. I do not have bogons enabled, and I understand how to enable bogons and still have access on this network. Not a concern for me at this time. Bogons are trapped upstream from me anyhow.

eth1 connects to the public network, which is lets say a 123.123.123.128/29, and it's IP would be lets say 123.123.123.130.
eth1 also has four secondaries statically routed to the 123.123.123.130 address, which exist on secondary interfaces eth1:[0-3]. Lets call this network 123.123.124.240/30.

All my apache VirtualHosts use 123.123.124.241 for incoming traffic. because this is a static routed subnet, all outbound traffic originates from the 123.123.123.130 primary source address. Not a problem.

In my previous firewall configs, I did nothing with INVALID state packets. I was interested to see how csf would deal with this, and to see how many invalid states were coming in.

Now here's my real issue...

Some (not all) legitimate users who hit my largest website are triggering the INVALID rules. Almost all of the invalid trips are happening with DPT=80. lfd decides these individuals are port scanning me and will block them for an hour, after which the user discovers "the site is back up" and starts trying to use it again, and lfd blocks again, ad nauseum, until they get a permanent ban.

Posting the rest of this in a sec, something (not the URLs) in the rest of my post is triggering the forum's new user URL prevention regex... I think I only need 1-2 more posts to get where I can post useful data about the issue.

Posted: **16 Jan 2009, 19:34**

Here's what the email notices are looking like. Note, I only changed my IPs in this list because I have to believe A) the IRS has good security controls on their ingress traffic, and B) the IRS has good security controls on their egress traffic and workstation security. This guy is a confirmed legitimate user from a confirmed legitimate site, so the thoughts I've read elsewhere about "INVALID" packets possibly being an exploit attempt are not likely to be applicable in this case.

Code: Select all

Time:    Fri Jan 16 12:26:43 2009 -0600
IP:      152.216.11.5 (US/United States/internet9.irs.gov)
Hits:    11
Blocked: temporarily for 3600 seconds

Sample of block hits:
Jan 16 12:25:49 toshiro kernel: Firewall: *INVALID* IN=eth1 OUT= MAC=00:30:48:57:e2:5b:00:1a:30:38:90:00:08:00 SRC=152.216.11.5 DST=123.123.124.241 LEN=40 TOS=0x00 PREC=0x00 TTL=48 ID=13191 PROTO=TCP SPT=32555 DPT=80 WINDOW=65535 RES=0x00 ACK FIN URGP=0
Jan 16 12:25:49 toshiro kernel: Firewall: *INVALID* IN=eth1 OUT= MAC=00:30:48:57:e2:5b:00:1a:30:38:90:00:08:00 SRC=152.216.11.5 DST=123.123.124.241 LEN=40 TOS=0x00 PREC=0x00 TTL=48 ID=14299 PROTO=TCP SPT=32555 DPT=80 WINDOW=65535 RES=0x00 ACK FIN URGP=0
Jan 16 12:25:50 toshiro kernel: Firewall: *INVALID* IN=eth1 OUT= MAC=00:30:48:57:e2:5b:00:1a:30:38:90:00:08:00 SRC=152.216.11.5 DST=123.123.124.241 LEN=40 TOS=0x00 PREC=0x00 TTL=48 ID=15656 PROTO=TCP SPT=32555 DPT=80 WINDOW=65535 RES=0x00 ACK FIN URGP=0
Jan 16 12:25:50 toshiro kernel: Firewall: *INVALID* IN=eth1 OUT= MAC=00:30:48:57:e2:5b:00:1a:30:38:90:00:08:00 SRC=152.216.11.5 DST=123.123.124.241 LEN=40 TOS=0x00 PREC=0x00 TTL=48 ID=17744 PROTO=TCP SPT=32555 DPT=80 WINDOW=65535 RES=0x00 ACK FIN URGP=0
Jan 16 12:25:51 toshiro kernel: Firewall: *INVALID* IN=eth1 OUT= MAC=00:30:48:57:e2:5b:00:1a:30:38:90:00:08:00 SRC=152.216.11.5 DST=123.123.124.241 LEN=40 TOS=0x00 PREC=0x00 TTL=48 ID=21944 PROTO=TCP SPT=32555 DPT=80 WINDOW=65535 RES=0x00 ACK FIN URGP=0
Jan 16 12:25:52 toshiro kernel: Firewall: *INVALID* IN=eth1 OUT= MAC=00:30:48:57:e2:5b:00:1a:30:38:90:00:08:00 SRC=152.216.11.5 DST=123.123.124.241 LEN=40 TOS=0x00 PREC=0x00 TTL=48 ID=28465 PROTO=TCP SPT=32555 DPT=80 WINDOW=65535 RES=0x00 ACK FIN URGP=0
Jan 16 12:25:54 toshiro kernel: Firewall: *INVALID* IN=eth1 OUT= MAC=00:30:48:57:e2:5b:00:1a:30:38:90:00:08:00 SRC=152.216.11.5 DST=123.123.124.241 LEN=40 TOS=0x00 PREC=0x00 TTL=48 ID=34861 PROTO=TCP SPT=32555 DPT=80 WINDOW=65535 RES=0x00 ACK FIN URGP=0
Jan 16 12:25:57 toshiro kernel: Firewall: *INVALID* IN=eth1 OUT= MAC=00:30:48:57:e2:5b:00:1a:30:38:90:00:08:00 SRC=152.216.11.5 DST=123.123.124.241 LEN=40 TOS=0x00 PREC=0x00 TTL=48 ID=49032 PROTO=TCP SPT=32555 DPT=80 WINDOW=65535 RES=0x00 ACK FIN URGP=0
Jan 16 12:26:03 toshiro kernel: Firewall: *INVALID* IN=eth1 OUT= MAC=00:30:48:57:e2:5b:00:1a:30:38:90:00:08:00 SRC=152.216.11.5 DST=123.123.124.241 LEN=40 TOS=0x00 PREC=0x00 TTL=48 ID=6093 PROTO=TCP SPT=32555 DPT=80 WINDOW=65535 RES=0x00 ACK FIN URGP=0
Jan 16 12:26:15 toshiro kernel: Firewall: *INVALID* IN=eth1 OUT= MAC=00:30:48:57:e2:5b:00:1a:30:38:90:00:08:00 SRC=152.216.11.5 DST=123.123.124.241 LEN=40 TOS=0x00 PREC=0x00 TTL=48 ID=51941 PROTO=TCP SPT=32555 DPT=80 WINDOW=65535 RES=0x00 ACK FIN URGP=0
Jan 16 12:26:40 toshiro kernel: Firewall: *INVALID* IN=eth1 OUT= MAC=00:30:48:57:e2:5b:00:1a:30:38:90:00:08:00 SRC=152.216.11.5 DST=123.123.124.241 LEN=40 TOS=0x00 PREC=0x00 TTL=48 ID=29303 PROTO=TCP SPT=32555 DPT=80 WINDOW=65535 RES=0x00 ACK FIN URGP=0

Notice- neither his SPT or DPT have rotated, so why does lfd think this is a port scan?

Here's my csf.conf:

Code: Select all

[root@toshiro csf]# egrep -v "(^#|^$)" csf.conf
GENERIC = "1"
TESTING = "0"
TESTING_INTERVAL = "5"
AUTO_UPDATES = "1"
ETH_DEVICE = ""
ETH_DEVICE_SKIP = "eth0,lo"
TCP_IN = "21,22,25,53,80,110,113,808,904,995,8009,8222,8308,8333"
TCP_OUT = "20,21,22,25,43,53,80,110,113,443,4321,5190,6667,9898"
UDP_IN = "20,21,53,123,32768,32769,32770,32771"
UDP_OUT = "20,21,53,113,123"
ICMP_IN = "1"
ICMP_IN_RATE = "1/s"
ICMP_OUT = "1"
ICMP_OUT_RATE = "1/s"
MONOLITHIC_KERNEL = "0"
DROP = "DROP"
DROP_LOGGING = "1"
DROP_IP_LOGGING = "0"
DROP_ONLYRES = "0"
DROP_NOLOG = "67,68,111,113,135:139,445,513,520"
PACKET_FILTER = "1"
DROP_PF_LOGGING = "1"
SYNFLOOD = "1"
SYNFLOOD_RATE = "100/s"
SYNFLOOD_BURST = "150"
PORTFLOOD = "21,22,25,53,80,110,113,808,904,995,8009,8222,8308,8333"
VERBOSE = "1"
SYSLOG = "0"
DYNDNS = "0"
DYNDNS_IGNORE = "0"
IGNORE_ALLOW = "0"
DNS_STRICT = "0"
DENY_IP_LIMIT = "100"
DENY_TEMP_IP_LIMIT = "100"
LF_DAEMON = "1"
BLOCK_REPORT = ""
LOGFLOOD_ALERT = "1"
LF_PERMBLOCK = "1"
LF_PERMBLOCK_INTERVAL = "86400"
LF_PERMBLOCK_COUNT = "4"
LF_NETBLOCK = "0"
LF_NETBLOCK_INTERVAL = "86400"
LF_NETBLOCK_COUNT = "4"
LF_NETBLOCK_CLASS = "C"
GLOBAL_ALLOW = ""
GLOBAL_DENY = ""
GLOBAL_IGNORE = ""
LF_GLOBAL = ""
CC_DENY = ""
CC_ALLOW = ""
CC_INTERVAL = "7"
LF_TRIGGER = "1"
LF_TRIGGER_PERM = "1"
LF_SELECT = "0"
LF_EMAIL_ALERT = "1"
LF_SSHD = "5"
LF_SSHD_PERM = "1"
LF_FTPD = "5"
LF_FTPD_PERM = "1"
LF_SMTPAUTH = "5"
LF_SMTPAUTH_PERM = "1"
LF_POP3D = "5"
LF_POP3D_PERM = "1"
LF_IMAPD = "5"
LF_IMAPD_PERM = "1"
LF_HTACCESS = "5"
LF_HTACCESS_PERM = "1"
LF_MODSEC = "5"
LF_MODSEC_PERM = "1"
LF_SUHOSIN = "0"
LF_SUHOSIN_PERM = "1"
LF_CSF = "1"
LF_SSH_EMAIL_ALERT = "1"
LF_SU_EMAIL_ALERT = "1"
LF_DIRWATCH = "60"
LF_DIRWATCH_DISABLE = "0"
LF_DIRWATCH_FILE = "0"
LF_FLUSH = "3600"
LF_INTEGRITY = "3600"
LF_EXPLOIT = "300"
LF_EXPLOIT_CHECK = "JS,SUPERUSER"
LF_INTERVAL = "300"
LF_PARSE = "5"
LT_EMAIL_ALERT = "1"
LT_POP3D = "0"
LT_IMAPD = "0"
LF_DSHIELD = "1"
LF_DSHIELD_URL = "http://feeds.dshield.org/block.txt"
LF_SPAMHAUS = "1"
LF_SPAMHAUS_URL = "http://www.spamhaus.org/drop/drop.lasso"
LF_BOGON = "0"
LF_BOGON_URL = "http://www.cymru.com/Documents/bogon-bn-agg.txt"
CT_LIMIT = "200"
CT_INTERVAL = "30"
CT_EMAIL_ALERT = "1"
CT_PERMANENT = "0"
CT_BLOCK_TIME = "1800"
CT_SKIP_TIME_WAIT = "0"
CT_STATES = ""
CT_PORTS = ""
PT_LIMIT = "60"
PT_INTERVAL = "60"
PT_SKIP_HTTP = "0"
PT_DELETED = "1"
PT_USERPROC = "10"
PT_USERMEM = "100"
PT_USERTIME = "1800"
PT_USERKILL = "0"
PT_LOAD = "30"
PT_LOAD_AVG = "5"
PT_LOAD_LEVEL = "6"
PT_LOAD_SKIP = "3600"
PT_LOAD_ACTION = ""
PS_INTERVAL = "300"
PS_LIMIT = "10"
PS_PORTS = "0:65535"
PS_PERMANENT = "0"
PS_BLOCK_TIME = "3600"
PS_EMAIL_ALERT = "1"
AT_ALERT = "1"
AT_INTERVAL = "60"
AT_NEW = "1"
AT_OLD = "1"
AT_PASSWD = "1"
AT_UID = "1"
AT_GID = "1"
AT_DIR = "1"
AT_SHELL = "1"
CC_LOOKUPS = "1"
MESSENGER = "0"
MESSENGER_TEMP = "1"
MESSENGER_PERM = "1"
MESSENGER_USER = "csf"
MESSENGER_CHILDREN = "10"
MESSENGER_HTML = "8888"
MESSENGER_HTML_IN = "80,2082,2095"
MESSENGER_TEXT = "8889"
MESSENGER_TEXT_IN = "21"
MESSENGER_RATE = "30/m"
MESSENGER_BURST = "5"
OLD_REAPER = "0"
IPTABLES = "/sbin/iptables"
MODPROBE = "/sbin/modprobe"
IFCONFIG = "/sbin/ifconfig"
SENDMAIL = "/usr/sbin/sendmail"
PS = "/bin/ps"
FUSER = "/sbin/fuser"
VMSTAT = "/usr/bin/vmstat"
LS = "/bin/ls"
MD5SUM = "/usr/bin/md5sum"
TAR = "/bin/tar"
CHATTR = "/usr/bin/chattr"
HTACCESS_LOG = "/var/log/httpd/error_log"
MODSEC_LOG = "/var/log/httpd/error_log"
SSHD_LOG = "/var/log/secure"
SU_LOG = "/var/log/secure"
FTPD_LOG = "/var/log/messages"
SMTPAUTH_LOG = "/var/log/secure"
POP3D_LOG = "/var/log/maillog"
IMAPD_LOG = "/var/log/maillog"
IPTABLES_LOG = "/var/log/messages"
SUHOSIN_LOG = "/var/log/messages"
CUSTOM1_LOG = "/var/log/messages"
CUSTOM2_LOG = "/var/log/messages"
CUSTOM3_LOG = "/var/log/messages"
CUSTOM4_LOG = "/var/log/messages"
CUSTOM5_LOG = "/var/log/messages"
CUSTOM6_LOG = "/var/log/messages"
CUSTOM7_LOG = "/var/log/messages"
CUSTOM8_LOG = "/var/log/messages"
CUSTOM9_LOG = "/var/log/messages"
DEBUG = "0"

Posted: **17 Jan 2009, 16:16**

lfd is picking the multiple INVALID packets up under the Port Scan Tracking option due to this condition:

# This feature blocks all iptables blocks from the iptables logs, including
# repeated attempts to one port or SYN flood blocks, etc

As to why the packets are being marked by iptables as INVALID, I cannot really help you. I have seen intermediate routers cause this if they alter the TCP packet data in such a way that causes iptables to flag them as INVALID.

The iptables man page for the INVALID state says iptables flags such packets:

Possible states are INVALID meaning that the packet could not be identified for some reason which includes running out of memory and ICMP errors which don't correspond to any known connection

Possible solutions:

1. Disable PACKET_FILTER then INVALID packets will be ignored by iptables

or

2. Disable DROP_PF_LOGGING then invalid packets will still be blocked, but they won't register against Port Scan Tracking

Posted: **19 Jan 2009, 16:51**

chirpy,

I guess I didn't catch the "repeated attempts to one port" as part of the port scanning.

I certainly don't want to disable PF, and I've read elsewhere about disabling DROP_PF_LOGGING, but does that end up stopping the port scanning feature? Is there some way I can (without violating your license agreement) force the system to ignore INVALID state packets in the logging?

Maybe it's still too early, and maybe I'm just cloudy headed since I managed to lock myself out of the server with one bad ssh attempt this morning, even though it's set to not trigger under 5... or maybe I misunderstand that part of the configuration as well.

Posted: **21 Jan 2009, 11:01**

That's what disabling DROP_PF_LOGGING will provide you with. It won't disable the port scanning feature for anything other than INVALID packets.

Posted: **21 Jan 2009, 15:47**

Brilliant. Figured that out shortly after my reply, sorry I neglected to update the post to mention that. Thanks for taking the time to explain.

Posted: **18 May 2013, 12:54**

Hi there, I'm getting the same problem as described in this thread. I have updated the PS_PORTS setting to

PS_PORTS = "0:79,81:65535,ICMP"

which I believe should solve the problem, since there's no way I'm going to consider anybody connecting on port 80 to be doing a port scan. I'm new to csf so would appreciate some confirmation of my logic from someone more knowledgable

Regards, Ben

ConfigServer Community Forum

Strange blocks, "Port Scan" on INVALID state packets from legitimate users

Strange blocks, "Port Scan" on INVALID state packets from legitimate users

Re: Strange blocks, "Port Scan" on INVALID state packets fro