What about adding ipfwadm/ipchains rules/chains for the input rules on the
internet interface (ppp0) ?
I mean something like ipchains -A input -i ppp0 -j DENY after accept rules
for thing you DO need (like for ICMP replys and HTTP for webservers ?)
Vriendelijke Groeten / Kind Regards,
Alexander van Luijpen
Philips Semiconductors Nederland
Test and Product Engineering
MOS4YOU - C075 OTP / Consumer Systems Nijmegen - BL Video
email: [EMAIL PROTECTED] email: [EMAIL PROTECTED]
tel: (+31)-24-353 4639 tel:
(+31)-24-378 9475
Let's make things better
> -----Original Message-----
> From: Charles Roten [SMTP:[EMAIL PROTECTED]]
> Sent: Wednesday, May 05, 1999 11:38 AM
> To: Linux Net Mailing List
> Cc: D. Andrews; Charles Roten
> Subject: Re: Security
>
> [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]
-
To unsubscribe from this list: send the line "unsubscribe linux-net" in
the body of a message to [EMAIL PROTECTED]
