Exposed RDP Servers See 150K Brute-Force Attempts Per Week (techrepublic.com) 51
Slashdot reader Cameyo shares a report from TechRepublic: Remote Desktop Protocol (RDP) is -- to the frustration of security professionals -- both remarkably insecure and indispensable in enterprise computing. The September 2019 Patch Tuesday round closed two remote code execution bugs in RDP, while the high-profile BlueKeep and DejaBlue vulnerabilities from earlier this year have sent IT professionals in a patching frenzy. With botnets brute-forcing over 1.5 million RDP servers worldwide, a dedicated RDP security tool is needed to protect enterprise networks against security breaches. Cameyo released on Wednesday an open-source RDP monitoring tool -- appropriately titled RDPmon -- for enterprises to identify and secure against RDP attacks in its environment. The tool provides a visualization of the total number of attempted RDP connections to servers, as well as a view of the currently running applications, the number of RDP users, and what programs those users are running, likewise providing insight to the existence of unapproved software. RDPmon operates entirely on-premise, the program data is not accessible to Cameyo.
Customers of Cameyo's paid platform can also utilize the RDP Port Shield feature, also released Wednesday, which opens RDP ports for authenticated users by setting IP address whitelists in Windows Firewall when users need to connect. RDP was designed with the intent to be run inside private networks, not accessible over the internet. Despite that, enterprise use of RDP over the internet is sufficiently widespread that RDP servers are a high-profile, attractive target for hackers. The report says Cameyo found that Windows public cloud machines on default settings -- that is, with port 3389 open -- experience more than 150,000 login attempts per week.
Customers of Cameyo's paid platform can also utilize the RDP Port Shield feature, also released Wednesday, which opens RDP ports for authenticated users by setting IP address whitelists in Windows Firewall when users need to connect. RDP was designed with the intent to be run inside private networks, not accessible over the internet. Despite that, enterprise use of RDP over the internet is sufficiently widespread that RDP servers are a high-profile, attractive target for hackers. The report says Cameyo found that Windows public cloud machines on default settings -- that is, with port 3389 open -- experience more than 150,000 login attempts per week.
Ad? (Score:4, Insightful)
Isn't this just an ad for "Cameyo's paid platform"? I probably see thousands of connection attempts a week to port 3389 on my firewall without any RDP server at all. This isn't really news, every public port is scanned and vulnerabilities are probed.
Don't leave non-public services open to the internet.
Yet Windows have no Built-in method to block repea (Score:4, Interesting)
Re: (Score:1)
I m shocked because there is no easy way to block ip after x failures or something like that. Even the event viewer do not report the ip address that try to login. Shameful.
And who would have a Windoze machine that wasn't behind a firewall???
Re: (Score:2)
Re: (Score:2)
That's the wrong way to go about it.
All remote access to intranet and management interfaces should require VPN connectivity to the internal network first.
Whoever is exposing RDP to the internet is an idiot (same applies to SSH 99% of the time). And yeah, maybe that means there a lot of idiots.
Re: (Score:2)
IPv6 fans. People who do not believe in fans. People who visit kiosks or libraries that do not use NAT but instead are part of a school's or businesses relative large public IP address space.
Re: (Score:3)
Re: (Score:2)
That's not even close to true. [ponderthebits.com]
Pretty close, according to your link (Score:2)
You linked to a page that's thousands and thousands of words to explain how the author manages to eventually find the information in most cases. He spent many hours trying to figure out how to get this information, the author says
The very first log entry he mentions you need is what Microsoft so calls "User authentication succeeded" - which does NOT indicate that authentication succeeded, or was even attempted.
Then you go look at a different log next. According to your link, you need to look for either th
Re: (Score:2)
Re: (Score:1)
I m shocked because there is no easy way to block ip after x failures or something like that. Even the event viewer do not report the ip address that try to login. Shameful.
Here's a feature request for it: https://github.com/cameyo/rdpm... [github.com] -- anyone interested in implementing it?
Firewalls, VPNs, SSH Tunnels... (Score:1)
Re: (Score:3)
From my experience, when these things are setup they are not done by Professional IT staff. But that one guy at the office who seems to think they know a little more about computers than everyone else. Being this guys job isn't IT, nor is ultimately responsible for any bad IT decision will often do what it takes to get it to work. Even if the company does have and IT Department, they will work to go around them, because they will tell them no, and spend some more time to come up with better solution.
Not k
Port does not matter (Score:2)
Re: (Score:3)
I normally have a rule in my firewall - make more than 2 connection attempts to ports that are not open - get banned for an hour. I do it on mikrotik natiely, but I suggest you look at fail2ban https://fail2ban.org/ [fail2ban.org]
Re: (Score:2)
Correct link:
https://www.fail2ban.org/wiki/... [fail2ban.org]
Seems you need to www at the start!
Re: (Score:2)
Since the port isn't open, you can't have a full 3-way handshake attempt, therefore you're relying on 2 syn packets sent to ports that are not open...
So what if someone sends spoofed SYN packets? Your firewall rules will block the spoofed source addresses.
Someone malicious can use this to block addresses that you actually want to communicate with, or they can use it to just fill up your firewall ruleset with redundant entries.
Fail2ban is a little better as it triggers on full 3 way handshakes followed by ac
Re: (Score:2)
That's called security by obscurity, I have done it for many many years - I got one of my systems (I support about 20) owned by doing that, due to really crap passwords.
Now we have a much stronger password, fully patched machines, still do the port trick - it's still not really good enough, IF there's a clear vunerability sadly.
It's better to use a VPN and then 'connect locally' as someone else said. :(
None the less it is super convienient
Firewall + VPN... (Score:2)
And just why do these machines have direct internet access? It isn't like a VPN is rocket science. And, for the machines exposed within a large corporate network, why aren't sufficiently granular controls in place to limit attack surface?
(Reminds myself of the vendor we have that uses Team Viewer to access our network without proper protection...)
Re: (Score:2)
It isn't like a VPN is rocket science.
That's how you feel about it, but my management disagreed. I explained, demonstrated, walked them through it, got a couple to try it ...
They were already used to the speed and ease of RDP so that's what I did. I did make changes to practices to help out. I never did get hit, though I could see the attempts to do so.
Re: (Score:2)
FWIW, IKEv2 is your friend...
Re: (Score:2)
FWIW, IKEv2 is your friend...
Thanks, but so is TCP/IP.
Both are protocols.
Re: (Score:1)
Re: (Score:2)
Agreed - although to some extent, why shouldn't they be on the Internet? I mean, I have SSH ports open to the world, why not RDP?
Since I'm educated about such matters, I obviously wouldn't put RDP onto the Internet because Windows and pretty much anything to do with it is riddled with security issues. But in principle, it ought to be possible - which is probably why it persists as a "thing". Windows and Microsoft have a lot to answer for.
As for the VPN - I wonder about that too - most of these servers are b
Re: (Score:2)
Security works best in layers, so if you care about it you try to have multiple independent layers of authentication. Of course, management of that is a pain in the ass.
SSH can do it reasonably safely iff you are using certificates. User/password authentication exposed to the internet is asking for trouble... and you are still relying on a single layer of security.
We used RDP ... (Score:3)
... and what I did was change the port from 3389 to the last four digits of our telephone number.
I monitored the logs on the firewall and RDP was the number-one hit. I could see the name and password they tried.
Mostly it was admin, administrator, and then random usernames and the passwords were blank or the same as the username.
Attacks did decrease a lot and I think it was because port scanners found nothing at 3389.
Whitelisting an IP was not an option. My people traveled all over. I used CNAME at the domain level to craft subdomains with the user's names spelled backwards.
Re: (Score:2)
Re: (Score:1)
I didn't even work in tech 10 years ago and had a VPN connection to my house. It's not that hard to set up.
Re: (Score:2)
Good question. It was not.
Management (or manglement as I called them) was already used to RDP and they refused to budge despite my best efforts.
The people who signed my check always prevailed. I did retain the rejection of my proposal to use VPN. Never had to use it.
Re: (Score:2)
... and what I did was change the port from 3389 to the last four digits of our telephone number.
I monitored the logs on the firewall and RDP was the number-one hit. I could see the name and password they tried.
Mostly it was admin, administrator, and then random usernames and the passwords were blank or the same as the username.
Attacks did decrease a lot and I think it was because port scanners found nothing at 3389.
Whitelisting an IP was not an option. My people traveled all over. I used CNAME at the domain level to craft subdomains with the user's names spelled backwards.
We did that for awhile too, but eventually we were found and targeted. VPN turned out to be the correct solution.
Re: (Score:3)
Changing ports isn't a good option.
Your internal network access should be extremely limited on the internet.
Setup a VPN Solution, have users who need access have to log into the VPN (For extra points setup the VPN to have 2 factor authentication)
Setup SSH Port forwarding, similar concept as a VPN but focuses on only one port.
You cannot trust a humans ability to monitor port traffic, as most of these attacks are automatic. Find an IP Address with ports open, send crap over it, and see what happens.
Re: (Score:2)
That works great in theory, but I didn't own the place and the owners did not want that. I retired from there after 28 years and never got hit.
What my replacements do is their concern.
150 per week? (Score:2)
Just my 2 cents
Re: (Score:3)
Disable password login.
Ensure that you just drop all packets to and from anything listed on the DROP and EDROP lists and from the martian lists.
You can get lists of "bad actors" that are engaged in active attacks. Automate adding them to your drop list as well.
Rate limit connection attempts and if they are persistent enough add them to your drop list.
If they get on your drop list for one service and they try a different service, add them to the global drop list.
If they to connect to ports that are not open
Re: (Score:2)
My view is enforce decent passwords. I dislike keys because they get stolen as people move them about on USB thumb drives etc. Then rate limit the connections and use fail2ban to blacklist IP addresses for a time. They move on pretty quickly.
Security Stratergies (Score:2)
I just set up a new VPS... Pounded. (Score:3)
I recently set up a new Debian VPS... never had RDP installed, or SAMBA, or any kind of Windows/Microsoft-related service. Yet I'm still getting pounded by Chinese, Indian, and Russian IPs.
I started logging each time an nftables firewall rule drops an incoming packet - and they are coming in every second. Sometimes 2 or 3 drops per second. The log filled up to several MB very quickly, in less than an hour I think. Here is a sanitized excerpt of a couple of entries:
trace id 20136c0d ip gFwall4 gInc packet: iif "eth0" ether saddr xx:xx:xx:xx:xx:xx ether daddr xx:xx:xx:xx:xx:xx ip saddr 79.133.115.177 ip daddr x.x.x.x ip dscp cs0 ip ecn not-ect ip ttl 117 ip id 9809 ip length 52 tcp sport 63424 tcp dport 3389 tcp flags == syn tcp window 8192
trace id 80e9a5cc ip gFwall4 gInc packet: iif "eth0" ether saddr xx:xx:xx:xx:xx:xx ether daddr xx:xx:xx:xx:xx:xx ip saddr 180.157.204.224 ip daddr x.x.x.x ip dscp cs0 ip ecn not-ect ip ttl 117 ip id 8018 ip length 52 tcp sport 60411 tcp dport microsoft-ds tcp flags == syn tcp window 8192
"dport microsoft-ds" and "dport 3389" indicate RDP and MS Remote Assistance ports, for those not familiar with nftables traces. Services I have never ran. This VPS has been online for about a week now and they haven't slowed down. They are also hitting other ports regularly, but around half of them seem to be RDP-related.
Does anyone have any advice here? Did I get unlucky and got provisioned an IP that formerly had a Windows host on it?
Re: (Score:3)
Are you dropping the packets or responding with "NO ROUTE TO PORT" or "ADMINISTRATIVELY PROHIBITED". If you just drop the packet without telling them WHY then you can expect them to just keep probing. The other alternative for TCP connections is to send them to a tarpit. Eventually the remote host will just crash when it has consumed all its resources.
Re: (Score:2)
They are being dropped with the "drop" command in nftables. I believe that is a silent drop. These are the last entries for both the traces:
trace id 20136c0d ip gFwall4 gInc rule iifname "eth0" nftrace set 1 drop (verdict drop)
trace id 80e9a5cc ip gFwall4 gInc rule iifname "eth0" nftrace set 1 drop (verdict drop)
I had been told it's better to silently drop the packets, so the bots won't even detect there is a host at that IP. But maybe that ship has already sailed with my address. Would the "no route"
Re: (Score:2)
I had been told it's better to silently drop the packets, so the bots won't even detect there is a host at that IP.
I thought that too, but if the host responds to _anything_ including ping / ICMP / BGP / etc., they'll know you're there.
Re: (Score:2)
If you reject the packet with a response, the connecting machine will give up.
If you drop the packet, the connecting machine will send several more packets on the assumption that the packet has been lost somewhere in transit. What you do want to do is throttle responses to avoid backscatter.
An amplification attack isn't practical with just SYN packets, as the replies wouldn't be any bigger than the initial requests. The only thing it would do is reflect the attack off relay hosts so you could mask the poten
Re: (Score:1)
Re: (Score:2)
Any packets that come in to ports I don't use are already getting dropped. Debian 10 uses nftables instead of iptables but I think the "drop" command works the same, silently drops the packet. These are the last entries on both of my example traces:
....
trace id 20136c0d ip gFwall4 gInc rule iifname "eth0" nftrace set 1 drop (verdict drop)
trace id 80e9a5cc ip gFwall4 gInc rule iifname "eth0" nftrace set 1 drop (verdict drop)
I've actually tried setting up fail2ban but it doesn't seem to work well with nftab
Re: (Score:2)
The ipv4 internet is polluted with this crap, malware will just scan sequential or random addresses until it finds vulnerable hosts. If you have a direct ipv4 connection to the internet, you will see scan attempts constantly and theres nothing you can do about it.
This is much less of a problem with ipv6, where the address blocks are large enough to render scanning like this completely impractical. Attackers would have to discover your address via other means.
Pah! (Score:1)
Doing it wrong... (Score:2)
If you expose RDP (or any other of the default microsoft protocols) to the internet you're doing it wrong... They are simply not designed to be used like this.
Also, using IP whitelists is becoming less and less practical with the prevalence of nat.
Nothing built in Windows, but you can add it (Score:2)