Intrusion Detection Systems mailing list archives

Previous By Date Next
Previous By Thread Next

Re: a novice question. -large networks -reply

From: blue0ne () igloo org (Jackie Chan)
Date: Sun, 26 Mar 2000 08:43:15 -0500 (EST)

Archive: http://msgs.securepoint.com/ids
FAQ: http://www.ticm.com/kb/faq/idsfaq.html
IDS: http://www-rnks.informatik.tu-cottbus.de/~sobirey/ids.html
UNSUBSCRIBE: email "unsubscribe ids" to majordomo () uow edu au
First we need a good network diagram so that we can determine choke points
and where best to place passive 'Taps'.  I'm useless unless I have a good
network diagram. :)

blue0ne

On Sun, 26 Mar 2000 Mark.Teicher () predictive com wrote:


So let's go ahead and see if a commercial IDS application can be applied 
and what ruleset should be in place with a network this large.

There are couple of questions one must ask when trying to scale to a 
network this large.

How many sensors (i.e. engines, agents, etc)
How many operator consoles?
Where would the Main Console be located?
What types of alerts should be monitored?

/mark




Jackie Chan <blue0ne () igloo org>
03/26/00 04:07 AM

 
        To:     Mark.Teicher () predictive com
        cc:     CrumrineGL () state gov, ids () uow edu au, raj2569 () yahoo com, 
Valerie.Blanchard () predictive com
        Subject:        Re: IDS: a novice question. -large networks


Agreed.


blue0ne

On Sun, 26 Mar 2000 Mark.Teicher () predictive com wrote:


OK,

Try monitoring 120 fully saturated Class 'C's, 10 Class 'B's, and 4 

Class

'A's plus a population of over 5,000 remote users using various dial-up
solutions with RADIUS, TACACS+, plus Security Dynamic Tokens, mixed
operating systems, mixed router/gateway platforms varying from Proteons,
Gator Boxes, DECBrouters, to Foundry boxes.  The network connectivity
consisted of 4 OC12s, 16 T-3s, ATM and Frame Relay.  Network protocols
went from one end of the spectrum to the other, plus some proprietary
protocols that are way past their prime.

In actuality, the network description above does exist and has been
working quite well for more than a few years.  Various commercial IDS 

and

homegrown monitoring tools have been sprinkled across the network over 

the

years and it is to the point where monitoring of the network only 

requires

two people to maintain.

The monitoring of an IDS system requires more than just visual actuity,
but requires some planning before to deployment and understanding what 

and

IDS system can or cannot do.





Jackie Chan <blue0ne () igloo org>
03/26/00 01:58 AM


        To:     Mark.Teicher () predictive com
        cc:     CrumrineGL () state gov, ids () uow edu au, raj2569 () yahoo com,
Valerie.Blanchard () predictive com
        Subject:        Re: IDS: a novice question. -reply


MArk, I agree with all you said except the point that you preseumably
missed from my last post.  I stated that teh monitoring of IDS should be
analagoud to a cop walking a beat, not the IDS itself.  The people in
charge of the IDS should gain such an intimate knowledge about the 

network

inquestion, that they are aware of the slightest modification. Obviously
the alrger the network monitored, the harder this is to become reality,
but speaking from IDS monitoring experience, I have yet to find a 

network

that can overwhelm me :)

blue0ne

On Sun, 26 Mar 2000 Mark.Teicher () predictive com wrote:


Yes, but most IDS systems do not have that check in their common
vulnerability/attack signature data files.  DG-UX is also another one

that

is not covered by itself, but lumped together with the common Sendmail
DEBUG/WIZ attack vulnerability.  HP Sendmail and DG-UX implementation 

of

Sendmail have some nuances/vulnerabilities one must manually check 

for.

There are not many saavy sys mongers out there that still remember 

those

two vendor versions of Sendmail.  Trust issue??  Sendmail does not 

have

a

switch to trust other servers, it appears that the other servers may

have

other problems as well.

DG-UX and HP Sendmail versions still exist, the last version I 

observed

was in 1997, at a large aircraft company.  The recommendation was for
Sendmail to removed from the system.  The server's purpose was not to
forward mail but to process large cad/cam drawings.  So the

recommendation

was to remove the SendMail binaries and daemons from the system, 

instead

of pointing out to the customer, they should upgrade to the latest and
greatest version of Sendmail.

This is where skills in working with an organization and understanding
each servers purpose and providing real life advice versus what the 

IDS

or

Host Scanner provides.

IDS is not analagous to a cop walking a beat, since a cop walking a 

beat

has the intelligence to make a real decision based on other factors 

than

what an IDS system may chirp about and what it is supposed to do when

the

sysadmin sets a rule set/policy.  It really is an extra set of eyes 

for

a

cop.

/m

Mark, in the case of HP Sendmail versions, or any sendmail versions 

for

that matter, you would be surprised how many of our core industries

still

utilize old platforms that dont even use sendmail, but were part of 

the

default installation, and are still vulnerable to this day.  I for one
recently found an old version of a DG-UX implementation of Sendmail 

that

I

would have thought didint exist anymore.  The funny thing was, it was

the

last ditch effort, and it made the entire server farm available to me

due

to trust issues.


This is where the security admin (if there is such a position) should
become intimate with the network in question, constantly scanning to 

see

if any new services have poped up on the network, and in an attempt to
squash any unused or vulnerable services.  The monitoring of IDS
definatley has to be anlagous to a cop walkin a beat.

blue0ne
Previous By Date Next
Previous By Thread Next

Current thread: