Millions of 'must be firewalled' services are open to the entire internet – research Millions of services that ought to be restricted are exposed on the open internet, creating a huge risk of hacker attack against databases and more. Infosec firm Rapid7’s researchers took a close look at the millions and millions of individual services that live on the public IP network, one of the most fundamental components …
It's not news TO YOU. The thread immediately following yours shows that it was of interest to someone and the insight gained may just have made the net a better place.
So, y'know, how about you just shut the fuck up if this is all you have to say, huh? Sooo bored of reading this post over and over.
I still find that there are lot of companies with zero comprehension of internet protocols and their caveats. It's not exactly an uncommon thing to see people using FTP or Basic Auth for HTTP websites and then having to explain why they might want to use more secure protocols such as SFTP, FTPS or HTTPS for these types of things to at least get some basic level of encryption on there. Mainly seems to affect smaller businesses as larger businesses will have their own IT department that most of the time will have at least one person who is security aware/conscious. Smaller businesses still make up a significant amount of services online.
Encrypted protocols will provide confidentiality of data, but they won't protect you from unneeded, vulnerable services published on the Internet. Using stronger auth method will help, but won't protect from flaws exploitable without authentication (Heartbleed, for example, didn't need it).
What people forget is the Internet is a TCP/IP network, not an HTTP one. Everything (mostly) that works on a LAN will work and will be accessible on the broader internet as well (OK, NAT or the like may save your butts sometimes....). To reduce the attack surface, you have to make them not accessible every time they are unneeded. Just enabling encryption, if available, is useless.
Then you have to harden what you need to publish.
Indeed, encryption won't protect you from vulnerable services being opened to the Internet. I mentioned basic auth specifically and FTP because these send the credentials in plain text which even if you firewalled off all non-essential services could still allow a server to be compromised in horrible horrible ways. However your description of the Internet as TCP/IP network is wrong, the Internet is an IP network, it is not limited to TCP and only blocking TCP ports will not secure a server either since you'd leave UDP, icmp and various other protocols too.
I do not see much point in blocking potentially vulnerable services when you have left knowingly vulnerable services wide open while also sending everybody else between you and home a copy of the key. Which I guess is to say, there is one point closing all the windows on a house if the front is left wide open. Sure you need to make sure the windows are closed but you also need to ensure random people can't just walk in via the front door. So yes, while you need to protect the wider area, you also need to make sure the granted access itself is not compromised and using protocols like FTP sure ain't a good way of doing that. More so when that FTP access is as super users or administrators, which I have seen "because it's easier/more convenient".
Sorry, but 'TCP/IP' is the quick and quite official way way to refer to the 'Internet Protocol Suite'.
About the other issues, anonymous FTP for public files is not an issue. FTP with self-sogned certificates not properly checked is not much more secure than without. An FTP server open to the Internet when it should not, maybe unmaintained, is a bigger issue.
The "small business" problem is largely down to how much they can afford, the shite that third parties sell them, and the convenience they want because they think no-one will ever target them.
We support around 60 SMB's - from one person, up to about a hundred.
Quick examples that pop to the top of my head:
* MD wants RDP access. VPN not possible as too complex for them to set up remoting around different machines, 2FA not possible as they might not always have their phone, and will remote from different places so firewall can't be locked down (and they wouldn't get a static for home anyway). Result = RDP access open to world. And I *know* her password is "admin123". She won't change this and has been told UMPTEEN times.
* 3rd party sell software to company to upload docs to other companies. It's FTP, and their crudely written software doesn't support anything but basic FTP. Result = Pretty unsecure FTP server on the Internet, locked down with whatever the strongest password is chosen by their customer. 3rd party won't secure it any further as there isn't a demand, and we as IT supplier are just told "fix it, it cost 5 grand!" If we didn't, someone else would.
* I know double-figure sites of ours that have their CCTV open to the world - the "engineers" who install them when you point out the dangers of this just say mockingly "I don't think anyone is interested in X's CCTV!". Again, sites just say "fix it, we want the cameras on our phones!"
Cue the youngsters and/or the naive with their "call yourselves an IT outfit, that's hardly professional" but the top and bottom of it is 1) they ARE told, 2) they IGNORE it, so we at least try workarounds, 3) if we didn't set things up as requested, we'd be out on our ears and someone who didn't bother with steps (1) and (2) would be taken on instead.
Take the first example - I know companies exist that wouldn't even have warned her about her password being weak - because we took over from them and she huffed and puffed saying it'd never been a problem before!
I remember when I started at my current workplace.
All kinds of stuff open and port-forwarded for little or no reason.
Everything open "because otherwise things don't work".
And nobody paid attention to whether that port 80 that software needed was port 80 OUTGOING or INCOMING so they just opened everything "just in case". And in 90% of cases I say, it actually just wanted port 80 outgoing (i.e. so it could check for updates) but it was having everything exposed.
I came in, put in a deny-by-default firewall, waited for people to shout or things to stop working. Apart from a few things that turned out not to be related anyway (but it took a lot of convincing), and opening up - say - the telecoms remote access ports ONLY to the telecoms company instead of any passing IP, everything worked. And grc.com provided a "clean" sweep of the system - showing only the ports we were deliberately opening.
Then I put in reverse proxy - so even our "port 80" isn't really port 80 at all. It's just a proxy to the internal systems that don't need to be individually port-forwarded, locked down etc. and that only ever received already-filtered-and-IPS/IDS requests from the reverse proxy. As a nice bonus, the RP was able to SSL a few services that weren't capable of SSL by themselves.
Don't even get me started on the state of the RDP server configuration. Guest logins, anyone?
It's scary how often people on tech lines answer "Oh, just exclude our software/services/device from your filtering / firewall", and even scarier how often that's interpreted as a blanket exception rather than just poking holes where they are actually needed.
If GRC.com and/or nmap show that your public IP is putting out anything more than the explicit services you know you are providing to the world (e.g. SMTP, HTTP, RDP, etc.) and/or that those ports do anything more than ask for login details or filter requests from the very start, then you're doing something incredibly badly wrong.
UPnP is my biggest bugbear in a home-use scenario. A protocol that allows unauthenticated software on the local network to just request port-forwards from any external port range to any internal port range without user's knowledge or consent ("so that the video works"). I honestly just turn that off as one of the first things on any router I buy.
It should be made illegal to scan ports on servers you don't own without a license.
Your 'license' could be the purchase of a '.portscan' TLD, we can levy nice big fees to get one of those. Anyone scanning from any other TLD is breaking the rules.
I wonder how much bandwidth is consumed by all the port scanners.
Real world numbers?
Swamped, by orders of magnitude, by the sheer TCP traffic for the number of attempts to connect to port 22 (SSH) or 25 (SMTP) on a datacentre dedicated server on 100Mbps line, even when those ports are closed and have never offered a service.
Include port 80 and you're swamped by another order of magnitude as automated scans from virus-laden networks try to attack /phpmyadmin/admin.cgi or whatever, even if your site doesn't have any HTTP server running at all.
Passive port scans from security companies etc. don't even figure in the numbers. Even the automated port-80 bot scans (from Googlebot and a thousand and one genuine "research" bots) aren't worth bothering about.
But the junk trying to hit your SSH and/or send you spam swamps them all.
And in terms of bytes transferred, your genuine traffic on ANY service that you offer (even NTP pool membership, or a website, or an email server) will swamp them all.
TCP is quite an efficient protocol to shut down connections quickly, and you can have several thousand connection attempts in the same on-the-wire size of even the first few replies for a real HTTP response (i.e. someone visiting your website).
It's really not a factor to worry about, and nobody bothers to filter. Rate-limit? Possibly, but you've already received the packet by that point anyway. But nobody really bothers to filter out port scans on their upstream firewall, it's not worth the effort for the traffic you save.
I wonder how much bandwidth is consumed by all the port scanners.
For my home connection
Attempted Scans
From: Jun 5 04:02:44 To: Jun 10 18:59:13
packet counters: tcp: 5546, udp: 6052, icmp: 239
Total bytes: 1356610
So, A vanishingly small amount of bandwidth compared to all the normal traffic in/out (approx 12GB) over the same period.
However, multiply that small amount globally...
We went from owning all our MFP's outright to leasing Canon units, they weren't happy about us wanting the default logins changed from user: 5000 password: 6000 to something a little harder to use.
Then there were the URL's they wanted the devices to access and the management connectivity, so they could update their firmware whenever they want.
As it is we managed to set them all to the same email address for sending and blocked that address from sending outside the organisation.
Man I hope someone does an attack on one of the printer manufacturers equipment connections, as that's the only way these slack idiots will wake up and put decent security in their products.
Sounds like Canon have some lessons to learn from Konica Minolta; yeah I work there: http://www.biz.konicaminolta.com/services/csrc/ in a place called New Zealand.
It connects via an optional proxy, change of passwords is no problem. The other issues you mention in your post are valid and solvable. Sounds like your Canon Techies didn't listen to the customer.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
