> Port 25 (we assume sendmail listening)
> -> This port is connected to sendmail, because
> sendmail listens on it. I don't touch
> packets to this port. Everything goes
> thru sendmail is is then handled by
> it.
>
> Port 24 (nothing - no daemon - no nothing)
> -> This port is unconnected. There is no
> service behind it. Here I would drop
> the received packet without sending
> an ACK+RST.
> So: There couldn't have been any connection to
> port 24, because nobody is listening there...
> > The patch is not suitable for kernel inclusion IMHO.
> Then it has to more complicated and I think that
> would be slower...
> According to some Phrack (49? - I can't remember) I
> read, Microsoft operating systems don't send an ACK+RST.
> So they couldn't be scanned in this way - but almost
> every Unix. This is sad...
That's a crock. Windows boxen can be scanned very easily and you
do get return information back.
Plus, you're not really accomplishing anything here. Just the mere
fact that your system can first be identified by a quick check on certain
common ports such as 25, 21, or 139 will identify the existance of your
box. Then the absence of return data will identify whether or not a
service is present. A parallel port scanner, such as what we have in the
ISS Internet Scanner, can rapidly determine what services you have and
what ones you don't whether you return an ACK+RST or not. We've demonstrated
that numerous times by scanning through filtering firewalls which drop
packets which fail the rule sets. Since this can be done asynchronously
against large number of ports, you don't have to time out sequentially
for each and every one either.
It is handy to be able to log port scanning attempts, but yours
is not the way to do it. This can be done in user space with a variety
of tools and no need for a kernel patch. You can even put some post
processing on it to log a message and ring some alarm for an attack, without
a kernel kprintf for each packet. As others have pointed out, unrestrainted
kernel kprints with no rate limiting opens you up to some nasty DoS attacks.
I can hit a system so fast with SYN's that I can take out switched 10baseT
hubs. Do you think you can generate kernel messages that fast and still
maintain a functioning system?
Now, something like abacus sentry is something else. Once it
detects port scanning, it can shut down access to even the legitimate
ports from the attacker and really mess with his abilities to determine
what you have or don't have. Again, this is pure user space with no
kernel patches required. This is much more fun to play with and much
more effective at security.
Sooo... The long and the short of it appears to be this. Your
patch is intended to reduce the amount of information a scanner can accumulate
about your system. On this point it fails miserably. I can determine just
as much as before, I may just have to take a few timeouts to do it. Your
patch is intended to log scanning attempts. Well, we already have that with
user space tools that don't incure the DoS risk that your patch does. Your
patch does introduce a potential DoS attack that otherwise would not
exist. Is there some benefit here that out-weighs that risk?
> Bye.
> --
> Joachim Baran jbaran@hildesheim.sgh-net.de
> Breslauerstr.18 http://prinz.hannover.sgh-net.de/~jbaran
> 31171 Mahlerten Network Administration
> Lower Saxony/Germany and Programming
Mike
-- Michael H. Warfield | (770) 985-6132 | mhw@WittsEnd.com (The Mad Wizard) | (770) 925-8248 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0xDF1DD471 | possible worlds. A pessimist is sure of it!- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/