Re: dilemmas

[Randy Bush]

On Thu, 03 Nov 2016 12:03:32 +0900, Royce Williams wrote:
> On Wed, Nov 2, 2016 at 6:47 PM, William Herrin  wrote:
>> On Wed, Nov 2, 2016 at 10:39 PM, Randy Bush  wrote:
>>> the sysadmins' dilemma: do you install today's critical update or
>>> wait a day until the next one is out before you reboot 50 servers?
>>
>> Neither. You wait for the normal patch cycle because the other six
>> barriers to exploiting the vulnerability will work just fine until
>> then.
>>
>> The vulnerability that cuts through every layer of a well engineered
>> defense is rare.
> 
> As is the well-engineered defense.

yep.  and thanks for the forward, reminding my why i have a long
.procmailrc.

Re: dilemmas

[Royce Williams]

On Wed, Nov 2, 2016 at 6:47 PM, William Herrin  wrote:

> On Wed, Nov 2, 2016 at 10:39 PM, Randy Bush  wrote:
> > the sysadmins' dilemma: do you install today's critical update or wait a
> > day until the next one is out before you reboot 50 servers?
>
> Neither. You wait for the normal patch cycle because the other six
> barriers to exploiting the vulnerability will work just fine until
> then.
>
> The vulnerability that cuts through every layer of a well engineered
> defense is rare.
>

As is the well-engineered defense.

Royce

Re: dilemmas

[William Herrin]

On Wed, Nov 2, 2016 at 10:39 PM, Randy Bush  wrote:
> the sysadmins' dilemma: do you install today's critical update or wait a
> day until the next one is out before you reboot 50 servers?

Neither. You wait for the normal patch cycle because the other six
barriers to exploiting the vulnerability will work just fine until
then.

The vulnerability that cuts through every layer of a well engineered
defense is rare.

Regards,
Bill Herrin


-- 
William Herrin  her...@dirtside.com  b...@herrin.us
Owner, Dirtside Systems . Web: 

dilemmas

[Randy Bush]

the users' dilemma: do you buy a mac today, or wait six month hoping
they will fix X (for your particular X)?

the sysadmins' dilemma: do you install today's critical update or wait a
day until the next one is out before you reboot 50 servers?

Re: Syn flood to TCP port 21 from priveleged port (80)

[Theodore Baschak]

This might be a little late on this thread, however I just saw the
following news item on twitter which seemed pertinent to this story:
http://www.theregister.co.uk/2016/11/02/william_hill_ddos/
I guess they're a bookie who's under DDoS?


Theodore Baschak - AS395089 - Hextet Systems
https://ciscodude.net/ - https://hextet.systems/
http://mbix.ca/


On Wed, Nov 2, 2016 at 3:46 AM, Christian Kildau  wrote:

> There is some nice research regarding systems "abusable" for reflection by
> tcp port and the amplification factor depending on the OS:
> http://www.christian-rossow.de/publications/tcpamplification-woot2014.pdf
>
> And in more detail:
> https://www.usenix.org/system/files/conference/
> usenixsecurity14/sec14-paper-
> kuhrer.pdf
>
> Best regards,
> Chris
>
> On Tue, Nov 1, 2016 at 11:21 PM, Ken Chase  wrote:
>
> > what's the density of open port 21s on the planet though? trying to
> > estimate
> > the traffic resulting against the two target /21s.
> >
> > Your dump only has 2 ip's in it though, on your /19 so not
> representative.
> >
> > My dump is 500 synacks returned in 14 seconds to 32 ips in a /22. This
> > would give
> > 128M ftp responders across the whole /0 (modulo actual space in use, etc,
> > so call it 32M responders?). (It's also a short timespan for a dump as
> > well.)
> > Syn-ack seems to be a 58 byte packet (?ish).
> >
> > 32 * 10^6 * 500/14 * 58*8 / 10^9 = 530 Gbps
> >
> > even if im off by 4 in density of ftp sites on the internet despite my
> > already
> > reducing it by 4, we're talking ~100+ Gbps.
> >
> > /kc
> >
> >
> > On Tue, Nov 01, 2016 at 03:59:49PM -0600, Selphie Keller said:
> >   >Yeah it is an odd ball attack for sure, here is a 5000 packet sample
> of
> >   >what I was seeing in connection to this attack
> >   >https://mystagic.io/80to21.pcap , don't think it's the entire /0 for
> > ftp
> >   >port as I am not seeing it on many other subnets, which is why I am
> >   >thinking someone did a pre-scan before conducting this wacky attack,
> >   >otherwise, I would have likely seen other port 21's seeing activity,
> > but so
> >   >far any IP that didn't have 21 as an actual service isn't seeing the
> syn
> >   >packets. This could be unique to my location, others observing this
> > attack
> >   >may be able to chime in and report what they are seeing if they seen
> 80
> > src
> >   >syn to port 21 where 21 isn't an actual ftp running. Yeah this is
> pretty
> >   >easy to filter.
> >   >
> >   >On 1 November 2016 at 13:48, Ken Chase  wrote:
> >   >
> >   >> Not sure why reflected RSTs are the goal here, they're not much of
> an
> >   >> amplification
> >   >> to the original syn size. Additionally causing a mild dos of my
> > clients'
> >   >> stuff
> >   >> when it begins throttling # of connections, ie noticeable. (not
> that i
> >   >> want to
> >   >> help scriptkids improve their attacks...). Im guessing port 80 was
> > chosen
> >   >> for improved
> >   >> fw piercing.
> >   >>
> >   >> Sure is widespread though, 5 clients on very different networks all
> > seeing
> >   >> similar
> >   >> saturation. Someone has a nice complete prescanned list of open ftps
> > for
> >   >> the
> >   >> entire internet out there (or are they just saturating the whole
> /0?)
> >   >>
> >   >> Easy to filter though:
> >   >>
> >   >> tcp and src port 80 and src net '(141.138.128.0/21 or
> 95.131.184.0/21
> > )'
> >   >> and dst port 21
> >   >>
> >   >> Adapt for your fw rules of choice.
> >   >>
> >   >> /kc
> >   >>
> >   >>
> >   >> On Tue, Nov 01, 2016 at 07:39:40PM +, Van Dyk, Donovan said:
> >   >>   >I think Ken has nailed it. I think the source addresses are
> > spoofed so
> >   >> you reflect the connection (tcp syn ack) to those source addresses.
> > Get
> >   >> enough of those connections and the server is dead.
> >   >>   >
> >   >>   >Since your port 21 is open
> >   >>   >
> >   >>   >telnet 109.72.248.114 21
> >   >>   >Trying 109.72.248.114...
> >   >>   >Connected to 109.72.248.114.
> >   >>   >Escape character is '^]'.
> >   >>   >
> >   >>   >Your address was probably scanned and saw it could be used in the
> >   >> attack.
> >   >>   >
> >   >>   >Regards
> >   >>   >--
> >   >>   >Donovan Van Dyk
> >   >>   >
> >   >>   >SOC Network Engineer
> >   >>   >
> >   >>   >Office: +1.954.620.6002 x911
> >   >>   >
> >   >>   >Fort Lauderdale, FL USA
> >   >>   >
> >   >>   >
> >   >>   >
> >   >>   >
> >   >>   >The information contained in this electronic mail transmission
> and
> > its
> >   >> attachments may be privileged and confidential and protected from
> >   >> disclosure. If the reader of this message is not the intended
> > recipient (or
> >   >> an individual responsible for delivery of the message to such
> > person), you
> >   >> are strictly prohibited from copying, disseminating or distributing
> > this
> >   >> communication. If you have received this communication in error,
> > please
> >   >> notify 

Re: Syn flood to TCP port 21 from priveleged port (80)

[Christian Kildau]

There is some nice research regarding systems "abusable" for reflection by
tcp port and the amplification factor depending on the OS:
http://www.christian-rossow.de/publications/tcpamplification-woot2014.pdf

And in more detail:
https://www.usenix.org/system/files/conference/usenixsecurity14/sec14-paper-
kuhrer.pdf

Best regards,
Chris

On Tue, Nov 1, 2016 at 11:21 PM, Ken Chase  wrote:

> what's the density of open port 21s on the planet though? trying to
> estimate
> the traffic resulting against the two target /21s.
>
> Your dump only has 2 ip's in it though, on your /19 so not representative.
>
> My dump is 500 synacks returned in 14 seconds to 32 ips in a /22. This
> would give
> 128M ftp responders across the whole /0 (modulo actual space in use, etc,
> so call it 32M responders?). (It's also a short timespan for a dump as
> well.)
> Syn-ack seems to be a 58 byte packet (?ish).
>
> 32 * 10^6 * 500/14 * 58*8 / 10^9 = 530 Gbps
>
> even if im off by 4 in density of ftp sites on the internet despite my
> already
> reducing it by 4, we're talking ~100+ Gbps.
>
> /kc
>
>
> On Tue, Nov 01, 2016 at 03:59:49PM -0600, Selphie Keller said:
>   >Yeah it is an odd ball attack for sure, here is a 5000 packet sample of
>   >what I was seeing in connection to this attack
>   >https://mystagic.io/80to21.pcap , don't think it's the entire /0 for
> ftp
>   >port as I am not seeing it on many other subnets, which is why I am
>   >thinking someone did a pre-scan before conducting this wacky attack,
>   >otherwise, I would have likely seen other port 21's seeing activity,
> but so
>   >far any IP that didn't have 21 as an actual service isn't seeing the syn
>   >packets. This could be unique to my location, others observing this
> attack
>   >may be able to chime in and report what they are seeing if they seen 80
> src
>   >syn to port 21 where 21 isn't an actual ftp running. Yeah this is pretty
>   >easy to filter.
>   >
>   >On 1 November 2016 at 13:48, Ken Chase  wrote:
>   >
>   >> Not sure why reflected RSTs are the goal here, they're not much of an
>   >> amplification
>   >> to the original syn size. Additionally causing a mild dos of my
> clients'
>   >> stuff
>   >> when it begins throttling # of connections, ie noticeable. (not that i
>   >> want to
>   >> help scriptkids improve their attacks...). Im guessing port 80 was
> chosen
>   >> for improved
>   >> fw piercing.
>   >>
>   >> Sure is widespread though, 5 clients on very different networks all
> seeing
>   >> similar
>   >> saturation. Someone has a nice complete prescanned list of open ftps
> for
>   >> the
>   >> entire internet out there (or are they just saturating the whole /0?)
>   >>
>   >> Easy to filter though:
>   >>
>   >> tcp and src port 80 and src net '(141.138.128.0/21 or 95.131.184.0/21
> )'
>   >> and dst port 21
>   >>
>   >> Adapt for your fw rules of choice.
>   >>
>   >> /kc
>   >>
>   >>
>   >> On Tue, Nov 01, 2016 at 07:39:40PM +, Van Dyk, Donovan said:
>   >>   >I think Ken has nailed it. I think the source addresses are
> spoofed so
>   >> you reflect the connection (tcp syn ack) to those source addresses.
> Get
>   >> enough of those connections and the server is dead.
>   >>   >
>   >>   >Since your port 21 is open
>   >>   >
>   >>   >telnet 109.72.248.114 21
>   >>   >Trying 109.72.248.114...
>   >>   >Connected to 109.72.248.114.
>   >>   >Escape character is '^]'.
>   >>   >
>   >>   >Your address was probably scanned and saw it could be used in the
>   >> attack.
>   >>   >
>   >>   >Regards
>   >>   >--
>   >>   >Donovan Van Dyk
>   >>   >
>   >>   >SOC Network Engineer
>   >>   >
>   >>   >Office: +1.954.620.6002 x911
>   >>   >
>   >>   >Fort Lauderdale, FL USA
>   >>   >
>   >>   >
>   >>   >
>   >>   >
>   >>   >The information contained in this electronic mail transmission and
> its
>   >> attachments may be privileged and confidential and protected from
>   >> disclosure. If the reader of this message is not the intended
> recipient (or
>   >> an individual responsible for delivery of the message to such
> person), you
>   >> are strictly prohibited from copying, disseminating or distributing
> this
>   >> communication. If you have received this communication in error,
> please
>   >> notify the sender immediately and destroy all electronic, paper or
> other
>   >> versions.
>   >>   >
>   >>   >
>   >>   >On 11/1/16, 3:29 PM, "Ken Chase"  wrote:
>   >>   >
>   >>   >seeing an awful lot of port 80 hitting port 21. (Why would
> port 80
>   >>   >ever be used as source?). Also saw a buncha cpanel "FAILED:
> FTP"
>   >> alerts flickering
>   >>   >on and off as the service throttled itself at a couple client
> sites
>   >> I manage.
>   >>   >
>   >>   >I see 540 unique source IPs hitting 32 destinations on my
> network
>   >> in just 1000
>   >>   >packets dumped on one router.
>   >>   >
>   >>   >All from multiple sequential registered 

Re: Large BGP Communities beacon in the wild

[Mark Tinka]

On 27/Oct/16 08:19, Job Snijders wrote:

> Please verify if you can see 192.147.168.0/24 and 2001:67c:208c::/48

Looks good for me.

Both come with:

unknown transitive attribute: flag 0xE0 type 0x20 length 0xC
value  3CCA  0001  0001

Mark.

Re: MPLS in the campus Network?

[Mark Tinka]

On 24/Oct/16 22:13, Wayne Bouchard wrote:

> If the reason for L2 transport is purely customer driven and purely
> ptp, then a L2 VPN solution would be better than directly transporting
> the frames. If you don't have to bridge it directly, don't. Keep the
> core at layer 3 wherever possible. L2 can be very hard to debug when
> there are issues.

Not sure I understand - are you advocating for EoMPLS (l2vpn) over
EoDWDM more often than not, if possible?.

Mark.