once upon a time i wrote a program called tft.c that tested tcp flags by
running through all 64 combinations of flags (i didn't include X+Y) and
checking what kind of packets came back. solaris stood out like a sore
thumb based on some odd packets that it dropped instead of ACKing.
interested parties should check out tft.c which was posted to BUGTRAQ
a long ass time ago.
On Wed, 22 Nov 2000, Ofir Arkin wrote:
> Cameron,
>
> I have read the Article in the sysAdmin magazine, unfortunately it is not
> enough to fool me :)
>
> The article, for those who do not subscribed to SysAdmin, deals with
> changing parameters with
> Solaris so NMAP will not detect it. The article suggests changing the PMTU
> policy, and harden the sequence
> numbers sequencing.
>
> But, there are a lot of other wild ideas we can use that will reveal the
> Solaris box.
> Changing the most common identification parameters will not hide the other
> :)
> Sure, it will make the job harder, but not impossible.
>
>
> Ofir Arkin [ofir_at_itcon-ltd.com]
> Senior Security Analyst
> Chief of Grey Hats
> ITcon, Israel.
> http://www.itcon-ltd.com
>
> Founder
> http://www.sys-security.com
>
> "Opinions expressed do not necessarily
> represent the views of my employer."
>
>
> -----Original Message-----
> From: Cameron Palmer [mailto:cameron_palmer_at_hotmail.com]
> Sent: Sunday, November 05, 2000 2:50 AM
> To: of_at_securityfocus.com; ofir_at_itcon-ltd.com; lance_at_spitzner.net
> Cc: nmap-hackers_at_insecure.org
> Subject: NMAP Identity obscuring
>
>
> I know we have seen the argument before, but the recent SysAdmin magazine
> has an article on Solaris security. They recommend changing some NDD
> parameters to obscure the identity of Solaris from nmap. They have some
> interesting points, which is essentially they aren't looking for that as the
> sole form of protection of the machine but merely make Solaris conform to
> the RFCs instead of having its own quirks that give away too much
> information. I would normally be dissuaded from security by obscurity
> arguments, but by taking out the things that make the OS unique and conform
> to RFCs you do raise the ante as it were. Additionally I've seeen some
> other good OS tuning parameters with NDD that help performance that are a
> good idea, like fixing your Quad card to having multiple MAC addresses
> instead of the single hostid. Apparently you can gain a 40% speed boost on
> a Checkpoint firewall. This came from the Checkpoint web site. They have a
> number of recommendations for security related changes.
>
> Any thoughts?
>
> cameron.
>
>
> From: Oliver Friedrichs <of_at_securityfocus.com>
> To: Ofir Arkin <ofir_at_itcon-ltd.com>, Lance Spitzner <lance_at_spitzner.net>
> CC: nmap-hackers_at_insecure.org
> Subject: RE: firewalk meets nmap - TTL (tested)
> Date: Sat, 04 Nov 2000 15:36:23 -0800
> MIME-Version: 1.0
> Received: from mta1.snfc21.pbi.net (mta1-pr) by sims1.snfc21.pbi.net (Sun
> Internet Mail Server sims.3.5.2000.01.05.12.18.p9) with ESMTP id
> <0G3I00609XSQ25_at_sims1.snfc21.pbi.net> for palmer74_at_sims-ms-daemon; Sat, 4
> Nov 2000 15:41:14 -0800 (PST)
> Received: from amy.insecure.org ([208.184.74.98]) by mta1.snfc21.pbi.net
> (Sun Internet Mail Server sims.3.5.2000.01.05.12.18.p9) with SMTP id
> <0G3I000N7XQ0PL_at_mta1.snfc21.pbi.net> for palmer74_at_sims1.snfc21.pbi.net; Sat,
> 04 Nov 2000 15:39:37 -0800 (PST)
> Received: (qmail 20825 invoked by uid 508); Sat, 04 Nov 2000 23:46:19 +0000
> Received: (qmail 20725 invoked from network); Sat, 04 Nov 2000 23:41:28
> +0000
> Return-path: <nmap-hackers-return-887-palmer74=pacbell.net_at_insecure.org>
> Message-id: <10786F3AE30CD4118FAC00A0CC58F9F1015929_at_MAIL>
> X-Mailer: Internet Mail Service (5.5.2650.21)
> Precedence: bulk
> Delivered-to: mailing list nmap-hackers_at_insecure.org
> Delivered-to: moderator for nmap-hackers_at_insecure.org
> Mailing-List: contact nmap-hackers-help_at_insecure.org; run by ezmlm
>
> >Lance, we should automate this somehow. This is a cool thing.
> >But again correct configuration will prevent this from happening.
>
> This is a really neat idea. It should be easy to automate, if you
> add in some traceroute functionality to nmap to determine the hop
> where packets are being dropped (this would be the firewall), then
> you only need to specify an address on the internal network. I think
> nmap could use UDP/TCP ACK/ICMP traceroute functionality anyways.
> And while your at it, make it parallel, send out 32 packets with
> incrementing ttl's at the very start.. none of this 1 hop at a time
> slowness.
>
> - Oliver
>
> --------------------------------------------------
> For help using this (nmap-hackers) mailing list, send a blank email to
> nmap-hackers-help_at_insecure.org . List run by ezmlm-idx (www.ezmlm.org).
>
>
> _________________________________________________________________________
> Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.
>
> Share information about yourself, create your own public profile at
> http://profiles.msn.com.
>
>
>
> --------------------------------------------------
> For help using this (nmap-hackers) mailing list, send a blank email to
> nmap-hackers-help_at_insecure.org . List run by ezmlm-idx (www.ezmlm.org).
>
--------------------------------------------------
For help using this (nmap-hackers) mailing list, send a blank email to
nmap-hackers-help_at_insecure.org . List run by ezmlm-idx (www.ezmlm.org).
Received on Nov 23 2000
Intro
