On Sat, 29 Jan 2005 14:48:44 -0500, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > On Sat, Jan 29, 2005 at 03:05:35PM +0000, michael wrote: > > On debian-user it was suggested I also post this here, thanks, Michael > > -------- Forwarded Message -------- > > From: michael <[EMAIL PROTECTED]> [snip] > > I notice that frequently many machines around here get attacked by a > > potential hacker (a prog I guess) trying lots of usernames to get in to > > all the machines, using the same set of usernames at the same time. Have > > people seen this on their machines? I'm guessing it's a virus/worm on a > > Windows box doing this but does anybody know more? > > > > I've followed & done most of the suggestions listed in chpts 4 & 5 of > > "Securing Debian" HowTo/Manual although I will admit to not following > > and therefore not having got around to firewalling. Other suggestions > > most welcome. > > [snip] > 1. Enable SSH Protocol version 2 ONLY. SSH Protocol version 1 has some > security flaws with known exploits. This can be done commenting out > (or removing) > Protocol 2,1 > and replacing it with > Protocol 2 > > The downside to doing this is that clients that don't speak SSH protocol > version 2 cannot connect, but most folks have upgraded nowadays anyways. > > 2. Make sure Privilege Separation is turned on by setting: > UsePrivilegeSeparation yes > > This creates a child process that does not run as root for incoming > connections. The benefit of this is that a buffer overflow crashing > the process will not give the attacker the identity of root. > > The default for this should be yes and I believe Woody comes this > way. > > 3. Make sure root can not log in: > PermitRootLogin no > > This may be a pain from the perspective of system administration, > but you really don't want someone to log in as root from remote for > auditing purposes anyway. Always su! > > 4. Make sure .rhost and hosts.equiv authentication is not used > RhostsAuthentication no > IgnoreRhosts yes > HostbasedAuthentication no > > This is a holdover from the use of .rhosts and /etc/hosts.equiv > files for authentication. Do not enable it for it bypasses the > password authentication process. > > 5. Depending on the laws where you live, a simple login banner can > protect you. I usually put in some snappy legalese text that's > been approved by my employer's legal office in the file /etc/issue. > Banner /etc/issue [snip]
6. use the AllowUsers option in sshd_config and put a comma separated list of users that are allowed to login remotely. All other users will simply be denied access. 7. Use tcp_wrappers to allow only a handful of IPs to login remotely to your box. If you don't have a static IP that you use yourself to login to your computer remotely, you might want to allow IPs coming from ISPs in your own country/region. That way you limit attacks to a very limitted subset of IPs that can be tracked (and possibly sued) :-) Use whois to determine the IP blocks for major ISPs. -- ----)(----- Luis M System Administrator Kiskeyix.org "We think basically you watch television to turn your brain off, and you work on your computer when you want to turn your brain on" -- Steve Jobs in an interview for MacWorld Magazine 2004-Feb No .doc: http://www.fsf.org/philosophy/no-word-attachments.es.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
