On Feb 8, 2:53am, Henry Katz wrote:
> Subject: Two security issues
> Dear Firewalls readers,
>
> I am absolutely astounded that not a peep has been heard on this group
> since the CERT advisory last Thursday re widespread internet breakins.
> Today's WSJ said UCB, Texas and other sites were attacked probably from
> PA and Phoenix. Any comments?
>
> I also noted today, as I am currently involved in database administration,
> that the sybase user passwords are easily grep'd out of the master.dat
> files. Did I miss something here? This isn't strictly firewall related and I
> shall cross-post to security groups.
Actually, if you are running a reasonably well-constructed firewall
system along the design of SEAL or the TIS toolkit, and are pathologically
paranoid by not having any logins to the firewall machines, then the attack
described in the CERT advisory is one of those "oh yeah, I remember those
days of harvesting userids and passwords...".
One thing that never ceases to amaze me (and I am no expert, but just someone
that has been around all sorts of dp shops from broadcasting to the army
to an r&d environment) is that in order for vandals to succeed, you have
to have the assistance (unwitting, mind you) of the systems admin whose
machine is the target, the software producers that write buggy code, and
users who value convenience more than safety.
As an admin, I can't forsee EVERY possible attack on EVERY possible port
exposed to the outside world. But, I can limit the number of ports that
I will let you talk to, limit the protocols that I allow my machines to
understand, log, log, log _anything_ that my firewall does (in both
directions), and force validation and strict connection rules for the
limited subset of facilities that I do somehow let through.
This accomplishes two things:
1) By limiting the services allowed through, I limit my exposure to a
finite set of applications. Having the source code for the application
daemons, I can then go through them with a fine comb to remove all the
lousy parts and run very simple, very controllable gateways that only
allow strict compliance with the protocol usage in the manner _I_
specify.
2) Grokking the logs regularly, looking for the anomalies, overdriving
processes, and authorization failures, repeated accesses, and the like.
Network (and systems) security is not a reactive process if you want to
be safe. It is an iterative, proactive (in the true sense of the word...)
daily application of _all_ of your sysadm skills. Sometimes it is
playing the heavy and shutting down an internal user, other times it is
compoisng messages to domain admins complete with log output to find out
why someone in their namespace ran finger against you continually for
an hour.
But, if you don't have a mechanism in place that will tell you this, and
you are as open as the front door to Macy's on a Saturday afternoon, then
an attack such as the CERT advisory will certainly get your attention in
more than a cursory manner. But, if you are aware of what attacks can
be mounted in the TCP/IP world, and the known techniques for doing so,
then understanding just what the CERT put out will become almost a
read-and-toss (after a look through the logs...) event.
You can certainly sleep easier, IMHO. But that doesn't mean that I ignore
it. I read, I learn, and I apply the lesson.
Just my (somewhat windy...) $.02
Comments welcome, flames to /dev/null.
--
Bryan D. Boyle |Physical: ER&E, Rt. 22, Clinton, NJ 08801
#include <disclaimer> |Logical: Cogito sum, ergo sum, cogito.
(908) 730-3338 |Virtual: bdboyle @
erenj .
com
"Friends don't let friends run Windows..." -Me
References:
|
|
