Re: Network Scanning

Jeroen Massar <jeroen@unfix.org> Mon, 07 April 2008 21:39 UTC

Return-Path: <ipv6-bounces@ietf.org>
X-Original-To: ipv6-archive@megatron.ietf.org
Delivered-To: ietfarch-ipv6-archive@core3.amsl.com
Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 685313A69DE; Mon, 7 Apr 2008 14:39:50 -0700 (PDT)
X-Original-To: ipv6@core3.amsl.com
Delivered-To: ipv6@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 921E028C29A for <ipv6@core3.amsl.com>; Mon, 7 Apr 2008 14:39:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.15
X-Spam-Level:
X-Spam-Status: No, score=-2.15 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, J_CHICKENPOX_65=0.6, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W6g283fAPZFf for <ipv6@core3.amsl.com>; Mon, 7 Apr 2008 14:39:47 -0700 (PDT)
Received: from abaddon.unfix.org (abaddon.unfix.org [IPv6:2001:41e0:ff00:0:216:3eff:fe00:4]) by core3.amsl.com (Postfix) with ESMTP id 34C133A6CE3 for <ipv6@ietf.org>; Mon, 7 Apr 2008 14:39:47 -0700 (PDT)
Received: from [IPv6:2001:41e0:ff42:b00:216:cfff:fe00:e7d0] (spaghetti.ch.unfix.org [IPv6:2001:41e0:ff42:b00:216:cfff:fe00:e7d0]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jeroen) by abaddon.unfix.org (Postfix) with ESMTPSA id 4E61440202D; Mon, 7 Apr 2008 23:39:59 +0200 (CEST)
Message-ID: <47FA94AF.50905@spaghetti.zurich.ibm.com>
Date: Mon, 07 Apr 2008 23:39:59 +0200
From: Jeroen Massar <jeroen@unfix.org>
Organization: Unfix
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.12) Gecko/20080213 Lightning/0.8 Thunderbird/2.0.0.12 Mnenhy/0.7.5.666
MIME-Version: 1.0
To: Sean Siler <Sean.Siler@microsoft.com>
Subject: Re: Network Scanning
References: <47F6A2D0.3040602@spaghetti.zurich.ibm.com> <200804042201.m34M1Jec007787@omr12.networksolutionsemail.com> <004301c896a6$e5ff23e0$b1fd6ba0$@com> <F9296A6B5FA8B342A16483B956B26BB10670BB6522@NA-EXMSG-C114.redmond.corp.microsoft.com>
In-Reply-To: <F9296A6B5FA8B342A16483B956B26BB10670BB6522@NA-EXMSG-C114.redmond.corp.microsoft.com>
X-Enigmail-Version: 0.95.6
OpenPGP: id=333E7C23
X-Virus-Scanned: ClamAV version 0.92.1, clamav-milter version 0.92.1 on abaddon.unfix.org
X-Virus-Status: Clean
Cc: "ipv6@ietf.org" <ipv6@ietf.org>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1090019873=="
Sender: ipv6-bounces@ietf.org
Errors-To: ipv6-bounces@ietf.org

Sean Siler wrote:
> Microsoft based Operating Systems join the All Nodes On Link Multicast Group
 > as specified by RFC 4291, but that RFC does not mandate that nodes must
 > reply to ICMP echo requests.  So while we do not reply to pings to 
ff02::1,
 > we are also in compliance with the RFC.

Thus, as such, to identify this OS, one would just have to send an MLD 
Query on the link, receive the responses, and tada, you have, per the 
RFC, all the hosts that at least comply to the RFC, then substract the 
ones you receive an ICMP echo from et voila you know what is doing this 
trick, which currently means that it is most likely Windows-based as all 
the KAME's including even OpenBSD reply to the ANOL-ping. The KAME ones 
you can even do Node Queries to to get more data out of them.

As both MLD and ICMP Echo are ICMP packets, and both is 1 packet 
outbound (request/query), and several inbound (the replies), nothing 
really is of a difference.

Unless of course the OS is programmed to have a notion of a 'secure 
router' which would mean one need to do some spoofing, unless the switch 
is smart enough to detect&block those kind of action.

The real solution to on-link attacks is of course to compartmentalize 
the network and to have secure hosts in the first place. Then the only 
issue left is that rather annoying factor called humans :)

Greets,
  Jeroen

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------