security of a new installation / steps to take

[Olivier Nicole]

Hi,

To all the things that follow (sorry about top reply) I'd add a clever
configuration of tcpwrapper (/etc/hosts.allow) whenever it is
possible: allows to open a service to a list of given clients only.

It is just another layer of security.

Olivier

> > 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 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
> 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