[EMAIL PROTECTED] wrote ...
> I am a kind of new Linux user, pardon me if I am posting to the wrong
> group...
>
> I have a simple Q. Recently I set up a Linux machine with Apache and
> FTP services to use as my companies web server. The machine was hacked
> into and was being used to telnet and finger into other machines. My
> ISP shutdown our service for a few days and would tell me exactly what
> occured, just that over a 2 week period they got many complaints from
> companies being hacked from my server address. They told me it was
> serious enough that I should report it to the FBI and submit my hard
> drive to the feds to investigate. In the mean time I am trying to
> figure out how to make my server more secure. It was my understanding
> that the Red Hat version I am using was pretty secure straight out of
> the box. I didn't change too many settings.
>
> Can anyone suggest any security programs that would help identify holes
> in my setup? I have heard of one such program called COPS, any others
> I should use? I have looked for books on Linux security but havent
> found any yet? any recomendation?
>
> Thanks in advance! I have learned a lot from just being a passive
> member of this group, reading all the Qs and As over the past few
> months...
>
> David Andrews
> PC LAN Admin
> MPIUA
> [EMAIL PROTECTED]
Wow. Ugly way to get started in Unix security ... Brrrrr .....
I'm no security guru, by any means, but I do have a few common-sense
observations, and suggestions to offer that might help somewhat.
On my last job, I first managed, then built and configured, Solaris-
based firewall boxes. Now, a _firewall_ box should be made as hard as
possible to crack into .... It occurred to me, after a bit (given my
depressingly slow uptake :) that much of what I had learned could
easily be extrapolated to a Linux environment.
But it looks like Lance Spitzner beat me to the punch on that one !
Thanks, Lance !
Check out
http://www.enteract.com/~lspitz/armoring.html (Armoring Solaris)
http://www.sabernet.net/papers/secureSolaris.html
(Unix Security Handbook, Solaris 2.6 and Solaris 7)
http://www.sabernet.net/papers/secureSolaris5.html
(Unix Security Handbook, Solaris 2.5.1)
http://www.enteract.com/~lspitz/linux.html (Armoring Linux)
The following discussion summarizes the "Armoring Linux" URL,
http://www.enteract.com/~lspitz/linux.html
The basic message of Lance Spitzner's page seems to be the following:
1) Install /var in a separate partition. Lance recommends 200 Mb,
with 400 Mb as a practical maximum. The intent is to prevent
logs of system problems (and Joe SlimeBall's attempts to compromise
your box !!) from crushing the partition(s) with kernel(s) and
system binaries to load.
2) Decide which services you do NOT need. if you aren't going to use
your box as a Usenet News server, then yank out the inn package. If
you are running RedHat, this will be incredibly easy, since that
functionality resides in, at most, two _packages_, which may be
installed and removed at will with the "rpm" command-line tool. On
my RedHat 5.2 box, the incantation was
rpm -e inn-1.7.2-14 inn-devel-1.7.2-14
Blooie! Gone.
3) Keep track of the security problems that are reported on
[EMAIL PROTECTED] Or just keep tabs on the RedHat OS updates.
RedHat security patches always seem to show up there in a timely
manner.
4) Take a walk through /etc/inetd.conf. Insert a "#" at the beginning
of lines which specify services you neither need nor want. This
will
be most of them, more than likely.
5) Go through the /etc/rc.d/rc?.d/ directories (on a RedHat box) and
decide which of the symlinks to "start" scripts (the ones that start
with "S") start up daemons whose functionality you neither want nor
need. When you find one, say "S20rusersd", do
mv S20rusersd _S20rusersd
That disables the symlink in a reversible way, should you decide at
a later time to restore the service, but _prevents_ the service from
being started upon system boot.
Use Lance Spitzner's discussion as a starting point for which
services are "unnecessary".
6) Populate /etc/issue with an appropriate warning message. Could be
useful if the system gets cracked anyway, and the matter ends up in
court. This will involve changes to /etc/rc.d/rc3.d/S99local on
a Red Hat box.
7) Convert to shadow passwords if this has not already been set up by
default. Old-style encrypted passwords resided in /etc/passwd, but
under "shadow password" systems, they reside in /etc/shadow. Do a
manual page lookup on "pwconv".
8) Remove unnecessary system accounts from /etc/passwd. Example: if
you
aren't running a News server, the "news" account has no function.
So why leave it in /etc/passwd ?? YANK THE "ftp" ACCOUNT (unless
you
_want_ the grief associated with anonymous ftp administration :) !!
9) Make sure "root" is in /etc/ftpusers. That way, root cannot ftp
into
your box !!
10) Make sure root cannot telnet to the system directly ! Check out the
file /etc/securetty. It should only contain line like
tty4
and not lines like
ttyp2
11) Tweak TCP Wrappers. It almost certainly is already installed on
your
Linux box. /etc/hosts.allow is what TCP Wrappers uses to determine
which hosts can access the system, and /etc/hosts.deny is TCP
Wrappers'
"bad actor" file.
-
To unsubscribe from this list: send the line "unsubscribe linux-net" in
the body of a message to [EMAIL PROTECTED]
