Merit Network
Can't find what you're looking for? Search the Mail Archives.
  About Merit   Services   Network   Resources & Support   Network Research   News   Events   Home

Discussion Communities: Merit Network Email List Archives

North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

snmp-forum

  • From: Sue Joiner
  • Date: Thu Feb 14 14:37:18 2002

Forwarded for Ian Finlay by owner-nanog.  Sorry for the slow turn
around, I was flying back from Miami yesterday.

  -sue

Sue Joiner
Merit Network
owner-nanog@merit.edu

XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

Date: Wed, 13 Feb 2002 12:56:11 -0500 (EST)
From: Ian Finlay <iaf@cert.org>
X-X-Sender: iaf@watson.blue.cert.org
To: nanog@merit.edu
Cc: cert@cert.org
Subject: snmp-forum
Message-ID:
<Pine.LNX.4.44.0202131253250.8143-100000@watson.blue.cert.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-nanog@merit.edu


-----BEGIN PGP SIGNED MESSAGE-----


As you may already know, the CERT/CC has set up a forum where
administrators can share ideas and techniques that can be used to
develop proper defenses. We have essentially created an unmoderated
mailing list for system and network administrators to discuss helpful
techniques and tools. You can subscribe to the mailing list by sending
an email message to majordomo@cert.org. In the body of the message,
type

subscribe snmp-forum

After you receive the confirmation message, follow the instructions in
the message to complete the subscription process.

This information was included in the Advisory we sent out yesterday
(http://www.cert.org/advisories/CA-2002-03.html). Since that time,
~525 people have subscribed and the list continues to grow. I have
included a digest of what has transpired on the list so far for your
convenience.

Because of the expertise that exists within the NANOG community, we'd
love to have you folks participate (some of you are already).

Thanks,
Ian

Ian A. Finlay
CERT (R) Coordination Center
Software Engineering Institute
Carnegie Mellon University
Pittsburgh, PA  USA  15213-3890




- ----------- Forwarded Message ----------
Date: Wednesday, February 13, 2002 12:33 PM -0500
From: Joshua Wright <jwright@jwu.edu>
To: "'snmp-forum@cert.org'" <snmp-forum@cert.org>
Subject: RE: Bypassing Cisco ACL's for SNMP

<me backpedaling>

Reading Cisco's advisory another few times, it seems the configuration
in
question that will bypass ACLs goes like this:

access-list 1 permit host X.X.X.X
access-list 1 deny any log
snmp-server community blah rw 1
snmp-server host X.X.X.X blah

When setting the trap host for SNMP with the same community string,
access
to the SNMP will be permitted with no access to the MIB (bypassing the
ACL).
This is because of the order the configuration commands are kept in the
configuration file, the "snmp-server host" command happens _after_ the
"snmp-server community" command.  According to the Cisco advisory, even
without access the MIB, the PROTOS tool has the ability to DoS the
router.

You can configure the router in this fashion:

access-list 1 permit host X.X.X.X
access-list 1 deny any log
snmp-server host X.X.X.X blah
snmp-server community blah rw 1

And your ACL will be applied, but a reboot will revert to the same order
as
described above.

Best to use different community strings for GET/SET and traps.  Better
yet,
use a different pair of community string for each router you control.
Better still, filter UDP/161 and UDP/162 at your edge, then apply the
steps
described in the Cisco advisory.

</me backpedaling>

The question remains however - why does IOS accept SNMP GET/SET PDUs on
a
community string defined for traps, even without access to the MIB?  Why
not
just reject these packets as if we didn't have "snmp-server community
string" defined?  I consider this a separate bug aside from the PROTOS
exploit.


- - -Joshua Wright
Team Leader, Networks and Systems
Johnson & Wales University
Joshua.Wright@jwu.edu 

pgpkey: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xD44B4A73
fingerprint: FDA5 12FC F391 3740 E0AE BDB6 8FE2 FC0A D44B 4A73



- - -----Original Message-----
From: snmp-forum@cert.dfn.de [mailto:snmp-forum@cert.dfn.de]
Sent: Wednesday, February 13, 2002 9:01 AM
To: snmp-forum@cert.org
Subject: Bypassing Cisco ACL's for SNMP


- - -----BEGIN PGP SIGNED MESSAGE-----

Joshua Wright writes:
> Trying to confirm or deny posting on securitydatabase.net that indicates
"If
> there is a snmp-communitystring defined with an ACL on it and a
'snmp-server
> host' is configured with the same community-string, then a packet could be
> send to the router/switch, that ignores all ACL's on the device".  The
> posting is possibly suspect to misinterpretation of the CERT advisory, but
> otherwise scary if confirmed.

Not really. This is basically a configuration error. 

Imagine the following configuration:

	access-list 1 permit host X.X.X.X
	access-list 1 deny any
	snmp-server community blah rw 1
	snmp-server community blah rw

So what the 3rd line says is: Allow SNMP PDUs but only from ip address
X.X.X.X (depending on the definition of access-list 1) and only when
the community is equal to "blah".

Then the 4th line says: Allow all SNMP PDUs as long as the community
string is equal to "blah".

What we really have are two conflicting statements and the cisco
device just obeys the last order given. These are only to options of
the same statement, none of them is "superior" to the other.

Really, this is IMHO just a plain dumb way to configure SNMP on
ciscos.

> Certainly, UDP ACL's can be bypassed easily through spoofing the
> source address of the packet, but this requires knowledge of the
> permit statements in the ACL as well as the community string for
> access.

The only safe way, as long as fixed IOS versions are not widely
deployed, is to have a seperate management VPN (with IPSec on it) or
to manage the routers only through SSH. Both may not be present on
some devices.

Of course, the canonical way would be to ditch SNMPv1 and switch to
SNMPv3 with signing and encryption turned on. But that is diffucult,
because

a) SNMPv2 and SNMPv3 are not supported by most SNMP manager software.
b) I'm not sure about the performance impact on the managers side when 
   dealing with a lot of devices.
c) I'm not sure about the performance impact on the agents side when 
   dealing with a lot of requests in a short time.

Regards,
		Klaus Moeller, DFN-CERT

- - - -- 
Klaus Moeller          |                      mailto:moeller@cert.dfn.de
DFN-CERT GmbH          |            http://www.cert.dfn.de/team/moeller/
Oberstrasse 14b        |                        Phone: +49(40)808077-555
D-20144 Hamburg        |                          FAX: +49(40)808077-556
Germany	               |         PGP-Key: finger moeller@ftp.cert.dfn.de

- - -----BEGIN PGP SIGNATURE-----
Version: 2.6.2i
Comment: Processed by Mailcrypt 3.5.5, an Emacs/PGP interface

iQEVAwUBPGpxbYrEggYLt8j5AQFYIAf5AcIIsrEUGSraka5ZmG9cwhJtxzAq3T8e
CTa2YnqrGhBDWdn68NG4ivqJJqweQ5FraK/0WlWBKXwjmrd5oWFP5AHt0L0MhaBL
8tC45njL6sVlG7d8gb1+/Z/3VmsbBOX9c3++veuDCuHuaq2071sraWFQuxglPIng
TAEc+jAHBo+UAj9Zs8GXA1HJs3DWrOg9tO9u9aHtesXh8Mcj78jH9ycafszIzGU7
0s/N0CBXWtiUeZ/qLx0YzcmGj4KHfuXMjmh4rQlsG5pD70PEkCwBtp5v361pCjky
NyK2MeW2uUs2WZLKNSGUGau7VtZT0ZugS4R9rwcZe/oCA58bCielLw==
=zFlB
- - -----END PGP SIGNATURE-----

- - ---------- End Forwarded Message ----------



- - ---------- Forwarded Message ----------
Date: Wednesday, February 13, 2002 12:16 PM -0500
From: Joshua Wright <jwright@jwu.edu>
To: snmp-forum@cert.org
Subject: RE: Cisco SNMP Recommendations? 

This is good practice, but does not protect you from the Cisco
"surprise"
community strings (cable-docsis, ILMI) that have been uncovered in IOS.
Surely, others exist.

Best to block SNMP at your firewall or border router before it enters
your
network.  Also apply the controls you have documented below for a
multi-tiered approach.

Also, I am a fan of adding "access-list 10 deny any log" to ACL's to
gather
some logging information.  This makes numbered access-lists difficult to
maintain when adding additional hosts to be permitted because you have
to
perform a "no access-list 10" and recreate the entire ACL to add another
permitted host/network.

My 2 cents.

- - -Joshua Wright
Team Leader, Networks and Systems
Johnson & Wales University
Joshua.Wright@jwu.edu 

pgpkey: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xD44B4A73
fingerprint: FDA5 12FC F391 3740 E0AE BDB6 8FE2 FC0A D44B 4A73



- - -----Original Message-----
From: Ryan J Standish [mailto:rjs9@lurch.cit.buffalo.edu]
Sent: Wednesday, February 13, 2002 11:50 AM
To: Jim Duncan
Cc: Robert.Osantowski@infoUSA.com; snmp-forum@cert.org
Subject: Re: Cisco SNMP Recommendations? 


Any opinions/ideas?

If protecting the router itself is the only concern, does the following
acls offer any less protection than applying an explicit acl to an
interface instead of just to the snmp-server config?  Is the rtr still
vulnerable to an snmp DOS attack?

access-list 10 remark -- SNMP Read Access --
access-list 10 permit 192.168.100.0 0.0.0.255

access-list 11 remark -- SNMP Write and Telnet Access --
access-list 11 permit 192.168.100.0 0.0.0.255

snmp-server community foobar RO 10
snmp-server community foobar2 RW 11


- - ---------- End Forwarded Message ----------



- - ---------- Forwarded Message ----------
Date: Wednesday, February 13, 2002 12:16 PM -0500
From: Jim Duncan <jnduncan@cisco.com>
To: snmp-forum@cert.org
Subject: port 1993 is a shill

Folks, I can't find the previous message, but earlier today someone in
this forum asked about filtering port 1993 in regard to the current SNMP
vulnerabilities.

We don't use port 1993, tcp or udp, in any Cisco products.  There is no
reason to call special attention to it.

Port 1993 is an artifact from a moribund project many years ago that
provided network management over TCP using a system based on SNMP.  I
believe the effort predates any 11.0 releases of IOS.  I could find no
11.x or 12.x releases that provided services for port 1993, tcp or udp. 

Filtering unnecessary ports and turning off unneeded services is always
a good idea, but there is nothing especially important about 1993.  We
have mentioned this in our advisory and ask that unless you have
specific reasons to include it, please remove it from your
own notices.  It generates a lot of unnecessary calls and messages.

If you _do_ have a good reason to mention it, please let us know. :-)

Thanks.

	Jim



==
Jim Duncan, Product Security Incident Manager, Cisco Systems, Inc.
http://www.cisco.com/warp/public/707/sec_incident_response.shtml
E-mail: jnduncan@cisco.com  Phone(Direct/FAX): +1 919 392 6209



- - ---------- End Forwarded Message ----------



- - ---------- Forwarded Message ----------
Date: Wednesday, February 13, 2002 12:10 PM -0500
From: Joshua Wright <jwright@jwu.edu>
To: "'snmp-forum@cert.org'" <snmp-forum@cert.org>
Subject: RE: Cisco SNMP Recommendations? 

I would modify your ACL slightly to add logging information for attempts
to
access SNMP resources:

ip access-list extended example1
 deny udp any any eq snmp log-input
 deny udp any any eq snmptrap log-input
 permit ip any any

If you are not already, start logging to a syslog server as well:

logging facility local0
logging trap debug
logging 1.1.1.1

On your Unix box, something like

$ echo "local0.debug	    /var/log/routerlogs.log" >>/etc/syslog.conf
$ kill -HUP pid_of_syslogd

They you will have some logging information regarding whether you have
broken something legitimate, or if someone is trying to access SNMP
illegitimately.  You can also check out "sh logging" if you are "logging
buffered nnn".

SANS also recommended blocking UDP/1993, but only if your IOS was born
in
the stone ages (e.g. <11.0).  If your IOS is <11.0 you have other issues
to
worry about. :)

- - -Joshua Wright
Team Leader, Networks and Systems
Johnson & Wales University
Joshua.Wright@jwu.edu 

pgpkey: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xD44B4A73
fingerprint: FDA5 12FC F391 3740 E0AE BDB6 8FE2 FC0A D44B 4A73



- - -----Original Message-----
From: Jim Duncan [mailto:jnduncan@cisco.com]
Sent: Wednesday, February 13, 2002 11:29 AM
To: Robert.Osantowski@infoUSA.com
Cc: snmp-forum@cert.org
Subject: Re: Cisco SNMP Recommendations? 


Robert Osantowski writes:
> Could anyone offer their suggestions for blocking SNMP requests at a
network
> boundary on a Cisco Router?
> 
> I could place an ACL on the inbound Internet interface and do something
like
> I've shown below, but I'm wondering if there is a better way?
> 
>	Interface Serial0/0
>	  ip access-group example1 in
> 
>	ip access-list extended example1
>	 deny udp any any eq snmp
>	  deny udp any any eq snmptrap
>	   permit ip any any
> 
> Any feedback would be appreciated.  Thanks.

Rob, this is the same thing we recommend in our advisory,
http://www.cisco.com/warp/public/707/cisco-malformed-snmp-msgs-pub.shtml

	Jim




==
Jim Duncan, Product Security Incident Manager, Cisco Systems, Inc.
http://www.cisco.com/warp/public/707/sec_incident_response.shtml
E-mail: jnduncan@cisco.com  Phone(Direct/FAX): +1 919 392 6209


- - ---------- End Forwarded Message ----------



- - ---------- Forwarded Message ----------
Date: Wednesday, February 13, 2002 11:49 AM -0500
From: Ryan J Standish <rjs9@lurch.cit.buffalo.edu>
To: Jim Duncan <jnduncan@cisco.com>
Subject: Re: Cisco SNMP Recommendations? 

Any opinions/ideas?

If protecting the router itself is the only concern, does the following
acls offer any less protection than applying an explicit acl to an
interface instead of just to the snmp-server config?  Is the rtr still
vulnerable to an snmp DOS attack?

access-list 10 remark -- SNMP Read Access --
access-list 10 permit 192.168.100.0 0.0.0.255

access-list 11 remark -- SNMP Write and Telnet Access --
access-list 11 permit 192.168.100.0 0.0.0.255

snmp-server community foobar RO 10
snmp-server community foobar2 RW 11



- - ---------- End Forwarded Message ----------



- - ---------- Forwarded Message ----------
Date: Wednesday, February 13, 2002 11:28 AM -0500
From: Jim Duncan <jnduncan@cisco.com>
To: Robert.Osantowski@infoUSA.com
Subject: Re: Cisco SNMP Recommendations? 

Robert Osantowski writes:
> Could anyone offer their suggestions for blocking SNMP requests at a
network > boundary on a Cisco Router?
> 
> I could place an ACL on the inbound Internet interface and do something
like > I've shown below, but I'm wondering if there is a better way?
> 
>	Interface Serial0/0
>	  ip access-group example1 in
> 
>	ip access-list extended example1
>	 deny udp any any eq snmp
>	  deny udp any any eq snmptrap
>	   permit ip any any
> 
> Any feedback would be appreciated.  Thanks.

Rob, this is the same thing we recommend in our advisory,
http://www.cisco.com/warp/public/707/cisco-malformed-snmp-msgs-pub.shtml

	Jim




==
Jim Duncan, Product Security Incident Manager, Cisco Systems, Inc.
http://www.cisco.com/warp/public/707/sec_incident_response.shtml
E-mail: jnduncan@cisco.com  Phone(Direct/FAX): +1 919 392 6209



- - ---------- End Forwarded Message ----------



- - ---------- Forwarded Message ----------
Date: Wednesday, February 13, 2002 10:22 AM -0600
From: Robert.Osantowski@infoUSA.com
To: snmp-forum@cert.org
Subject: Cisco SNMP Recommendations?



Could anyone offer their suggestions for blocking SNMP requests at a
network boundary on a Cisco Router? 

I could place an ACL on the inbound Internet interface and do something
like I've shown below, but I'm wondering if there is a better way? 

        Interface Serial0/0 
          ip access-group example1 in 

        ip access-list extended example1 
         deny udp any any eq snmp 
         deny udp any any eq snmptrap 
         permit ip any any 

Any feedback would be appreciated.  Thanks. 

- - -Rob Osantowski 

- - ---------- End Forwarded Message ----------



- - ---------- Forwarded Message ----------
Date: Wednesday, February 13, 2002 4:30 PM +0100
From: snmp-forum@cert.dfn.de
To: snmp-forum@cert.org
Subject: Bypassing ACL's to DoS Cisco routers through OOB SNMP GET's

Joshua Wright writes:
> And goes on to mention that the PROTOS tool may be able to DoS a router
that > has no access to the MIB through the use of the community string
used to > SEND trap information.

As far as I understand this: As long as the SNMP Server is enabled
(although no communities are defined), the cisco does evaluate SNMP
PDUs. If the error is triggered *before* the community string is
evaluated (for example, when evaluating the structure of the PDU or
the version number), the "protection" from the community string is
bypassed.

> I do not understand what extra protection is gained from having a
different > community string for access to the MIB and for sending SNMP
traps.  I > believe this is a good common practice, and using ACL's to
control access to > the router is an otherwise good idea as well. 
Unless
someone is sniffing > the segment that the SNMPv1 messages are sent out
on,
what is the ultimate > risk of having the community string the same for
MIB
access and for traps? > Has the PROTOS tool uncovered a spot in the MIB
where the community string > is kept?

This only works, if the traps take a different way from the router to
the manager than the requests take from the manager to the router. If, 
in this case, the community in the trap PDU is the same as for request 
PDUs, the cisco would be compromised.

Second: Traps may be triggered from the outside, even if the attacker
has no way to access the device through the "management channel". So,
the attacker could trigger and sniff a trap anytime he/she wants,
while requests from the manager may be send only a few times a day.

But I agree on the basic point, it's pretty useless if the attacker
can sniff both traps and requests.

Regards,
		Klaus Moeller, DFN-CERT

- - -- 
Klaus Moeller          |                      mailto:moeller@cert.dfn.de
DFN-CERT GmbH          |            http://www.cert.dfn.de/team/moeller/
Oberstrasse 14b        |                        Phone: +49(40)808077-555
D-20144 Hamburg        |                          FAX: +49(40)808077-556
Germany	               |         PGP-Key: finger moeller@ftp.cert.dfn.de

- - ---------- End Forwarded Message ----------



- - ---------- Forwarded Message ----------
Date: Wednesday, February 13, 2002 3:00 PM +0100
From: snmp-forum@cert.dfn.de
To: snmp-forum@cert.org
Subject: Bypassing Cisco ACL's for SNMP

- - -----BEGIN PGP SIGNED MESSAGE-----

Joshua Wright writes:
> Trying to confirm or deny posting on securitydatabase.net that indicates
"If > there is a snmp-communitystring defined with an ACL on it and a
'snmp-server > host' is configured with the same community-string, then
a
packet could be > send to the router/switch, that ignores all ACL's on
the
device".  The > posting is possibly suspect to misinterpretation of the
CERT advisory, but > otherwise scary if confirmed.

Not really. This is basically a configuration error. 

Imagine the following configuration:

	access-list 1 permit host X.X.X.X
	access-list 1 deny any
	snmp-server community blah rw 1
	snmp-server community blah rw

So what the 3rd line says is: Allow SNMP PDUs but only from ip address
X.X.X.X (depending on the definition of access-list 1) and only when
the community is equal to "blah".

Then the 4th line says: Allow all SNMP PDUs as long as the community
string is equal to "blah".

What we really have are two conflicting statements and the cisco
device just obeys the last order given. These are only to options of
the same statement, none of them is "superior" to the other.

Really, this is IMHO just a plain dumb way to configure SNMP on
ciscos.

> Certainly, UDP ACL's can be bypassed easily through spoofing the
> source address of the packet, but this requires knowledge of the
> permit statements in the ACL as well as the community string for
> access.

The only safe way, as long as fixed IOS versions are not widely
deployed, is to have a seperate management VPN (with IPSec on it) or
to manage the routers only through SSH. Both may not be present on
some devices.

Of course, the canonical way would be to ditch SNMPv1 and switch to
SNMPv3 with signing and encryption turned on. But that is diffucult,
because

a) SNMPv2 and SNMPv3 are not supported by most SNMP manager software.
b) I'm not sure about the performance impact on the managers side when 
   dealing with a lot of devices.
c) I'm not sure about the performance impact on the agents side when 
   dealing with a lot of requests in a short time.

Regards,
		Klaus Moeller, DFN-CERT

- - - -- 
Klaus Moeller          |                      mailto:moeller@cert.dfn.de
DFN-CERT GmbH          |            http://www.cert.dfn.de/team/moeller/
Oberstrasse 14b        |                        Phone: +49(40)808077-555
D-20144 Hamburg        |                          FAX: +49(40)808077-556
Germany	               |         PGP-Key: finger moeller@ftp.cert.dfn.de

- - -----BEGIN PGP SIGNATURE-----
Version: 2.6.2i
Comment: Processed by Mailcrypt 3.5.5, an Emacs/PGP interface

iQEVAwUBPGpxbYrEggYLt8j5AQFYIAf5AcIIsrEUGSraka5ZmG9cwhJtxzAq3T8e
CTa2YnqrGhBDWdn68NG4ivqJJqweQ5FraK/0WlWBKXwjmrd5oWFP5AHt0L0MhaBL
8tC45njL6sVlG7d8gb1+/Z/3VmsbBOX9c3++veuDCuHuaq2071sraWFQuxglPIng
TAEc+jAHBo+UAj9Zs8GXA1HJs3DWrOg9tO9u9aHtesXh8Mcj78jH9ycafszIzGU7
0s/N0CBXWtiUeZ/qLx0YzcmGj4KHfuXMjmh4rQlsG5pD70PEkCwBtp5v361pCjky
NyK2MeW2uUs2WZLKNSGUGau7VtZT0ZugS4R9rwcZe/oCA58bCielLw==
=zFlB
- - -----END PGP SIGNATURE-----

- - ---------- End Forwarded Message ----------



- - ---------- Forwarded Message ----------
Date: Wednesday, February 13, 2002 8:16 AM -0500
From: Joshua Wright <jwright@jwu.edu>
To: "'snmp-forum@cert.org'" <snmp-forum@cert.org>
Subject: Bypassing Cisco ACL's for SNMP

Trying to confirm or deny posting on securitydatabase.net that indicates
"If
there is a snmp-communitystring defined with an ACL on it and a
'snmp-server
host' is configured with the same community-string, then a packet could
be
send to the router/switch, that ignores all ACL's on the device".  The
posting is possibly suspect to misinterpretation of the CERT advisory,
but
otherwise scary if confirmed.

Certainly, UDP ACL's can be bypassed easily through spoofing the source
address of the packet, but this requires knowledge of the permit
statements
in the ACL as well as the community string for access.

Can anyone provide any additional information regarding this claim? 
Cisco
did not provide any indication in their security advisory that this is
true.

Thanks.

- - -Joshua Wright
Team Leader, Networks and Systems
Johnson & Wales University
Joshua.Wright@jwu.edu 

pgpkey: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xD44B4A73
fingerprint: FDA5 12FC F391 3740 E0AE BDB6 8FE2 FC0A D44B 4A73



- - ---------- End Forwarded Message ----------



- - ---------- Forwarded Message ----------
Date: Wednesday, February 13, 2002 7:56 AM -0500
From: Joshua Wright <jwright@jwu.edu>
To: "'snmp-forum@cert.org'" <snmp-forum@cert.org>
Subject: Bypassing ACL's to DoS Cisco routers through OOB SNMP GET's

Cisco has posted a security advisory regarding malformed SNMP
message-handling vulnerabilities at
http://www.cisco.com/warp/public/707/cisco-malformed-snmp-msgs-pub.shtml.
In their advisory, Cisco identifies a workaround that involves using an
ACL
to control access to the SNMP MIB on the router.

The advisory continues with a caveat that mentions:

"If community strings are also configured for notifications, they must
be
different than the community strings used for requests in order for this
workaround to be effective."

And goes on to mention that the PROTOS tool may be able to DoS a router
that
has no access to the MIB through the use of the community string used to
SEND trap information.

I do not understand what extra protection is gained from having a
different
community string for access to the MIB and for sending SNMP traps.  I
believe this is a good common practice, and using ACL's to control
access to
the router is an otherwise good idea as well.  Unless someone is
sniffing
the segment that the SNMPv1 messages are sent out on, what is the
ultimate
risk of having the community string the same for MIB access and for
traps?
Has the PROTOS tool uncovered a spot in the MIB where the community
string
is kept?

Any other comments on the functionality of the PROTOS tool are welcome
as
well.

Thanks.

- - -Joshua Wright
Team Leader, Networks and Systems
Johnson & Wales University
Joshua.Wright@jwu.edu 

pgpkey: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xD44B4A73
fingerprint: FDA5 12FC F391 3740 E0AE BDB6 8FE2 FC0A D44B 4A73



- - ---------- End Forwarded Message ----------



- - ---------- Forwarded Message ----------
Date: Wednesday, February 13, 2002 3:16 AM -0800
From: Noah Leaman <nleaman@apple.com>
To: SNMP-Forum <snmp-forum@cert.org>
Subject: HP OpenView and the SNMP problems

How about people using HP OpenView products (e.g. Network Node
Manager)...
any tips to help secure oneself from this SNMP issue?

- - --
Noah


- - ---------- End Forwarded Message ----------



- - ---------- Forwarded Message ----------
Date: Wednesday, February 13, 2002 10:50 AM +0000
From: "Clay, James" <James.Clay@bskyb.com>
To: "'snmp-forum@cert.org'" <snmp-forum@cert.org>
Subject: HPUX and the SNMP problems

Hello,

Has anyone got any more details/experience with the SNMP problem for
MC/ServiceGuard and EMS for HPUX?       

Thanks,

Jim


**********************************************************************
Information in this email is confidential and may be privileged. 
It is intended for the addressee only. If you have received it in error,
please notify the sender immediately and delete it from your system. 
You should not otherwise copy it, retransmit it or use or disclose its
contents to anyone. 
Thank you for your co-operation.
**********************************************************************


- - ---------- End Forwarded Message ----------



- - ---------- Forwarded Message ----------
Date: Wednesday, February 13, 2002 11:11 AM +0100
From: Livens Wim <WLivens@colt-telecom.be>
To: "'snmp-forum@cert.org'" <snmp-forum@cert.org>
Subject: nmap scan


Does anyone has a reliable way of scanning large address ranges for open
udp
snmp ports ?

I tried nmap -v -sU -p161,162,199,391,1993 but this gives false
positives if
the packets are dropped by packet filters (ACLs on routers)

The manpage seems to confirm this:

The technique is to send 0 byte
udp packets to each port on the target machine.  If
we  receive  an ICMP port unreachable message, then
the port is closed.   Otherwise  we  assume  it  is
open. 

Since an ACL just drops the packet, nmap assumes the port is open.

- - -- 
Wim Livens.

- - ---------- End Forwarded Message ----------


-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 5.0i for non-commercial use
Charset: noconv

iQCVAwUBPGqny6CVPMXQI2HJAQFWtAP+LxMWaj66sdbHADBm5tyYjsvAgxgqpu7c
SNfL8k7swFE9EAh3AgI1Pwyq9qoaUsowSsmqn0EtV5HVC4XCNzvUZiXk1RL+dZls
3dg//YQS7hxHkciXCIOcJFV50VrO6KRC8s+0KsJiif44fiSbJhCnpfhwDVFEj+Co
L8oMxGirxfw=
=WYTP
-----END PGP SIGNATURE-----




Discussion Communities


About Merit | Services | Network | Resources & Support | Network Research
News | Events | Contact | Site Map | Merit Network Home


Merit Network, Inc.