|Zbigniew Szalbot||Feb 20, 2008 4:02 pm|
|Schiz0||Feb 20, 2008 4:09 pm|
|Bill Moran||Feb 20, 2008 4:32 pm|
|Matthew Seaman||Feb 20, 2008 5:21 pm|
|Zbigniew Szalbot||Feb 20, 2008 5:41 pm|
|Jerry McAllister||Feb 20, 2008 5:58 pm|
|Matthew Seaman||Feb 20, 2008 6:03 pm|
|Paul Schmehl||Feb 20, 2008 6:37 pm|
|Olivier Nicole||Feb 22, 2008 3:37 am|
|Subject:||security of a new installation / steps to take|
|From:||Olivier Nicole (on...@cs.ait.ac.th)|
|Date:||Feb 22, 2008 3:37:59 am|
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.
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 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 free...@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.
 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