Port Scanning Temporary Block on Linux Centos

Question

I am running a VPS server (Linux CentOS) to provide web hosting for my clients.

Yesterday, one of my clients got blocked out by the LFD firewall on my server:

I got a server admin email notification with the following subject line:

lfd on vps.audetwebhosting.net: 24.2.190.167 
(US/United States/c-24-2-190-167.hsd1.ct.comcast.net) 
blocked for port scanning

and the body contained lines like:

Time: Sun Mar 31 11:29:35 2013 -0400
IP: 24.2.190.167 (US/United States/c-24-2-190-167.hsd1.ct.comcast.net)
Hits: 11
Blocked: Temporary Block

Sample of block hits:
Mar 31 11:28:22 vps kernel: [2760494.944535] Firewall: *TCP_IN Blocked* IN=venet0 OUT= MAC= SRC=24.2.190.167 DST=64.131.66.177 LEN=64 TOS=0x00 PREC=0x00 TTL=48 ID=14772 DF PROTO=TCP SPT=50780 DPT=587 WINDOW=65535 RES=0x00 SYN URGP=0
Mar 31 11:28:23 vps kernel: [2760496.050542] Firewall: *TCP_IN Blocked* IN=venet0 OUT= MAC= SRC=24.2.190.167 DST=64.131.66.177 LEN=64 TOS=0x00 PREC=0x00 TTL=48 ID=28408 DF PROTO=TCP SPT=50780 DPT=587 WINDOW=65535 RES=0x00 SYN URGP=0 

My client is not all that tech savvy so I don't think that they would just casually run a port scan on their Mac laptop.

I am guessing about what might have happened:

(1) Client laptop has a virus that is doing a port scan

(2) Client opened the console window and tried to ping their website

(3) Some hacker is squatting on cleint WiFi connection

(4) Client visited a website with some has a web app that does a port scan

(5) Client has some firewall/anti-malware software that may be doing a port scan

(6) Client has a router that scans ports

I am wondering, how someone could accidentally trigger a port scan type of response from the firewall?

I am a web programmer not a Linux guru, so I am not even sure how to best ask this question. Thank you for your patience.

Answer 1

LFD is the "Login failure daemon" of your CSF-firewall, it's blocking IPs for failed login attempts. From http://www.configserver.com/cp/csf.html :

To complement the ConfigServer Firewall (csf), we have developed a Login Failure Daemon (lfd) process that runs all the time and periodically (every X seconds) scans the latest log file entries for login attempts against your server that continually fail within a short period of time. Such attempts are often called "Brute-force attacks" and the daemon process responds very quickly to such patterns and blocks offending IP's quickly. Other similar products run every x minutes via cron and as such often miss break-in attempts until after they've finished, our daemon eliminates such long waits and makes it much more effective at performing its task.

From your email notification:

DPT=587
DPT=587

As long as there are no other destination ports specified by LFD, this doesn't seem to be a portscan. Port 587 is the SMTP mail submission port. It seems he tried to login to your SMTP, but the login failed, and because of some failed login attempts, LFD blocked his IP. Perhaps this is caused by a wrong password specified in his Email client.

Answer 2

There are some options that are not so likely:

(2) Pinging isn't considered as a port scan. There are some admins that prefer to configure their machines to ignore pings completely, but no firewall that I know considers pings as port scans.

(4) There are web applications that preforms port scan, but they only scan the host that uses the application, in order to give it a report about the status of this firewall. I don't think any web app will allow one to preform a port scan of a different destination.

(5) There's no firewall that I know that preform a port scan on a machine other than one it's installed on.

(6) Same goes for routers.

. Before attempting any technical analysis, the best thing is probably to ask the client what did he do. He might have read a tutorial about nmap and decided to check your server. If he cannot tell what might have caused this reaction from your firewall, then he should be the one checking the security of his laptop and his network. In my opinion, the best thing you can do at the server side is to run a network sniffing tool (such as tshark), however, by doing so the only additional information you can obtain is what ports exactly were scanned. You already have the abusing IP address in your firewall log, but you cannot tell from this whether the client did it on his own, a virus on his computer did it, or someone else from the same internal network as the client did it.