networking chapter

Bennett Todd bet at
Fri Jan 2 07:35:12 PST 2004

2004-01-02T10:07:16 ashes:
> Networking should have its own chapter, unless there are
> networking footnotes on sysklogd, or unless someone has a
> different idea. I'm looking for net-tools, ineutils, and sysklogd
> replacements, maybe ones who are ssl aware.  Suggestions? I assume
> hlfs is importing ssl...

I've been doing host hardening with a focus on network hardening for
quite a few years now, I've comments:-).

For nearly all systems except truly built-by-hand LFS systems,
network hardening starts off trivial; disable or remove all
vender-provided daemons that listen on the network (lsof -Pni finds
'em great), then install your own builds (with strong configuration
mgmt, so packaging is in order here) of the latest and best versions
of just the ones you need. Packaging is in order because you will
have to very very aggressively track security patch releases.

syslogd shouldn't listen on the network unless you actually need it
to, and if you do, you should switch to syslog-ng and use tcp over
the net, with iptables rules to restrict to only those hosts you
actually need to listen from.

SSL can be a help for certain jobs, but its use should be measured,
as the primary implementation today OpenSSL has one of the scarier
security track records. gnutls may be better, but it hasn't received
a lot of scrutiny yet so it might be premature to say. Always
remember that SSL is one of those revolting protocols invented by
inept lummoxes --- it's got ASN.1 BER in it. This makes a case for
favouring stunnel, where practical, over embedded implementations,
since it's likely to be quicker an easier to plug in a new stunnel
and restart them all, then to replace a dynamic library against
which some unknown number of daemons may be running, and some of
which may have statically linked the lib. Stunnel w/ transproxy
support enabled is a pretty clean way to make ssl versions of
network services.

I almost never run an inetd; it seems like most of the casual
daemons that run from inetd aren't the most secure.

Consider very carefully what services you can live without. The more
you live without, the better.

If you have a very occasional, rare need, e.g. remote admin via ssh
that you won't use very often, think about using Ostiary to
temporarily enable it when you actually need it. I can't think of
too many network authentication services whose crypto design I'd
trust more than Ostiary. NB you _have_ to use long, truly random
keys for Ostiary. Cut-n-paste is your friend here.

For some services there are best-of-breed secure daemons available.

If you want to offer SMTP, then you should be running Postfix or
qmail. If you want to offer DNS, djbdns is the choice. Sadly, we
don't have an unquestionable winner for ssh. At the moment I'm fond
of dropbear, been hoping to find time to give it a really close
audit one of these days.

Take the time to setup snort, tune it so it's quiet on your net,
automate signature updates, and arrange for notification when it
alarms. It takes an hour or two after you've done it a few times,
and the results are well worth it.

If you really want badass secure, think about a honeyd + snort
watching all the unused ip addrs, this gives you the best chance I
know of, of getting an alert when someone is hitting you with a day0

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <>

More information about the hlfs-dev mailing list