TO UNSUBSCRIBE: email "unsubscribe issforum" in the body of your message to [EMAIL PROTECTED] Contact [EMAIL PROTECTED] for help with any problems! ----------------------------------------------------------------------------
Jason, I am not sure if this really helps, but let me briefly explain what I am making out of it (I have seen those duplicates during my evaluation, too). A network sensor sits on a network segment, where all packets of each IP src and dst address should always have the same MAC address mappings. E.g. if you are sniffing on the mirrorport of a switch all packets originating from IP x.x.x.x should always have the MAC of the last hop which alway stays the same (unless you are using asymmetrical routing or so, what you claimed not to do). Now if your network sensor sees that some packets that originate from IP x.x.x.x have another MAC, it assumes that this could be due to some misconfiguration in your network or due to a spoofed packet. E.g. I think I have seen those alerts during tests with snot, which uses random src IP addresses. Another thing I could think of is TCP kills. But from my tests I have learned that RS not only spoofs the IP address, but also the MAC address (although this does not apply for Solaris, because according to Robert Graham, the OS prevents them from overwriting the MAC address). HTH, Detmar ---------------------------original message------------------------ Hi, I'm still having problems with duplicate IP address alerts and would value any ideas. I'm running a small static test system and I'm not doing anything fancy with routers etc. I've even left an arp trace running and inspected the packets at and around the time of the RealSecure alerts, but all the arp packets (requests and responses) all look fine - normal broadcast requests and unicast responses from the correct MAC addresses. If I can't figure out how to analyze duplicate IP address alerts in a simple environment like this, especially when I've got a corresponding arp trace, then I'm going to have problems in the wild. Please could somebody explain how RealSecure determines duplicate IP address events, or at least the meaning of the MAC1/MAC2 fields in the Event Details window? Thanks, Jason On Fri, 14 Jun 2002 16:50:49 +0100, Jason Renard <[EMAIL PROTECTED]> wrote: > >TO UNSUBSCRIBE: email "unsubscribe issforum" in the body of your message to >[EMAIL PROTECTED] Contact [EMAIL PROTECTED] for help with any problems! >---------------------------------------------------------------------------- > >Hi, > >I have the following in a small test environment (all v65): > >System [S2] with IP address [I2] MAC address [E2] - it's a Network Sensor >System [S3] with IP address [I3] MAC address [E3] - it's an Event Collector >System [S5] with IP address [I5] MAC address [E5] - it's a console > >Occasionally I see a Duplicate IP address event (there was one last night at 00:35), for example: > >Duplicate IP address (Suspicious arp) > >SourceIPaddress: I2 >DestIPaddress: I3 >SourceEthernetAddress: E2 >SourceEthernetAddress: E3 >MAC1: E5 >MAC2: E2 > >The online help says "RealSecure Network Sensor detects the duplicate IP address by monitoring ARP >packets and comparing the MAC address and IP addresses found in each packet. When it detects two >packets with the same IP address address, but different MAC addresses it creates this IPDuplicate >event" > >Please could somebody help with the following? > >1) Does RealSecure only use ARP packets or will it examine normal IP packets as well? The latter >would be more of an overhead, however it could catch more instances of duplicate IP addresses. > >2) If RealSecure only uses ARP packets, does it use the DLC source/destination from those packets or >does it use the payload Sender/Target fields? > >3) Does RealSecure apply this processing to both SOURCE and DESTINATION addresses? > >4) Most importantly, WHAT DO THOSE FIELDS MEAN? I presume the first four fields relate to the packet >which tripped the event, and I'm assuming it was probably an ARP reply. So what do the fields MAC1 >and MAC2 mean? > >5) ANY other info on this topic would be appreciated so that I can try to put these events into >context. > >Thanks, >Jason > >Jason Renard > >Warning - all views expressed are my own. >I cannot guarantee the accuracy of everything >I've said - use it at your own risk. > > Jason Renard Warning - all views expressed are my own. I cannot guarantee the accuracy of everything I've said - use it at your own risk. -- GMX - Die Kommunikationsplattform im Internet. http://www.gmx.net
