From owner-freebsd-questions@FreeBSD.ORG Fri Feb 22 03:38:17 2008 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A365116A405 for ; Fri, 22 Feb 2008 03:38:17 +0000 (UTC) (envelope-from on@cs.ait.ac.th) Received: from mail.cs.ait.ac.th (mail.cs.ait.ac.th [192.41.170.16]) by mx1.freebsd.org (Postfix) with ESMTP id 2660D13C465 for ; Fri, 22 Feb 2008 03:38:16 +0000 (UTC) (envelope-from on@cs.ait.ac.th) Received: from banyan.cs.ait.ac.th (banyan.cs.ait.ac.th [192.41.170.5]) by mail.cs.ait.ac.th (8.13.1/8.12.11) with ESMTP id m1M3cEk6044032 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 22 Feb 2008 10:38:14 +0700 (ICT) Received: (from on@localhost) by banyan.cs.ait.ac.th (8.13.6/8.12.11) id m1M3cC5t051862; Fri, 22 Feb 2008 10:38:12 +0700 (ICT) Date: Fri, 22 Feb 2008 10:38:12 +0700 (ICT) Message-Id: <200802220338.m1M3cC5t051862@banyan.cs.ait.ac.th> From: Olivier Nicole To: jerrymc@msu.edu 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> X-Virus-Scanned: on CSIM by amavisd-milter (http://www.amavis.org/) Cc: zszalbot@gmail.com, freebsd-questions@freebsd.org Subject: Re: security of a new installation / steps to take X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2008 03:38:17 -0000 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