[linux-sec-uk] Patching and Patching again

Doug Winter linux-sec-uk at mailman.lug.org.uk
Wed Sep 17 11:13:06 2003


--HWvPVVuAAfuRc6SZ
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Wed 17 Sep Vitor Ventura wrote:
>   This is impressive, every time a new bug appears, there we go again,
> patching and patching, rushing things that might go wrong (and usualy do =
).
> What about tcpwrappers, source control, firewalls ? Do we really need to
> have ssh,ftp,etc open to every body?

Of course not.

>   Of course we shouldn't be to confident on these tools, but that should
> give us enought time to think about the patching strategy, instead of just
> blindly pathing everything. With my experience I have seem many of my
> clients, with all this put into practice but internaly they don't protect
> their servers, so they are infected by virus any way. Shouldn't this be t=
he
> time to change the paradigm? Shoulnd't we think in a diferente way of
> implementing secure systems whithout the rushing?

Sure - defence in depth is obviously the most secure strategy.  However,
security is only one part of the economic tradeoffs we have to make.
Increasing security often increases complexity.  Increasing complexity
increases the brittleness of systems in response to change, and
increases the chances of pilot error.

Most real-world loss of service is a result of cock-up, not malicious
attack, and so designing systems that reduce the chance of cock-up is
also very important.

There are some services, like ssh and console access, that you
absolutely require for emergency access - in our shop we restrict ssh
access only to networks that we know operators use.  But this doesn't
mean you shouldn't patch those ssh servers - the networks our operators
are on could be compromised after all.

Patching is never going to be the answer - there is no way everyone can
keep up with all the patching, and I'd doubt whether it's a good
strategy in production systems.  Patches are often not backported, and
in real world production sites you often run old software, since you're
not going to replace working systems just for the joy of running the
latest version.

Also, clearly, patches don't exist for unknown problems, whereas a good
security strategy, limiting access where it can be sensibly controlled
without impacting operations overmuch, can mitigate even unknown flaws
and security holes.

If your systems are well designed, there are probably very few services
you need to panic about patching - but ssh is almost certainly one of
them.

Doug.

--=20
6973E2CF print 2C95 66AD 1596 37D2 41FC  609F 76C0 A4EC 6973 E2CF
"If you are the type of person who likes assault weapons, there
is a place for you - the United States Army. We have them."
   -- General Wesley Clark, responding to a question on gun control


--HWvPVVuAAfuRc6SZ
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE/aDOrdsCk7Glz4s8RAiPeAJ43tiXmjBr59sU3gUznh7EBhjc+bACfXuTh
TniHg5xuP68XSdKlfQfB6Js=
=wdAq
-----END PGP SIGNATURE-----

--HWvPVVuAAfuRc6SZ--