Network monitoring/IDS rant - What's hot what's not?

[Christopher J. Wolff]

Tivoli, Openview, Unicenter, ipmonitor, mrtg, nagios?

There are many network monitoring options but each option has its
pitfalls.  I'm rapidly coming to the conclusion that any software
Computer Associates publishes is designed for the criminally insane.
However, there 'has' to be something that offers more visibility into a
major WAN than MRTG/RRDTOOL.  

Perhaps I'm on a Computer Associates rant today but can anyone share any
positive experiences with E-trust intrusion detection?  5 MB of traffic
flow paralyzes a dual P3 with gobs of ram and it still misses signatures
that Snort does not miss.  Originally I was going to blame this lousy
performance on application tuning; however, it was a CA engineer that
set this box up.

Any IDS suggestions would be greatly appreciated as well.

Regards,
Christopher J. Wolff, VP CIO
Broadband Laboratories, Inc.
http://www.bblabs.com

Re: 69.0.0.0/8 - Please update your filters

[Stephen Gill]

As a brief reminder and in addition to the URLs below folks are also
welcome to peer with the Team-Cymru's bogon route server which will
automatically and securely update your bogon filters for you.
Instructions are available at:

http://www.cymru.com/Bogons/index.html

Cheers,
-- steve
[EMAIL PROTECTED]

-Original Message-
From: Chan, KaLun 
Sent: Thursday, February 20, 2003 4:18 PM
To: Chan, KaLun; DL NOC Managers; DL NOC-IP Services
Cc: Eisenhart, William; Minter, Daniel; DL Neteng-core-ip
Subject: RE: [ARIN-20030123.943] 69.3.0.0/Covad - who had this block
before?


All,

It has recently come to our attention that many Internet routers are
still
filtering out IP addresses in the 69.0.0.0/8 range. If YOU are still
filtering this block in your router, please modify your filters
accordingly.
Thank You

IANA IPv4 Allocation List -
 
Bogon List -  
Secure IOS Template -
 
Secure BGP Template -
 
Secure BIND Template -


Sincerely,
 
Ka Lun Chan (KC)
Security Operation Center
COVAD Communication 
SOC#: 866-722-2602
Dir   #: 408-434-4919
Fax #: 408-434-2191
Easy to do Business with

AS852 - AS577 problems ?

[Mike Tancsa]

Anyone know what is up between them in Ontario, Canada ?  I am seeing 
pretty high latency and packet loss in both directions.  Dont know if its a 
chronic capacity problem or just a dead/down circuit ?

Bell's looking glass showed (prior to my prepending)

BGP routing table entry for 199.212.134.0/24, version 89013385
Paths: (2 available, best #1)
  Not advertised to any peer
  852 11647, (received & used)
206.108.96.231 (metric 2060) from 206.108.96.17 (206.108.96.17)
  Origin IGP, metric 1000, localpref 110, valid, internal, best
  Community: 577:55 577:4520 577:5602 577:10100
  Originator: 206.108.96.231, Cluster list: 206.108.96.17, 206.108.96.1
  852 11647, (received & used)
206.108.96.231 (metric 2060) from 206.108.96.18 (206.108.96.18)
  Origin IGP, metric 1000, localpref 110, valid, internal
  Community: 577:55 577:4520 577:5602 577:10100
  Originator: 206.108.96.231, Cluster list: 206.108.96.18, 206.108.96.1
Type escape sequence to abort.
Tracing the route to ns.sentex.ca (199.212.134.1)
  1 bxsmc-fe5-0-0.in.bellnexxia.net (205.207.238.210) 20 msec 204 msec 200 
msec
  2 core2-toronto63-pos11-5.in.bellnexxia.net (206.108.98.141) 0 msec 0 
msec 4 msec
  3 core4-toronto63-pos6-0.in.bellnexxia.net (64.230.242.105) 0 msec 4 
msec 0 msec
  4 core4-toronto12-pos13-0.in.bellnexxia.net (64.230.242.181) 0 msec 0 
msec 0 msec
  5 core1-toronto12-pos0-1.in.bellnexxia.net (64.230.242.198) 0 msec 0 
msec 0 msec
  6 bx5-toronto12-so-0-1-0-0.in.bellnexxia.net (64.230.242.150) 0 msec 0 
msec 0 msec
  7 toroonnlgr00.bb.telus.com (154.11.3.25) [AS 852] 176 msec 180 msec 176 
msec
  8 toroonzddr00.bb.telus.com (154.11.6.3) [AS 852] 172 msec 176 msec 176 msec
  9  *
hespler155ATM-waterloo.sentex.ca (199.212.135.77) [AS 11647] 164 msec 
172 msec
 10  *
ns.sentex.ca (199.212.134.1) [AS 11647] 160 msec *

and a traceroute from telus' route server to Bell
route-views.on>traceroute 206.108.111.125
Type escape sequence to abort.
Tracing the route to bx5-toronto12-so-0-0-1-0.in.bellnexxia.net 
(206.108.111.125)

  1 toroonxngr00.bb.telus.com (154.11.63.85) 0 msec 0 msec 0 msec
  2 toroonnlbr00.bb.telus.com (154.11.11.37) 4 msec 0 msec 0 msec
  3 toroonnlgr00.bb.telus.com (154.11.11.58) 0 msec 0 msec 0 msec
  4 bx5-toronto12-so-0-0-1-0.in.bellnexxia.net (206.108.111.125) [AS 577] 
164 msec 164 msec 164 msec
route-views.on>
route-views.on>show ip bgp 206.108.111.125
BGP routing table entry for 206.108.111.0/24, version 117710304
Paths: (2 available, best #1)
  Advertised to non peer-group peers:
198.32.162.100 198.32.162.102
  577, (aggregated by 577 206.108.96.25)
154.11.0.147 from 154.11.0.150 (154.11.0.150)
  Origin IGP, metric 0, localpref 90, valid, internal, 
atomic-aggregate, best
  Originator: 154.11.0.147, Cluster list: 154.11.0.150
  577, (aggregated by 577 206.108.96.25)
154.11.0.147 from 154.11.0.151 (154.11.0.151)
  Origin IGP, metric 0, localpref 90, valid, internal, atomic-aggregate
  Originator: 154.11.0.147, Cluster list: 154.11.0.151
route-views.on>

i.e. as soon as it hits Bell's network, there is quite a jump in latency 
and packet loss.

Some of the paths to 577 out of Telus actually go down via Sprint in 
Chicago which seems rather odd
e.g.
route-views.on>show ip bgp 198.235.69.11
BGP routing table entry for 198.235.69.0/24, version 239594939
Paths: (2 available, best #1)
  Advertised to non peer-group peers:
198.32.162.100 198.32.162.102
  1239 577
154.11.0.155 from 154.11.0.150 (154.11.0.150)
  Origin IGP, metric 100, localpref 100, valid, internal, best
  Originator: 209.115.137.204, Cluster list: 154.11.0.150
  1239 577
154.11.0.155 from 154.11.0.151 (154.11.0.151)
  Origin IGP, metric 100, localpref 100, valid, internal
  Originator: 209.115.137.204, Cluster list: 154.11.0.151
route-views.on>

Anyone know whats up ?

---Mike

Mike Tancsa,  tel +1 519 651 3400
Sentex Communications,[EMAIL PROTECTED]
Providing Internet since 1994www.sentex.net
Cambridge, Ontario Canada www.sentex.net/mike

Re: 69.0.0.0/8 - Please update your filters

[Haesu]

> If the alternative is getting space, giving it to customers, and
> explaining why they can't reach X, Y, and Z on their connection to us, but
> they can on other internet connections, we're going to at least have to
> try.

True, but we'd have to try something that would be effective... Imagine
how many of those incompetent ASN's still have _outdated_ technical
contact email and phone numbers..

>
> I like the idea of moving the gtld servers into such space.  That way, the
> networks that are at fault will break, and they'll be well motivated to
> fix their filters.

I think this is the way to go. It will break the ASN's who do not properly
have updated filters. The only thing to be careful is a type of
consequence where some of _your_ customers may attempt to get to one of
the broken ASN's. DNS issue at the broken ASN's may cause few
minor-to-medium oddities that may cause more phone calls on your end.

-hc

>
> --
>  Jon Lewis [EMAIL PROTECTED]|  I route
>  System Administrator|  therefore you are
>  Atlantic Net|
> _ http://www.lewis.org/~jlewis/pgp for PGP public key_
>
>

Re: 69.0.0.0/8 - Please update your filters

[jlewis]

On Tue, 25 Feb 2003, Haesu wrote:

> And how quickly would those ASN's respond to or even comprehend the
> bogon-filter update notices? If those ASN's are competent and
> quick-responsive ones, we should not even be having these prroblems to
> begin with.

If the alternative is getting space, giving it to customers, and 
explaining why they can't reach X, Y, and Z on their connection to us, but 
they can on other internet connections, we're going to at least have to 
try.

I like the idea of moving the gtld servers into such space.  That way, the 
networks that are at fault will break, and they'll be well motivated to 
fix their filters.  
 
--
 Jon Lewis [EMAIL PROTECTED]|  I route
 System Administrator|  therefore you are
 Atlantic Net|  
_ http://www.lewis.org/~jlewis/pgp for PGP public key_

Re: 69.0.0.0/8 - Please update your filters

[E.B. Dreger]

SS> Date: Tue, 25 Feb 2003 19:46:53 -0600
SS> From: Stephen Sprunk

(Props to whoever thought up what you put in the "To" field)


SS> From an academic standpoint, that would be a very interesting
SS> experiment.  However, most of us are paid to keep our
SS> networks or services running, not to intentionally break
SS> them.

I see.  So you advocate innocent 69/8 users suffering because you
don't want to cause pain for the lazy and inept?  I'd rather see
the latter paying for their sins, not innocent third parties.
Note that my suggestions (credit to Jeff Wheeler for suggesting
roots in new IP allocations) would break NOTHING on a properly-
maintained network.

Let's put it this way:  69/8 evidently is still being filtered by
some, despite pleading and time.  Things _will_ break.  This
won't be the last time we encounter new allocations, either.
_Someone_ will feel pain.

Who do you feel should bear the brunt?  How do you propose to
make it happen?


Eddy
--
Brotsman & Dreger, Inc. - EverQuick Internet Division
Bandwidth, consulting, e-commerce, hosting, and network building
Phone: +1 (785) 865-5885 Lawrence and [inter]national
Phone: +1 (316) 794-8922 Wichita

~
Date: Mon, 21 May 2001 11:23:58 + (GMT)
From: A Trap <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Subject: Please ignore this portion of my mail signature.

These last few lines are a trap for address-harvesting spambots.
Do NOT send mail to <[EMAIL PROTECTED]>, or you are likely to
be blocked.

Re: 69.0.0.0/8 - Please update your filters

[Haesu]

> Somebody with one of these new cursed allocations ought to setup a system
> with two IPs (one from the new block, one from an older established block)
> and do reachability tests to various parts of the net, and then automate
> sending a notice of bogus filters to those ASNs reachable from the old IP,
> but not from the new one.


And how quickly would those ASN's respond to or even comprehend the
bogon-filter update notices? If those ASN's are competent and
quick-responsive ones, we should not even be having these prroblems to
begin with.

-hc

>
> If I end up with some of this space, I'll be doing this.
>
> --
>  Jon Lewis [EMAIL PROTECTED]|  I route
>  System Administrator|  therefore you are
>  Atlantic Net|
> _ http://www.lewis.org/~jlewis/pgp for PGP public key_
>
>

Re: 69.0.0.0/8 - Please update your filters

[jlewis]

On Tue, 25 Feb 2003, Stephen Sprunk wrote:

> Thus spake "E.B. Dreger" <[EMAIL PROTECTED]>
> > I _still_ like the idea of putting DNS roots in new IP blocks
> > during sunrise and having the final octet be .0 and/or .255.  It
> > would be nice to catch dated bogon filters, lame attempts at
> > smurf stopping, _and_ stale root.cache in one blow.
> 
>  From an academic standpoint, that would be a very interesting experiment.
> However, most of us are paid to keep our networks or services running, not
> to intentionally break them.

The trouble is, some people are neglecting their jobs and making things 
rough for others (the people getting new allocations).

Somebody with one of these new cursed allocations ought to setup a system 
with two IPs (one from the new block, one from an older established block) 
and do reachability tests to various parts of the net, and then automate 
sending a notice of bogus filters to those ASNs reachable from the old IP, 
but not from the new one.

If I end up with some of this space, I'll be doing this.
 
--
 Jon Lewis [EMAIL PROTECTED]|  I route
 System Administrator|  therefore you are
 Atlantic Net|  
_ http://www.lewis.org/~jlewis/pgp for PGP public key_

Re: 69.0.0.0/8 - Please update your filters

[Stephen Sprunk]

Thus spake "E.B. Dreger" <[EMAIL PROTECTED]>
> I _still_ like the idea of putting DNS roots in new IP blocks
> during sunrise and having the final octet be .0 and/or .255.  It
> would be nice to catch dated bogon filters, lame attempts at
> smurf stopping, _and_ stale root.cache in one blow.

 From an academic standpoint, that would be a very interesting experiment.
However, most of us are paid to keep our networks or services running, not
to intentionally break them.

S

Stephen Sprunk "God does not play dice."  --Albert Einstein
CCIE #3723 "God is an inveterate gambler, and He throws the
K5SSSdice at every possible opportunity." --Stephen Hawking

Re: 69.0.0.0/8 - Please update your filters

[E.B. Dreger]

HV> Date: Tue, 25 Feb 2003 14:09:26 -0800
HV> From: "Hsu, Vicky"


HV> It has recently come to our attention that many Internet
HV> routers are still filtering out IP addresses in the
HV> 69.0.0.0/8 range. If YOU are still filtering this block in

Even after the NANOG thread months back?  Yuck.

I _still_ like the idea of putting DNS roots in new IP blocks
during sunrise and having the final octet be .0 and/or .255.  It
would be nice to catch dated bogon filters, lame attempts at
smurf stopping, _and_ stale root.cache in one blow.


Eddy
--
Brotsman & Dreger, Inc. - EverQuick Internet Division
Bandwidth, consulting, e-commerce, hosting, and network building
Phone: +1 (785) 865-5885 Lawrence and [inter]national
Phone: +1 (316) 794-8922 Wichita

~
Date: Mon, 21 May 2001 11:23:58 + (GMT)
From: A Trap <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Subject: Please ignore this portion of my mail signature.

These last few lines are a trap for address-harvesting spambots.
Do NOT send mail to <[EMAIL PROTECTED]>, or you are likely to
be blocked.

69.0.0.0/8 - Please update your filters

[Hsu, Vicky]

-Original Message-
From: Chan, KaLun 
Sent: Thursday, February 20, 2003 4:18 PM
To: Chan, KaLun; DL NOC Managers; DL NOC-IP Services
Cc: Eisenhart, William; Minter, Daniel; DL Neteng-core-ip
Subject: RE: [ARIN-20030123.943] 69.3.0.0/Covad - who had this block before?


All,

It has recently come to our attention that many Internet routers are still
filtering out IP addresses in the 69.0.0.0/8 range. If YOU are still
filtering this block in your router, please modify your filters accordingly.
Thank You

IANA IPv4 Allocation List -
 
Bogon List -  
Secure IOS Template -
 
Secure BGP Template -
 
Secure BIND Template -


Sincerely,
 
Ka Lun Chan (KC)
Security Operation Center
COVAD Communication 
SOC#: 866-722-2602
Dir   #: 408-434-4919
Fax #: 408-434-2191
Easy to do Business with

Re: untied

[Christopher L. Morrow]

On Mon, 24 Feb 2003, Ron da Silva wrote:

>
>
> Hmm...I've called one of their 800's before and had an
> option to select "3" to complain (er I mean talk to someone)

hint: if you have a 'nonstandard' computer (not windows/mac) don't mention
that or your complaint gets /dev/null'd :( experience.

> about their website.  Maybe you can reach someone who
> knows someone with a clue that way...
>
> -ron
>

[ISN] SIP weakness could expose VoIP gear to attacks

[Bram Shirani]

(forwarded from ISN)

http://www.nwfusion.com/news/2003/0224sip.html

By Phil Hochmuth
Network World Fusion
02/24/03

A glitch in some vendors' Session Initiation Protocol (SIP) software
could leave SIP-enabled devices - such as IP phones, IP PBXs and
instant messaging clients - vulnerable to denial-of-service attacks,
the CERT Coordination Center said last week.

The Oulu University Secure Programming Group (OUSPG) discovered that
when a certain SIP test suite (PROTOS c07-sip) is applied to SIP
clients devices or proxy servers, it caused "impacts ranging from
unexpected system behavior and denial of services to remote code
execution," according to the CERT warning.

The vulnerably relates to the "invite" messages SIP devices send to
each other to initiate sessions such as VoIP calls, text chat or
video.

SIP is an emerging VoIP protocol used to establish sessions among SIP
"agents," such as IP phones, softphones, text chat clients, and video
applications. Industry observers have called text-based SIP the
successor to the H.323 protocol, used widely in IP-based telephony and
videoconferencing equipment. Vendors with IP PBX and phone products
that use SIP include Alcatel, Avaya, Cisco, Mitel, Nortel, Pingtel,
Ploycom, and Siemens. Microsoft Windows Messenger - a Web telephony,
chat and video client included in Windows XP - also uses SIP.

According to CERT and Cisco's Web site, Cisco's 7940 and 7960 models
of IP phones running SIP images prior to version 4.2 are vulnerable,
as well as Cisco routers running Cisco IOS 12.2T and 12.2X. PIX
firewalls running software versions with SIP support - beginning with
version 5.2(1) and up to, but not including versions 6.2(2), 6.1(4),
6.0(4) and 5.2(9) - are also affected, Cisco says. Fixes to these
products are available from Cisco's Web site.

Microsoft says its SIP-based software is not affected by the
vulnerability.

Nortel says its Succession Communication Server 2000 and Succession
Communication Server 2000 - Compact are affected by the vulnerability
only when SIP-T has been enabled on the IP PBX products. Patches for
these products are available at Nortel's Web site.

Other vendors with SIP-based products have not posted comments on the
CERT Coordination Center Web site.

-
ISN is currently hosted by Attrition.org

Thanks for the heads-up.

[tbolling]

>> Voyager IP http://www.vger.com/products.shtml#v_ip 

>Where did you see a demo? Any idea what it costs? I just sent them an 
>email. Not much info on their web site, and their contact submission form 
>is broken. 

Sorry about the broken link, should be fixed now. Your e-mail should get 
a reply shortly if you haven't gotten one already.

Web Caches..

[Mark Segal]

I'm wondering if anybody has had RECENT experience with web caches. If so,
what is your favourites?  why? 

Two stipulations:
1) I want one that doesn't require a department to maintain a list of
uncachable objects.
2) It must support wccp.

Off list replies are welcomed.
Mark

--
Mark Segal
Director, Data Services
Futureway Communications Inc.
Tel: (905)326-1570

Re: IP Management tool for service providers

[jlewis]

On Thu, 20 Feb 2003, John Todd wrote:

> Here's one.  I haven't used it in production, but the demo that I was 
> given was pretty slick.  Works on pretty much any POSIX platform... 
> Alas, it is commercial software.
> 
> Voyager IP   http://www.vger.com/products.shtml#v_ip

Where did you see a demo?  Any idea what it costs?  I just sent them an 
email.  Not much info on their web site, and their contact submission form 
is broken.

> This was referenced on the list back in Jan of 2002:
> http://www.freeipdb.org/ http://www.globalcrossing.com

A coworker took a look at this recently.  He had some difficulty getting 
it installed properly and it lacks some features we'd require relating to 
the tracking of IP allocations in the ways ARIN demands.

> This was referenced on the list in November of 2001:
> http://www.brownkid.net/NorthStar/

I just installed this.  Installation went easily, but it doesn't seem to
actually work :)  After adding a big block of space and creating one
allocation in it, the links to create additional subnets bring up the
wrong page.  It seems very browser dependent.  i.e. with various versions
of Netscape and Mozilla on Linux, some of the pages don't work (but don't
produce any error messages).  The same pages did work in IE on Windows, at
least until the whole thing quit working.  It also lacks necessary
features and doesn't seem to be flexible enough to incorporate the
features I want without digging into the code.

The basics of what I think an IP allocation tracking system needs (at 
least for any ARIN member) are:

1) Ability to track allocations from multiple IP blocks

2) Ability to track type of assignment (i.e. assigned vs reserved)

3) Ability to track service category as required on ARIN additional 
request form.  i.e.  Dial-up|Cable|Web Hosting|Leased Line|
xDSL|Co-location|Wireless|Other-

4) Storage of customer name and contact info for each allocation

5) Storage of justification info for each assignment

6) Ability to present unallocated space in such a way that allocations can
be done efficiently.  i.e. if a /28 needs to be allocated, make it easy to
find unallocated existing /28's, rather than do unnecessary subnetting to
create a new /28.

7) Auditing.  When it's additional request time, you need to be able to 
audit your assignments and add up how much space is reserved, how 
much is assigned, how much is being used for each of the various ARIN 
defined categories, look up justifications, etc.

8) Automated swip/unswip or hooks to automate rwhois maintenance would be 
nice, but not absolutely required.

The systems I've seen so far lack multiple features from the above list.  
Is everyone just using flat files, spreadsheets, or home grown solutions?

--
 Jon Lewis [EMAIL PROTECTED]|  I route
 System Administrator|  therefore you are
 Atlantic Net|  
_ http://www.lewis.org/~jlewis/pgp for PGP public key_

Re: Symantec detected Slammer worm "hours" before

[Scott Francis]

On Mon, Feb 24, 2003 at 05:07:33PM -, [EMAIL PROTECTED] said:
[snip]
> So they meant they got IDS "hits" hours before anyone posted a full
> description of the attacks to bugtraq when they said they had detected
> the worm hours before it spread?
> That's a novel use of english :)

One typically finds little else in marketing. :)
-- 
Scott Francis || darkuncle (at) darkuncle (dot) net
  illum oportet crescere me autem minui


pgp0.pgp
Description: PGP signature