Re: weird scans from port 80

From: Fredderic (fredderic@iprimus.com.au)
Date: 01/29/03 

From: "Fredderic" <fredderic@iprimus.com.au>
Date: Thu, 30 Jan 2003 01:05:30 +1000

> I see no reason why them not knowing your OS is going to
> give you any protection. And they might even have other
> ways to find out.

I see no reason to make their intents easier.

> So if the connection is in the CLOSED state (which is
> always the case if the peer is unknown to you) any
> arriving packet without a RST bit must be answered
> with a RST packet. (It does not say that a firewall is
> allowed to ignore the packet and send no RST.)

I don't think anyone's disputing the RFC. I think we're all disputing it's
application in todays internet.

> It is easy to imagine situations where clients not
> responding can cause problems for a server. Imagine a
> server which has clients with dynamic IP address.
> Imagine client computers often turned off with
> connections in the open state. If new clients getting
> the old IP address ignores packets from this connection,
> how is the server going to know they are to be closed?
> How many open connections of this kind can the server
> be expected to handle?

Well, how many servers don't use some form of ping to quiet connections to
make sure they're still there? In a world with modems and potentially
unreliable connections, any server suffering from this problem should be
redesigned with reality a little more in mind.

> Also consider SYN floods. Some servers could be DoS
> attacked by filling up their connection tables. Why
> wouldn't a few more open connections every day never
> getting a RST packet eventually perform as much trouble
> as a lot in a short time? And what if a SYN flood was
> performed with spoofed IP addresses? If the computer
> whos IP was spoofed replyed with a correct RST packet
> the server would be able to remove that entry from its
> connection table.

Hence the timeout.

> You were the one to say that a firewall was an exception
> to the general rule that a RST must be send in reply to
> an unexpected TCP packet.

You seem to be playing on the fact that you don't ALWAYS reply with an RST,
yet the intensity of your arguments suggests that you do. You have
advocated breaking the RFC's yourself. You just hide behind the fact that
you're using a little bit of rate limiting.

I'm sorry, but I know for a fact that it doesn't take much of a DoS to knock
off a modem connection. In fact, most ISP's probably wouldn't even notice a
sufficiently well-crafted DoS aimed at an average modem user. So I
personally would rather a potential attacker didn't know I was here in the
first place.

And as I've said, any server piffing packets at me should be smart enough to
consider the possibility that its true target may not be there anymore.

> Oh, now you just seem to think the RST packets are
> optional without even caring to read the standard.
> Is that any better?

Our dispute isn't with the RFC. It's with your application of it.

I once heard a saying... "Anything taken to an extream, becomes an error".
And that, strangely as it may sound, goes for rules and laws also. When
you're driving your car down the street, the cops with their radar guns
allow a few km/h leaniancy in most states, and in the rest they consider
their speed limits to already be a few km/h above what they should be. Even
the definition of murder is tempered with reference to intent. In every
case, 100% compliance isn't being strictly enforced. Same goes for RFC's.
I fully intend to comply with the RFC's; but intent or no intent, that's
just not always appropriate and/or practical. They discuss the ideal
situation. But everywhere there is also mention of how to handle non-ideal
situations. What to do if the other end is broken. And so on... But for
obvious reasons not EVERY potential source of impracticality is discussed.
So they stick to their ideal situation, with only a tightly limited
"topical" variance, and leave the exceptions to another discussion on
another day.

Relevant Pages

  • Re: is this an attak?
    ... The first packet you show has a source address of 66.90.71.151, ... Singapore or anywhere else outside of your local network should not be ... Unless you are planning to run a public mail server, ... connections should be accepted only ...
    (comp.os.linux.security)
  • PPTP Packet Filtering via VPN
    ... My clients establish connections using PPTP with 128-bit ... I want to restrict network traffic by defining IP packet ... filters on the VPN server policy. ...
    (microsoft.public.win2000.security)
  • Re: Closing tcp socket connections
    ... >>> The protocol between client and server is very simple, ... >>> packet sent by the client a new connection will be opened, ... Keeping connections open is not so easy in this case... ...
    (comp.programming)
  • Re: weird scans from port 80
    ... > current connection' supposed to mean in the context of a *NEW* packet?? ... cannot all be represented so connections in the CLOSED ... connection not in your table is in the CLOSED state. ... a RST bit must be responded with a RST packet. ...
    (comp.os.linux.security)
  • Re: RST ACK
    ... connections where is functions as the server. ... SYN-RST behavior is when is functions as the client. ... >> But shouldn't the server send a RST vs a RST ACK? ...
    (microsoft.public.win32.programmer.networks)