Subject: [tcpm] security draft: section 14 review

From: Mark Allman <[email-masked]>
Date: Wed, 06 Apr 2011 08:11:57 -0400

I agreed to try to review section 14 of the security draft, which I was
able to do between meetings yesterday.  Comments:

  o The point of this section is not clear to me.  Port scans do not
    impact TCP's security.  They may impact the host's security, but
    such a broadening of scope seems strange to me.  E.g., TCP can be
    used to carry all manner of malcode, but do we want to tackle that
    problem in this document?  I hope not.  I don't see much in this
    section that is all that useful TCP-wise.

  o The document should at least show perspective about scanning.  That
    is, in the limit if an adversary has enough time and enough machines
    they can figure out your open/closed ports no matter what you do.
    Of course, there are things one can do to make this take longer or
    require a larger set of scanners.  But, at least we should start
    from the reality that at the end of the day this activity cannot be
    prevented.

  o I *think* this section is sketching techniques that can be used to
    force adversaries to expend more resources in finding a host's
    open/closed ports.  But, if this is the goal then it ought to be
    explicitly stated.

  o BTW, port scanning is not a big chunk of the scanning we see [we've
    recently been working on an extension of an IMC 2007 paper on the
    subject].  To the contrary we mostly see network scans of a given
    port.  Our conjecture is that attackers have some attack vector (IIS
    exploit, say) and so there is no reason to see if (say) the ssh port
    is open on some machine.  Rather, it is more important to find which
    machines might be running a web server.  So, a scan across hosts
    instead of a scan across ports makes a lot more sense.  Obviously,
    this is not the entirety of scans and some indeed do port scan some
    set of ports (one presumes this is a multi-vector attack)---these
    are just not as common according to our data.

  o All these scan types are just clever exploitation of some small
    feature / bug in the spec or the way stacks are coded.  You probably
    didn't identify all such behavior.  Rather than introduce a bunch of
    new and quite specific rules ("don't RST if there is no ACK bit
    set") how about just introducing a blanket rule that says "its OK to
    not respond to crap"?  I.e., if you have no connection state
    (whether that be active or in TIME-WAIT or whatever) then just don't
    respond to anything that isn't a SYN.  Lots of firewalls (network
    and host) implement that general policy now.

    I understand the peer might have some out-of-date connection state
    or something and a RST might help it better understand a connection
    is gone, but thats an optimization.  And blocking these can
    certainly be viewed as a policy decision.

    But, even with this rule you still can be found out.  It makes it
    more difficult as the attackers have to issue normal looking
    communication, but it doesn't solve the problem.

  o This section represents another instance of the "parallel specs"
    problem I sketched the other day.  There are new proposed rules in
    here that update 793.  What is one to do when looking at a full
    standard vs. a 100-page BCP?  This is creating a mess.

In sum, this doesn't look like "TCP security" to me and so I'd just
assume leave it out.

allman

---

From: Fernando Gont <[email-masked]>
Date: Wed, 06 Apr 2011 16:29:37 -0300

Hi, Mark,

Thanks so much for taking the time to review Section 14. Please find my
comments inline....

>     section that is all that useful TCP-wise.

This section is meant to cover all variants of TCP-based portscans, some
of which are based on features/bugs of existing stacks. Some variants
can be mitigated if some changes to the code are applied.

(Note: I'm simply providing a rationale for the Section)

>     from the reality that at the end of the day this activity cannot be

Agreed. One point to note is that some scan methods are more stelathy
than others. e.g., simply connect()-scan versus an ACK scan.

>     open/closed ports.  But, if this is the goal then it ought to be

Actually, it aims at covering the existing TCP-based techniques, and to
provide mitigations for the more stealthy ones.

>     machines might be running a web server.  

I think this depends on what the attacker is trying to achieve. If he's
just after more nodes for his botnet, yes: he just has an exploit, and
only cares about a specific port. If it's a targetted attack, then he'll
probably sweep the entire port range of the target host(s).

That said, the port-scanning techniques described in this section
applies to both cases. i.e., if there are stealthy port-scanning
techniques, an attacker would possibly would those over the trivial
connect()-based scan.

>     didn't identify all such behavior.  

You might be right. FWIW, these are the "known" ones.

>     Rather than introduce a bunch of

How would you suggest to codify such rule? -- Because it's something
along the lines of "don't respond to crap", then there's the question of
"what do you mean by crap?"

But yes, if all those stealthy portscan techniques can be mitigated with
a simply rule such as the one you mentioned, that sounds like a valid
way forward.

>     communication, but it doesn't solve the problem.

Agreed. But it becomes easier to track.

>     problem I sketched the other day.  

I don't think I've received your note (was it posted to tcpm? If not,
please send it off-list to me).

>     There are new proposed rules in

Wouldn't RFC793 be formally updated in this respect? Or maybe a short
I-D issued in response to these std issues?

> In sum, this doesn't look like "TCP security" to me and so I'd just

So you argue that these issues should not be addressed in this document?
(e.g., mitigations for stealh port-scan methods). And if not here, where?

Thanks again!

Best regards,
-- 
Fernando Gont
e-mail: [email-masked] || [email-masked]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

---

From: Mark Allman <[email-masked]>
Date: Wed, 06 Apr 2011 15:46:51 -0400

> (Note: I'm simply providing a rationale for the Section)

I still don't get it.  This has nothing to do with TCP security.

I am not responding to a bunch of your comments directly because I think
you said what I said and so I'm going to assume we agree.

> I think this depends on what the attacker is trying to achieve. If
> he's just after more nodes for his botnet, yes: he just has an
> exploit, and only cares about a specific port. If it's a targetted
> attack, then he'll probably sweep the entire port range of the target
> host(s).

I was sketching what we *see*.

> "what do you mean by crap?"

Well, I think I defined it like this:

    I.e., if you have no connection state (whether that be active or in
    TIME-WAIT or whatever) then just don't respond to anything that
    isn't a SYN.  

> please send it off-list to me).

(Yes- I sent several to TCPM the other day.)

> So you argue that these issues should not be addressed in this document?

To be clear, I argued the other day that this document should not exist
on the grounds that it creates a gigantic mess.  But, that aside these
issues are not issues that impact TCP security.  There are many
"security issues" that *involve* TCP, but that doesn't mean we need to
change TCP to mitigate them.

allman

---

From: Fernando Gont <[email-masked]>
Date: Wed, 06 Apr 2011 17:24:49 -0300

> I still don't get it.  This has nothing to do with TCP security.

The stealth port-scanning techniques are based on TCP features/bugs. If
one ones to mitigate them, they need to be mitigated in the TCP code.
That's why they are discussed in this document.

> I was sketching what we *see*.

Agreed. Just curious: where has the dataset been obtained? (I ask
because I'd expect your data to represent the general case. OTOH, one
would expect NSA's networks and the like to have their whole port ranges
swept completely)

>     TIME-WAIT or whatever) then just don't respond to anything that

That sounds very reasonable. Should I e.g. simply make some general
comments on availalable stealth port-scanning techniques, provide
references, and just include this rule? (in replacement of the current
Section 14)

> (Yes- I sent several to TCPM the other day.)

I have found them now (three posts on April 4th).

> change TCP to mitigate them.

My *personal* take is that, if they are TCP-specific (as the stealth
port-scanning techniques), and can be easily fixed, we should do it.
IMO, these stealth portscan techniques should not exist.

I'll let others weigh in.

Just to make sure I got your point clear: Aside from your comments about
the document in general, you argue that this section should be removed,
and that this document should not try to mitigate the stealth
portscanning vectors?

Thanks!

---

From: Mark Allman <[email-masked]>
Date: Wed, 06 Apr 2011 16:45:19 -0400

> one ones to mitigate them, they need to be mitigated in the TCP code.

(Or in a firewall like everyone does.)

> Agreed. Just curious: where has the dataset been obtained?

LBL.  See ...

  Mark Allman, Vern Paxson, Jeff Terrell.  A Brief History of Scanning.
  ACM SIGCOMM/USENIX Internet Measurement Conference, October 2007.
  http://www.icir.org/mallman/papers/scan-history-imc07.pdf

... which only pays scant attention to port scanning and not in a
terribly meaningful way, but we are working on better stuff.  And, for
more recent data.  But, that gives you some idea of the data we're
looking at.

> references, and just include this rule? (in replacement of the current

If you wrote a one-page I-D that said a TCP MAY "not respond to crap"
(codified better of course) such that it basically mimics broadly used
firewalling strategies that might be OK.  You can put whatever you want
in section 14 of this document...I won't support it.

allman

---

From: Fernando Gont <[email-masked]>
Date: Wed, 06 Apr 2011 18:13:40 -0300

> (Or in a firewall like everyone does.)

In quite a number of cases, firewalls need to mitigate things simply
because implementations are not doing as good as they could/should. I
don't see why one should rely on a firewall for *this*

> more recent data.  But, that gives you some idea of the data we're

Thanks for the pointer. I'll read your paper.

Thanks,