Not long ago I heard from a reader who wanted advice on how to stop someone from scanning his home network, or at least recommendations about to whom he should report the person doing the scanning. I couldn’t believe that people actually still cared about scanning, and I told him as much: These days there are countless entities — some benign and research-oriented, and some less benign — that are continuously mapping and cataloging virtually every device that’s put online.
One of the more benign is scans.io, a data repository of research findings collected through continuous scans of the public Internet. The project, hosted by the ZMap Team at the University of Michigan, includes huge, regularly updated results grouped around scanning for Internet hosts running some of the most commonly used “ports” or network entryways, such as Port 443 (think Web sites protected by the lock icon denoting SSL/TLS Web site encryption); Port 21, or file transfer protocol (FTP); and Port 25, or simple mail transfer protocol (SMTP), used by many businesses to send email.
When I was first getting my feet wet on the security beat roughly 15 years ago, the practice of scanning networks you didn’t own looking for the virtual equivalent of open doors and windows was still fairly frowned upon — if not grounds to get one into legal trouble. These days, complaining about being scanned is about as useful as griping that the top of your home is viewable via Google Earth. Trying to put devices on the Internet and then hoping that someone or something won’t find them is one of the most futile exercises in security-by-obscurity.
To get a gut check on this, I spoke at length last week with University of Michigan researcher Zakir Durumeric (ZD) and Michael D. Bailey at the University of Illinois at Urbana-Champaign (MB) about their ongoing and very public project to scan all the Internet-facing things. I was curious to get their perspective on how public perception of widespread Internet scanning has changed over the years, and how targeted scanning can actually lead to beneficial results for Internet users as a whole.
MB: Because of the historic bias against scanning and this debate between disclosure and security-by-obscurity, we’ve approached this very carefully. We certainly think that the benefits of publishing this information are huge, and that we’re just scratching the surface of what we can learn from it.
ZD: Yes, there are close to two dozen papers published now based on broad, Internet-wide scanning. People who are more focused on comprehensive scans tend to be the more serious publications that are trying to do statistical or large-scale analyses that are complete, versus just finding devices on the Internet. It’s really been in the last year that we’ve started ramping up and adding scans [to the scans.io site] more frequently.
BK: What are your short- and long-term goals with this project?
ZD: I think long-term we do want to add coverage of additional protocols. A lot of what we’re focused on is different aspects of a protocol. For example, if you’re looking at hosts running the “https://” protocol, there are many different ways you can ask questions depending on what perspective you come from. You see different attributes and behavior. So a lot of what we’ve done has revolved around https, which is of course hot right now within the research community.
MB: I’m excited to add other protocols. There are a handful of protocols that are critical to operations of the Internet, and I’m very interested in understanding the deployment of DNS, BGP, and TLS’s interception with SMTP. Right now, there’s a pretty long tail to all of these protocols, and so that’s where it starts to get interesting. We’d like to start looking at things like programmable logic controllers (PLCs) and things that are responding from industrial control systems.
ZD: One of the things we’re trying to pay more attention to is the world of embedded devices, or this ‘Internet of Things’ phenomenon. As Michael said, there are also industrial protocols, and there are different protocols that these embedded devices are supporting, and I think we’ll continue to add protocols around that class of devices as well because from a security perspective it’s incredibly interesting which devices are popping up on the Internet.
BK: What are some of the things you’ve found in your aggregate scanning results that surprised you?
ZD: I think one thing in the “https://” world that really popped out was we have this very large certificate authority ecosystem, and a lot of the attention is focused on a small number of authorities, but actually there is this very long tail — there are hundreds of certificate authorities that we don’t really think about on a daily basis, but that still have permission to sign for any Web site. That’s something we didn’t necessary expect. We knew there were a lot, but we didn’t really know what would come up until we looked at those.
There also was work we did a couple of years ago on cryptographic keys and how those are shared between devices. In one example, primes were being shared between RSA keys, and because of this we were able to factor a large number of keys, but we really wouldn’t have seen that unless we started to dig into that aspect [their research paper on this is available here].
MB: One of things we’ve been surprised about is when we measure these things at scale in a way that hasn’t been done before, often times these kinds of emergent behaviors become clear.
BK: Talk about what you hope to do with all this data.
ZD: We were involved a lot in the analysis of the Heartbleed vulnerability. And one of the surprising developments there wasn’t that there were lots of people vulnerable, but it was interesting to see who patched, how and how quickly. What we were able to find was by taking the data from these scans and actually doing vulnerability notifications to everybody, we were able to increase patching for the Heartbleed bug by 50 percent. So there was an interesting kind of surprise there, not what you learn from looking at the data, but in terms of what actions do you take from that analysis? And that’s something we’re incredibly interested in: Which is how can we spur progress within the community to improve security, whether that be through vulnerability notification, or helping with configurations.
BK: How do you know your notifications helped speed up patching?
MB: With the Heartbleed vulnerability, we took the known vulnerable population from scans, and ran an A/B test. We split the population that was vulnerable in half and notified one half of the population, while not notifying the other half, and then measured the difference in patching rates between the two populations. We did end up after a week notifying the second population…the other half.
BK: How many people did you notify after going through the data from the Heartbleed vulnerability scanning?
ZD: We took everyone on the IPv4 address space, found those that were vulnerable, and then contacted the registered abuse contact for each block of IP space. We used data from 200,000 hosts, which corresponded to 4,600 abuse contacts, and then we split those into an A/B test. [Their research on this testing was published here].
So, that’s the other thing that’s really exciting about this data. Notification is one thing, but the other is we’ve been building models that are predictive of organizational behavior. So, if you can watch, for example, how an organization runs their Web server, how they respond to certificate revocation, or how fast they patch — that actually tells you something about the security posture of the organization, and you can start to build models of risk profiles of those organizations. It moves away from this sort of patch-and-break or patch-and-pray game we’ve been playing. So, that’s the other thing we’ve been starting to see, which is the potential for being more proactive about security.
BK: How exactly do you go about the notification process? That’s a hard thing to do effectively and smoothly even if you already have a good relationship with the organization you’re notifying….
MB: I think one of the reasons why the Heartbleed notification experiment was so successful is we did notifications on the heels of a broad vulnerability disclosure. The press and the general atmosphere and culture provided the impetus for people to be excited about patching. The overwhelming response we received from notifications associated with that were very positive. A lot of people we reached out to say, ‘Hey, this is a great, please scan me again, and let me know if I’m patched.” Pretty much everyone was excited to have the help.
Another interesting challenge was that we did some filtering as well in cases where the IP address had no known patches. So, for example, where we got information from a national CERT [Computer Emergency Response Team] that this was an embedded device for which there was no patch available, we withheld that notification because we felt it would do more harm than good since there was no path forward for them. We did some aggregation as well, because it was clear there were a lot of DSL and dial-up pools affected, and we did some notifications to ISPs directly.
BK: You must get some pushback from people about being included in these scans. Do you think that idea that scanning is inherently bad or should somehow prompt some kind of reaction in and of itself, do you think that ship has sailed?
ZD: There is some small subset that does have issues. What we try to do with this is be as transparent as possible. All of our hosts we use for scanning, if look at them on WHOIS records or just visit them with a browser it will tell you right away that this machine is part of this research study, here’s the information we’re collecting and here’s how you can be excluded. A very small percentage of people who visit that page will read it and then contact us and ask to be excluded. If you send us an email [and request removal], we’ll remove you from all future scans. A lot of this comes down to education, a lot of people to whom we explain our process and motives are okay with it.
BK: Are those that object and ask to be removed more likely to be companies and governments, or individuals?
ZD: It’s a mix of all of them. I do remember offhand there were a fair number of academic institutions and government organizations, but there were a surprising number of home users. Actually, when we broke down the numbers last year (PDF), the largest category was small to mid-sized businesses. This time last year, we had excluded only 157 organizations that had asked for it.
BK: Was there any pattern to those that asked to be excluded?
ZD: I think that actually is somewhat interesting: The exclusion requests aren’t generally coming from large corporations, which likely notice our scanning but don’t have an issue with it. A lot of emails we get are from these small businesses and organizations that really don’t know how to interpret their logs, and often times just choose the most conservative route.
So we’ve been scanning for a several years now, and I think when we originally started scanning, we expected to have all the people who were watching for this to contact us all at once, and say ”Please exclude us.’ And then we sort of expected that the number of people who’d ask to be excluded would plateau, and we wouldn’t have problems again. But what we’ve seen is, almost the exact opposite. We still get [exclusion request] emails each day, but what we’re really finding is people aren’t discovering these scans proactively. Instead, they’re going through their logs while trying to troubleshoot some other issue, and they see a scan coming from us there and they don’t know who we are or why we’re contacting their servers. And so it’s not these organizations that are watching, it’s the ones who really aren’t watching who are contacting us.
BK: Do you guys go back and delete historic records associated with network owners that have asked to be excluded from scans going forward?
ZD: At this point we haven’t gone back and removed data. One reason is there are published research results that are based on those data sets, results, and so it’s very hard to change that information after the fact because if another researcher went back and tried to confirm an experiment or perform something similar, there would be no easy way of doing that.
BK: Is this what you’re thinking about for the future of your project? How to do more notification and build on the data you have for those purposes? Or are you going in a different or additional direction?
MB: When I think about the ethics of this kind of activity, I have very utilitarian view: I’m interested in doing as much good as we possibly can with the data we have. I think that lies in notifications, being proactive, helping organizations that run networks to better understand what their external posture looks like, and in building better safe defaults. But I’m most interested in a handful of core protocols that are under-serviced and not well understood. And so I think we should spend a majority of effort focusing on a small handful of those, including BGP, TLS, and DNS.
ZD: In many ways, we’re just kind of at the tip of this iceberg. We’re just starting to see what types of security questions we can answer from these large-scale analyses. I think in terms of notifications, it’s very exciting that there are things beyond the analysis that we can use to actually trigger actions, but that’s something that clearly needs a lot more analysis. The challenge is learning how to do this correctly. Every time we look at another protocol, we start seeing these weird trends and behavior we never noticed before. With every protocol we look at there are these endless questions that seem to need to be answered. And at this point there are far more questions than we have hours in the day to answer.
Great article, I’m surprised many people even notice the scans I would have though they would get lost in all the background noise.
The link to the research article on shared primes in RSA keys “[their research paper on this is available here].” seems to be missing.
Firewalls, IDS/IPS, and security devices that analyze netflows will all alert on various types of scanning activity (e.g., one IP to many IPs on a single port, scanning IPs across multiple or all ports, sequential or random scanning of a range of IPs by a single or multiple IPs, etc.).
SOC people check out these alerts, determine what type of scanning was being performed (maybe even the scanning tool used if packet captures of the traffic are available), evaluate the threat level of the scan to their network, and decide if the IP has exhibited sufficient malicious activity (or originated from a suspicious geographical location) to warrant blocking on the network’s Internet firewall(s). This is part of the game SOC people play every day.
At least the benign scanners will stop after port discovery. And at least the Michigan guys and the Georgia Tech guys tell you what they are doing, and offer to stop if you ask them. My favorite is watching the scans after an exploit hits seclists, then its the wild wild west till a patch comes out. It’s like watching hungry fish fight for a bit of food.
For the bored SOC, try a honeypot on the side.
I always point my small to midsize business clients to gateway services that automatically track and analyse this scanning, and put it into a monthly report that is more understandable to the end user. This data can help the information security person at such organizations. It really didn’t cost much either until ZoneAlarm dropped the Z100G series; so now you have to shop around to find something comparable. The IT guy/gal at such businesses are already strapped for time and knowledge about who might be attacking them, and what to do about it; so every little bit helps.
Brian, do you have a link to the first paper related to their comment that “primes were being shared between RSA keys”. There doesn’t seem to a link in the brackets at the end of that para.
Thanks.
Looks like this might possibly be the missing link…
“Widespread Weak Keys in Network Devices”
Whups! Something ate the URL. Trying again…
https://factorable.net/
It’s interesting that the commented URL https://factorable.net/ comes up with a yellow padlock in the address bar of Chrome Stable Release Version 42.0.2311.135 m, rather than the more secure green padlock. Right clicking on the word “Connection” tab shows the site could be more secure. I’m just a home user, and no security expert, so it’s a bit amusing to me this group has this exposure.
click on the padlock itself…they appear to be running TLS 1.0…and obsolete security software…woops!
Funny how it ends up that way! The people throwing rocks, end up the ones living in glass houses. 🙂
The Chrome warning actually doesn’t have to do with the fact that the site uses TLS 1.0, it’s because their cert is signed with a SHA-1 signature, which is now deprecated. You can’t really single them out, as over half the web still uses it (you can easily go to places like chase.com and see the same thing).
This warning is fairly new, and is intended to motivate organizations to acquire new certs during the “sunset” period of sha1 signed certs.
Food for thought: This type of scan probably won’t scale to IPV6. To hide from this sort of scan, just use IPV6.
Also, what if they add a check for logins with poor passwords using the top 10 common passwords? The top 1000 common passwords? The top million common passwords?
But I have no problem in general with these sorts of scans.
This information published at scans.io is very fascinating to analyze and is scary to see the overall security posture of the internet. Kudos to the research and researchers. Here is some analysis I have done on the information:
http://thepcn3rd.blogspot.com/2015/04/analysis-of-scansio-rapid7-udp-scans.html
http://thepcn3rd.blogspot.com/2015/04/analysis-of-scansio-university-of.html
http://thepcn3rd.blogspot.com/2015/04/07-of-ip-addresses-continue-to-be.html
The fact that there are a lot of embedded devices out there that can’t be patched isn’t surprising, but it is concerning.
I’ve got a thermostat that has wifi capability, but there’s no way I’m turning that on because I don’t know how I can be 99.9999% sure that it won’t be remotely controllable by someone other than me.
I have a coworker who has a wifi-enabled garage door opener and it alerts him on his phone when it opens or closes. He can also open or close it from his phone. The question is: Who else can control his garage door?
I have the same concerns about wifi-enabled security systems.
That’s an interesting point, I just purchased a Nest but haven’t installed it yet. I assume, like most other wifi enabled things (printers, etc), there will be a password layer to the security. Some users will keep the default and that makes them vulnerable but others will change them to more secure, custom passwords that will increase their security.
Am I incorrect in this assumption?
Lisa,
I’m less concerned about someone guessing the password to my thermostat than I am the discovery of a security hole that can’t be patched. The thermostat in my house is sold by the manufacturer of the HVAC system. I seriously doubt the manufacturer of my HVAC system has expertise in wifi-enabled devices and provided a secure way to update the software/firmware. I’m 100% sure they wouldn’t offer to replace, free of charge, every thermostat with the security hole.
I suspect your Nest can be updated when a security hole is found.
I suspect that if a security hole is found in my coworker’s garage door opener, he will have to replace his control board at a minimum.
Bob and Lisa,
Wifi devices connected to your home network are likely behind your DSL/Cable router, which does not let outside connections in unless you have specifically allowed them. Thus no one on the internet can even see your device let alone scan it. Your router will be blocking all scans.
If you don’t have a router that provides a firewall, you really should get one, having all your home devices accessible from the internet is a very bad idea.
My previous attempt at replying got eaten. It never even showed up as awaiting moderation.
Tom,
I have an ISP supplied wireless router, but I have zero confidence that it is kept up to date with patches. I could get my own router and disable the wireless portion of the ISP router, but as we have seen, the manufacturers of consumer grade routers don’t do a good job of publishing patches. Fortunately, the only non-computing device I have on my network is an all-in-one printer that is old enough that it can’t be updated over wifi. I also only turn it on when I print something and turn it off afterwards.
Tom,
The majority of “IoT” devices like the Nest, Dropcam, SmartThings hub, and all these other “smart home” gadgets simply use STUN techniques to call home (outbound through the firewall) and hold open a port, so that when you want to change your thermostat from your phone while you’re at work, or check on the dog, you can access your device from the internet.
Granted this is going to be an “ephemeral” port, so it might be a bit tricky to scan for, but it’s going to have a port open to the net. That’s how it “just works”. Most current and even many 5-7 year old home/small biz routers have *some* degree of firewalling (beyond just NAT), but they don’t have a restrictive outbound policy, so they will not stop these devices.
Given the technology industry lifecycle, you’ll see these things supported for three years if you’re lucky, and then any future bugs are fair game. From there it’s a matter of a well crafted scan to locate vulnerable gadgets. Instant botnet.
Personally, I hope there isn’t a “password” layer per se.
Ideally your devices will initially generate some sort of very-long-random-token, and share that (preferably public-key-private-key style) between the Nest and your first device.
Ideally the password for controlling your nest is really only something that would unlock that actual key that your phone has to talk to the Nest. In such a model, when you want to add another “trusted device”, you have that second device talk to your first phone, it too generates a public key, sends it to your phone, which uploads it to the Nest, which will then be willing to accept it later, and that second device asks you for a password to protect its key.
Basically: we shouldn’t be trusting users to design passwords, we should at best trust users not to actively lose control of their phones.
And when your phone is lost, if you have a second paired phone, you would go in and ask Nest to disavow the lost phone’s key. — Of course, if you lose your only paired device, you’d go direct to the Nest and ask it to stop or something.
As for whether most devices do this, or only some… Well, there was a recent report about a drug dispenser which didn’t have any authentication requirements (and happily connected to the hospital WiFi).
In today’s world, I’d assume 99% of devices have broken security at best.
A laptop/desktop which gets automatic updates and is running a supported OS is your best bet.
A mobile device first shipped w/in the last year, running a supported OS and where you proactively update to the latest is the next wrt security. The more third party apps you install, the more likely it is to be insecure by some definition.
Any mobile device whose first ship date is more than a year ago is probably not in a good shape (I’m picking my terminology carefully, there are still Android 2.3 devices being sold — those aren’t getting security updates; And yes, It’s possible for an iPhone to be a bit over a year old and still be supported, but it’s hard to get perfect wording for this…).
Unless someone is actively updating your Router (and your standard broadband ISP doesn’t count), it’s probably insecure.
It gets worse for other devices.
what the hell are they going to do to you if they are able to control your thermostat?
People get far too paranoid.
The issue isn’t whether they’ll turn your heat on and try to cook you… It’s whether they can use your thermostat as a launchpad for attacks using your internet connection. Once they are in, they’re in. For all intents and purposes your thermostat could be as useful as a Linux server.
Gather statistics to find when you are away.
On the coldest day of the year, a bad guy turns your ‘stat down and it freezes your pipes causing a flood. Maybe they turn your humidifier up and you have condensation that ruins your walls, woodwork, carpet, and other electronics.
On the hottest day, they turn up the heat, maybe crank open the humidifier and ruin your electronics, refridgerator, or anything else in your home with a compressor.
Or perhaps someone wants to kick your heat on and off, maybe start a housefire through a vulnerability discovered in a type of heater’s control board. Or kick your A/C compressor on and off and try to burn that up.
Best case scneario – they just wreck your thermostat and you’re inconvenienced while you shiver (or sweat) waiting for a repair.
Messing with a networked thermostat is one of the few ways to actual cause percievable, physical harm (think Stuxnet…).
If the hackers can use the thermostat to get inside your firewall, they’ll have open access to your internal computers, which may be much less protected.
Being a clever and security minded individual, you own and have configured a corporate grade firewall to prevent most internal devices from contacting the internet unless you wish that service (Nest thermostat, August Lock Connect). Using a thermostat as a launchpad they attack the following internal (LAN) connected devices which you probably haven’t updated and may never get security patched, anyway. You assume these devices are protected due to no ability to contact the outside world (and vice versa):
1. Wifi Garage Door opener – gain access to your garage and perhaps home.
2. August Lock (un Connect’ed) – gain access to your home.
3. IP enabled Security Cameras – see whatever the cameras see.
4. Media System (AVR) w/ Web Server, OS is Windows – Fun begins here.
5. Flatscreen TV w/ built-in camera – Do you get dressed to watch TV?
6. Kitchen equipment w/ embedded devices – Whatever attacks are possible.
7. LAN connected Security System – Unprotected IP alarm may be turned off.
8. IP Solar Panels – unsure of attack, turn them off?, cost you money?
The hacking skills required for this type of attack are fairly high because no scripts have been released and the installs are uncommon. The value to the attacker would be based upon the material stolen: (1) information (pictures of you naked, stuff from your home computer, your schedule at your house) or (2) things (whatever you have of value in your home, probably keys to a car for most, some artwork or jewelry for others).
Much better return to attack a commercial enterprise, large or small business, as they have things of greater value and more common infrastructure. However, there are a lot more homes than companies, so eventually, when IP devices are prolific and before we have a way to update their embedded software and without knowledgable home IT departments (perhaps never on that last one), some criminals will break into homes through devices vulnerabilities.
I can imagine someone WAR-walking through a city, scanning Wifi systems for vulnerabilities and looking for wifi enabled devices *or* attacking the central servers and climbing through them as a back channel.
Want to break into someone’s home? There’s an app for that.
Brian,
I wonder if there is also a subset of internet users, companies, educational institutions, etc who not only welcome being scanned in the interest of research but who actually request it in order to stay on top of their own security vulnerabilities?
This is one of the things that white hats do.
It’s like ShieldsUP! from GRC but in reverse, on a larger scale, and initiated by a single group rather than a user.
Anybody behind a router is pretty much immune to port scanning. The firewall in the router simply won’t respond to unsolicited outside requests. No open ports = no problem.
Assuming there isn’t software running somewhere within the network that opens a port somewhere.
Assuming that the network isn’t running on a compromised router (what are the odds?).
NAT is only a firewall by loose definition.
That gorgeous woman at the end of the bar doesn’t respond to advances, either. Until one time, when the advance is different, her interest is peeked, and she responds.
Too funny, thanks for the chortle!
piqued.
@ Tome R.
Until one day the Advanced Persistent Threat sleeping on your network, wakes up the the right port knock!
That’s to Tom R. and “wakes up TO the right port knock!”
Geeze I need to do better editing before I post! Sorry!
One fun scan is browser based. If you can get visitors to your site to run JS (i.e. if you can get visitors to visit your site, and they aren’t paranoid), you can get the browser to do a limited class of scanning for you.
I haven’t seen anyone write any real implementations of this recently, but there are some clever tricks one can do to try to figure out if things exist (basically timeouts give things away even if browsers try not to allow it, and if a server is willing to provide an image anywhere, you can learn a bit about it through some layout sniffing).
Firewalls really won’t save you. They will give you a false sense of security. And they’ll fall apart at some point.
with Subterfuge Attack Frmekerk Kalinux Offesive sec, of course everything
What they are taking about scanning is public facing services. If you put up a web server (port 80) it is so people can connect to it, which is all a port scanner does. What is annoying are the scans for non-public services, like ssh (port 22) which is the secure shell login protocol, which are attempts to break into your computer. I let this through my router firewall so I can log in remotely and the number of attempts to log in with guessed passwords every day is roughly 100. One can use log watch program like DenyHosts to automatically black list hosts that try repeatedly to log in and fail. The only success I’ve had against these is when they have used compromised Amazon EC3 hosts to scan and these can be shut down by contacting Amazon. But most evil scanners are run on compromised home computers with no one to contact.
Tom, that’s a common concern for many home and small business users. If you want to secure those open SSH ports a bit more by using port knocking, or if you already are, I’d recommend implementing an additional layer through single packet authorization or SPA.
There’s an open source project on GitHub called fwknop that I’ve made use of in the past, links below. I wouldn’t recommend this for everyone but since you seem to have some technical experience running your own server you might find it beneficial or at least worth reading up on.
http://www.cipherdyne.org/fwknop
http://www.cipherdyne.org/blog/2012/09/single-packet-authorization-the-fwknop-approach.html
Lock down ssh with these two steps:
1. Create a (password protected) ssh key and configure the host to ONLY allow logins with ssh keys, and NO root logins — no passwords. In /etc/sshd_config,
PermitRootLogin no
PasswordAuthentication no
ChallengeResponseAuthentication no
2. Configure your firewall to block bruteforce attacks. On OS X’s (BSD-based) pf, in /etc/pf.conf,
$int_if = “en0”
table persist
block drop log quick from
# ssh really restrictive
pass in quick inet proto tcp to ($int_if) port ssh \
keep state (max-src-conn 5, max-src-conn-rate 5/2, overload flush global)
This will bring down ssh attacks to near zero.
While that and other methods of hardening would help cut down on certain types of activity, there just aren’t many, if any, reasons to have your remote access ports publicly visible in the first place.
There are several open source software packages that easily offer the ability to conceal the services you have running on the other side of your perimeter, fwknop being one of the better maintained versions implementing single packet authorization.
To take it a step further, on the other side of your gateway you can and should restrict local user access and make everything immensely more secure by combining things like SPA and 2FA (on a seprate device such as mobile or dongle) with NAT/SNAT/DNAT.
Why allow a compromised device from within your network the ability to see, much less communicate with, any other service or device that it does not explicitly require access to?
Will these devices eventually become compromised? Yes, quite likely through some form of social engineering such as spear phishing. The Amazon/Wal-Mart gift card phishing e-mails have hit quite a few companies and individuals recently and have proven to be ridiculously successful. However, there is no reason to help facilitate an attacker’s lateral movement or visibility within your environment once they do gain access to such a device.
I should have specified in the previous post, Michael Rash’s open source application fwknop’s SPA implementation is authorization _plus_ authentication, within the packet itself as opposed to just the header. This allows for increased functionality and additional layers of security. It also now has support for TOR.
If you protect your legitimate remote access ports for services such as SSH, RDP, and others, with defensive layers such as this and other technologies like SDN and SDP, as well implementing things like two-factor OTP tokens via secondary device and/or biometric auth at every user credential transaction across as many devices/platforms as possible but critically on every server/account with sensitive data, along with encryption where possible, you will greatly increase the effectiveness of your existing SIEM and DevOps infrastructure.
I asked them to stop and they did. Why? We look for anomalies and a major one is connections to our servers by IP address rather than by DNS name. No legitimate user of our public services would ever do that and they raised a flurry of alerts every time they did it, which escalated a call tree. Which usually woke me up. 🙂
The original questioner has the right idea, but scanning isn’t the problem.
The problem is SYN packets from undesirables, and there’s plenty of open source support to block access from known attackers. These capabilities should be built-in to the OS, but are not.
I’ve used dshield, hphosts, and other lists in conjunction with the pf packet filter to bring down snort alerts to a small fraction of attacks that appear on an unmodified firewall.
And yes, ZMap’s port scans still show up on snort alerts, but ZMap are good guys. If you don’t want to be scanned by anyone, program snort to toss any scanners into a blacklist, but as Brian notes, this really isn’t the issue.
Googling these terms will show a variety of solutions to the spirit of the original question.
Hey Brian,
Most of this discussion seems to be around port scanning but what about full blown vulnerability scanning or exploit attempts such as heartbleed or shellshock against public facing assets? These attacks can occur from 1000 different IPs daily against public facing assets. Are these attempts actionable? Should organizations care more about this activity? Or should they view it the same way as port scanning and just accept that if they have a public facing asset it will be hit by all manner of exploits and just focus and doing regular internal vulnerability assessments as well as focus on alerting on post compromise behavior?
Interesting stuff.
Question Brian, how did you conduct this interview? Phone, in person, email, IM…?
Phone. I take scary copious and accurate notes. One of my first jobs at The Post was as a dictationist, so….
Wow! That’s a skill I don’t have. I joke that I got into writing software because my handwriting was unreadable, even by me.
for me, not a joke, but reality. I am forced by my professors to type up stuff, even when their previous words were: “the assignment says to write, not type; so follow that, please”
the words after that were “I can’t read a single word of this. Please oh please, type this up” —- he had to figure out eventually
Kyle, I stopped being in awe of educators a long time ago, once I became as educated and, sometimes, more experienced, than some of them. Some are pretty good and some are arrogant, petty bullies who appear to look at the rest of us as the great unwashed. Some have real experience and some live in ivory towers.
Educrats can circle the wagons pretty fast when you complain. ‘A little sunshine’ and not backing down works wonders, but not if you need the degree. They win. For someone like me who needs credit to maintain professional certification, some can be very annoying.
The UM study, to me, is just wasted taxpayer money since few benefits apparently reach the great unwashed like me. I took a look at one of their scholarly publications. It was pretty loose and not even close to being a justification for their nuisance activity. They refer to themselves as “Computer Scientists”. To me, they look like computer scientists protected by tenure. If I am wrong and Actual useful information is the end product of their activity, please correct me as I would like to learn something new.
MS has about 12 system updates and 1 for IE security
https://technet.microsoft.com/library/security/ms15-may
https://technet.microsoft.com/library/security/ms15-041
Flash Player 17.0.0.188 (Win and Mac)
https://www.adobe.com/products/flashplayer/distribution3.html
fun fun fun
I can’t believe people still care if their networks are scanned, either, personally.
I’ve gone for scanning 1.1.1.1 to 223.223.223.223, inb4 it slows my network and computer, the crap down.
Though zmap and masscan are better.
Most aren’t for attacks; there’s such a thing as white and grayhats, and many people don’t understand that.
oh, and using port 0 to scan all ports is FUN, but astoundingly looooooooong.
I should probably clarify that, at the time, I was using Angry IP Scanner, which is cruddy java.
That’s against what Zmap and Masscan are better/more-effective.
Brian’s article here brings up a very common activity used by defenders, researchers, and attackers alike. It also serves a good reminder that the very simple fact that your services are visible on the Internet increases your risk exponentially regardless of almost all defensive layers you may have implemented. This is an unnecessary risk that can be mitigated.
What many large global organizations, including at the government and military level, have been doing for some time now, in addition to many other things, is concealing the existence of these services from all but authorized devices, in the first place.
With the most recent versions of current technologies such as Software Defined Networking (SDN), Software Defined Perimeters (SDP), and Single Packet Authorization (SPA), there is simply no reason to ever have remote access ports, IP addresses, or DNS records, open or visible to anyone on the Internet, and increasingly even internally behind your firewall to the Intranet.
The Cloud Security Alliance, along with Waverly Labs and others, have been working on a collaborative project since 2013 that now aims to implement such technologies as several of five main security layers and release this as an open source framework that everyone can benefit from. However, much of this technology is currently available independently of this project and may already (unlikely) be in use within your environment.
For additional reading, you should all check out the below. Note, I am unaffiliated with all of these projects and people.
http://www.cipherdyne.org/blog/2015/04/nat-and-single-packet-authorization.html
http://www.darkreading.com/cloud/cloud-security-alliance-waverley-labs-collaborate-on-open-source-software-defined-perimeter-spec/d/d-id/1320421
Thanks for the detailed information. I was shocked when some IP addresses I found on a router log came from China, then later from UM. Later I discovered that scans are common and the steps I had taken much earlier were protecting me from problems.
To me, the UM study is a lot like testing front door knobs just because you can, then, maybe, poking your head in the door and telling the resident their door was unlocked. When I first discovered the UM scans on my log, I thought they were just some smart a** kids using UM property for a little extra credit and exploration. No different from the Chinese hackers earlier.
Agree with issues from earlier comments about internet of things potential issues. Given that I do banking on my PC, I honestly don’t care about betterment of man studies if I never read any of the benefits in commonly accessible publications. Scholarly publication in obscure journals still looks, to me, like good excuses to play with people and feel smug about it.
Later this year I plan to look into building a sophos or the like gateway just to be sure these people stay out. Hopefully my updated DD-WRT software and certificates protect my OpenVPN and SSH pass throughs so I can browse on public wi-fi, securely, by linking through my home router. If not, please ask UM to publicize this and be useful in the process.
Additionally, I would like to note that the heroics mentioned above where the intrepid researcher bragged about saving innumerable sites from HeartBleed … their comment reminded me of Al Bundy’s frequent reminders to all of his four touchdowns in one game back at Polk High. If the reference escapes you, look it up.
I could also take credit for saving the world via the article I wrote in my blog about HeartBleed. So could Google for giving me access to the material I used in my article. (Let’s take a lap, Google.)
UM: What have you done for me lately, or in any respect besides making me feel the need to put together a Unified Threat Gateway? Where’s your blog dedicated to information that can be applied by regular people?
I think you sort of answered your own question. The fact that you now realize or feel the need for a UTM solution in order to efficiently increase visibility into your environment’s threat landscape. These studies provide valuable data and greatly help to identify weak spots or potential future liabilities that contribute to the overall global conversation on this topic.
Ian,
You are correct. They did make me aware of my need for a UTM gateway solution. However, they did it via public nuisance activity … much like some of the other commenters who like to play with open source software toys. I await public disclosure of how their activity differs from the kiddies above. Please cite any social benefit gained via UM scanning … other than saving the world from Heartbleed. UM is taxpayer supported and, at this time, it looks looks like thinly veiled taxpayer fraud by providing the IT dept with toys for fun. UM .. please correct my erroneous impression. How can I, or anyone else, benefit from your activity, other than feeling the need for a UTM gateway?
Also, re the Heartbleed victory; how did you know who was unprotected without engaging in more than passive scanning? I don’t know how to use a scanner and your explanation would add credibility to your activity.
Calling it a public nuisance activity is a matter of opinion and you will find yourself in the minority in that regard.
There was a time not very long ago that perhaps more or even most people shared your view, however, as the evidence becomes clearer by the day that these threats we face are extremely serious the need to understand the entire situation from the broadest point of view down to the most granular level makes it critical for defenders to have an abundance of research data at their disposal.
You might try and do a bit more research of your own on the implementations of such data. As the Internet of Things grows exponentially these types of studies will become incredibly valuable in understanding the overall global state of our interconnected devices.
1 more thing and I’ll move on. This is consuming too much of my time and I’m essentially wasting it.
The scans I found using UM IP addresses had nothing to do with any well known port. All were in the 5 digit range. What does that have in common with the explanation given in the main story?
There is a very simple way to protect your home PC network from your home’s “things” like thermostats and toasters. Buy a second cheapo home router and put it behind your existing one.
In other words, plug the second router WAN port into the DMZ port of the main one. Then configure your “things” to use the second router and not the first one.
That will put your “things” on a second IP subnet that cannot access your home PC network any easier than an attack from the Internet could. And it’s a lot cheaper.