Messages in this thread | | | From | "Michael H. Warfield" <> | Subject | Re: [Patch] IPv4 TCP security impovement | Date | Sun, 10 Jan 1999 12:06:20 -0500 (EST) |
| |
Joachim Baran enscribed thusly: > On Sat, Jan 09, 1999 at 01:53:53AM +0100, Andi Kleen wrote: > > On Fri, Jan 08, 1999 at 08:07:45PM +0100, Joachim Baran wrote: > > > I'm talking about UNCONNECTED ports. Understand the > > > patch - luke... (Sorry - but that's how it is). > > The ports are unconnected because they have been opened by a different machine > > that had the same IP. Your machine does not know that they exists, until > > the packets arrive. > OK - now very slow:
> 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/
| |