Date: Fri, 22 Feb 2008 10:38:12 +0700 (ICT) From: Olivier Nicole <on@cs.ait.ac.th> To: jerrymc@msu.edu Cc: zszalbot@gmail.com, freebsd-questions@freebsd.org Subject: Re: security of a new installation / steps to take Message-ID: <200802220338.m1M3cC5t051862@banyan.cs.ait.ac.th> In-Reply-To: <20080220175451.GA56513@gizmo.acns.msu.edu> (message from Jerry McAllister on Wed, 20 Feb 2008 12:54:51 -0500) References: <94136a2c0802200802r790ea5b1ye6f1a331b15ed6f4@mail.gmail.com> <47BC61BA.60103@infracaninophile.co.uk> <20080220175451.GA56513@gizmo.acns.msu.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
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@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200802220338.m1M3cC5t051862>