opendns port scanning

[uk01]

Hi, we are a web host and have received alot of port scans to our new dedicated servers. Our firewall thinks requests from opendns are port scans and blocks the ip address 208.67.222.222.

We researched further and found out they are not hackers, they are a reputable company. However, we wonder why so many requests are being sent to our servers. Its been 50+ within a 30minute period. So you can understand why our firewall blocks the ip. The port scanning uses port 53 dns port and UDP - random ports (which is what triggers the scanning)

I know this forum is about cpanel but I thought this would be an issue to raise with so many hosts using whm with cfs firewall etc. I wonder if when a host blocks opendns ip's anyone using opendns can't access any of the websites stored with that host?

I wonder if this is the reason so many users of opendns have problems accessing some websites? I wonder how many web hosts just leave this ip blocked, not knowing that it is for opendns.

We would whitelist them, but need to understand first why this isn't something which is widely spoken of. I've spent hours on the internet and can't really find an info, it surprises me that this isn't an issue which opendns have a page on their site about - info for webhosts?

My datacentre added the ips to the csf allow list but within minutes it blocked it again! But why are they port scanning in the first place? It says on the small bits of info I can find on their website, it is not port scans, they are answering requests at a different port or something, but who's making the requests, we didn't have this problem with the vps's?

[uk01]

hi, got a rather sarcastic reply from a user at opendns, however he does provide some info once I get through his sarcasm...
OpenDNS Community > Forums > Port Scanning

It seems that what is triggering the port scans, is opendns responding to dns lookups by our server by existing web programs doing DNS lookups, especially reverse ones, e.g. against DNSBLs to prevent spam etc. We have recently turned on the spam database checks in csf firewall, and the amount of spam is drastically reduced, maybe it is this that is generating the dns lookups?

FOUND THIS - IS THIS A VIABLE SOLUTION?
Sysadmin: Iptables Block or open DNS / bind service port 53

[mambovince]

I am also receiving plenty of port scanning email alerts.

Time: Tue Jan 12 15:09:52 2010 -0500
IP: 94.229.166.11 (GB/United Kingdom/94.229.166.11.srvlist.ukfast.net)
Hits: 11
Blocked: Temporary Block

Sample of block hits:
Jan 12 15:08:42 usb kernel: Firewall: *TCP_IN Blocked* IN=venet0 OUT= MAC= SRC=94.229.166.11 DST=205.234.102.174 LEN=60 TOS=0x00 PREC=0x00 TTL=54 ID=53962 DF PROTO=TCP SPT=47006 DPT=8080 WINDOW=5840 RES=0x00 SYN URGP=0
Jan 12 15:08:45 usb kernel: Firewall: *TCP_IN Blocked* IN=venet0 OUT= MAC= SRC=94.229.166.11 DST=205.234.102.174 LEN=60 TOS=0x00 PREC=0x00 TTL=54 ID=53963 DF PROTO=TCP SPT=47006 DPT=8080 WINDOW=5840 RES=0x00 SYN URGP=0
Jan 12 15:08:51 usb kernel: Firewall: *TCP_IN Blocked* IN=venet0 OUT= MAC= SRC=94.229.166.11 DST=205.234.102.174 LEN=60 TOS=0x00 PREC=0x00 TTL=54 ID=53964 DF PROTO=TCP SPT=47006 DPT=8080 WINDOW=5840 RES=0x00 SYN URGP=0
Jan 12 15:09:03 usb kernel: Firewall: *TCP_IN Blocked* IN=venet0 OUT= MAC= SRC=94.229.166.11 DST=205.234.102.174 LEN=60 TOS=0x00 PREC=0x00 TTL=54 ID=53965 DF PROTO=TCP SPT=47006 DPT=8080 WINDOW=5840 RES=0x00 SYN URGP=0
Jan 12 15:09:12 usb kernel: Firewall: *TCP_IN Blocked* IN=venet0 OUT= MAC= SRC=94.229.166.11 DST=205.234.102.174 LEN=60 TOS=0x00 PREC=0x00 TTL=54 ID=48014 DF PROTO=TCP SPT=47384 DPT=8080 WINDOW=5840 RES=0x00 SYN URGP=0
Jan 12 15:09:15 usb kernel: Firewall: *TCP_IN Blocked* IN=venet0 OUT= MAC= SRC=94.229.166.11 DST=205.234.102.174 LEN=60 TOS=0x00 PREC=0x00 TTL=54 ID=48015 DF PROTO=TCP SPT=47384 DPT=8080 WINDOW=5840 RES=0x00 SYN URGP=0
Jan 12 15:09:21 usb kernel: Firewall: *TCP_IN Blocked* IN=venet0 OUT= MAC= SRC=94.229.166.11 DST=205.234.102.174 LEN=60 TOS=0x00 PREC=0x00 TTL=54 ID=48016 DF PROTO=TCP SPT=47384 DPT=8080 WINDOW=5840 RES=0x00 SYN URGP=0
Jan 12 15:09:33 usb kernel: Firewall: *TCP_IN Blocked* IN=venet0 OUT= MAC= SRC=94.229.166.11 DST=205.234.102.174 LEN=60 TOS=0x00 PREC=0x00 TTL=54 ID=48017 DF PROTO=TCP SPT=47384 DPT=8080 WINDOW=5840 RES=0x00 SYN URGP=0
Jan 12 15:09:42 usb kernel: Firewall: *TCP_IN Blocked* IN=venet0 OUT= MAC= SRC=94.229.166.11 DST=205.234.102.174 LEN=60 TOS=0x00 PREC=0x00 TTL=54 ID=52726 DF PROTO=TCP SPT=32895 DPT=3128 WINDOW=5840 RES=0x00 SYN URGP=0
Jan 12 15:09:45 usb kernel: Firewall: *TCP_IN Blocked* IN=venet0 OUT= MAC= SRC=94.229.166.11 DST=205.234.102.174 LEN=60 TOS=0x00 PREC=0x00 TTL=54 ID=52727 DF PROTO=TCP SPT=32895 DPT=3128 WINDOW=5840 RES=0x00 SYN URGP=0
Jan 12 15:09:51 usb kernel: Firewall: *TCP_IN Blocked* IN=venet0 OUT= MAC= SRC=94.229.166.11 DST=205.234.102.174 LEN=60 TOS=0x00 PREC=0x00 TTL=54 ID=52728 DF PROTO=TCP SPT=32895 DPT=3128 WINDOW=5840 RES=0x00 SYN URGP=0

Are these false positives, a configuration issue or a bug in CSF?

Many thanks,

- Vince

[ModServ]

Same as me

Jan 18 07:27:56 xxxxxxxx kernel: Firewall: *TCP_IN Blocked* IN=eth1 OUT= MAC=00:30:48:c5:ed:ff:00:1b:0d:ec:a2:40:08:00 SRC=216.14.118.98 DST=208.43.79.168 LEN=48 TOS=0x00 PREC=0x00 TTL=54 ID=31611 DF PROTO=TCP SPT=64041 DPT=8443 WINDOW=8192 RES=0x00 SYN URGP=0
Jan 18 07:27:56 xxxxxxxx kernel: Firewall: *TCP_IN Blocked* IN=eth1 OUT= MAC=00:30:48:c5:ed:ff:00:1b:0d:ec:a2:40:08:00 SRC=216.14.118.98 DST=208.43.79.169 LEN=48 TOS=0x00 PREC=0x00 TTL=54 ID=31612 DF PROTO=TCP SPT=64042 DPT=8443 WINDOW=8192 RES=0x00 SYN URGP=0
Jan 18 07:27:56 xxxxxxxx kernel: Firewall: *TCP_IN Blocked* IN=eth1 OUT= MAC=00:30:48:c5:ed:ff:00:1b:0d:ec:a2:40:08:00 SRC=216.14.118.98 DST=208.43.79.170 LEN=48 TOS=0x00 PREC=0x00 TTL=54 ID=31615 DF PROTO=TCP SPT=64043 DPT=8443 WINDOW=8192 RES=0x00 SYN URGP=0
Jan 18 07:27:56 xxxxxxxx kernel: Firewall: *TCP_IN Blocked* IN=eth1 OUT= MAC=00:30:48:c5:ed:ff:00:1b:0d:ec:a2:40:08:00 SRC=216.14.118.98 DST=208.43.79.171 LEN=48 TOS=0x00 PREC=0x00 TTL=54 ID=31616 DF PROTO=TCP SPT=64044 DPT=8443 WINDOW=8192 RES=0x00 SYN URGP=0
Jan 18 07:27:59 xxxxxxxx kernel: Firewall: *TCP_IN Blocked* IN=eth1 OUT= MAC=00:30:48:c5:ed:ff:00:1b:0d:ec:a2:40:08:00 SRC=216.14.118.98 DST=208.43.79.169 LEN=48 TOS=0x00 PREC=0x00 TTL=54 ID=69 DF PROTO=TCP SPT=64042 DPT=8443 WINDOW=8192 RES=0x00 SYN URGP=0
Jan 18 07:27:59 xxxxxxxx kernel: Firewall: *TCP_IN Blocked* IN=eth1 OUT= MAC=00:30:48:c5:ed:ff:00:1b:0d:ec:a2:40:08:00 SRC=216.14.118.98 DST=208.43.79.168 LEN=48 TOS=0x00 PREC=0x00 TTL=54 ID=70 DF PROTO=TCP SPT=64041 DPT=8443 WINDOW=8192 RES=0x00 SYN URGP=0

[mambovince]

I'm hoping that either someone from cPanel support or CHirpy will reply to this topic and give us some insight.

- Vince

[cPanelDon]

I'm hoping that either someone from cPanel support or CHirpy will reply to this topic and give us some insight.

- Vince

By stock-default cPanel and WHM does not include firewall rules that would block activity such as port scanning; this is something that a system administrator would have setup or have handled by the unique firewall (e.g., iptables) configuration used on the system. If it is unknown why the system is configured that way I recommend escalating the issue to the upstream data center or server hosting provider as they will have full access to assist directly.

If using CSF, a third-party software product, to manage iptables rules I recommend referring to the vendor's official web site and their available support channels for in-depth assistance with the configuration:
http://www.configserver.com/cp/csf.html
http://forum.configserver.com/
http://www.configserver.com/contact.html
http://www.configserver.com/support.html

[mambovince]

Hi Don,
Thanks for replying, already mentioned we are using CSF:

Are these false positives, a configuration issue or a bug in CSF?

And have tried asking same question on the developers forum :-(

Thanks

[cPanelDon]

Hi Don,
Thanks for replying, already mentioned we are using CSF:
Are these false positives, a configuration issue or a bug in CSF?

And have tried asking same question on the developers forum :-(

Thanks

Given the provided log information it appears the firewall configuration lead to the traffic being blocked; if this was not desired I would believe it is a configuration issue within the firewall software and I would consider adjusting the firewall configuration so that it does not occur or is less likely to reoccur.