Re: Attempt to breakin
From: YouCanToo (dwmoar_at_findmoore.net)
Date: Sun, 10 Jul 2005 02:18:56 -0700
Alexander Clouter wrote:
> On 2005-07-08, Todd Knarr <email@example.com> wrote:
>>I've seen a lot of these on my systems. It looks like someone trying
>>a really dumb brute-force attack. You can do a few things to protect
> Although dumb its effective. Working on an ISP helldesk we recently blocked
> one of our users for scanning 200,000 hosts in port 22; in all probability he
> had a weak username/password combination and someone ran a trojan on his
> machine. We use snort to detect these things and pick up the results in the
> morning for human decision making.
> The amusing part about it is that the user knew they were blocked (we
> high-jack the web browser to redirect them to a 'disabled' page explaining
> whats happened) and so called asking if we could permit port 22 to be opened
> to his machine so that he could remotely clean the machine. We explained we
> could not do this as he was obviously infected with something trojan than
> makes good use of port 22 and did it to scan/infect 200,000 machines. The
> reply was golden, "whats port 22 used for"....WTF, *you* asked *us*...to but?
> Needless to say I think we confirmed to ourselves the user believes in secure
> passwords such as 'password' for the root account :)
>>1) Make sure your sshd is up to the most recent version with all the
>> latest security fixes.
> good advice, this was another thought of ours, an SSH daemon thats more than
> a year or two old has a couple of very easy to remotely "get root" exploits.
>>2) Lock out direct root logins, require people to come in as a normal
>> user and then su to root.
> in /etc/ssh/sshd_config you should have a line that says 'PermitRootLogin
> no'. Its well worth also having a 'wheel' account so that only a handful of
> people that belong to the 'wheel' group can 'su' to root; on a Debian box I
> like to make us of the 'staff'/'users' groups to double up as a 'wheel' flag;
> anyone whos primary group is 'staff' can 'su'.
>>3) Lock out password access and require everyone to come in using a
>> public key. Nobody can guess passwords if sshd won't accept passwords
>> for login.
> Extremely good advice however not logistically practical for everyone. If
> only a few people administer the box then obviously this should be the
> rule however if its a box that used by "computer students" who seem to
> spend more time playing Counterstrike rather than programming their projects
> they seem to not be bearly able to comprend passwords :)
>>4) Identify the IP addresses or netblocks the attacks are coming from and,
>> if you don't need access from those same blocks yourself, firewall them
>> off or add deny entries in hosts.allow to block access to sshd from
>> those addresses/netblocks.
> Depends strongly on your needs. If you are expected to maintain the box
> whilst you are on holiday with a mobile phone in India for example, this is
> not practical; if however the box should only be available to the
> office/company/country then block it; please make sure the firewall rule
> is a REJECT :)
Thanks for everybodys suggestions and help