TO UNSUBSCRIBE: email "unsubscribe issforum" in the body of your message to [EMAIL PROTECTED] Contact [EMAIL PROTECTED] for help with any problems! ----------------------------------------------------------------------------
Hi Everyone, I have read this words in a message from this list: "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)." Could anyone confirm to me the fact that the solaris prevent the MAC address spoofing from the network sensor? If it were true, how the sensor send the RST packets? With his own MAC Address? This question is very important for me because, in a switched environnement, the MAC address spoofing from the sensor is a very tough problem to solve. Thanks by advance, ------------------------------------------------------------ Laurent Cabal Ing�nieur S�curit� ALTHES "L'expertise s�curit�" 53 rue Albert Samain 59650 Villeneuve d'Ascq tel: 33 (0) 3.20.33.84.40 fax: 33 (0) 3.20.33.84.31 http://www.althes.fr -----Message d'origine----- De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Envoy� : dimanche 23 juin 2002 23:03 � : [EMAIL PROTECTED]; [EMAIL PROTECTED] Objet : Re: Duplicate IP event - how does it use ARP and what do the fields mean (exactly)? 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 *---------------------------------------------------------------* * Cet e-mail et toutes les pi�ces jointes sont destin�s aux * * seules personnes auxquelles ils sont sp�cifiquement adress�s * * et n'engagent que le signataire de ces documents et non la * * structure dont il d�pend. * * Leur existence et leur contenu ont un caract�re confidentiel. * * Toute utilisation ou diffusion non autoris�e est interdite. * * Si vous avez re�u cet e-mail ou si vous d�tenez sans en �tre * * le destinataire, nous vous demandons de bien vouloir nous en * * informer imm�diatement. * * Cette note assure que ce message a �t� contr�l� et ne * * comprenait aucun virus connu � ce jour, n�anmoins tout * * message �lectronique est susceptible d'alt�ration. * * Nous d�clinons toute responsabilit� au titre de ce message * * s'il a �t� alt�r�, d�form� ou falsifi�. * *---------------------------------------------------------------*
