I have had several people talk to me over the last few days about having their machine compromised. The infection vector appears to be weak ssh passwords. The compromise appears to based on people scanning for open ssh ports then brute forcing passwords before installing a Trojan that connects to IRC and accept commands from a channel (such as .ddos <ip>). Please, make sure you're using a secure password. If passwd warns you that a password is insecure, CHANGE IT. http://www.wlug.org.nz/ChoosingPasswords provides a couple of methods on how to choose a good password. Make sure everything is up to date on your system: for debian: apt-get update apt-get dist-upgrade -u for fedora core click on the blinking red (!) in the corner to get it to do the updates. If you don't use ssh (or don't know what it is) DISABLE IT, or just uninstall it. If you do use ssh, consider using tcpwrappers to lock it to something like "*.nz". See http://www.wlug.org.nz/AdvancedSecurityNotes. To check if you've been compromised, try "locate emech". If it shows up any files (particularly in /tmp or /var/tmp) then you have been compromised. Bugger. If you have, and need help, email me off list and we'll talk about what you can do.
Also if you use ssh and you have a between your machines and the net, and you should, make sure the SSH ports are closed, so that ssh will only work on your network, of you need to access your machine over the Internet, then install a vpn. Sorry perry, but you missed this one ;-) But yep, thats nasty.
If you don't use ssh (or don't know what it is) DISABLE IT, or just uninstall it.
If you do use ssh, consider using tcpwrappers to lock it to something like "*.nz". See http://www.wlug.org.nz/AdvancedSecurityNotes.
On Fri, Oct 22, 2004 at 09:25:43AM +1300, Perry Lorier wrote:
I have had several people talk to me over the last few days about having their machine compromised. The infection vector appears to be weak ssh passwords. The compromise appears to based on people scanning for open ssh ports then brute forcing passwords before installing a Trojan that connects to IRC and accept commands from a channel (such as .ddos <ip>).
You'd be better off not allowing passwords at all. In /etc/ssh/sshd_config set: PermitRootLogin no ChallengeResponseAuthentication no PasswordAuthentication no If your using ssh you should use ssh keys, then only a user with their key and their key password can get in. Wrappers and iptables it up a storm aswell. Cheers, James.
Please, make sure you're using a secure password. If passwd warns you that a password is insecure, CHANGE IT. http://www.wlug.org.nz/ChoosingPasswords provides a couple of methods on how to choose a good password.
Make sure everything is up to date on your system: for debian: apt-get update apt-get dist-upgrade -u for fedora core click on the blinking red (!) in the corner to get it to do the updates.
If you don't use ssh (or don't know what it is) DISABLE IT, or just uninstall it.
If you do use ssh, consider using tcpwrappers to lock it to something like "*.nz". See http://www.wlug.org.nz/AdvancedSecurityNotes.
To check if you've been compromised, try "locate emech". If it shows up any files (particularly in /tmp or /var/tmp) then you have been compromised. Bugger. If you have, and need help, email me off list and we'll talk about what you can do.
_______________________________________________ wlug mailing list | wlug(a)list.waikato.ac.nz Unsubscribe: http://list.waikato.ac.nz/mailman/listinfo/wlug
On Fri, Oct 22, 2004 at 09:25:43AM +1300, Perry Lorier wrote:
I have had several people talk to me over the last few days about having their machine compromised. The infection vector appears to be weak ssh passwords. The compromise appears to based on people scanning for open ssh ports then brute forcing passwords before installing a Trojan that connects to IRC and accept commands from a channel (such as .ddos <ip>).
For a few weeks (or more), some of us have noticed lots of connection attempts on port 22 (the ssh) port from IP addresses all around, suggesting it is an automated worm rather than `just' script kiddies. If you have a machine running sshd on a publicly reachable interface, you might want to limit access to it. You can either investigate using tcpwrappers, as Perry suggested, or use the standard iptables firewalling... for people who aren't familiar with it, here is part of my iptables setup: # set up a new chain for ssh traffic iptables -N ssh_syn # filter the start of incoming ssh connections (includes forwarded!) iptables -A INPUT -p tcp --syn --dport 22 -j ssh_syn # only allow IP addresses that I'm likely to be using to connect iptables -A ssh_syn -s 10.0.0.0/8 -j ACCEPT iptables -A ssh_syn -s 192.168.0.0/16 -j ACCEPT # university of waikato iptables -A ssh_syn -s 130.217.0.0/16 -j ACCEPT # iconz adsl dynamic range iptables -A ssh_syn -s 210.48.0.0/17 -j ACCEPT iptables -A ssh_syn -s 210.185.0.0/19 -j ACCEPT # hoiho.wlug.org.nz iptables -A ssh_syn -s 203.97.10.50/32 -j ACCEPT # default is to deny incoming ssh connections iptables -A ssh_syn -j LOG iptables -A ssh_syn -j REJECT No, it's not perfect (especially if/when my isp changes the allocations for dynamic ip), but it stops all traffic from outside those networks. The "-j LOG" means that all the other attempts get logged to syslog - I see 11 attempts in the last few days to connect to my sshd, and 23 attempts in the week before... John
On 22/10/2004, at 9:57 AM, John R. McPherson wrote:
For a few weeks (or more), some of us have noticed lots of connection attempts on port 22 (the ssh) port from IP addresses all around, suggesting it is an automated worm rather than `just' script kiddies.
Yes, you're right. I have just taken a look at our logs on a server with open ssh access and, indeed, there are quite a number of obvious connection attempts at trying to guess passwords on standard accounts (such as root, admin, user, guest, etc.). In our case shutting down access to specific IP ranges is not a viable option, since we cannot know ahead of time what are the valid IP numbers that legitimate connections come from. So that raises a question: Is there a means by which the ssh connections can be monitored and if there are a series of attempts from one originating IP number involving illegal usernames or invalid passwords, to have that IP address dumped into a host reject list. Presumably that would have to be a tempory blacklist since the IP address is likely to be dynamically allocated by some ISP. Thoughts on this? Michael.
* Michael Cree <cree(a)phys.waikato.ac.nz> [2004-10-22 00:47]:
Thoughts on this?
Don't do it. Automated blacklisting is vulnerable to spoofed source addresses -- an attacker could abuse it to lock you or other legitimate users out of your own service. Regards, -- Aristotle "Like punning, programming is a play on words." -- Alan J. Perlis, "Epigrams in Programming"
Michael Cree wrote:
On 22/10/2004, at 9:57 AM, John R. McPherson wrote:
For a few weeks (or more), some of us have noticed lots of connection attempts on port 22 (the ssh) port from IP addresses all around, suggesting it is an automated worm rather than `just' script kiddies.
Yes, you're right. I have just taken a look at our logs on a server with open ssh access and, indeed, there are quite a number of obvious connection attempts at trying to guess passwords on standard accounts (such as root, admin, user, guest, etc.).
In our case shutting down access to specific IP ranges is not a viable option, since we cannot know ahead of time what are the valid IP numbers that legitimate connections come from.
So that raises a question: Is there a means by which the ssh connections can be monitored and if there are a series of attempts from one originating IP number involving illegal usernames or invalid passwords, to have that IP address dumped into a host reject list. Presumably that would have to be a tempory blacklist since the IP address is likely to be dynamically allocated by some ISP.
http://www.wlug.org.nz/pam_tally(8) Kinda looks to do what you want, per user, not per IP tho :)
Perry Lorier wrote:
I have had several people talk to me over the last few days about having their machine compromised. The infection vector appears to be weak ssh passwords. The compromise appears to based on people scanning for open ssh ports then brute forcing passwords before installing a Trojan that connects to IRC and accept commands from a channel (such as .ddos <ip>).
I don't want to be stating something obvious or stupid, but what about running SSH on a high port ? I do that and have VERY little activity. - Drew
I don't want to be stating something obvious or stupid, but what about running SSH on a high port ? I do that and have VERY little activity.
Security through obscurity doesn't work very well[1]. You'll do a lot better in the long term to make sure your SSH passwords are secure, or to only allow key-based auth, or to use TCP wrappers or firewalling to limit who *can* connect. [1] This will prevent the current attacks, but it's only a matter of time before there are worms out there scanning all ports and making note of common services on high ports.
Daniel Lawson wrote:
I don't want to be stating something obvious or stupid, but what about running SSH on a high port ? I do that and have VERY little activity.
Security through obscurity doesn't work very well[1]. You'll do a lot better in the long term to make sure your SSH passwords are secure, or to only allow key-based auth, or to use TCP wrappers or firewalling to limit who *can* connect.
[1] This will prevent the current attacks, but it's only a matter of time before there are worms out there scanning all ports and making note of common services on high ports.
I totally agree with Daniel and also Gavin. From outside, using a VPN is definitely the way to go. VPN is something I would implement on the firewall which would be a separate appliance to the host - As you know a Cisco Router with the IOS IP Plus/FW/3DES image or a NetScreen dedicated FW appliance are what turns me on.
I totally agree with Daniel and also Gavin.
From outside, using a VPN is definitely the way to go.
VPN is something I would implement on the firewall which would be a separate appliance to the host - As you know a Cisco Router with the IOS IP Plus/FW/3DES image or a NetScreen dedicated FW appliance are what turns me on.
To me, the advantage of SSH is I know I can connect into the machines from anywhere in the world. I'm happy to, if necessary, mess with keys to get this level of access, but I'm not happy to say "I can only connect from this netblock and these two other IPs." When you consider the proliferation of SSL VPN technology (such as OpenVPN) these days, why is a VPN any different to SSH itself? They are both SSL encrypted connections. Running telnet over a SSL VPN sounds exactly like using SSH to me. Why add extra complexity? Craig
To me, the advantage of SSH is I know I can connect into the machines from anywhere in the world. I'm happy to, if necessary, mess with keys to get this level of access, but I'm not happy to say "I can only connect from this netblock and these two other IPs."
There is another alternative, which seems fairly quaint at first: port knocking. I wasn't convinced of its usefuless to start with, but it's growing on me. Before you can connect to a host, you have to send a specially crafted "knock" sequence, and the receiving host then opens up a specific, short lived firewall rule for you to access your service. The initial description refers to a sequence of SYN probes, but this could just as easily be a packet to a specific port containing a particular sequence of bytes (aka, a password).
When you consider the proliferation of SSL VPN technology (such as OpenVPN) these days, why is a VPN any different to SSH itself? They are both SSL encrypted connections. Running telnet over a SSL VPN sounds exactly like using SSH to me. Why add extra complexity?
They aren't quite the same thing. If you want to run terminal + database + random app + whatever over the public intenet, you could set up multiple SSH port forwards, or you could set up one VPN. We all know this though.
I think that the reverse is also a good idea, Similar to the idea of port knocking, if the machine detect's a number of failed authentication attempts if could block the source IP from attempting to authenticate for a period of time. Brute force attacks usually require a large number of attempts, unless your password is really insecure... I'm have a feeling that something like this does actually exist but I have no idea what name it goes by. Any ideas anyone? For many month's now I have noticed a lot of failed attempts in my syslogs so I removed password auth as an option which has been suggested, problem is unless you have a USB Flash drive having your Key with you can be problematic.. As the last wlug meeting I went to was more than 3 years ago I'm not up on what topics have been covered in meeting's but perhaps general security would be a good topic... Raymond Daniel Lawson wrote:
To me, the advantage of SSH is I know I can connect into the machines from anywhere in the world. I'm happy to, if necessary, mess with keys to get this level of access, but I'm not happy to say "I can only connect from this netblock and these two other IPs."
There is another alternative, which seems fairly quaint at first: port knocking. I wasn't convinced of its usefuless to start with, but it's growing on me. Before you can connect to a host, you have to send a specially crafted "knock" sequence, and the receiving host then opens up a specific, short lived firewall rule for you to access your service. The initial description refers to a sequence of SYN probes, but this could just as easily be a packet to a specific port containing a particular sequence of bytes (aka, a password).
As the last wlug meeting I went to was more than 3 years ago I'm not up on what topics have been covered in meeting's but perhaps general security would be a good topic...
We covered security from a network point of view - firewalls, DMZs, VPNs, SSL, VLANs, service separation and so on. Covering practical day-to-day security might be a good option
Craig Box wrote:
<> To me, the advantage of SSH is I know I can connect into the machines from anywhere in the world. I'm happy to, if necessary, mess with keys to get this level of access, but I'm not happy to say "I can only connect from this netblock and these two other IPs."
I guess that really comes down how you want to administer your box , and basically what turns you on at the end of the day. I certainly feel more comfortable with the idea of not opening ssh access to the world.
<>When you consider the proliferation of SSL VPN technology (such as OpenVPN) these days, why is a VPN any different to SSH itself? They are both SSL encrypted connections. Running telnet over a SSL VPN sounds exactly like using SSH to me. Why add extra complexity?
Good point... I was thinking more along the lines of IPSec, GRE,... rather than SSL VPNs. Basically running an SSH connection over the VPN connection, I do this quite often. Yeah, it is more complex, but at the end of the day, by doing this, somebody has got to hack into the router/firewall/vpn concentrator, and then hack into the host. That's why I suggested using a dedicated FW Appliance in front of the host.
Daniel Lawson wrote:
I don't want to be stating something obvious or stupid, but what about running SSH on a high port ? I do that and have VERY little activity.
Security through obscurity doesn't work very well[1]. You'll do a lot better in the long term to make sure your SSH passwords are secure, or to only allow key-based auth, or to use TCP wrappers or firewalling to limit who *can* connect.
[1] This will prevent the current attacks, but it's only a matter of time before there are worms out there scanning all ports and making note of common services on high ports.
I have a secure password. An insecure password isn't just an ssh issue that's an issue on all parts whenever you create a login. SSH just happens to be one of the easily attacked protocols via brute force. I say using a high port because this DOES get around 99.9% of current port scans for ssh brute force on port 22. Until these brute force attacks start recognising I am using a higher port then I will consider filtering though I find this is trivial at this current time as I get through to the box via means that use dynamic ip addressing. The only machine I am getting brute forced on is a machine I didn't set up and get forwarded the daily security emails with these in the logs. I haven't been touched on any of my other 8+ servers. They are hitting common names and users like 'test' and 'guest'. Another precaution is not allowing your services users ssh access, mysql, httpd/www, etc (make sure their shell is something like /bin/true) they generally hit common service names as well. My 2 cents. - Drew
* Drew Broadley <drew(a)corrupt.co.nz> [2004-10-21 23:06]:
I don't want to be stating something obvious or stupid, but what about running SSH on a high port ? I do that and have VERY little activity.
That *is* a good immediate response, in the way crush zones are: they don't mean you can get away with no seat belt. It is by no means a substitute for real security, just a good way to stave off a first wave of exploits targetting a vulnerable service, that can buy you time to lock it down. But it's *nothing* *more* *than* *that*. Regards, -- Aristotle @j = ((qw)" Just " )), @a = ((qw " another" )), @p = ((qw " Perl " )), @h = ((qw " hacker " )), (()),),(s""@j,",s (" )))g), print
A. Pagaltzis wrote:
* Drew Broadley <drew(a)corrupt.co.nz> [2004-10-21 23:06]:
I don't want to be stating something obvious or stupid, but what about running SSH on a high port ? I do that and have VERY little activity.
That *is* a good immediate response, in the way crush zones are: they don't mean you can get away with no seat belt. It is by no means a substitute for real security, just a good way to stave off a first wave of exploits targetting a vulnerable service, that can buy you time to lock it down.
But it's *nothing* *more* *than* *that*.
Regards,
Disclaimer: I am in no way advising to use a higher port INSTEAD of firewall rulesets and filtering. - Drew
participants (11)
-
A. Pagaltzis -
Craig Box -
Daniel Lawson -
Drew Broadley -
Gavin Denby -
James Clark -
John R. McPherson -
Lindsay Druett -
Michael Cree -
Perry Lorier -
Raymond Burgess