I was perusing my firewall logs today and saw Qualys scans inbound, which is unusual. Qualys authors an industrial-grade vulnerability scanning software package...you typically don't see scans from Qualys.com itself.

This could be a misconfigured scan. I've alerted the IP owner and Dshield.org.

This could also be Qualys being contracted to scan for the hosting provider.

Admins: are you guys aware of 3rd-party scanning from Qualys?

Logs are below:

/var/log/messages:Apr 19 19:00:47 starchild kernel: ICMP-request: IN=eth0 OUT= MAC=fe:fd:40:3e:e7:dc:00:0c:db:fc:8b:59:08:00 SRC=62.210.136.189 DST=xxx.xxx.xxx.xxx LEN=28 TOS=0x00 PREC=0x00 TTL=245 ID=63520 PROTO=ICMP TYPE=8 CODE=0 ID=0 SEQ=0
/var/log/messages:Apr 19 19:00:47 starchild kernel: Connection attempt (PRIV): IN=eth0 OUT= MAC=fe:fd:40:3e:e7:dc:00:0c:db:fc:8b:59:08:00 SRC=62.210.136.189 DST=xxx.xxx.xxx.xxx LEN=40 TOS=0x08 PREC=0x00 TTL=235 ID=39424 PROTO=TCP SPT=13201 DPT=443 WINDOW=512 RES=0x00 SYN URGP=0
/var/log/messages:Apr 19 19:00:47 starchild kernel: Connection attempt (PRIV): IN=eth0 OUT= MAC=fe:fd:40:3e:e7:dc:00:0c:db:fc:8b:59:08:00 SRC=62.210.136.189 DST=xxx.xxx.xxx.xxx LEN=40 TOS=0x08 PREC=0x00 TTL=235 ID=34560 PROTO=TCP SPT=20381 DPT=110 WINDOW=512 RES=0x00 SYN URGP=0
/var/log/messages:Apr 19 19:00:47 starchild kernel: Connection attempt (PRIV): IN=eth0 OUT= MAC=fe:fd:40:3e:e7:dc:00:0c:db:fc:8b:59:08:00 SRC=62.210.136.189 DST=xxx.xxx.xxx.xxx LEN=58 TOS=0x10 PREC=0x00 TTL=54 ID=0 DF PROTO=UDP SPT=45843 DPT=53 LEN=38
/var/log/messages:Apr 19 19:00:47 starchild kernel: Connection attempt (PRIV): IN=eth0 OUT= MAC=fe:fd:40:3e:e7:dc:00:0c:db:fc:8b:59:08:00 SRC=62.210.136.189 DST=xxx.xxx.xxx.xxx LEN=78 TOS=0x00 PREC=0x00 TTL=54 ID=0 DF PROTO=UDP SPT=45843 DPT=137 LEN=58
/var/log/messages:Apr 19 21:13:29 starchild kernel: Connection attempt (PRIV): IN=eth0 OUT= MAC=fe:fd:40:3e:e7:dc:00:0c:db:fc:8b:59:08:00 SRC=62.210.136.189 DST=xxx.xxx.xxx.xxx LEN=78 TOS=0x00 PREC=0x00 TTL=54 ID=0 DF PROTO=UDP SPT=45843 DPT=137 LEN=58
/var/log/messages:Apr 19 21:14:33 starchild kernel: Connection attempt (PRIV): IN=eth0 OUT= MAC=fe:fd:40:3e:e7:dc:00:0c:db:fc:8b:59:08:00 SRC=62.210.136.189 DST=xxx.xxx.xxx.xxx LEN=78 TOS=0x00 PREC=0x00 TTL=54 ID=0 DF PROTO=UDP SPT=45843 DPT=137 LEN=58
/var/log/messages:Apr 19 22:00:00 starchild kernel: Connection attempt (PRIV): IN=eth0 OUT= MAC=fe:fd:40:3e:e7:dc:00:0c:db:fc:8b:59:08:00 SRC=62.210.136.189 DST=xxx.xxx.xxx.xxx LEN=40 TOS=0x00 PREC=0x00 TTL=235 ID=50432 PROTO=TCP SPT=65024 DPT=88 WINDOW=4096 RES=0x00 SYN URGP=0
/var/log/messages:Apr 19 22:00:00 starchild kernel: Connection attempt (PRIV): IN=eth0 OUT= MAC=fe:fd:40:3e:e7:dc:00:0c:db:fc:8b:59:08:00 SRC=62.210.136.189 DST=xxx.xxx.xxx.xxx LEN=40 TOS=0x10 PREC=0x00 TTL=235 ID=47616 PROTO=TCP SPT=65024 DPT=22 WINDOW=4096 RES=0x00 SYN URGP=0
/var/log/messages:Apr 19 22:00:16 starchild kernel: Connection attempt (PRIV): IN=eth0 OUT= MAC=fe:fd:40:3e:e7:dc:00:0c:db:fc:8b:59:08:00 SRC=62.210.136.189 DST=xxx.xxx.xxx.xxx LEN=52 TOS=0x08 PREC=0x00 TTL=54 ID=47118 DF PROTO=TCP SPT=41880 DPT=443 WINDOW=5840 RES=0x00 SYN URGP=0
/var/log/messages:Apr 19 22:00:25 starchild kernel: Connection attempt (PRIV): IN=eth0 OUT= MAC=fe:fd:40:3e:e7:dc:00:0c:db:fc:8b:59:08:00 SRC=62.210.136.189 DST=xxx.xxx.xxx.xxx LEN=52 TOS=0x08 PREC=0x00 TTL=54 ID=1232 DF PROTO=TCP SPT=41980 DPT=443 WINDOW=5840 RES=0x00 SYN URGP=0
/var/log/messages:Apr 19 22:00:34 starchild kernel: Connection attempt (PRIV): IN=eth0 OUT= MAC=fe:fd:40:3e:e7:dc:00:0c:db:fc:8b:59:08:00 SRC=62.210.136.189 DST=xxx.xxx.xxx.xxx LEN=52 TOS=0x08 PREC=0x00 TTL=54 ID=1236 DF PROTO=TCP SPT=41980 DPT=443 WINDOW=5840 RES=0x00 SYN URGP=0
/var/log/messages:Apr 20 00:06:31 starchild kernel: Connection attempt (PRIV): IN=eth0 OUT= MAC=fe:fd:40:3e:e7:dc:00:0c:db:fc:8b:59:08:00 SRC=62.210.136.189 DST=xxx.xxx.xxx.xxx LEN=28 TOS=0x00 PREC=0x00 TTL=20 ID=26203 PROTO=UDP SPT=7710 DPT=1 LEN=8
/var/log/messages:Apr 20 00:06:31 starchild kernel: Connection attempt (UNPRIV): IN=eth0 OUT= MAC=fe:fd:40:3e:e7:dc:00:0c:db:fc:8b:59:08:00 SRC=62.210.136.189 DST=xxx.xxx.xxx.xxx LEN=28 TOS=0x00 PREC=0x00 TTL=20 ID=26203 PROTO=UDP SPT=7710 DPT=17211 LEN=8
/var/log/messages:Apr 20 00:06:31 starchild kernel: ICMP-request: IN=eth0 OUT= MAC=fe:fd:40:3e:e7:dc:00:0c:db:fc:8b:59:08:00 SRC=62.210.136.189 DST=xxx.xxx.xxx.xxx LEN=40 TOS=0x00 PREC=0x00 TTL=20 ID=26203 PROTO=ICMP TYPE=8 CODE=0 ID=7710 SEQ=7710
/var/log/messages:Apr 20 00:06:36 starchild kernel: Connection attempt (UNPRIV): IN=eth0 OUT= MAC=fe:fd:40:3e:e7:dc:00:0c:db:fc:8b:59:08:00 SRC=62.210.136.189 DST=xxx.xxx.xxx.xxx LEN=28 TOS=0x00 PREC=0x00 TTL=1 ID=40301 PROTO=UDP SPT=2827 DPT=17211 LEN=8
/var/log/messages:Apr 20 00:06:36 starchild kernel: Connection attempt (PRIV): IN=eth0 OUT= MAC=fe:fd:40:3e:e7:dc:00:0c:db:fc:8b:59:08:00 SRC=62.210.136.189 DST=xxx.xxx.xxx.xxx LEN=28 TOS=0x00 PREC=0x00 TTL=1 ID=40301 PROTO=UDP SPT=2827 DPT=1 LEN=8

Only some kind of unix FOOL would per... um, uhhhhh, oh yeah. Nevermind.

James

I e-mailed Qualys and got confirmation that this was a customer of theirs that misconfigured a very large scan.

On another note, I'd think that someone here or someone at the datacenter would be concerned about this type of activity, as this wasn't a regular 'scan'. This is far from 'door-knob' jiggling. Actual attempts on applications are made, although the attempts aren't followed through to the fullest extent.

Probably from the sheer amount of scans they probably get on a day to day I'm sure they dont really care, but is probably logged somewhere so they can investigate if somebody opens a ticket or the like.

The security analyst in me sees this as far more than the typical scan. This also wasn't something that came from the typical user account either. Qualys does pentesting and vulnerability assessment consulting. Their scanning solution is definitely not your average nmap-like toolset. When you see scans of this nature, there are two things to worry about: is it an authorized scan and if so, who authorized and why?; has this scanner been compromised.

I could've sat on this and let someone else worry about it, but it was obviously an issue that Qualys addressed and apologized for (it wasn't supposed to happen and companies such as Qualys think such misconfigurations are highly important to remedy). Such scans have the potential to take out networks. I've also seen them kill such simple things as network-capable printers.

Part of the reason the internet is so rampant with questionable activity is that most people simply don't care.

I'd expect my hosting provider to care about someone testing security in this manner...using an enterprise tool to do it makes matters even more peculiar.

I'm not interested in a ticket...I'm not asking for support. As I pay for this service (and it DOES add up, no matter how cheap people think it is), I expect some type of interest in security beyond DoS activity. I see concern from the admins when someone buys a new account and can't wait several hours to gain access...I don't see the same type of concern for a security matter, which is a bit warped. If you tell me penetration scans originating from a known manufacturer of a security tool is commonplace, you're wrong.

Hosting providers do and should be responsible, security-wise. Its a cop-out to just say "its a scan...we see that every day".

Like I've said before, one man's junk is another man's treasure...

Along that same line, if Linode, ThePlanet, AtlantaNAP, HE.net, et. al., started filtering traffic (beyond what Atlanta already does), what is there to stop them from continuing down that path, and get more, and more, and more draconian with their filtering policies... "No more ICMP, you can ping flood", "No more FTP, its insecure", "No more SMTP, it causes spam", "No more ssh, some people have weak passwords", "No more HTTP, people are dumb and click on phishing links", and so on.

The short one liner: Don't mess with my bits.

</rant>

Linode is an unmanaged service. As long as the hardware and the network is up, their job is done. You contacted the source of the trouble and resolved it - that's how it's supposed to work.

_________________
/ Peter

Yeah, well, I never asked them to block...I did ask them for clarification (ie, is this authorized traffic, did you consult this consulting company to assess your datacenter?) There should be SOME concern, IMO. Imagine if you see someone using a slimjim on your car in your work's parking lot. This is not door-handle testing. Will you blow it off and just expect the police or security guards to intervene at their convenience? Or would you put a stop to the activity then ask the police follow-up questions later. I did the latter, in this case, only no one answered my questions.

I honestly don't think I was asking for much and I'm familiar enough with datacenters. Verizon (my company) has tons of them and we tend to be more proactive to such activity. Maybe I'm more sensitive to stuff like this since I manage a team that monitors for such activity....I still expect some type of interaction or rise, though.

I've lost track of how many times I've reported malicious traffic to either the netrange owner or isc.sans.org (who has assisted in taking down clearly compromised machines in the past). When reporting to the netrange owner (when the IP owner won't respond), 9 times out of 10, there is never a response. One site even retained a database of what they were doing and that dbase was accessible for the world to see.

I agree that the individual hosts and owners have a part in policing such issues, but you might be thinking differently when the cracker (and not skiddie) slipped into your machine. And since these are shared hosts, my system compromise could also end up being my neighbor's.

The linode, yeah...the network itself....I don't think so.

I asked questions, not for remediation...two different things. I can certainly ask the admins if they're aware of pentesting of the Linodes...you're acting like this is a funny concept. It is not.

unixfool,

I think you're going to have to be a lot more specific about what you're worried about for us to have a lot of sympathy. Linodes get scanned all the time. You keep saying this is different, but not why, not what's worrisome about this particular scan, or why we should care that it's coming from Qualys or anyone else. At the moment, I agree with everyone else: I don't want the datacenter or Linode policing, monitoring, or really in any way knowing anything about the traffic to and from my Linode.

It may be that you have some legitimate beef, but I think so far nobody here knows enough to agree with you. Can you help us out with that?

Apart from that, the forums are mainly for us to talk with each other. I don't think we can demand that Linode answer every random question tossed out on the forum. If you have something that you expect an answer to, that's what the support tickets are for.