Re: weird scans from port 80

From: Kasper Dupont (kasperd@daimi.au.dk)
Date: 01/23/03 

From: Kasper Dupont <kasperd@daimi.au.dk>
Date: Thu, 23 Jan 2003 16:16:38 +0100

Tim Haynes wrote:
>
> Kasper Dupont <kasperd@daimi.au.dk> writes:
>
> >
> > OS detection is not a security risk.
>
> No? Interesting. Some of us consider *any* information-leak to be a
> security risk.

Wether you reply or not is also an information. How would
you hide that fact from them? At worst they would only
find out the OS of your firewall, not the network behind
it. If you really care about that use a firewall that you
can make look like something else.

>
> > Reallity shows that attempts are made by attackers without the knowledge
> > of your OS or even if doesn't appear to be vulnurable.
>
> Reality also suggests that not everyone flinging packets at you is a kiddie
> or a worm.

So what do you think those who knows exactly what they
are doing and who are targeting you personally are going
to do?

I guess they'd find more vulnurable victims to use in
the attack to hide their own identity.

I think they are going to try attacks looking like a worm
or a kiddie, because they can do so and possibly get a
few helpful informations without you knowing you are
under an attack.

And when a vulnurability in some software is revealed
they can attempt an attack against you even if they do
not know if you are using the software. What would you do
about it? They have hidden their identity enough that you
cannot get them even though you know they attempted a
serious attack against your system. Are you going to
secure your system better? If you really can do that, why
not do it at once before the first attempt are made?

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.

>
> [snip]
> >> Oh, haha, still banging on about that one sentence of RFC793 as though it
> >> were applicable?
> >
> > For gods sake would you rather have had the entire RFC posted?
>
> That would also be unnecessary. However, posting something that didn't
> destroy your "point" for you might've been recommendable.
>
> > It specifies in all details when to send RST and when not to.
>
> You call "as a general rule" a "specification"?

Like I already said. It just sumarizes the specifications
in the RFC. The general rule is probably easier to
understand unless you choose to misunderstand it. And as
I already said, the RFC is too long to post it all.

>
> > This sentence just sumarizes all those rules. If you want to know more
> > about it read the RFC.
>
> Then you have failed to justify your "point" and are obviously unwilling to
> post something relevant to back it up. Nice knowing you.

And where is your documentation of a situation not
requiring a reset in response to an unexpected TCP packet?

>
> >> Look, get it through your head: the first clause in the snippet you
> >> quoted *alone* makes it highly questionable whether the rest applies.
> >> The subsequent sentence someone else quoted makes it even less likely.
> >> Trying to tar people who disagree with your stupid ideas as saying "it's
> >> a firewall therefore standards don't apply" is utterly offensive, when
> >> nobody here has ever said as much.
> >
> > It is not my stupid ideas, the RFC is the standard which you MUST conform
> > with.
>
> And I do. What's your problem?

Do you really? Do you handle the SEGMENT ARRIVES event
correctly? Now let's take a slightly longer quote from
page 65 of the RFC which might be the most interesting
case where an RST packet is to be send:

  SEGMENT ARRIVES

    If the state is CLOSED (i.e., TCB does not exist) then

      all data in the incoming segment is discarded. An incoming
      segment containing a RST is discarded. An incoming segment not
      containing a RST causes a RST to be sent in response. The
      acknowledgment and sequence field values are selected to make the
      reset sequence acceptable to the TCP that sent the offending
      segment.

      If the ACK bit is off, sequence number zero is used,

        <SEQ=0><ACK=SEG.SEQ+SEG.LEN><CTL=RST,ACK>

      If the ACK bit is on,

        <SEQ=SEG.ACK><CTL=RST>

      Return.

In particular the par saying: "An incoming segment not
containing a RST causes a RST to be sent in response."

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.)

>
> Now you're really talking crap. First you say that attempts to restrict the
> events responded-to are "against the RFCs" without justifying it, then you
> say the above? Since when did *not* sending a packet *add* to a DoS?

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?

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.

>
> > So, I guess he no longer has a problem, which means my advice have indeed
> > been helpful. The only reason for this thread to continue is you
> > insisting on violating the standards in the holy name of the firewall.
>
> I beg your pardon? Name *ANY* article where I have *EVER* defended such a
> position. I dare you.

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.

>
> >> If you won't be man enough to apologise to the group for the *** you've
> >> been spreading, at least shut up.
> >
> > I have no reason to apologise, I have just been defending the standards.
>
> You've just falsely accused me and in a previous article "various others"
> of suggesting violating "the standards", which you make no attempt to apply
> logically.

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

>
> Consider yourself <plonk>ed for extreme offensive idiocy.

Thank you. You too :-P 

-- 
Kasper Dupont -- der bruger for meget tid på usenet.
For sending spam use mailto:aaarep@daimi.au.dk
for(_=52;_;(_%5)||(_/=5),(_%5)&&(_-=2))putchar(_);