Having a bit of trouble with a Ubuntu 9.04 system - the hard disk is getting full, all the time. df and du are listing true (I believe) sizes of files, whereas the GUI application Disk Usage Analyzer is telling me that the usage is 18Gb out of 35Gb. Using lsof, poking around a bit, I found this: Code: wayne@workpc:~$ lsof +L1 COMMAND PID USER FD TYPE DEVICE SIZE NLINK NODE NAME python 3378 wayne 9r REG 8,1 1460 0 314799 /etc/passwd (deleted) According to a website I read, any open file with a link count of less than one is supposedly someone trying to hide something. The fact that they're trying to hide something to do with /etc/passwd using python is pretty alarming to me. Has something happened to this system? When setting up ssh logins so I could remotely administer it (its my dads work PC), I stupidly left ssh open to the internet on port 22 with the password the same as the username - I quickly fixed my error 20 minutes later when I was home again, but obviously this 20 minute window was large enough. I've instructed him to disconnect the network cable until I can see to it properly. Any comments, scaldings, insults or help appreciated.
(1) Its takes less than a minute to compromise a mis-configured system. (2) The data on the compromised system is no longer trustworthy. (3) With great power, comes great responsibility. => Know the tools you're using. (4) Consider it a learning lesson: What have I learned from this experience?...And correct your mistake. There's nothing more to say. You know what you did wrong. Learn from it.
If you're going to open 22 to the world, maybe consider key-only access... and use something like "fail2ban". I use it and it tails the SSH log and automatically adds an IP address to IP tables if they fail a certain amount of times in a given interval. Definitely unplug it, and don't replug it until it's been formatted... You have to remember with Ubuntu+sudo, that the user password IS the only thing protecting root access, and so avoids a few normally good security tips(no root SSH logins, separate passwords for privileged/non-privileged users etc...). Unfortunately, generally good security models(a la Unix) don't protect against weak passwords for privileged users on exposed ports!
Leaving SSH open isn't the problem, you know the problem... Next time try port knocking. http://www.portknocking.org/view/details
Sigh. No more going easy on my dad and passwords. Thanks for the input, guys - I've always been rather security conscious (not running ssh on default ports etc) but I was lazy setting up this system and I guess I paid the price. Will tighten my security, and my approach to security, from now on...
Running SSH on a non-default port is not security, it's obscurity and it's far from a security measure. At the very least you could have disallowed the user sudo rights (or not use it in the first place).
Using non-standard ports isn't something I personally bother with. Sure I get heaps of attempts at getting in but they're not getting anywhere. Btw security IS obscurity. Unknown address, unknown port, unknown username, unknown password. Every extra unknown you add - even if that means increasing the length of the password - is increasing security. It's all about knowing something that others do not. Of course an unknown port on its own is simply far too insufficient as a security measure, but it plays its part.
I move my services to non-standard ports, mostly to reduce the amount of noise with failed login attempts. I create an SSH group, and only users who are in that group may login via SSH. I'm not using keys, but my password is 16 characters and it's alphanumeric. At work, we need to be connected to the VPN (via OpenVPN) with our certificates and pre-shared key before we can shell in to a box.
Yeah you need to be careful. Public key encryption FTW. Code: May 5 02:41:44 PCName sshd[32579]: Invalid user test from 117.21.249.75 May 5 02:41:51 PCName sshd[32583]: Invalid user guest from 117.21.249.75 May 5 02:41:59 PCName sshd[32587]: Invalid user admin from 117.21.249.75 May 5 02:42:06 PCName sshd[32591]: Invalid user admin from 117.21.249.75 May 5 02:42:14 PCName sshd[32595]: Invalid user user from 117.21.249.75 May 5 02:42:21 PCName sshd[32599]: User root not allowed because account is locked May 5 02:42:29 PCName sshd[32603]: User root not allowed because account is locked May 5 02:42:36 PCName sshd[32607]: User root not allowed because account is locked May 5 02:42:44 PCName sshd[32611]: Invalid user test from 117.21.249.75
I run SSH on a non-standard port only to bypass the uni filter. Port 443 is unfiltered, everything else is proxy'ed. To the OP, remember that the system has been hacked. It is no longer trustworthy, you never know where a backdoor may be lying. The only solution is a reinstall, keeping only data if required. And by data I mean true data, check everything that is pulled.
I have inspected this system; the lack of HDD space was caused by a genuine application, namely Simple Backup. I had installed it but didn't have it configured correctly, so it was backing up everything to /var/backup and filling the small 40Gb drive very quickly. What of the strange result from lsof? Well, I'm not sure. I installed and ran chkrootkit (downloaded .deb manually and installed) and it did not detect anything. Reconnected the system to the internet and waited for a while, checking the output of lsof periodically, and observed no strange behaviour. Watched system resources using htop, noticed no strange processes or unexplained CPU usage spikes, monitored the ethernet bandwidth and noticed no extraneous data ... I can't be 100% sure, but I may have jumped the gun and made assumptions. In any case, the important data is backed up, and I will be closely monitoring the system.
Unless the username was VERY obvious (i.e. root, mysql, apache, john, michael) that you'd left the password the same as the username and allowed ssh access for, I'd be surprised if it was compromised in 20 minutes.
I left a ubuntu box with remote desktop with no password enabled to the internet. Returned the next day and there was a notepad file open saying "you got pwned" and thats all
I can't believe there are people trawling the 'net for THAT Hah He probably installed a rootkit or something though.
No it's not and it's far from an arguable topic. There's security through obscurity but changing the default port of 22 is far from any resemblance to the above. Recompiling the port signature of OpenSSH is a good example, and obviously something most people don't do. I've yet to work with a single SOx/PCI and ISO compliance that required the default port of critical non web services changed.
By pure definition, yes it is. The cut of the key to your front door, the code + rolling-code algorithm used in your cars remote, the username+password used to login to your gmail account. That's the point I was getting at. Each additional unknown adds an extra level of security, even if only minor, and very rarely reduces security. Using an unconventional port for ssh is certainly not the sole solution to security, but there is nothing wrong with doing it either.
I'm not arguing, I'm just helping others in OCAU learn and understand. If you want to continue to hold that incorrect stance, feel free. Your analogies are flawed because the unknown is infinite. Changing the port of SSH for example, only allows for 2^16 different variables and takes only an extra few seconds to determine. A correct analogy would be to change the height of your door lock on your front door.
Security is having port 22 open to the world, but requiring a key which all of China's botnets would take 100 years to crack. Obscurity is putting it on port 65000. A weak authentication scheme on port 65000 is no better than a weak authentication scheme on port 22... and if you have a sufficiently strong authentication scheme, and intruder detection, you can equally securely run it on the proper port, instead of fiddling with alternate ports.
