I have a small PC I use for exposing a private PC to the wider web via nginx proxy. It had two accounts on it: mine, and one I called “remote” with some basic password I set up to forward the proxy connection.
One day, this machine started making 100% CPU noises, for several hours. Wtf? I check the processes and a Tor node had been setup and was transmitting gigabytes to some Russian IP.
My brain goes into panic mode, I kill the process, wipe the remote user, and eventually pull the Ethernet plug.
I wish I hadn’t wiped the user directory as I wanted to know what was being sent and where. Nonetheless the logs showed that several Russian IPs had been attempting an SSH brute force for literally months and one finally guessed “remote” and weak password I set for it.
I have decades of experience on Unix system, and I cringe having made such a rookie mistake.
Lesson learned: change the default SSH port to a transient port, have one dedicated SSH user with a non-standard username, and use auth-key entry only.
I still wonder what was being sent over that Tor node, and why it required all the CPU cores. My best guess is crypto mining, or it was used for a DDOS attack net somewhere.
I see this claim all the time, and it bugs me every time. Obfuscation is a perfectly reasonable part of a defense in depth solution. That’s why you configure your error messages on production systems to give very generic error messages instead of the dev-centric messages with stack traces on lower environments, for example.
The problem comes when obscurity is your only defense. It’s not a full remediation on its own, but it has a part in defense in depth.
It buys you enough time to check the journals and see that a group of IPs have attempted various ports giving you enough time to block the IP altogether.
It also buys you disinterest from the malicious host, since probably there’s a hard limit on how many ports they will test, and they will flag your machine as “too much work” and try another.
Again, I agree with you that obfuscation is not security, but it sure does help.
From what I understand you obfuscate the port in order to limit the amount of incoming attacks. But then fail2ban would be a much more effective tool.
The disinterested aspect you described is the actual problem. Because it’s based on the assumption your port won’t be found, but it definitely will, and as soon as that happens you’ll end up in a database such as shodan and the entire effect is GONE.
Kind of - I obfuscate the port because it won’t show up on the list of well known TCP and UDP ports[0], but be in ephemeral region. To attack this port they would have to guess the number or do a full wide port scan of the system which will waste a large amount of their time. Though granted, they need probably less than a week.
I’ve honestly never understood the defaults of fail2ban, which seemed to do nothing on every system I’ve tried it on. I get much better results by parsing the journalctl logs, and grouping the ips and then passing them directly into iptables or UFW.
I kind of agree, but I also kind of disagree because if you are using the default port and default password, you’d be much more likely to be hacked with the default port rather than a non-standard port. Of course, you’d be even more secure with a non-default password (or key auth only). Plus, information leaking can definitely be used against you, so obscurity can actually help make things secure. You want to make yourself a less simple target than your neighbour in any way that you can.
I think they were either computing crypto-hashes and passing on the results back home (via Tor), or they were using my machine to send out several ping/fetch requests over Tor to DDOS some unknown target machine.
I want to say “yes” but you should still try to change the default ports for any process open to the web. Just because they can’t guess your ssh, doesn’t mean they can’t upload a root php script to your webserver which allows file uploads.
Just be as invisible as possible. Run nmap on your localhost with the defaults and see if anything is set to open. If so, change that port.
I have a small PC I use for exposing a private PC to the wider web via nginx proxy. It had two accounts on it: mine, and one I called “remote” with some basic password I set up to forward the proxy connection.
One day, this machine started making 100% CPU noises, for several hours. Wtf? I check the processes and a Tor node had been setup and was transmitting gigabytes to some Russian IP.
My brain goes into panic mode, I kill the process, wipe the remote user, and eventually pull the Ethernet plug.
I wish I hadn’t wiped the user directory as I wanted to know what was being sent and where. Nonetheless the logs showed that several Russian IPs had been attempting an SSH brute force for literally months and one finally guessed “remote” and weak password I set for it.
I have decades of experience on Unix system, and I cringe having made such a rookie mistake.
Lesson learned: change the default SSH port to a transient port, have one dedicated SSH user with a non-standard username, and use auth-key entry only.
I still wonder what was being sent over that Tor node, and why it required all the CPU cores. My best guess is crypto mining, or it was used for a DDOS attack net somewhere.
Obfuscation is not security, changing the port doesn’t increase your security
I see this claim all the time, and it bugs me every time. Obfuscation is a perfectly reasonable part of a defense in depth solution. That’s why you configure your error messages on production systems to give very generic error messages instead of the dev-centric messages with stack traces on lower environments, for example.
The problem comes when obscurity is your only defense. It’s not a full remediation on its own, but it has a part in defense in depth.
Changing the port isn’t really much obfuscation though. It doesn’t take long to scan all ports for the entire IPv4 range (see masscan)
It helps against stupid automated attacks though.
If someone has changed the port it’s likely that they have set up a great password or disabled password auth all together.
It’s worth it for just having cleaner logs and fewer attempts.
Those logs are useful to know which IPs to permanently block :)
Technically a password is obfuscation anyway
I hear you, but I disagree:
It buys you enough time to check the journals and see that a group of IPs have attempted various ports giving you enough time to block the IP altogether.
It also buys you disinterest from the malicious host, since probably there’s a hard limit on how many ports they will test, and they will flag your machine as “too much work” and try another.
Again, I agree with you that obfuscation is not security, but it sure does help.
From what I understand you obfuscate the port in order to limit the amount of incoming attacks. But then fail2ban would be a much more effective tool.
The disinterested aspect you described is the actual problem. Because it’s based on the assumption your port won’t be found, but it definitely will, and as soon as that happens you’ll end up in a database such as shodan and the entire effect is GONE.
Kind of - I obfuscate the port because it won’t show up on the list of well known TCP and UDP ports[0], but be in ephemeral region. To attack this port they would have to guess the number or do a full wide port scan of the system which will waste a large amount of their time. Though granted, they need probably less than a week.
I’ve honestly never understood the defaults of fail2ban, which seemed to do nothing on every system I’ve tried it on. I get much better results by parsing the journalctl logs, and grouping the ips and then passing them directly into iptables or UFW.
You’re probably right. What is shodan?
0: https://en.wikipedia.org/wiki/List_of_TCP_and_UDP_port_numbers
I kind of agree, but I also kind of disagree because if you are using the default port and default password, you’d be much more likely to be hacked with the default port rather than a non-standard port. Of course, you’d be even more secure with a non-default password (or key auth only). Plus, information leaking can definitely be used against you, so obscurity can actually help make things secure. You want to make yourself a less simple target than your neighbour in any way that you can.
It also cuts down on log spam which is nice.
I figure you’d know about it by now, but fail2ban would really help.
What do you think they were transmitting?
I think they were either computing crypto-hashes and passing on the results back home (via Tor), or they were using my machine to send out several ping/fetch requests over Tor to DDOS some unknown target machine.
So can this pretty much always be shut down by having sufficiently complex + long pw?
I want to say “yes” but you should still try to change the default ports for any process open to the web. Just because they can’t guess your ssh, doesn’t mean they can’t upload a root php script to your webserver which allows file uploads.
Just be as invisible as possible. Run
nmapon your localhost with the defaults and see if anything is set to open. If so, change that port.What about Stealth mode
What is stealth mode?
On Mac its part of security/firewall settings or sumfing
Ah okay. I have no clue about macs. I guess the equivalent in Linux would be OpenSnitch