Re: how to know scan is correct?

[Eric Hankins <eric () cnmnetwork com>]

Bart van Leeuwen wrote:
> Justin wrote:
> > On Wed, 9 Feb 2000, Marcy Abene wrote:
> >
> > > You can't avoid a syn scan - what do you think you are
> > > talking about?  Here, look. :->
> >
> > That's why you have a iptables/whatever module that listens looks for syns
> > to non-open ports, logs once, then filters the offending ip/netmask for 30
> > minutes or a few days if you're particularly fascist.  The chance that
> > they'll hit an important port in a random scan is (open ports) /
> > everything in /etc/services.  The chance that they'll get a significant
> > number of open ports before they hit a banned port and are filtered is
> > just about 0 unless the box is running a stock redhat installation, and in
> > that case you have more important things to worry about than whether or
> > not people can find open ports.
> >
> > Anyway, for people who are or who want to be seen as being really
> > concerned about security, you can always allow specific hostmasks and deny
> > everything else.  I always love it when an admin has to add a hostmask to
> > a box's filter rules before you can ssh in, but has 5 year old exploitable
> > suid binaries.
> >
> > Justin
>
> I think that what Reinoud was talking about is a way to hide filtered
> ports from nmap, and not about hiding 'open to everyone' ports from a
> scan.
> As you may know nmap will in many cases report that a port is filtered
> when you are not allowed to communicate with it while others are.
>
> Is this usefull? hmm... sometimes it is tho in many cases I would just
> close things down for the outside world. Anyway, if you have to filter,
> it may be a nice option to make that hard to find, ie, give the outside
> world the idea noone can talk imap to your machine, while in fact one
> other host on the net really has to be able to talk imap to your host.
> Only mildly usefull, but interesting enough I think.

As for not giving away your filtered ports, simply tell nmap what it
wants to hear. For tcp this means returning RST, and for udp return icmp
port-unreach. This is handled easily enough in ipf with "block
return-rst in on ..." for tcp and "block return-icmp(port-unr) in on
..." for udp. This also has the handy effect of fooling tcp sequence
prediction(fingerprint below). At least this is what i have observed
with solaris7, someone should probably confirm this behavior with *bsd.
So in protecting your imapd, those in the allow list will be allowed,
and according to everyone else theres nothing listening on the port.

> And heh, about those 5 year old suid binaries... no it doesn't do much
> good for the security of the box, no discussion about that, but without
> those someone who wants to do wrong can still do wrong, while limiting
> access to people who do explicitly not want to do wrong makes that the 5
> year old suid binary is completely irrelavant. Only problem is how to
> limit access to only those people... (note... machine != person so just
> an ip filter is usually not enough) and also... how to find such people
> ;P (when it comes to security of data and computer systens I usually do
> not trust anyone ;-)

I believe this is where the *gasp* NT/Trusted *nix model comes into
play...And even if you were to get accustomed to the gobs of assignable
system roles, I don't really anticipate a free/open-source
implementation of this coming to fruition due to the level of kernel
integration required. Although I would love to see perhaps a freebsd or,
more likely, an openbsd implementation of role based access, if at least
for a proof of concept.
        

> On another note, it seems to me that if people are going to setup their
> routers a bit better (enforcing that packets have a valid source ip for
> the port on which the packet enters the router) that this will also make
> it a lot harder to use decoys during a scan (since those decoys would
> contain source addresses which, acording to your isps router, can not
> come from you, and so will be dropped) Any thoughts on this?

Every competent network admin i know enforces outbound srcaddr
restrictions. I know i do just to avoid dealing with it later on.
Apparently competent network admins are few and far between, as
illustrated by the recent DDoS fandango(spoofed or not, lots of "admins"
dropped the ball), and the spoofed attacks that go unchecked day after
day. So barring massive reeducation of the end user (heh), the next
logical step is the upstream edge. The common answer here is "not enough
router cpu". And even then you will run into problems with multihomed
end-users. Perhaps filters could be dynamically generated based on BGP
advertisements. However, the DoS implications of this are nauseating at
best, keeping in mind that most places dont take advantage of the MD5
authentication of BGP. This also can go to hell if the end user becomes
a transit AS. All in all, an oz. of prevention is and will always be
worth a lb. of cure. 

-e