From: marvin greenlee (marvin@ccbootcamp.com)
Date: Wed Jan 19 2005 - 20:30:03 GMT-3
By default, NBAR shows sqlserver as tcp 1433.
r5#show ip nbar port-map sqlserver
port-map sqlserver tcp 1433
If your router shows differently, it is probably because you already applied
a port-map that changed it to something else.
Since the attack specifically uses UDP 1434, I would recommend using a
custom definition over redefining the existing definition for SQL traffic.
Cisco recommends matching UDP 1434 with a custom protocol in the Doc listed
below titled "SAFE SQL Slammer Worm Attack Mitigation".
SAFE SQL Slammer Worm Attack Mitigation
http://www.cisco.com/en/US/netsol/ns340/ns394/ns171/ns128/networking_solutio
ns_white_paper09186a00801cd7f5.shtml#wp43824
Cisco Security Advisory: MS SQL Worm Mitigation Recommendations
http://www.cisco.com/en/US/products/products_security_advisory09186a00801333
99.shtml
- Marvin Greenlee, CCIE#12237, CCSI# 30483
Network Learning Inc
marvin@ccbootcamp.com
www.ccbootcamp.com (Cisco Training)
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
ccie2be
Sent: Wednesday, January 19, 2005 3:06 PM
To: Group Study
Subject: nbar [bcc][faked-from]
Importance: Low
Hi guys,
This problem, from IE lab 15, task 9.1, is to filter a virus contained in
sql
traffic that is 404 bytes in length.
The official solution is this:
ip nbar port-map custom-01 udp 1434 <-- different
!
class-map match-all SQL_SLAMMER
match protocol custom-01 <-- different
match packet length min 404 max 404
!
policy-map STOP_SQL_SLAMMER
class SQL_SLAMMER
drop
!
interface Ethernet0/0
service-policy input STOP_SQL_SLAMMER
When I did the config, I did it slightly differently. I think my config
would
work just as well but I can't test this -
I don't have any Slammer worm packets hanging around.
Instead of using the commands above marked as different, I used the
following:
ip nbar port-map sqlserver udp 1434
match protocol sqlserver
I also wonder about one other thing. By default, sqlserver packets use udp
and port 1434 as seen by doing
show ip nbar port-map. Therefore the only way it seems that the infected
packets are distinquished from the
real sqlserver traffic is by packet length. If that's true, couldn't the
solution actually looked like this?
class-map match-all SQL_SLAMMER
match protocol sqlserver
match packet length min 404 max 404
where no special ip nbar port-map is needed?
Thanks, Tim
This archive was generated by hypermail 2.1.4 : Wed Feb 02 2005 - 22:10:24 GMT-3