| |||||||||||||
Linux botnetsLinux botnetsPosted Feb 15, 2007 2:47 UTC (Thu) by zlynx (subscriber, #2285)Parent article: Linux botnets
SELinux can help here. PHP applications should not be making outgoing network requests.
If SELinux is too difficult, iptables can filter away outgoing traffic as well. Not enough people put outgoing blocks on their firewalls.
A server farm / rack provider might also run IDS like Snort. See if you can get them to copy you on IDS alerts related to your IPs.
And for crying out loud, don't use your login password for your application's SQL account, helpfully listed in a plain text PHP include.
(Log in to post comments)
Linux botnets Posted Feb 15, 2007 9:34 UTC (Thu) by dd9jn (subscriber, #4459) [Link] Don't even use a password at all to login in to a server. sshd_config should have an entry "PermitRootLogin without-password" and user accounts should all have a disabled password. Use ~/.ssh/authorized_keys. If you have a need to login from more than one client machine, use a smart card to access the server. I know that this is a trivial suggestion but when I occasionally see people login to their servers, most are entering a password.
ssh public keys Posted Feb 15, 2007 11:05 UTC (Thu) by dion (subscriber, #2764) [Link] I think the reason that some (a lot of) people use passwords with ssh is that they see ssh as "telnet, only secure".
They haven't looked at authorized_keys or they think that distributing their keys is too much trouble.
I've recently moved from doing copy+paste of id_dsa.pub when needing access to using a handy little shell script (don't run it on your machine, unless you want me to access it): http://dion.swamp.dk/ssh.sh
Before doing that I some added only one of my desktop machines or maybe I didn't bother with the key setup at all and just used password login, because I rarely needed access to that particular system.
With this solution all I need to get access to a new box is to tell the administrator (well, myself most times) to run that script and I'll never need to log in with a password.
Putting your public key on your website really ought to be in every "root account for dummies"-type book.
ssh public keys Posted Mar 1, 2007 22:14 UTC (Thu) by muwlgr (guest, #35359) [Link] Not everyone knows about ssh-copy-id utility.May be that's what you need. This operation is very popular, so openssh developers have written the tool for us all...
Linux botnets Posted Feb 15, 2007 12:43 UTC (Thu) by minichaz (guest, #630) [Link] I agree with using keys (ideally with passphrases too) but there's no need to allow root logins through SSH, particularly on internet facing servers. Set "PermitRootLogin no" and use "AllowGroups" or "AllowUsers" to prevent attacks against other accounts which should never connect over SSH.
Charlie
Linux botnets Posted Feb 15, 2007 13:03 UTC (Thu) by dd9jn (subscriber, #4459) [Link] So and how do you get root access? Using su requires a password again and sudo without password will do nothing else but alias that user account to root. There is an old crypto rule which states: Put all your secret into one basket and watch that basket very well.
Public key authentication is far better than any password scheme. If you worry about a private key compromise, use a smart card.
Linux botnets Posted Feb 15, 2007 15:20 UTC (Thu) by rfunk (subscriber, #4054) [Link] Use sudo, with user's password. Make the basket of users who have access to sudo bevery small, and watch it closely. Being able to get direct access to a root shell from the internet is just crazy.
Linux botnets Posted Feb 15, 2007 20:22 UTC (Thu) by tetromino (subscriber, #33846) [Link] How is sudo any more secure than root ssh logins with a password? In either case, if you can guess ONE password, you get remote root...
remote root Posted Feb 15, 2007 21:21 UTC (Thu) by rfunk (subscriber, #4054) [Link] This is an old debate. But you'll be hard-pressed to find an experienced professionalsysadmin who will allow remote root logins. Allowing direct root access means that root access is not revokable per-admin; if the password is somehow compromised (e.g. an admin is fired or is careless with the password) you have to change the root password and communicate that to all admins (with the associated insecurity of that communication). If admins are getting root from their own accounts, then it's sufficient to disable or re-password a single admin's account without affecting other admins. So in the sudo case, if that one password is guessed, it's easier to recover than in the single remote-root case. Just running a root shell is dangerous. It's much better to be root only for what needs to be done as root, to avoid accidents or possibly tripping over sabotage (e.g. someone having gotten in and messing with your ls command). This slashdot comment is one place that covers the issue well: http://it.slashdot.org/comments.pl?sid=180864&cid=149...
remote root Posted Feb 16, 2007 0:25 UTC (Fri) by dd9jn (subscriber, #4459) [Link] "Allowing direct root access means that root access is not revokableper-admin; if the password is somehow compromised"
FWIW, I was talking about public key authentication for root access. This also means that revoking access is as simple as deleting one line from authorized_keys.
Where do you see the problem? I agree that logging of access is not as it should be but it is still available and come one, having root access does on most systems mean you have all the power to manipulate the logs. So why care.
remote root Posted Feb 19, 2007 15:54 UTC (Mon) by hein.zelle (guest, #33324) [Link] > Where do you see the problem? I agree that logging of access is not as it> should be but it is still available and come one, having root access does > on most systems mean you have all the power to manipulate the logs. So > why care.
One reason I care is that it's easy to accidently turn password authentication back on. On many debian systems I've seen, the option UsePAM (on by default) effectively allows password authentication, even when PasswordAuthentication is off. This is not the case on the latest ubuntu, but dangerous nevertheless. I'd rather have an ssh login as a regular user, and then become root using su.
What is the reasoning behind not using su to become root? I understand the password will go over the line, but it's encrypted. Is this advised against for fear of keyloggers or so?
Linux botnets Posted Feb 16, 2007 2:27 UTC (Fri) by smoogen (subscriber, #97) [Link] Ok the security gained by using two layers is via tracking down who logged in... which becomes very important in large teams. If you are administrating a couple hundred linux servers you may have a team of 5-12 people who need root access. Knowing who executed a root level command and when is important and more secure in that if you lock down sudo you can see what they ran versus having a black hole that root logged in at 02:00 and logged out at 02:30 and you have no idea what they ran.
In the case of small teams.. you may not feel that you need this, but it comes in handy if the business grows... you find yourself with 12-20 people with the root password.
Linux botnets Posted Feb 15, 2007 14:56 UTC (Thu) by tialaramex (subscriber, #21167) [Link] I don't see any reason to permit remote root login on Internet-facing servers (or desktop machines for that matter). A genuine administrator should have a user account, unique to them as a person, which can be audited.
The first attack scenario I'm considering is an outsider who is able to connect to the SSH server and perhaps has some limited (unprivileged) access to the target machine (e.g forum user access on a web server), plus they can snoop some of your traffic. This scenario would be typical for a black hat setting up a zombie network, who already has subverted some nearby machines in the network but not yours.
With root SSH logins, they can target the root account (yes, it could be renamed in theory, but unlike the Windows "Administrator" account that's not a routine precaution) and the only thing keeping you safe is that SSH server's authentication. Any flaws in that single line of defense whether security mistakes (you left your laptop unattended and they stole the private key file?) or system problems (OpenSSH is revealed to allow in 1-in-4 billion connections without authenticating) are a total loss.
In my alternative, they must actively target administrative users, without knowing in advance what names are used. Even if they get SSH access as a user, they still need to escalate to root, which is another layer of security, albeit one that we know is much weaker. On the other hand if they obtain (for example by social engineering) a root password or sudo root password equivalent, they still need remote access to use it. So in either case you've got two layer security.
I use and recommend private user logins, via ssh public keys PLUS an audited authentication step for escalating to root privileges. Also people should pay attention to the security of their SSH private keys. On every machine where you keep such a key, consider how a black hat might get access to the key and what they can access with it once they have it. If you use a passphrase (which you should) how are you sure the entry method is itself secure (IIRC trojans asking for the SSH passphrase have been seen in the wild) ?
Linux botnets Posted Feb 15, 2007 12:09 UTC (Thu) by NAR (subscriber, #1313) [Link] PHP applications should not be making outgoing network requests.Then how should a PHP-based forum software send a "registration succeeded" e-mail to the user? Could connect to the local SMTP server, but spam could be sent out this way too.
PHP sending mail Posted Feb 15, 2007 15:17 UTC (Thu) by rfunk (subscriber, #4054) [Link] The local SMTP server can do its own checking to detect and block outgoing spam.It can also queue the real messages when the recipient's mail server is temporarily unavailable; sending directly from PHP can't do that.
Linux botnets Posted Feb 16, 2007 2:34 UTC (Fri) by smoogen (subscriber, #97) [Link] The standard way I have seen it done is that the application uses 'local' delivery and that is checked for 'correctness' at the machine and at the border SMTP router. This stops the majority of spambots in a large environment.
Linux botnets Posted Feb 16, 2007 2:32 UTC (Fri) by smoogen (subscriber, #97) [Link] I will say that Selinux has saved a customers bacon before.. the person had a bad PHP app installed and it got abused. The attacker was not able to execute anything however because the Selinux policy wouldnt let the attacks do anything from network connections to data viewing.
[While I do not use it.. I am betting that grsecurity might be able to do the same thing.]
|
|||||||||||||