security of a new installation / steps to take
m.seaman at infracaninophile.co.uk
Wed Feb 20 17:22:12 UTC 2008
-----BEGIN PGP SIGNED MESSAGE-----
Zbigniew Szalbot wrote:
> So far I have had FreeBSD systems only in office so I used my hardware
> firewall (Dlink DFL 700) to block access to services on ports 22, etc.
> Now, at the ISP I won't be able to do this so I will need to be a lot
> more careful about security issues. I am planning to make a list of
> steps I need to take to configure the OS to my liking and install
> applications I need. However, I would really, really love to have some
> advice from you re the basic steps.
The important mantra to remember when securing a machine that is exposed
to the internet is:
What does not listen on the network cannot be used to compromise you.
In practice, this means run sockstat and look for all the processes
that are listening for connections on your external network interfaces.
If you don't need it, then don't run it.
If you don't need external access to it, then bind it to the loopback
interface or use it via a Unix domain socket (eg. 'skip-networking' in
If you do need it, then strongly prefer encrypted versions of network
protocols: IMAPS rather than IMAP, HTTPS instead of HTTP. This is
particularly important if people are using password based authentication
- -- otherwise you'ld be transmitting those passwords over the net in plain,
where they are vulnerable to snooping.
Ensure that any software that does listen on the network runs as an
unprivileged UID. Ensure that the login accounts used for such daemons do
not have real shells (/usr/sbin/nologin is a good choice) and preferably
either have a non-existent home directory, or a home directory that the
process does not own and cannot write to. The current working directory
of the process (frequently /, but you can use 'fstat -p pid' and look
for the 'wd' entry to find this) should similarly be unwritable by
the process. If the process can run chrooted or jailed then it's a good
idea to make it so.
Be very wary of many web based applications, particularly those written
in PHP. Sad to say, but many web developers just don't have a clue about
security and commit some enormous howlers. They also love writing web-
accessible configuration scripts, which you should take care to disable by
changing filesystem permissions once you've done the configuring parts
and also block or severely restrict access to by your webserver configuration.
If anyone proposes running any PHP code that requires you to set 'register_globals'
to 'on' in php.ini; well, suffice it to say, no sensible jury would
convict should that person come to an ... unfortunate ... end.
Make sure you track freebsd-announce at freebsd.org and apply any system patches
in a timely manner. Also make full use of portaudit(1) and generally ensure
that you are running up to date versions of any ported software.
If you can do all the above effectively, then your machine should be pretty
secure as is, even without running any severe filtering through the built in
 People that understand the implications of the weak routing model
as commonly seen in Unix servers (and certainly those that cannot control
access to the same layer-2 network their server is on) will want to protect
the loopback against spoofing attacks. The following 3-line pf.conf
will do the trick:
antispoof log quick for lo0
Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard
PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate
Kent, CT11 9PW
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.4 (FreeBSD)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----
More information about the freebsd-questions