This is a security addition to the original slides
consisting of some email correspondence by myself and
a forwarding from SANS by Peter Benjamin.
I just wanted to put these together for a single thing I could
point people to for this topic.
I didn't mention in this that you
probably should update any intrusion detection software
and it's database/signatures.
I want to thank Peter Skye, Don Gibbs and Peter Benjamin
for various pieces of information on this page.
Dallas E. Legan 18 Feb. 2002
Due to a late night typo the below was bounced when I
(and even more when I'm in a hurry.)
originally tried cc'ing it to uuasc@uuasc.org.
Sean Knox (OCLUG) pointed out, I'm probably not clear enough about
on the firewalling point. The point is to
firewall off access from WAN (in it's most general sense-
the Internet) to LAN ports 161/162 UDP
if at all possible.
(I realize many places depend on SNMP!)
He also pointed out, the test tool from the University
cited in the CERT announcments is can itself be used
for mischief.
(Though I'm certian some 'elements' out there will want
to 'improve' on it!)
The fact that Universities operate on the 'publish or perish'
principal probably is at least partly the 'blame' for the
flurry of news/activity on this topic.
Also wanted to thank Peter Skye (of SCOUG) for a couple of the links.
------- Start of forwarded message -------
(Posting to OCLUG@OCLUG.org list and possibly some others.
Feel free to forward if you think it's of value to anyone.
Pertinent URLs:
http://www.kb.cert.org/vuls/id/854306
http://www.cert.org/advisories/CA-2002-03.html
http://news.com.com/2100-1001-835602.html
http://www.theregister.co.uk/content/4/24042.html
)
I was noticing all the posts for the mailing list tonight
while looking over the digest, so I thought I should
speak out on the SNMP CERT issue.
OCLUG was one of the few I'm on the mailing list for I
didn't give my SNMP talk to, sharing my SNMP experience
while working in Phoenix.
Apologies if anyone feels I'm insulting their intelligence
with old news or the obvious, but just felt I should
spout off my thoughts on something I know a little about.
0) The items I saw were mainly warnings about potential
problems, not of any exploits actually in use.
This may have changed by the time you read this,
maybe I missed something.
Anyway, *calmly* take appropriate action.
1) The main CERT announcement pointed out the first
line of defense on this stuff is 'the perimeter',
i.e. your firewall. If you don't have one,
get to work installing one. If you don't have all UDP
blocked from outside your local network,
add some rules to make sure ports 161 and 162 UDP are
blocked from outside access.
They mentioned some others in the announcement,
but from what I could tell you'd have to be running
some pretty exotic hardware/software for the others
to be of any significance.
To get blunt about it, leaving these open
to strangers located wherever is foolish.
2) If you can access any hardware devices via
telnet/ssh/www etc. to configure them, hunt through
and make sure any page/menus etc.
that allow setting SNMP 'community strings'
are changed away from the defaults.
These are really passwords, and all of them,
including any for 'read-only' access are sensible
passwords, not the defaults.
Change these even if you never intend to use SNMP
to configure or monitor the hardware.
(see quote below.)
Even before this latest alert, SNMP had quietly made it into
the CERT top 10 exploits according to an note in
Linux Journal a year or so ago.
3) As they pointed out, you may want to check into
alternate network to configure/monitor things.
There may be ways to deacitvate SNMP if you aren't using it -
check whatever configuration scheme you may use to see if this
can be done.
4) By all means apply any patches/updates released.
This should be the last line of defense though.
As Sun Tzu pointed out in 'The Art of War',
if you are waging war on someone only a fool
is stingy about paying for 'spies' (intelligence):
'Therefore I say: 'Know the enemy and yourself,
in a hundred battles you will never be in peril.
When you are ignorant of the enemy but know yourself,
your chances of winning or losing are equal.
If ignorant of your enemy and of yourself,
you are certain in every battle to be in peril.'
-- trans. by Brig. Gen. Samuel B. Griffith, USMC
Hopefully there's nothing new for the people on this mailing
list, and this is of help if there was.
You may now resume your normally scheduled program viewing. :-)
Regards,
Dallas E. Legan II / leganii@surfree.com / dallasii@kincyb.com
Powered by......Lynx, the Internet at hyperkinetic speed.
------- End of forwarded message -------
__________________________________________________________________________
> ------------------------------
>
> Date: Sat, 16 Feb 2002 00:27:30 -0800
> From: XXXX <XXXX@XXXXXXX.XXX>
> Subject: [OCLUG] SNMP vulnerability
>
> Can anyone clarify, is this an internal (employee) threat or does it also
If the employees are bad people, it could be. :-)
> include devices (routers, firewalls, etc.) connected to the internet?
It especially includes these. :-)
Let me ramble on some.
*Don't panic!*
SNMP, Simple Network Management Protocol is normally
used to monitor, configure and control network equipment
such as routers, switches and cable/DSL 'modems',
but can be used with just about
anything attached to your network - workstations, printers etc..
One book on the subject discusses a network connected
lawn sprinkling system.
Naturally, this normally involves things on your local
network that you/your organization is responsible for.
Go to www.rfc-editor.org and look up RFC 1213 and
browse it to get some idea of what this protocol normally is used to
monitor or control. If the devices are 'SNMP enabled',
it must support the parameters in this particular RFC.
It normally allows remote gathering of traffic data
(typically for plotting with programs like MRTG or Cricket),
activating/deactivating ports and such.
Naturally you want to have sole access to this data,
and sole control of what this capability does to your network.
Allowing a college student in the Phillipines, high school
student in Canada, or unemployed programmer in Florida
to perform various flavors of Denial of Service attacks,
reconfiguration of your networking hardware, or simple
reconnisance of traffic on your network is not cool.
People who are not using SNMP to manage their network
(maybe it is small and not really needing it, maybe
they have alternate methods such as a serial/telnet/ssh/http
interface) may be unaware that their equipment is capable
of using this protocol and what it can do. Maybe their firewall has
holes due to misconfiguration due to ignorance etc.
(usually ports 161, 162 UDP)
They may have left the default 'community strings'
(SNMP jargon for passwords) unchanged from
installation. They may not of deactivated SNMP
capabilities they are not using.
Any of these things may help some stanger on the other
side of the world become the true manager of your
network. They may help these strangers perform
DoS on your network. Certainly if someone
geographicly far away can do this, a disgruntled employee
could figure out a way to do it also. There are probably other
bad things I haven't thought of they could do.
A university spent quite a bit of effort investigating
these possible security problems for very legitimate
reasons: to try and head off these problems by
finding out what they could do first and getting the information
to hardware and software producers who could make appropriate
changes. I've seen no mention of these flaws actually being
exploited yet, but the university that researched it did
develope a tool that might be used for the purpose,
or show the way for other exploits.
This whole mess seems to have come to a head because
the university operates on the principle of
'publish or perish'. They are not being evil, immoral or illegal
in any way, they are doing what they are supposed to do.
Dig out the truth for the benefit of society.
Even if you just have some kind of broadband access to
the Internet, your 'modem' may very well have SNMP
in the firmware. I haven't tracked this very carefully
(I'm still on PPP).
To reiterate what I posted the other day,
maybe a little clearer this time:
1) Make sure your firewall blocks off access to ports
161/162 UDP from the Internet. If you have any exotic hardware or software
that was mentioned in the CERT advisory, block off their
ports also. I'm refering to local/private vrs. Internet
firewall, but if you have any internal firewalls there
maybe some blocking that can be done there too if
you don't need SNMP protocol access accross these internally.
2) Make sure all SNMP 'community strings' have been
changed from defaults to sensible passwords such as
you would use for a userid on your system.
Since people will probably not be needing to
use these passwords, you can go hog wild on using maximum
length etc. without regard to convenience.
3) If you aren't using SNMP, and there is a way to deactivate it,
do so. This might be done via a serial port/telnet/ssh/http
interface you use to configure the equipment.
The software interface may mention 'trap' settings - turn all these off
if you don't have any software that monitors for these.
These typically are similar to software 'signals' that
the device might send over the network when significant events like
powering on or off, port deacitivation, invalid password entry etc. happen.
Make sure that if you aren't using them, any IP
address your device can send these to is as near
/dev/null conceptually as possible.
Blank is good if the software allows it, whatever.
Do the same for any screens/pages that mention anything to
do with SNMP. Don't worry, just do your best guess,
it will almost certainly make things better than
doing nothing at all.
Just make sure all SNMP related features are deactivated if
you aren't using them.
4) The test mentioned in your post is certainly good to use.
Maybe overkill for a home LAN where you can access the
device's configuration interface and with new information
realize what screens that may of been enigmatic are about,
no problem. If you administer a large, sophisticated
network, the tool may save a lot of work.
If any other tools come out from reliable sources, go for it.
5) When patches, software/firmware/hardware upgrades
to deal with these flaws come out apply them ASAP.
This is very powerfull technology that I had the
good fortune to work with while I was consulting in Phoenix.
Don't be afraid or panicked by all this, just take
the appropriate measures for your situation.
I know little about routing or dns, but did learn
some about this working where they needed some
custom scripts and help installing some open source
software to use this protocol.
After you learn some about SNMP, you may want to
use it, but take appropriate safeguards doing so.
Used conciously and knowledgably, it might actually
increase the security of your network.
Some URLs of interest (again for some people):
http://www.interesting-people.org/archives/interesting-people/200202/msg001
46.html
http://www.kb.cert.org/vuls/id/854306
http://www.cert.org/advisories/CA-2002-03.html
http://news.com.com/2100-1001-835602.html
http://www.theregister.co.uk/content/4/24042.html
(Thanks to Peter Skye of SCOUG & Don Gibbs at JPL
for these.
My SNMP page used at several presentations:
http://www.lafn.org/~aw585/snmp2.html
http://www.lafn.org/~aw585/perlnotes2.html
(UUASC-LA, SCLUG LUGFest, SCOUG, SD OS/2 User, etc.)
> "Earlier this week, the National Infrastructure Protection Center (NIPC)
> issued an official Warning telling the world that 'action may be
> required to prevent the possibility of criminal exploitation by
> malicious hackers' who can exploit vulnerabilities of SNMP. Newer data
> showed that nearly every organization must take significant action to
> avoid the widespread vulnerability. However, many user organizations do
> not know which systems need to be patched or protected, because they do
> not know where SNMP is running. With the help of more than a dozen
> government and commercial and university testers and developers, SANS
> is providing a free software package that can immediately identify where
> the SNMP service is running on every system or device connected to a
> network.
>
>
> "Installation, configuration and use are straightforward, and the
> documentation is good. We've used it to scan about three fourths of
> our 70 class-C-size subnets. It is very fast, and we've found a few
> rogue printers and other devices running SNMP. It's a lot faster and
> easier than running nmap for this specific purpose."
>
> To get a copy, email snmptool@sans.org. You'll get a note back with
> data on how to get the tool. We are using this method for distribution
> so we can inform you when any updates are provided in the tool."
>
>
>
> Orange County Linux Users Group http://www.oclug.org
> To unsubscribe mailto:majordomo@oclug.org?body=unsubscribe%20oclug
>
> ------------------------------
Regards,
Dallas E. Legan II / leganii@surfree.com / dallasii@kincyb.com
Powered by......Lynx, the Internet at hyperkinetic speed.
*=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-*
Message: B0000137456.MSG # in packet :#18.
Date: Sun, 17 Feb 2002 18:00:29 -0800
From: Peter Benjamin <pete@peterbenjamin.com>
To: uuasc@uuasc.org
Subject: SNMP: Important Router Audit Tool and Benchmark Web Brie
--------------------------------------------------------------------
Return-path: <UUASC-owner@biz.compata.com>
Date: Sun, 17 Feb 2002 18:00:29 -0800
To: uuasc@uuasc.org
From: Peter Benjamin <pete@peterbenjamin.com>
Subject: SNMP: Important Router Audit Tool and Benchmark Web Briefing
Mime-Version: 1.0
Sender: owner-UUASC@uuasc.org
Reply-To: UUASC@uuasc.org
Following up on Dallas's posts regarding SNMP
I sub to the SANS mailing list and just got this today
which at the bottom talks about a testing tool for SNMP
devices, and a seminar you might like to listen to.
Pete
-------------
You are invited to a web briefing unveiling the ...
...second most important security announcement about Cisco routers (so far)
this year!
Please forward this invitation to each of your network administrators
who have responsibility for managing Cisco routers.
Date: February 20, 2002
Time: 1 PM EST (1800 UTC)
If you use Cisco Routers in your company, you won't want to miss this
briefing.
SANS and the Center for Internet Security bring you George Jones and
the Router Audit Tool and Benchmark. The Router Audit Tool checks
security settings in the configurations of your Cisco IOS routers. It
reports the problems it finds and gives each router an overall score.
It also points you to the precise methods of fixing the problems. In
other words it plays the role of a top flight router security expert.
The Benchmark is based on the US National Security Agency Router
Security Configuration Guide, and provides the basis for the "best
practice" configuration rules and defines a minimum security baseline
for all routers running IOS 11 or 12.
All who register in advance will get access to George's slides and will
receive a private password to get into the web broadcast. Time for
questions will also be included.
Go to http://sans.digisle.tv/audiocast_022002/brief.htm to register for
this special event.
PS If you haven't tried the free SNMP self-testing tool to learn which
systems may be running SNMP -- and therefore are subject to the critical
vulnerability announced this week, get a description and instructions
on downloading a copy by emailing snmptool@sans.org. It works on
Windows but tests all kinds of devices. The current version is limited
to 10,000 systems per scan.
Pete
------------------------------------------------------------------------
--General instructions-- --Administrative requests--
Post to this list, Send to Majordomo@UUASC.org, no subject needed
send to UUASC@UUASC.org Include ONLY the following in the message BODY
Last resort, send to To unsubscribe: "unsubscribe UUASC"
owner-UUASC@UUASC.org Information or help: "info UUASC" or "help"
--- EOM ---
*=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-*
Message: B0000141833.MSG # in packet :#16.
Date: Thu, 21 Feb 2002 16:07:16 -0800
From: Peter Benjamin <pete@peterbenjamin.com>
To: uuasc@UUASC.org
Subject: SNMP Patches: FWD: SANS Security Alert Consensus #007
--------------------------------------------------------------------
Return-path: <UUASC-owner@biz.compata.com>
Date: Thu, 21 Feb 2002 16:07:16 -0800
To: uuasc@UUASC.org
From: Peter Benjamin <pete@peterbenjamin.com>
Subject: SNMP Patches: FWD: SANS Security Alert Consensus #007
Mime-Version: 1.0
Sender: owner-UUASC@UUASC.org
Reply-To: UUASC@UUASC.org
The SNMP patches available are listed below by vendor name
and links to the patch page.
The full email newsletter may be viewed at
http://archives.neohapsis.com/archives/sac/2002/
and select #007
-p
----------------------
-- Security Alert Consensus --
Number 007 (02.07)
Thursday, February 21, 2002
Created for you by
Network Computing and the SANS Institute
Powered by Neohapsis
----------------------------------------------------------------------
Welcome to SANS' distribution of the Security Alert Consensus.
----------------------------------------------------------------------
** Request your FREE Internet Security Handbook **
It's more important than ever to protect your information assets, avoid
business interruption, and prevent revenue loss. Request your *FREE*
copy of "Securing the Internet Economy: An Executive Guide to Managing
Online Risk" from Internet Security Systems (ISS). Click here:
http://www.iss.net/mktg/securitysolutions3/
----------------------------------------------------------------------
Many vendors have released patches for the SNMP problem discussed last
week. The full patch list is in this issue under Cross-Platform item
{02.07.001}. If you're not signed up for the Cross-Platform category,
you can view it in the online archive at:
http://archives.neohapsis.com/archives/sac/2002/
Microsoft this week also released a critical Internet Explorer
patch, which fixes six new problems as well as all known problems to
date. It's discussed under item {02.07.013}.
...snip...
*** {02.07.001} Cross - Update {02.06.011}: Multiple vendor SNMP
problems
Many vendors have released updated SNMP packages, which fix the
vulnerability discussed in {02.06.011} ("Multiple vendor SNMP
problems").
Microsoft Windows patches:
http://archives.neohapsis.com/archives/vendor/2002-q1/0032.html
HP updates for HPUX, HP Procurve switches and HP JetDirect servers:
http://archives.neohapsis.com/archives/hp/2002-q1/0053.html
Sun patches:
http://sunsolve.sun.com/pub-cgi/show.pl?target=home
Updated Conectiva RPMs:
http://archives.neohapsis.com/archives/linux/conectiva/2002-q1/0015.html
Updated Debian DEBs:
http://archives.neohapsis.com/archives/vendor/2002-q1/0030.html
Updated Cisco firmware for various Cisco devices:
http://archives.neohapsis.com/archives/cisco/2002-q1/0003.html
http://archives.neohapsis.com/archives/cisco/2002-q1/0004.html
Updated Mandrake RPMs:
http://archives.neohapsis.com/archives/bugtraq/2002-02/0165.html
Updates for Compaq Tru64, SANWorks Management Appliance and OpenVMS:
http://archives.neohapsis.com/archives/compaq/2002-q1/0053.html
Source: Microsoft, HP, Sun Conectiva, Debian, Cisco, Mandrake, Compaq
(SF Bugtraq)
http://archives.neohapsis.com/archives/vendor/2002-q1/0032.html
http://archives.neohapsis.com/archives/hp/2002-q1/0053.html
http://sunsolve.sun.com/pub-cgi/retrieve.pl?doctype=colldoc=secbull/
215&type=0&nav=sec.sbl&ttl=sec.sbl
http://archives.neohapsis.com/archives/linux/conectiva/2002-q1/0015.html
http://archives.neohapsis.com/archives/vendor/2002-q1/0030.html
http://archives.neohapsis.com/archives/cisco/2002-q1/0003.html
http://archives.neohapsis.com/archives/cisco/2002-q1/0004.html
http://archives.neohapsis.com/archives/bugtraq/2002-02/0165.html
http://archives.neohapsis.com/archives/compaq/2002-q1/0053.html
...snip...
Pete
------------------------------------------------------------------------
--General instructions-- --Administrative requests--
Post to this list, Send to Majordomo@UUASC.org, no subject needed
send to UUASC@UUASC.org Include ONLY the following in the message BODY
Last resort, send to To unsubscribe: "unsubscribe UUASC"
owner-UUASC@UUASC.org Information or help: "info UUASC" or "help"
--- EOM ---
One method of shutting down SNMP reported to work:
Ron Golan: At the LULA meeting last night (19 Feb. 2002) Drew Beach suggested that I port forward the SNMP ports of the Airport to a non-existant IP address. It works :)