mailing list archives
Re: how to know scan is correct?
From: Eric Hankins <eric () cnmnetwork com>
Date: Fri, 11 Feb 2000 13:11:49 -0800
Bart van Leeuwen 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
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
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.