Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 22 Jan 2006 11:04:36 +0000
From:      Matthew Seaman <m.seaman@infracaninophile.co.uk>
To:        Benjamin D Adams <freebsdworld@gmail.com>
Cc:        freebsd-chat@freebsd.org
Subject:   Re: FreeBSD 5.4 with no Firewall?
Message-ID:  <43D366C4.7020904@infracaninophile.co.uk>
In-Reply-To: <1137895868.789.4.camel@7Current.FreeBSDWorld.NET>
References:  <1137895868.789.4.camel@7Current.FreeBSDWorld.NET>

next in thread | previous in thread | raw e-mail | index | archive | help
This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig3E9FECB54ABBD8311697846D
Content-Type: text/plain; charset=ISO-8859-15
Content-Transfer-Encoding: quoted-printable

Benjamin D Adams wrote:
> I'm moving my server to a colocation.  Its a web-server (Apache 2.0) on=

> FreeBSD 5.4.  Should I get a gigabyte firewall first?(I plan on getting=

> one soon) How important? What can I do to help secure the OS its self?
> Any built in programs I should install first?

Sure, you can run a stand-alone FreeBSD box on the Internet without a
separate firewall, if you configure it carefully.  Mind you, you still ne=
ed
the same degree of care /with/ a firewall -- it just gives you another la=
yer
behind which you can get away with a few things.

What you need to look out for when securing a machine against attack from=

the network:

    a) processes with network listeners: if there's nothing listening
       at a particular network port, you can't be attacked through it.
       Use sockstat(1) to see what programs are listening on your network=

       interfaces -- including the loopback interface.  Do you really
       need to run that program?  Can you reconfigure something that list=
ens
       on all interfaces to bind to just the loopback interface?

    b) When considering processes that you have to run to provide the
       intended service -- are they configured to run as securely as
       possible?  Long-lived daemon processes, such as Apache should not
       be run as the root user[*].  Always run them under an unprivileged=

       UID that does not have a real shell (/sbin/nologin exists for that=

       purpose).  Make sure that UID cannot write to its home directory
       (setting daemon users homes to / is fine) or to any other signific=
ant
       locations -- a common mistake is to change the ownership of the
       webserver's document tree to the UID the web server runs under. =20
       Make full use of chroot(8) and jail(8) to further isolate exposed
       processes from the rest of the system.

    c) Do your homework, and keep alert to various channels where securit=
y
       information is available.  Sites like Secunia (http://secunia.com/=
),
       the VuXML project (http://www.vuxml.org/freebsd/) and not least an=
y
       mailing lists or newsgroups or fora dedicated to software you're
       running -- you should keep abreast of all such.  Understand the
       distinction between 'local' and 'remote' compromises or DoSes: it'=
s
       the remote ones you should spend energy worrying about unless you
       are providing logins on your server to untrusted users.  Keep
       installed software up to date.  The ports tree is actually really
       good at getting security related updates committed promptly.

       Similarly you should regularly update the OS itself.  Track one of=

       the -SECURITY branches, and upgrade when advisories come out. =20

    d) Abhor the use of any program which transmits sensitive information=

       across networks in plain text.  Use ssh(1) exclusively for remote =

       login access -- preferably with key based auth rather than using
       passwords.  Avoid ftp(1) for copying web content onto servers: any=
 of
       scp(1), rsync(1) [over SSH] or WebDAV over HTTPS will serve you be=
tter.
       If you have to display X programs on a remote desktop, always tunn=
el
       the X traffic through ssh(1).

    e) Configure a local packet filter -- one of pf(4), ipfw(8),ipf(8). Y=
our
       aim should be to be secure even without the firewall in place: it =
should
       be insurance rather than anything more.  Sometimes however it is t=
he only
       answer to protecting processes you have to run, but that expose th=
emselves=20
       on the net.

       Although there is one class of attack you can eliminate easily usi=
ng
       a packet filter which is hard to do otherwise: spoofing the loopba=
ck
       address.  If the machine you're protecting conforms to the 'weak r=
outing
       model' (as FreeBSD does) then it will accept a packet destined for=
 any of
       its network interfaces on any other interface irrespective of netw=
ork
       routing.  pf(4) makes preventing this really easy.  This three lin=
e
       pf.conf(5)  will prevent a lot of potential attacks against daemon=
s
       listening on the loopback address, although you'll probably want s=
omething
       a bit more comprehensive in actual use:

          scrub in
          pass all
          antispoof log quick for lo0

Keeping a server properly secured is not rocket science -- mostly it's ju=
st
common sense.  But you cannot just 'secure your server' and then forget a=
bout
it: lasting security means active maintenance.

	Cheers,

	Matthew

--=20
Dr Matthew J Seaman MA, D.Phil.                       7 Priory Courtyard
                                                      Flat 3
PGP: http://www.infracaninophile.co.uk/pgpkey         Ramsgate
                                                      Kent, CT11 9PW


--------------enig3E9FECB54ABBD8311697846D
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (FreeBSD)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFD02bL8Mjk52CukIwRA1+wAJ90wWMr0wXkiQ6KNTEMd0D8+FRifgCaA1Fz
pUgYo6w3WENFfijgN/iNDeI=
=Q1im
-----END PGP SIGNATURE-----

--------------enig3E9FECB54ABBD8311697846D--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?43D366C4.7020904>