This is part of The Pile, a partial archive of some open source mailing lists and newsgroups.
To: lsec@Mail.Linux-Consulting.com
Date: Sun, 24 Sep 2000 10:23:50 -0700
From: J C Lawrence <claw@kanga.nu>
Subject: [svlug] Re: [lsec] svlug stuff
<<I've crossed this to SVLUG for general interest>>
On Sat, 23 Sep 2000 23:32:17 -0700 (PDT)
alvin <alvin@Mail.Linux-Consulting.com> wrote:
> - gotta get back to building 15 (semi-hardened) boxes
> today/tommorrow
I'm interested in what people do to harden their boxes. The basic
pattern for me, written off the top of my head and in the order I
thought of them (I really should document this and checklist this
all):
-- Remove everything from /etc/inet.d. Nothing should ever run
from inet in my world if possible. Note: I have no problem
with inet daemons -- its just that my current preferred set of
daemons prefer running standalone (eg exim, muddleftpd). and I
like the fact that I can use `ps` to check on possibly running
daemons.
-- if the system will be sourcing publicly received mail, add
back in identd.
-- if the system must run POP3/IMAP, chose which daemons to run
very carefully and then TCP Wrap tightly.
-- Carefully work thru every single package you have installed on
your system and remove every one you don't ABSOLUTELY need. If
possible, make sure you remove the compilers and all
development libraries as well.
-- Ensure that all network daemons (eg MTA, FTPd, etc) are built
against libwrap (TCP Wrappers).
-- Put TCP Wrappers into paranoid mode by adding "ALL:PARANOID" to
/etc/hosts.deny
-- Carefully edit the TCP Wrappers setup on the system so that
network services may only be accessed from where I want them to
be (I usually only allow access from localhost, thus requiring
remote users to use an SSH port forward, stunnel SSL wrap).
-- If possible, remove all user logins except for yourself and
root.
-- If there are going to be multiple people with root access to
the box, create user acounts for them and individual root
accounts as well (I use the naming pattern of their normal
userID siffixed with a capital 'R'. eg "clawR" for me.) To
create these accounts, just create them as per normal with
adduser, and then change their UID and GID to 0 so they're
really root (/etc/passwd and /etc/groups).
-- If you do this, never tell anyone the actual root password
-- Install tripwire, suitably configure, gen a database for it,
and if possible, stick the DB on a CD. More typically I stick
the databases on a local partition (saves CD effort) which is
mounted RO. I then have a cron job or tiny daemon that
checks that the partition is really mounted RO, and if not
sends alerts.
-- Install and configure portsentry.
-- Install and configure iplogger.
-- Install and configure logckeck.
-- Install and configure XNTP3 and point at at least two statum
1 servers amd a couple stratum 2 and 3s.
-- Install and configure snort (if you don't have one running on
the local net already).
-- If possible remove Apache. If not possible, replace Apache
with thttpd (ie if you are doing static content only). If
still not possible, remove all the images etc from your Apache
confs and put under thttp. Why? Simpler traffic shaping and
prevention of certain (small) classes of DoS attacks.
-- Note: You can probably substitute hernel httpd for thttp
above, but I haven't checked into this.
-- If you run a daemon that supports CGIs, remove and if
not possible, audit all CGIs.
-- If you are running Debian, ensure that all your documentation
is not exported to the Internet via http://.../doc/. Either
configure it for localhost, or remove entirely.
-- Remove your FTPD daemon. Replace with either Marcus Ranum's
AFTPD or MuddleFTPd (I like and use the latter for purely
historical reasons).
-- If you go for muddleftpd, configure for anonymous logins
only.
-- Aside: I run muddleftpd in a chroot jail atop an FTP tree
which is copied from wu-ftpd's but is filled with trojan
binaries. ie it looks like wu-ftpd, but when or if they ever
get run they send alerts to me that someone tried to run
them. Reason: muddleftpd doesn't run external binaries for
the 'ls' command etc.
-- If you're going to run chroot jails, a good idea in general,
use Weitse Venema's chroot tools from:
ftp://ftp.porcupine.org/pub/security/index.html.
-- Rebuild the kernel and remove everything you don't absolutely
need.
-- Especially remove all SMBFS and NFS supports. (If you don't
have 'em you can't use 'em and you can't open holes with 'em)
-- Install SSH.
-- Ensure it disallows root logins.
-- Set logging to fascist.
-- Disallow rsh logins (you should have removed all RSH-style
supports above).
-- If you are running a multi-user box, install some form of
password checker. There's a PAM module for this.
-- If at all possible, remove all user logins from the box.
-- If you have to have some level of user logins (eg for
terminating SSH port forwards), bolt them down (if SSHv2 set
their shell to /bin/false, remove all write permissions to
their home directory, etc)
-- Install and configure an SNMP daemon (I usually set to only
allowing sets from localhost, queries from remote connections,
and then further limit to only allowing queries from specific
IPs). Note: I like the UCD SNMP daemon.
-- Configure your SNMP daemon to export specifics about all your
filesystems and critical processes (eg number of running
instances of server daemons, free space, etc.)
-- On a different box, install and configure cricket and point it
at this box to collect and graph your SNMP data.
-- Example: http://www.kanga.nu/stats/cricket/grapher.cgi
-- Note: I don't recommend exposing the collected data as I
have. Those interested however can find my cricket configs
here:
ftp://ftp.kanga.nu/pub/Kanga.Nu/cricket/kanga.nu.cricket.config.tar.gz
-- Install and configure an SNMP monitor on a remote box ala Mon
to watch your system values and send alerts if things vary
outside of tolerance.
-- Configure your daemons to help prevent DoS attacks (eg max
number of running instances (Exim/Apache), bandwidth profiling
(thttpd) etc.
-- Make sure /tmp is on its own partition, and is large (I
typically use 500Meg, often on its own disk).
-- Point /usr/tmp and /var/tmp at /tmp.
-- Install and configure tmpwatcher.
-- Make sure /var/log is on its own partition and is large (I
typically allocate at least a couple Gig).
-- Check and fix/configure how your logs are rotated. Except
for extremely spammy logs (eg MySQL reply logs) I generally
like to keep at least a year's history for logfiles.
-- If possible, run a seperate box as a loghost for all your
systems (in addition to having local logs).
-- Edit /etc/syslog.conf to ALSO send all logged data to
your loghost (should be on same network) as well as to local
disk.
-- Your loghost should have only one open port (syslog) with
all system access only occurring thru the console. If not
possible, add one extra open port for SSH, and the use
something like Opie for one-time-password logins.
-- Remove BIND.
-- If you need a local cacheing nameserver, install DJB's
cachedns.
-- Remove sendmail. I prefer Exim tho Postfix is also a good
solution as is QMail.
-- Make sure you remove lpd/lprng/cups. Daemonised printing
supports have no business on 'net connected systems.
-- Run nmap against your box and list and account for EVERY open
TCP and UDP port. Work hard to make the total number of open
ports zero. You won't make it as the whole reason for the box
is to offer some sort of services, but you can get close.
-- Make sure you do this after a fresh reboot.
-- Make sure you have and are running an suidmanager.
-- Audit your system (`find` is your friend) and make sure that
all SUID files are registered with your suidmanager.
...and a bunch more things I can't think of right now.
===
Date: Sun, 24 Sep 2000 21:00:55 -0400
From: Brian Coyle <brianc@magicnet.net>
To: SVLUG <svlug@lists.svlug.org>
Subject: Re: [svlug] Re: [lsec] svlug stuff
J C Lawrence wrote:
>
> I'm interested in what people do to harden their boxes. The basic
> pattern for me, written off the top of my head and in the order I
> thought of them (I really should document this and checklist this
> all):
SANS.org has several guides for locking down various flavors of *nix.
http://www.sans.org/newlook/publications/index.htm
If you are fairly proficient with security, you could probably
get by using the table of contents (which is available online) as
a checklist. Otherwise I'd recommend springing for the printed
copy. Some good stuff in there.
Here's the "Securing Linux" TOC-
http://www.sans.org/newlook/publications/linux_toc.htm
> -- If there are going to be multiple people with root access to
> the box, create user acounts for them and individual root
> accounts as well (I use the naming pattern of their normal
> userID siffixed with a capital 'R'. eg "clawR" for me.) To
> create these accounts, just create them as per normal with
> adduser, and then change their UID and GID to 0 so they're
> really root (/etc/passwd and /etc/groups).
YIKES!! A much more managable and auditable solution is sudo.
You really should only have ONE user (root) with a UID of zero...
With sudo, you can lock down users to the few specific commands they
might require, not wide open root access. It's very configurable.
===
To: Brian Coyle <brianc@magicnet.net>
Subject: Re: [svlug] Re: [lsec] svlug stuff
Date: Sun, 24 Sep 2000 19:49:52 -0700
From: J C Lawrence <claw@kanga.nu>
On Sun, 24 Sep 2000 21:00:55 -0400
Brian Coyle <brianc@magicnet.net> wrote:
> J C Lawrence wrote:
>> I'm interested in what people do to harden their boxes. The
>> basic pattern for me, written off the top of my head and in the
>> order I thought of them (I really should document this and
>> checklist this all):
> SANS.org has several guides for locking down various flavors of
> *nix.
> http://www.sans.org/newlook/publications/index.htm
> If you are fairly proficient with security, you could probably get
> by using the table of contents (which is available online) as a
> checklist. Otherwise I'd recommend springing for the printed
> copy. Some good stuff in there.
Yup, there's some good stuff there. Also at SecurityFocus and
RootPrompt. I've accumulated assorted links to such areas at:
http://www.kanga.nu/~claw/
As you might guess, I've mostly been looking into the Intrustion
Detection System area, so that's the best populated section.
>> -- If there are going to be multiple people with root access to
>> the box, create user acounts for them and individual root
>> accounts as well (I use the naming pattern of their normal userID
>> siffixed with a capital 'R'. eg "clawR" for me.) To create
>> these accounts, just create them as per normal with adduser, and
>> then change their UID and GID to 0 so they're really root
>> (/etc/passwd and /etc/groups).
> YIKES!! A much more managable and auditable solution is sudo.
> You really should only have ONE user (root) with a UID of zero...
> With sudo, you can lock down users to the few specific commands
> they might require, not wide open root access. It's very
> configurable.
I've never been compleatly happy with sudo. Not sure why. I
suspect it is because my general definition and use of "root" is an
absolute thing. I don't really grok the idea of a semi-root.
That's what things like the 'bin' user are (should) be for (tho most
Linux distributions seem to utterly ignore bin and sys as useful
well-used user-IDs).
===
To: lsec@Mail.Linux-Consulting.com
Date: Sun, 24 Sep 2000 20:42:14 -0700
From: J C Lawrence <claw@kanga.nu>
Subject: [svlug] Re: [lsec] svlug stuff - hardening stuff
On Sun, 24 Sep 2000 19:07:38 -0700 (PDT)
alvin <alvin@Mail.Linux-Consulting.com> wrote:
> hi ya jc...
> good list....
Thanks.
> - i'd add stuff about leaving telnet/ftp/pop/imap/ppp/etc to be on
> a separate insecure box that is denied access to a secure
> box....and a secure box cannot get to an insecure box..
Aside from the fact that I consider use of telnet for other than
protocol testing to be tantamount to a system administration crime,
yes. This is also a reason (among many others) to puch such
services on single-use special-case boxes. Expensive on systems and
IP space to be sure, but SysAdm time (and good sleep) is far more
expensive.
I've also been doing a fair bit of thinking lately about
administration of DMZs in this regard, which rather falls outside
the purview of this list.
My tendency so far in my thinking is to make a single box in the DMX
be an admin concentrator for the entire DMZ. All the other boxes in
the DMZ would then only allow user logins from the admin
concentrator box plus one or two specific other addresses (eg
additional concentrator inside the corporate LAN, and perhaps a
single off-site OOB box at connected via a different ISP etc (so as
to disallow the DMZ being isolated by the DMZ concentrator being
cracked/taken down/DoSed). I'm not happy yet that I've thought thru
all the implications tho.
> - i'd also add that they should apply all(as needed) the security
> patches for their distribution...after freshly installing from
> cdrom
Yup. With swepping generosity I'll enclude that in my etc list of
"other things I can't think of right now", along with suitable
ipchains rules (mostly for packet discards and blackholing). More
honestly however, I just forgot.
> - i'd also add backups to the list of security stuff... - hourly,
> daily, weekly, monthly incremental backups of critical
> data...stored on different servers - same for weekly/monthly full
> backups...
I generally recommend a three stage process:
Frequent on-site full backups (as different from incremental),
rotated on a reasonable period (usually yearly), with regularly
grandfathering (keeping of permanent backup sets outside of the
rotation) at a frequency of at least one in ten.
Similarly or slightly less frequent off-site backups, no less
frequent than your on-site grandfathers, with s similar rate of
grandfathering as proportional to your off-site rate.
I count incremental backups as strictly transitory. They're there
for easy recovery, usually quick/hit-fix type situations.
> - /tmp is supposedly world writable and stuff.... /usr/tmp,
> /var/tmp supposedly was a more secure temp area so i would NOT mix
> them up... i keep /tmp is small tooo....64/128M or so...
I don't keep them seperate any more as I'v not found a Linux
distribution that actually cares (not that I've checked with any
thoroughness). I specifically make the partition large so that a)
files will tend to hang around for analysis before being
automatically reaped, b) as cheap security against certain forms of
DoS attacks, and c) because it really hurts when /tmp gets full (a
down system is almost as bad as a cracked system).
> - donno if you had loghost machine in the list...where ALL log
> messages are routed to loghost....and it only allows console
> login....and nothing else to do but receive incoming log messages
They were in there.
> -- your list should be made into a "security howto" but i'd also
> give it different hardening levels... level1 security.....just do
> the simple config changes... and level3...where they have to
> recompile say tcpwrapper into it and or replace
> apache...etc..etc..
Yeah, since I wrote it I've been thinking about wrapping that list
up in something a little more comprehensive and explanatory. I'm
not entirely sure about the "levels of security" idea, but I could
see some use in splitting it into realms (for a home box, for a
firewall or gateway, for a 'net server, etc).
> - probably should run crack, tiger and other tools tooo in
> addition to nmap......if you want a good laugh...run crack on pop3
> servers....
This is an area that has been occupying some attention for me. I'm
really not sure *WHAT* I'd recommend as a good secure POP3 or IMAP
implementation. Sure, there are ways to protect the
authentications, but there's also the datastream itself to protect
etc ad infinitum. Email is an ugly world security-wise from a
corporate vantage -- and that's not even accounting for physical
security. You have to compromise somewhere, and every compromise
I've found yet has really ugly counterpoints I just do not like.
I guess this is another one of those adjudicated risk management
bits.
> - theres problems with postfix with majordomo... so some of the
> things have to be evaulated for tradeoffs...
I've not read about that, tho I don't follow the majordomo news any
more. I;m not fond of majordomo and wouldn't really recommend its
use in almost any case. There are too many other better featured,
easier to audit/constrain systems out there that possess fewer
warts.
> have fun linuxing alvin
You too.
===
From: Alvin Oga <alvin@planet.fef.com>
To: lsec@mail.Linux-Consulting.com
Date: Sun, 24 Sep 2000 21:32:51 -0700 (PDT)
Cc: svlug@svlug.org
Subject: [svlug] Re: [lsec] svlug stuff - hardening stuff
hi ya jc...
yeah..... i guess i like the idea of a separate "insecure"
box for emails.... cause there is no way we can police/manage
users passwd for their outlook/netscape based emails...
-- all insecure stuff is outside... the secure lan...
- we can do the firewalls, vpn, ipchains, et al in a separate
documents....of things to do and things not to...
- problem usually is....most people dont seem to want to protect
their boxes/data till after they've been hacked...
- and still not wlling to pay for their sysadmin to fix
it at 3am when somebody figured out the server died...
- and than there is all those nuisance factors.... to keep a nice
tight ship.... spammers and black holes and filters...
- i try to do backups such that....if last weeks full backup failed,
that i can still recover and rebuild the entire server till yesterday
or the last incremental backup that is still good....
.... i try to keep 2 or 3 different ways to get data restored.....
- lets ignore/consider that we could be accidentally reloading the
hackers trojan horse tooo.....but....thats what "eyes-n-brains"
are sometimes used for... during a restore....
===
To: Alvin Oga <alvin@planet.fef.com>
Subject: Re: [svlug] Re: [lsec] svlug stuff - hardening stuff
Date: Sun, 24 Sep 2000 21:53:51 -0700
From: J C Lawrence <claw@kanga.nu>
On Sun, 24 Sep 2000 21:32:51 -0700 (PDT)
Alvin Oga <alvin@planet.fef.com> wrote:
> yeah..... i guess i like the idea of a separate "insecure" box for
> emails.... cause there is no way we can police/manage users passwd
> for their outlook/netscape based emails... -- all insecure stuff
> is outside... the secure lan...
Yup. This is your DMZ.
> - we can do the firewalls, vpn, ipchains, et al in a separate
> documents....of things to do and things not to...
<nod>
Gotta think about this some.
> - problem usually is....most people dont seem to want to protect
> their boxes/data till after they've been hacked... - and still
> not wlling to pay for their sysadmin to fix it at 3am when
> somebody figured out the server died...
I had a talk with my current clients about this. They were being a
bit antsy about expenses and their intellectual property risks (they
have considerable original IP to protect). I tried to phrase the
conversation like this (with only marginal success (I phrased it
badly, and the below is a lousy phrasing that I should have known
better than)):
"Okay, let's turn this thing around for a minute. Imagine I just
walked in the door with a worried expression on my face and said the
following: 'I just found out that our network has been cracked for
the last week and I suspect that everything may have been fed to our
major (and well market established) competitor.' Now, once you've
stopped screaming and calling your lawyers, how much is mitigating
and controlling that risk worth to you? If you're honest with
yourself, if only from a business perspective, you'll admit that you
(the company) are at risk. The skill, ability, knowledge,
persistance and availability (given their other responsibilities) of
your SysAdm staff are the tools you have to attempt to control that
risk. Given that admission, what is risk management worth to you in
this area?"
It is a horrible question. It is not a question I know how to
correctly and sanely evaluate for a useful answer, certainly not
without italian-style handwaving. On the one hand you can blame the
phrasing of the question as it is a scare question based on emotive
reactions. On the other hand, the question is accurate and
correctly isolates critical points. Its like bobbing for apples in
a lava pit. It doesn't really matter: you're going to get burnt.
Unfortunately the security game is built on questions like that.
===
To: lsec@Mail.Linux-Consulting.com
Date: Sun, 24 Sep 2000 22:04:25 -0700
From: J C Lawrence <claw@kanga.nu>
Subject: [svlug] Re: [lsec] svlug stuff - hardening stuff
On Sun, 24 Sep 2000 21:32:51 -0700 (PDT)
Alvin Oga <alvin@planet.fef.com> wrote:
> - and than there is all those nuisance factors.... to keep a nice
> tight ship.... spammers and black holes and filters...
<nod> I keep going back and forth on using things like the RBL and
ORBS. Much as I really like the idea of them, and support their
existance, from a list owner perspective they're also annoying. FOr
instance I have several members continually skirting being
auto-unsubscribed because they are bouncing posts from other members
posting from INAME (which is on the RBL last I checked). Now I
could blame this on the bounce handling of the list server (one
could argue that it should ignore RBL bounces), but its equally easy
to argue that that's a specious argument, especially in a VERP world
(not that I use VERP).
===
Date: Thu, 28 Sep 2000 09:55:01 -0700 (PDT)
From: Deirdre Saoirse <deirdre@deirdre.net>
To: Todd Lyons <todd@mrball.net>
Subject: Re: [svlug] identd
On Wed, 27 Sep 2000, Todd Lyons wrote:
> I've been under the impression that identd was a security loophole and
> so do not run it at all. Is this not true? Is it safe to run in
> certain circumstances?
It's simply not a necessary service for most. If you like to use IRC, it's
pretty much a mandatory service to run as most IRC servers don't allow
users who don't respond to ident requests.
I don't know of it being especially a security hole, except insofar as it
binds to a privileged port and thus requires root authority to do so. I
wouldn't run any such services you don't need.
For example, though finger isn't really much of a security hole these
days, the one time it was has turned people off of using it. It used to be
useful. Some day, I'm going to write a nifty little finger daemon.
===
Date: Thu, 28 Sep 2000 10:31:26 -0700 (PDT)
From: Aaron T Porter <atporter@primate.net>
To: Deirdre Saoirse <deirdre@deirdre.net>
Cc: World Domination <svlug@svlug.org>
Subject: Re: [svlug] identd
On Thu, 28 Sep 2000, Deirdre Saoirse wrote:
> For example, though finger isn't really much of a security hole these
> days, the one time it was has turned people off of using it. It used to be
> useful. Some day, I'm going to write a nifty little finger daemon.
Finger is still a nasty security hole. It's a remote discovery
method even if there is no currently known exploit in the code.
===
Date: Thu, 28 Sep 2000 10:33:26 -0700 (PDT)
From: Deirdre Saoirse <deirdre@deirdre.net>
To: Aaron T Porter <atporter@primate.net>
Subject: Re: [svlug] identd
On Thu, 28 Sep 2000, Aaron T Porter wrote:
> On Thu, 28 Sep 2000, Deirdre Saoirse wrote:
>
> > For example, though finger isn't really much of a security hole these
> > days, the one time it was has turned people off of using it. It used to be
> > useful. Some day, I'm going to write a nifty little finger daemon.
>
> Finger is still a nasty security hole. It's a remote discovery
> method even if there is no currently known exploit in the code.
True -- I remember when it was a very common way to get someone's PGP key.
And no one ever said you had to give a *right* answer -- you could insert
fortune file responses, for example.
===
Date: 28 Sep 2000 18:14:55 -0000
Subject: Re: [svlug] identd
From: John Conover <conover@rahul.net>
To: svlug@lists.svlug.org
Some MTAs are configured to request ident/auth, as are some NNTP
servers, and some MP3 services, (like www.mp3.com.) Although they
request the service from the host, most will work without it-after it
times out, so there will be a latency getting these services to start
a transaction dialog, (sometimes running to five minutes.)
With ipchains, you can change the action on the auth port from DENY to
REJECT, which will just refuse service on port 113, (instead of not
answering it at all,) to all machines on the Internet, and the
transaction dialogs will begin immediately; and the identd daemon will
never be contacted-and no information returned about who is currently
on the system-so it will protect your system from culprits.
However, if you use ipchains to hide from the script kiddies by doing
combinations of DENY and -y, (ie., no SYN without ACKs, but allow
packets with both SYN and ACK flags set to ports > 1023,) to make the
host machine unresponsive to requests to initiate transactions from
the Internet, then the vandals can deduce that the machine is alive
and well because of the immediate REJECT on port 113.
The best bet is to ACCEPT transactions initiated to port 113, from
specific trusted hosts, (like your NNTP server, mail relay, etc.,) but
DENY all others, as a default policy. (However, if you are running a
system for a lot of other folks-like a corporate gateway, or an
ISP-that probably won't be workable for you.)
Even so, if an I-vandal sees the door slammed shut by a REJECT, it
will probably encourage the scoundrel to move on and look for easier
prey elsewhere ...
===
Date: Thu, 28 Sep 2000 12:36:15 -0700
To: svlug@svlug.org
Subject: Re: [svlug] fingerd (was identd)
From: Chris Waters <xtifr@dsp.net>
On Thu, Sep 28, 2000 at 10:31:26AM -0700, Aaron T Porter wrote:
> Finger is still a nasty security hole. It's a remote discovery
> method even if there is no currently known exploit in the code.
First of all, ITYM fingerd, not finger.
Calling it a "security hole" because it does what it's designed to do
is slightly over the top, I think. Fingerd is something that people
may not want to run because it reveals things they may not want to
reveal, but at the same time, there are also now versions that allow a
great deal of control over exactly what gets revealed.
Fingerd (even one of the newer, more controllable versions) is
probably not something you want to install unless you know what you're
doing, but that goes for most daemons, especially net service daemons.
It's a way of publishing information, and you should only run it if
you want to publish information -- much like httpd or nntpd or
something.
The real problem is not poor innocent daemons like fingerd -- it's
flakey distributions that try to install everything including the
kitchen sink by default.
===
Date: Sun, 24 Sep 2000 19:07:38 -0700 (PDT)
From: <alvin@Mail.Linux-Consulting.com>
To: lsec@Mail.Linux-Consulting.com
Subject: [svlug] Re: [lsec] svlug stuff - hardening stuff
hi ya jc...
good list....
- i'd add stuff about leaving telnet/ftp/pop/imap/ppp/etc
to be on a separate insecure box that is denied access
to a secure box....and a secure box cannot get to an insecure
box..
- i'd also add that they should apply all(as needed) the security patches
for their distribution...after freshly installing from cdrom
- i'd also add backups to the list of security stuff...
- hourly, daily, weekly, monthly incremental backups
of critical data...stored on different servers
- same for weekly/monthly full backups...
- if any day or week of backup data is lost.... assumption is
i can restore that lost data by the next days incremental
backup since i always do incremental backup from the last
"full backup"
- /tmp is supposedly world writable and stuff....
/usr/tmp, /var/tmp supposedly was a more secure temp area
so i would NOT mix them up...
i keep /tmp is small tooo....64/128M or so...
- donno if you had loghost machine in the list...where ALL log messages
are routed to loghost....and it only allows console login....and
nothing else to do but receive incoming log messages
-- your list should be made into a "security howto"
but i'd also give it different hardening levels...
level1 security.....just do the simple config changes...
and
level3...where they have to recompile say tcpwrapper into it
and or replace apache...etc..etc..
- probably should run crack, tiger and other tools tooo in addition to
nmap......if you want a good laugh...run crack on pop3 servers....
- theres problems with postfix with majordomo...
so some of the things have to be evaulated for tradeoffs...
===
Date: Thu, 28 Sep 2000 20:49:40 -0700
From: Rick Moen <rick@linuxmafia.com>
To: World Domination <svlug@svlug.org>
Subject: Re: [svlug] identd
begin wayne@qconcepts.net quotation:
> (Quick comment: my original post should have referred to tcpserver
> replacing inetd...
I'd personally either run regular inetd with tcp wrappers (as giving me
all the filtering/control *I* need), or xinetd.
> Unfortunately, as a sysadmin, I'm stuck in a bind on this issue; two
> conflicting principles. On one hand, I believe that {Open || Free}
> Software is generally the best solution to most server issues;
It would be nice to evaluate Bernstein's licence for ucspi-tcp on its
merits, but Bernstein didn't issue one. So, you don't even know what
his conditions of use _are_.
> If a machine gets compromised that I am responsible for, and is
> exploited with the "wu-ftpd bug of the week"(tm) what am I going to
> say? "Sorry, but I know there was a better, more secure server
> available, but I didn't use it because the licence is iffy?
Illogical, without including other ftpds with good licences and good
security. http://linuxmafia.com/pub/linux/security/ftp-daemons
> But I have had to build anonymous-only ftp sites on contract. Bernstein's
> publicfile works best (for me) in that case.)
Your views on oftpd, pftpd, and troll-ftpd are what, by the way?
(Hell, I'd personally even use Ranum's aftpd before I'd use Bernstein
code, but that's just me.)
I think the best advantage Bernstein has is in his DNS tools, but I'd
still rather use bind in a chroot jail, or dents, to keep that man's
whacked-out design ideas and licence problems out of my life.
===
Date: Thu, 28 Sep 2000 21:10:07 -0700
From: "Jeffrey B. Siegal" <jbs@quiotix.com>
To: Rick Moen <rick@linuxmafia.com>
Subject: Re: [svlug] identd
Rick Moen wrote:
> It would be nice to evaluate Bernstein's licence for ucspi-tcp on its
> merits, but Bernstein didn't issue one. So, you don't even know what
> his conditions of use _are_.
That's not quite true. His viewpoint is here:
http://cr.yp.to/softwarelaw.html
By my interpretation of his intent as stated in that document, and my
unserstanding of copyright law, his software is not open source because
it fails to satisfy items 1, 3, and 4 of the OSD.
It is proprietary software distributed with source code at no charge.
===
Date: 29 Sep 2000 19:00:57 -0000
Subject: Re: [svlug] identd
From: John Conover <conover@rahul.net>
To: svlug@lists.svlug.org
wayne@qconcepts.net writes:
> There is a secure replacement for identd that works quite well:
>
> http://cr.yp.to/ucspi-tcp/tcpserver.html
>
> Although it's a bit of black magic to get any of ucspi-tcp to work
> correctly (chant the mantra: I will not have /usr/local a symlink, I will
> not have /usr/local a symlink...), Bernstein's tools are rock solid.
>
> (Ducks incoming flames regarding Bernstein's stupid (yet
> apparently nonexistant) licencing)
Hi Wayne. You mean run identd under tcpserver, right?
BTW, tcpserver has some advantage over tcpwrappers in being robust
against DoS attacks.
===