security of a new installation / steps to take

Jerry McAllister jerrymc at
Wed Feb 20 17:58:57 UTC 2008

On Wed, Feb 20, 2008 at 05:22:02PM +0000, Matthew Seaman wrote:

This is a very nice summary.
I will steal it and post it on the wall in our cube-maze hallway.


> Hash: SHA256
> 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[1] or use it via a Unix domain socket (eg. 'skip-networking' in
> MySQL configuration)
> 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 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
> firewalls.
> 	Cheers,
> 	Matthew
> [1] 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:
> scrub in
> pass all
> antispoof log quick for lo0
> - -- 
> Dr Matthew J Seaman MA, D.Phil.                   7 Priory Courtyard
>                                                   Flat 3
> PGP:     Ramsgate
>                                                   Kent, CT11 9PW
> Version: GnuPG v2.0.4 (FreeBSD)
> Comment: Using GnuPG with Mozilla -
> iD8DBQFHvGG68Mjk52CukIwRCNfQAJ9yaAXQzhNgfF31V+AtArEyDvdPigCffAuG
> afcraoWgVfPnUlSj4S8Zswk=
> =uZ1e
> _______________________________________________
> freebsd-questions at mailing list
> To unsubscribe, send any mail to "freebsd-questions-unsubscribe at"

More information about the freebsd-questions mailing list