Re: [Fwd: security]
On Sat, 29 Jan 2005 14:48:44 -0500, smj@littleprojects.org
<smj@littleprojects.org> 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 <linux@networkingnewsletter.org.uk>
[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
Reply to: