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 --------------------------------------------------------------------
- RE: Network Scanning Brian McGehee
- Re: Network Scanning Jeroen Massar
- Network Scanning Prasanna Ram Venkatachalam
- Re: Network Scanning Jeroen Massar
- RE: Network Scanning TJ
- Re: Network Scanning David Malone
- RE: Network Scanning Sean Siler
- Re: Network Scanning Jeroen Massar
- RE: Network Scanning Manfredi, Albert E