<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <div class="moz-cite-prefix"><font size="-1"><font face="Arial">The
          prob<font size="-1">lem is it's impossible to forge<font
              size="-1"> a<font size="-1"> UDP header to be greater than
                65535 no matter what you put in the header. The only <font
                  size="-1">exception is some exo<font size="-1">tic I<font
                      size="-1">Pv6 jum<font size="-1">b</font>ograms
                      which I doubt are very <font size="-1">widely
                        supported (or routed).<br>
                      </font></font></font>Sounds like more of a bug in
                  the<font size="-1"> cloudflare</font> profile systems
                  than anything.<font size="-1"><font size="-1"><font
                        size="-1"></font></font><br>
                    <br>
                    Martin<br>
                  </font></font></font></font></font></font></font>
      <div class="moz-signature"><font style="font-family: Arial;
          font-size: 10pt;"><br>
        </font></div>
      On 4/03/2013 9:36 AM, Mark Tees wrote:<br>
    </div>
    <blockquote
      cite="mid:B8CFB527-9CF2-4CC4-BA34-EAA08988DEFC@gmail.com"
      type="cite">
      <pre wrap="">
The mentioned on their blog that config walk likely wrong as it was typed out manually. The rule should have been 99971-99985 if it was legitimate.

But that was never legitimate. Any attack signature that had a packet size larger than what is real shouldn't have made it in. A guess would be that maybe their detection system picked up packets with forged headers.

On 04/03/2013, at 9:40 AM, Jonathan Thorpe wrote:

</pre>
      <blockquote type="cite">
        <pre wrap="">There appears to be something a little odd about the rule they've installed. 

+    route 173.X.X.X/32-DNS-DROP {
+        match {
+            destination 173.X.X.X/32;
+            port 53;
+            packet-length [ 99971 99985 ];
+        }
+        then discard;
+    }

Specifically, they mention "In this case, our attack profiler output the fact that the attack packets were between 99,971 and 99,985 bytes long". Unless there's a typo in the report, the packet-length statement above only includes the two listed.

The other thing that looks weird is that IPv4 supports a maximum packet length header of 16-bits (65,535), so how are packet lengths above this possible?

Kind Regards,
Jonathan



From: <a class="moz-txt-link-abbreviated" href="mailto:ausnog-bounces@lists.ausnog.net">ausnog-bounces@lists.ausnog.net</a> [<a class="moz-txt-link-freetext" href="mailto:ausnog-bounces@lists.ausnog.net">mailto:ausnog-bounces@lists.ausnog.net</a>] On Behalf Of Jeffrey Sims
Sent: Monday, 4 March 2013 8:55 AM
To: Don Gould
Cc: <a class="moz-txt-link-abbreviated" href="mailto:ausnog@lists.ausnog.net">ausnog@lists.ausnog.net</a>
Subject: Re: [AusNOG] Cloudflare offline

+1 for a great approach by Cloudflare!

Agreed, now people know there is a potential bug in JunOS that eegits of the internet might try again (ie: mimik the packet size again to trigger the bug conditions to crash the network). 

Collaboration is the key!

On Mon, Mar 4, 2013 at 8:31 AM, Don Gould <a class="moz-txt-link-rfc2396E" href="mailto:don@bowenvale.co.nz"><don@bowenvale.co.nz></a> wrote:


On 4/03/2013 10:21 a.m., Jethro Carr wrote:
On Mon, 2013-03-04 at 04:37 +1100, Emily Ozols wrote:
So... Who's getting fired?

<bit of snipping...>

the key difference
between a competent engineer and an incompetent one is whether they
followed processes and handled the disaster in a professional manner.

I think a key difference is when people just fess up to a mistake so everyone can learn from it! :)

Nothing worse than wondering what caused the stuff up and if you could have been part of the cause.

Even worse is making a stuff up that you might not have if you'd just known that someone else had done exactly the same thing the week before but didn't share because they were fearful of not being able to feed their kids the next week.

+1 for a great approach by Cloudflare!

D

-- 
Don Gould
31 Acheson Ave
Mairehau
Christchurch, New Zealand
Ph: + 64 3 348 7235
Mobile: + 64 21 114 0699


_______________________________________________
AusNOG mailing list
<a class="moz-txt-link-abbreviated" href="mailto:AusNOG@lists.ausnog.net">AusNOG@lists.ausnog.net</a>
<a class="moz-txt-link-freetext" href="http://lists.ausnog.net/mailman/listinfo/ausnog">http://lists.ausnog.net/mailman/listinfo/ausnog</a>

_______________________________________________
AusNOG mailing list
<a class="moz-txt-link-abbreviated" href="mailto:AusNOG@lists.ausnog.net">AusNOG@lists.ausnog.net</a>
<a class="moz-txt-link-freetext" href="http://lists.ausnog.net/mailman/listinfo/ausnog">http://lists.ausnog.net/mailman/listinfo/ausnog</a>
</pre>
      </blockquote>
      <pre wrap="">
_______________________________________________
AusNOG mailing list
<a class="moz-txt-link-abbreviated" href="mailto:AusNOG@lists.ausnog.net">AusNOG@lists.ausnog.net</a>
<a class="moz-txt-link-freetext" href="http://lists.ausnog.net/mailman/listinfo/ausnog">http://lists.ausnog.net/mailman/listinfo/ausnog</a>
</pre>
    </blockquote>
    <br>
  </body>
</html>