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>