[Greg Saunders <gregs@xxxxxxxxxxxxxxx>]

Well the problem went away after powering off the wireless client.

I have double checked and bridging is NOT turned on so even thought the
notebook was wired into the switch AND wirelessly connected it should not
have been showing those MAC addresses from the wireless side of things.  Not
sure why we would still get this without even having the bridging component
installed.  If the notebook is connected wirelessly only or wired only we
don't see the MAC address problem either.

I guess there could be a problem with the software for the DLINK wireless
client, but it is strange that it is doing it.

Greg 

-----Original Message-----
From: Giles Scott [mailto:gscott@xxxxxxxxxxxxxxxxx] 
Sent: Friday, November 19, 2004 6:16 AM
To: Ethereal user support
Subject: RE: [Ethereal-users] MAC Address duplicates

Actually it's probably not the AP, it more likely to be a wireless client
doing the reflection.

You'll need to do a capture of the packets in the Air as well.

G.


-----Original Message-----
From: ethereal-users-bounces@xxxxxxxxxxxx
[mailto:ethereal-users-bounces@xxxxxxxxxxxx] On Behalf Of Giles Scott
Sent: Friday, November 19, 2004 10:44 AM
To: Ethereal user support
Subject: RE: [Ethereal-users] MAC Address duplicates

The AP should not be doing this...
I would use Ethereal to monitor the port the AP is connected to and filter
on the 'eth.src' of your servers to see what it is reflecting.

Cheers

Giles Scott
Aruba Wireless Networks

-----Original Message-----
From: ethereal-users-bounces@xxxxxxxxxxxx
[mailto:ethereal-users-bounces@xxxxxxxxxxxx] On Behalf Of Greg Saunders
Sent: Thursday, November 18, 2004 8:16 PM
To: 'Ethereal user support'
Subject: RE: [Ethereal-users] MAC Address duplicates

I have an update...

- I was able to do a telnet file capture while continuously telling the
switch to show me it's MAC address assignment.

- I then removed the junk and imported this into a SQL table where I could
query the data.

- I was then able to query it and saw the following:

- I found MAC addresses that showed up on 2 different ports within a 2 hour
period.  There were a total of 9 MAC addresses that did this.

- Out of these 9 MAC Addresses there was 1 port that was always involved and
that was a Wireless Access Point on port A2.  

- This Access Point is configured with WPA security so it should be secure.
We have turned off this device and have yet to experience the problem since.
Granted it has only been a couple of hours so we will wait until morning to
say this is resolved, BUT we at this point do NOT know why this Wireless
Access Point's etherenet interface would claim to have these various MAC
addresses.  

- I know it will show the MAC address of any units that wirelessly attach to
it.  I can watch this happen by monitoring the ports' MAC assignment and
when I attach to the wireless access point with a notebook I see the
notebooks MAC address show up in the switch on port A2 along with the
wireless access point's MAC address.

- The MAC address that we were able to capture were the ones belonging to
our various servers which we were losing connection to.

- Now the BIG question is why would this be happening???  If I have a
notebook attached to the switch and this notebook also had the wireless NIC
installed and connected to the wireless access point which is also connected
to the switch... CAN this be the problem?   If so why would my Wireless
NIC
say that it had the MAC addresses of some of the other servers?

Thanks in advance!

 

-----Original Message-----
From: Giles Scott [mailto:gscott@xxxxxxxxxxxxxxxxx]
Sent: Thursday, November 18, 2004 1:22 PM
To: Ethereal user support
Subject: RE: [Ethereal-users] SQL Slammer - How to identify

Hi,

- I am currently capturing in a text file the listing of the MAC address
assignments to the ports repetatively hoping to catch a port changing its
MAC address assignment

GS>
I've seen this in the past (a long time ago) some NIC cards can send out
packets with the wrong source MAC address (in the case I was looking at it
was the default gateway MAC) this caused all the traffic destined for the
router to go into a black hole. But only for a very short period of time, as
the switch re-learns the correct slot/port very quickly.

We called this MAC address reflection. The company I worked for at the time
had to add code so the switch could drop (and log) these packets before the
switch learned the MAC address. It was a nightmare to find.

Another way to be sure this is/not the problem is to manually add static FDB
entries to the switch for important devices, to prevent the switch learning
the device on the wrong port.

If you're interested in making sure your clients don't have Trojans etc I
would look at running Nessus (http://www.nessus.org) against all you
machines.

Cheers

Giles


-----Original Message-----
From: ethereal-users-bounces@xxxxxxxxxxxx
[mailto:ethereal-users-bounces@xxxxxxxxxxxx] On Behalf Of Greg Saunders
Sent: Thursday, November 18, 2004 4:06 PM
To: 'Ethereal user support'
Subject: RE: [Ethereal-users] SQL Slammer - How to identify

Thanks for the replies... Here is why I was asking. (This is kinda long to
give the detail)

*** Details ***

- We have an HP Procurve 4000M which is connected to subnet 172.20.2.0.

- This subnet has 10MB and 100MB devices with some having full duplex and a
small number having half duplex.  Most of the half duplex are print servers.

- The HP Procurve 4000M has 3 ports that connect to other switches.  1 to
another HP Procurve 4000M and 2 to small linksys switches that have most of
the slow print servers and such tied to them.

- We are running on a Windows NT domain with NT servers, 2000 servers, 2000
workstations, XP workstations, 98 workstations, SQL 7.0 server, Exchange
5.5
Server, HP print servers, and Intel print servers.

- We generally don't have high network utilization, it is normally below
5
percent all the time, once in a while when we do a network backup or large
file transfers will it go higher.

*** Symptoms ***

- We first noticed problems when our Network Monitoring software (basically
ping sweeps, event log monitoring, and NT server monitoring) noticed
multiple servers going down for just a few seconds.  The ping was set give
an alert if it detected 3 or more pings greater than 500ms.  I also bumped
it to 6 or more pings greater than 500ms to make it less sensitive.
Later
we found that it wasn't because of low latency, but pings requests not
getting replies at all.

- We also noticed applications like Outlook would loose connection to the
Exchange server briefly, applications that communicated directly to SQL
would loose connection and you would have to restart the app, and other
similar problems.

- Based on a 1 minute ping sweep of about 10 servers we are seeing a drop of
about 10 to 20 drops a day.

- Based on a 30 second ping sweep of about 10 servers we are seeing a drop
of about 30 or more a day.

- Based on a 10 second ping sweep of about 10 servers we are seeing a drop
of about 60.

- This is not isolated to one server it is happening on all of our servers.

- Some servers seem to experience it more than others, but no pattern is
really found here.

- We never see a "link loss" it is always just a matter of not being able to
communicate with the server for short time periods

- Usually the loss of communication is about 3 seconds, but I have seen it
last up to a minute.

*** Testing / Diagnosing ***

- We first started examining all of the logs and alerts that were generated
by the HP Procurve Switch and found nothing.  There were a couple of
CRC/alignment errors on one port and a couple of FCS rx errors on another
port.  But other than that we have no errors. 

- The switch diagnostics don't show any problems and looking at the numbers
the buffers are not used up and the memory is not used up.

- All servers have the latest MS security patches as well... Especially ones
that used the RPC buffer overflow problmes.

- All of our units and servers are protected with TrendMicro products with
the latest patterns and they don's see anything.

- We decided to start capturing packets to see if there were any of the
common worm / virus.  For capturing of packets I had the switch's monitoring
port monitor all ports so I could get a dump of everything.  I did this for
several hours and after examining the captures I didn't see anything
resembling a worm and none of the basic filters for the most common worms
revealed anything.

- One of my tests was while I was pinging server A from PC B I was not
getting replies.  I then went to server A and ping out to another unit.
Server A was getting replies and as soon as I had done this PC B started
getting replies from Server A.  When I stopped the pinging from Server A, PC
B quit seeing Server A.  After about a minute everything went back to
normall.

- I worked with HP and they swapped out the HP Procurve Chassis and we ended
up with the same results.

- After a bunch more tests HP was willing to send all new modules and we
swapped them and we have the same problem.  So now we have a whole new
switch and modules.

- HP wanted to determine whether or not the pings were actually traversing
the switch and making it to the servers so we did the tests below.
Listed
you will find the ports we were testing and how things were connected.

**********
Server TBGSMS with IP 172.20.2.6 on Port B1 Notebook TBGITSOLO2K with IP
172.20.2.12 on Port D6 (which is only monitoring port B1 and the notebook is
capturing packets) PC TBGGREGS with IP 172.20.2.4 on Port D7 (This pc is
also capturing
packets)
 
I turn packet capturing on for both 172.20.2.12 (D6) and 172.20.2.4 (D7) I
then start a ping utility that sends 1 ping every 2500ms with 32 bytes
continuously from 172.20.2.4 (D7).
 
The pc on 172.20.2.4 (D7) is capturing every packet it sends and the
replies.
The Notebook on 172.20.2.12 (D6) is capturing all packet inbound/outbound to
172.20.2.6 (B1) as well as it's own traffic.
 
Then pc on 172.20.2.4 (D7) shows that it did not receive replies to 5 icmp
ping requests in a row which spans 20 seconds.  I then look at the capture
on the monitoring port (D6) and it does not see the 5 pings that were
outbound from 172.20.2.4 (D7).  Basically the ping requests never traversed
the switch.  In the capture log on 172.20.2.12 (D7) you see all the ping
requests and replies to and from 172.20.2.6 (D6) up until those 5 never show
up and then you start seeing them pick back up again.

HP wanted to verify that the pings actually got to the switch from
172.20.2.4 (D7) so we started monitoring (D7) from (D6) and tested for this.
When 172.20.2.4 (D7) pinged without getting replies I was able to see that
the pings were getting to the actuall D7 port via the monitoring port and
they were intact.
**********

- So... I was able to prove that periodically the switch was not forwarding
packets to the destination they were intended to be.

- Never did we see the utilization of the network or the switch go up
sufficiently to cause dropped packets.  We are talking 1 to 10 percent
utilization with the majarity of the time it is well be low 5%.

- In my mind the only other thing I could think of is that the MAC table in
the switch is possible getting incorrect MAC addresses being set and causing
the problems we are seeing. Oh... We are NOT using VLAN's and NOT using tree
spanning.  The switch is setup basically as default.

- I am currently capturing in a text file the listing of the MAC address
assignments to the ports repetatively hoping to catch a port changing its
MAC address assignment.

*** Conclusions / Help needed ***

- I am open to any suggestions on what this problem could be.

- I am open to any assistance you can provide on how to use Ethereal to
catch something going on.  What would you recommend looking for to help
isolate this problem.

Thanks in advance and if you got this far then I am impressed.

Greg

-----Original Message-----
From: Andrew Hood [mailto:ajhood@xxxxxxxxx]
Sent: Thursday, November 18, 2004 5:10 AM
To: Ethereal user support
Subject: Re: [Ethereal-users] SQL Slammer - How to identify

Greg Saunders wrote:
> Hey folks,
> 
> How can I identify the SQL slammer if I am capturing all the packets 
> on my switch through a monitoring port?  What specifics should I look 
> for... is there a filter or something to spot this?

I've seen Martin's reply, and would agree installing Snort would be a
simpler solution than trying to get Ethereal to pick them out.

The Snort rules for CVE CAN-2002-0649 a.k.a. Slammer a.k.a Saphire are:

alert udp $EXTERNAL_NET any -> $HOME_NET 1434 (msg:"MS-SQL Worm propagation
attempt"; content:"|04|"; depth:1; content:"|81 F1 03 01 04 9B 81 F1
01|";
content:"
sock"; content:"send"; reference:bugtraq,5310; reference:bugtraq,5311;
reference:cve,2002-0649; reference:url,vil.nai.com/vil/content/v_99992.htm;
classtype:mis c-attack; sid:2003; rev:6;)

alert udp $HOME_NET any -> $EXTERNAL_NET 1434 (msg:"MS-SQL Worm propagation
attempt OUTBOUND"; content:"|04|"; depth:1; content:"|81 F1
03 01 04 9B 81 F1|"; con
tent:"sock"; content:"send"; reference:bugtraq,5310; reference:bugtraq,5311;
reference:cve,2002-0649; reference:url,vil.nai.com/vil/content/v_99992.htm;
classty pe:misc-attack; sid:2004; rev:5;)

alert udp $EXTERNAL_NET any -> $HOME_NET 1434 (msg:"MS-SQL version overflow
attempt"; dsize:>100; content:"|04|"; depth:1; reference:bugtraq,5310;
reference:cve ,2002-0649; reference:nessus,10674; classtype:misc-activity;
sid:2050;
rev:5;)

--
There's no point in being grown up if you can't be childish sometimes.
                 -- Dr. Who

_______________________________________________
Ethereal-users mailing list
Ethereal-users@xxxxxxxxxxxx
http://www.ethereal.com/mailman/listinfo/ethereal-users

_______________________________________________
Ethereal-users mailing list
Ethereal-users@xxxxxxxxxxxx
http://www.ethereal.com/mailman/listinfo/ethereal-users


_______________________________________________
Ethereal-users mailing list
Ethereal-users@xxxxxxxxxxxx
http://www.ethereal.com/mailman/listinfo/ethereal-users

_______________________________________________
Ethereal-users mailing list
Ethereal-users@xxxxxxxxxxxx
http://www.ethereal.com/mailman/listinfo/ethereal-users


_______________________________________________
Ethereal-users mailing list
Ethereal-users@xxxxxxxxxxxx
http://www.ethereal.com/mailman/listinfo/ethereal-users


_______________________________________________
Ethereal-users mailing list
Ethereal-users@xxxxxxxxxxxx
http://www.ethereal.com/mailman/listinfo/ethereal-users