Re: [j-nsp] NTP Reflection

[Mark Tees]

Thanks Ben I will review those links.

I have the MX book and have read a decent portion of it. Thats what I was
referring to. A quick glance shows some similar examples as to what was in
the MX book. Same author so it makes sense.


On Tue, Jan 14, 2014 at 2:52 PM, Ben Dale  wrote:

>
> On 14 Jan 2014, at 12:31 pm, Mark Tees  wrote:
>
> > What I was referring to was a detailed ACL/Filter for lo0 that only
> allows
> > traffic for enabled services on the routing engine.
> >
> > For example if Juniper posted a firewall filter template with all the
> > possible services customers could then activate/deactivate what they need
> > from the policy and log fails before discarding etc.
>
> What you think you're after is "show system connections" which is more or
> less "netstat -an" and shows all ports that are listening on your RE - you
> can now filter at will.
>
> Providing a list of every service for people to modify is not going to
> solve these problems - "Oh hey, I'm using NTP, I'd better enable all those
> rules"..
>
> What you actually want is an ACL with ONLY the services you've actually
> configured and understand from the source/destinations you're using them
> from and deny all else - then you *mostly* don't need to worry about this
> sort of thing.
>
> If your employer is too tight to spring for the MX book (worth every cent
> and then some), the following free Day One books will provide everything
> you're after (sign up for a J-Net login if you don't already have one):
>
>
> http://www.juniper.net/us/en/community/junos/training-certification/day-one/fundamentals-series/securing-routing-engine/
>
> http://www.juniper.net/us/en/community/junos/training-certification/day-one/fundamentals-series/hardening-junos-devices-checklist/
>
> http://www.juniper.net/us/en/community/junos/training-certification/day-one/fundamentals-series/configuring-junos-policies/
>
> Ben




-- 
Regards,

Mark L. Tees
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] NTP Reflection

[Ben Dale]

On 14 Jan 2014, at 12:31 pm, Mark Tees  wrote:

> What I was referring to was a detailed ACL/Filter for lo0 that only allows
> traffic for enabled services on the routing engine.
> 
> For example if Juniper posted a firewall filter template with all the
> possible services customers could then activate/deactivate what they need
> from the policy and log fails before discarding etc.

What you think you're after is "show system connections" which is more or less 
"netstat -an" and shows all ports that are listening on your RE - you can now 
filter at will.

Providing a list of every service for people to modify is not going to solve 
these problems - "Oh hey, I'm using NTP, I'd better enable all those rules"..

What you actually want is an ACL with ONLY the services you've actually 
configured and understand from the source/destinations you're using them from 
and deny all else - then you *mostly* don't need to worry about this sort of 
thing.

If your employer is too tight to spring for the MX book (worth every cent and 
then some), the following free Day One books will provide everything you're 
after (sign up for a J-Net login if you don't already have one):

http://www.juniper.net/us/en/community/junos/training-certification/day-one/fundamentals-series/securing-routing-engine/
http://www.juniper.net/us/en/community/junos/training-certification/day-one/fundamentals-series/hardening-junos-devices-checklist/
http://www.juniper.net/us/en/community/junos/training-certification/day-one/fundamentals-series/configuring-junos-policies/

Ben
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] NTP Reflection

[Mark Tees]

Of course.

I don't know if that means you should negate a decent local filter on a box.


On Tue, Jan 14, 2014 at 1:51 PM, Dobbins, Roland  wrote:

>
> On Jan 14, 2014, at 9:31 AM, Mark Tees  wrote:
>
> > Not "Oh, NTP attacks are the flavour of the day! We better post a
> security KB article about it."
>
> If one has implemented iACLs at the edges of one's network, wouldn't this
> by default shield the ntp service on the router from abuse from the
> Internet at large?
>
> ---
> Roland Dobbins  // 
>
>   Luck is the residue of opportunity and design.
>
>-- John Milton
>
>
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>



-- 
Regards,

Mark L. Tees
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] NTP Reflection

[Mark Tees]

I hope I am wrong here but the only place I have seen a decent example of
an accurate and secure lo0 firewall filter was in the Juniper MX series
book?


On Tue, Jan 14, 2014 at 9:44 AM, Paul S.  wrote:

> On 1/14/2014 午前 07:14, Jared Mauch wrote:
>
>> On Jan 13, 2014, at 5:03 PM, Chuck Anderson  wrote:
>>
>>  Shouldn't this be SOP anyway?
>>>
>> In the past many ISPs provided time to customers from the router
>> hardware.  The difference I’ve seen here is regarding the speed that
>> devices will respond.  The Juniper devices have a faster processor so will
>> respond much faster than an “ISR” device from other vendors.  The lack of
>> ability to further tweak the ntp.conf is a bit frustrating.
>>
>> - Jared
>>
>>
>> ___
>> juniper-nsp mailing list juniper-nsp@puck.nether.net
>> https://puck.nether.net/mailman/listinfo/juniper-nsp
>>
>
> I've never really seen any ISPs who actually use proper firewall filters
> to allow NTP requests on the routers publicly; so it's 'somewhat'
> manageable - still.
>
> Granted, Juniper should have ways to distinguish client behavior from
> server behavior, still.
>
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>



-- 
Regards,

Mark L. Tees
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] NTP Reflection

[Dobbins, Roland]

On Jan 14, 2014, at 9:31 AM, Mark Tees  wrote:

> Not "Oh, NTP attacks are the flavour of the day! We better post a security KB 
> article about it."

If one has implemented iACLs at the edges of one's network, wouldn't this by 
default shield the ntp service on the router from abuse from the Internet at 
large?

---
Roland Dobbins  // 

  Luck is the residue of opportunity and design.

   -- John Milton


___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] NTP Reflection

[Mark Tees]

Thanks John,

I should have been more specific about what I meant.

Just filtering for NTP traffic in a firewall filter is fine and easy.

What I was referring to was a detailed ACL/Filter for lo0 that only allows
traffic for enabled services on the routing engine.

For example if Juniper posted a firewall filter template with all the
possible services customers could then activate/deactivate what they need
from the policy and log fails before discarding etc.

There was a very good example in the Juniper MX series book under the
security section.

What I am getting at is that Juniper should be providing security templates
like this in a KB article. It should be straight forward easy to access
information. Not "Oh, NTP attacks are the flavour of the day! We better
post a security KB article about it."

Much like what is listed here except maintained by Juniper and detailed
enough to include everything enabled:
http://www.cymru.com/gillsr/documents/junos-template.htm

In the mean time I will use the example from the MX series book in my
config templates.

Mark


On Tue, Jan 14, 2014 at 1:10 PM, John Kristoff  wrote:

> On Tue, 14 Jan 2014 12:38:12 +1100
> Mark Tees  wrote:
>
> > Can we get detailed lo0 filters listed too please?
>
> Hi Mark,
>
> While I'll defer to Juniper for their recommendations, we've had this
> for some time (scroll down to the Juniper section):
>
>   <
> http://www.team-cymru.org/ReadingRoom/Templates/secure-ntp-template.html>
>
> John
>



-- 
Regards,

Mark L. Tees
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] NTP Reflection

[John Kristoff]

On Tue, 14 Jan 2014 12:38:12 +1100
Mark Tees  wrote:

> Can we get detailed lo0 filters listed too please?

Hi Mark,

While I'll defer to Juniper for their recommendations, we've had this
for some time (scroll down to the Juniper section):

  

John
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] NTP Reflection

[Mark Tees]

Oh oh someones listening just received:
JSA10613Mitigation
of NTP amplification attacks involving Junos

Can we get detailed lo0 filters listed too please?





On Tue, Jan 14, 2014 at 9:53 AM, Mark Tees  wrote:

> I hope I am wrong here but the only place I have seen a decent example of
> an accurate and secure lo0 firewall filter was in the Juniper MX series
> book?
>
>
> On Tue, Jan 14, 2014 at 9:44 AM, Paul S.  wrote:
>
>> On 1/14/2014 午前 07:14, Jared Mauch wrote:
>>
>>> On Jan 13, 2014, at 5:03 PM, Chuck Anderson  wrote:
>>>
>>>  Shouldn't this be SOP anyway?

>>> In the past many ISPs provided time to customers from the router
>>> hardware.  The difference I’ve seen here is regarding the speed that
>>> devices will respond.  The Juniper devices have a faster processor so will
>>> respond much faster than an “ISR” device from other vendors.  The lack of
>>> ability to further tweak the ntp.conf is a bit frustrating.
>>>
>>> - Jared
>>>
>>>
>>> ___
>>> juniper-nsp mailing list juniper-nsp@puck.nether.net
>>> https://puck.nether.net/mailman/listinfo/juniper-nsp
>>>
>>
>> I've never really seen any ISPs who actually use proper firewall filters
>> to allow NTP requests on the routers publicly; so it's 'somewhat'
>> manageable - still.
>>
>> Granted, Juniper should have ways to distinguish client behavior from
>> server behavior, still.
>>
>> ___
>> juniper-nsp mailing list juniper-nsp@puck.nether.net
>> https://puck.nether.net/mailman/listinfo/juniper-nsp
>>
>
>
>
> --
> Regards,
>
> Mark L. Tees
>



-- 
Regards,

Mark L. Tees
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] NTP Reflection

[John Kristoff]

On Mon, 13 Jan 2014 20:47:08 -0500
ML  wrote:

> Juniper didn't want to be outdone by Cisco.  Cisco devices act the
> same way once they are configured as NTP clients.

IOS devices, at least those with which I'm familiar, don't implement the
full specification that includes mode 6/7 functions so they can be
somewhat less bad from an amplification perspective.

John
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] NTP Reflection

[ML]

On 1/13/2014 4:25 PM, Richard A Steenbergen wrote:

Dear Juniper,

Please tell me you didn't actually do this. Please tell me that I'm just
missing something, and that you would never do something so insane. Did
you guys REALLY ship code that automatically enables an NTP server that
responds to the world, with no authentication or options to restrict
access or commands, whenever someone configures the router to be an NTP
client? Because that's sure what it looks like.



Juniper didn't want to be outdone by Cisco.  Cisco devices act the same 
way once they are configured as NTP clients.

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] NTP Reflection

[Paul S.]

On 1/14/2014 午前 07:14, Jared Mauch wrote:

On Jan 13, 2014, at 5:03 PM, Chuck Anderson  wrote:


Shouldn't this be SOP anyway?

In the past many ISPs provided time to customers from the router hardware.  The 
difference I’ve seen here is regarding the speed that devices will respond.  
The Juniper devices have a faster processor so will respond much faster than an 
“ISR” device from other vendors.  The lack of ability to further tweak the 
ntp.conf is a bit frustrating.

- Jared


___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp


I've never really seen any ISPs who actually use proper firewall filters 
to allow NTP requests on the routers publicly; so it's 'somewhat' 
manageable - still.


Granted, Juniper should have ways to distinguish client behavior from 
server behavior, still.

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] NTP Reflection

[Chris Adams]

Once upon a time, Richard A Steenbergen  said:
> Please tell me you didn't actually do this. Please tell me that I'm just
> missing something, and that you would never do something so insane. Did
> you guys REALLY ship code that automatically enables an NTP server that
> responds to the world, with no authentication or options to restrict
> access or commands, whenever someone configures the router to be an NTP
> client? Because that's sure what it looks like.

That is the case.  A co-worker at my PPOE went through this last week;
an NTP reflection attack to a Juniper M10i OC-3 interface to the
Internet caused routing protocols to flap repeatedly because it
overloaded the RE (so not just participating in somebody else's DDoS but
also crippling the router).

This appears to be the case on all JUNOS routers and switches
(everything I tried anyway).  "restrict default ignore" should be the
default, with an option to disable that or allow more remote devices to
monitor your NTP.

AFAIK the only current way to fix is it firewall filter on lo0 that
limits inbound UDP port 123 to be from your NTP servers (and monitoring
system, if you monitor NTP).
-- 
Chris Adams 
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

[j-nsp] Thoroughly confused about matching forwarding class in firewall filters

[John Neiberger]

I'm trying to troubleshoot a one-way audio problem and I'm very
confused. The traffic is marked as EF but it's not making it to the
destination. The egress interface has a firewall filter that at first
glance appears to permit all EF:

term permit-fec-ef {
from {
forwarding-class VOIP-BEARER;
}
then {
count fec-ef;
accept;
}
}

However, I wondered about the forwarding class and how it is
configured or derived when applied to a firewall filter. I'm still
fairly green when it comes to Junos, so the first place I checked was
"show configuration class-of-service forwarding-classes" but that just
showed me this:

class VOIP-BEARER queue-num 3 priority high;

That's clearly not what I'm looking for because that has no way to
identify the traffic.

Next, I thought perhaps it was configured under the classifiers, so I
looked there. However, I found several classifiers that had the same
forwarding class configured, so now I think that there must be a way
to know which of those forwarding classes is really being referred to
in the firewall filter. I next assume that the forwarding class must
be related to the one associated with the classifier applied to the
interface. This is a subinterface that has a ieee-802.1p classifier
associated with it named DOT1P-CLASSIFIER, which looks like this:

forwarding-class BASIC-DATA {
loss-priority low code-points [ DOT1P-0 DOT1P-1 DOT1P-2 DOT1P-4
DOT1P-6 DOT1P-7 ];
}
forwarding-class PRIORITY-DATA {
loss-priority high code-points DOT1P-3;
}
forwarding-class PREMIUM-DATA {
loss-priority low code-points DOT1P-5;
}

It doesn't have a forwarding class named VOIP-BEARER at all. So, how
in the world does matching on a forwarding class in a firewall filter
work? How does the filter know which forwarding class is being
referenced if you match on a forwarding class? And in my case, the
egress interface does not have a forwarding class with that name in
the classifier associated with the interface, so what is the firewall
filter even matching?

Junos class of service is the bane of my existence. Once in a while I
think I have it figured out how all these pieces fit together, but
then something like this comes up and ruins my fantasy. :-)
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] NTP Reflection

[Jared Mauch]

On Jan 13, 2014, at 5:03 PM, Chuck Anderson  wrote:

> Shouldn't this be SOP anyway?

In the past many ISPs provided time to customers from the router hardware.  The 
difference I’ve seen here is regarding the speed that devices will respond.  
The Juniper devices have a faster processor so will respond much faster than an 
“ISR” device from other vendors.  The lack of ability to further tweak the 
ntp.conf is a bit frustrating.

- Jared


___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] NTP Reflection

[Jared Mauch]

On Jan 13, 2014, at 4:25 PM, Richard A Steenbergen  wrote:

> Dear Juniper,
> 
> Please tell me you didn't actually do this. Please tell me that I'm just 
> missing something, and that you would never do something so insane. Did 
> you guys REALLY ship code that automatically enables an NTP server that 
> responds to the world, with no authentication or options to restrict 
> access or commands, whenever someone configures the router to be an NTP 
> client? Because that's sure what it looks like.
> 
> The documentation on the subject is interesting too:
> 
> http://www.juniper.net/techpubs/en_US/junos13.1/topics/task/configuration/network-time-protocol-time-server-time-services-configuring.html
> 
> Configuring the Router or Switch to Operate in Client Mode:
> * Do something
> 
> Configuring the Router or Switch to Operate in Server Mode:
> * Do the exact same thing
> 
> Sigh... I'd be more disappointed, but hey it doesn't crash anything when 
> someone uses your routers as an NTP reflection attack amplifier, so I 
> suppose you can at least be proud of that.
> 
> For anyone who doesn't know what I'm talking about, you might want to 
> read:
> 
> http://blog.cloudflare.com/understanding-and-mitigating-ntp-based-ddos-attacks
> https://isc.sans.edu/forums/diary/NTP+reflection+attack/17300
> 
> And then start making sure UDP/123 is blocked in your lo0 firewall 
> filters.

I’ve not seen any way other than firewall filters to mitigate this traffic.  
There is a juniper “enhancement” pending to upgrade the NTP version.

- Jared
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] NTP Reflection

[Chuck Anderson]

On Mon, Jan 13, 2014 at 03:25:19PM -0600, Richard A Steenbergen wrote:
> And then start making sure UDP/123 is blocked in your lo0 firewall 
> filters.

Shouldn't this be SOP anyway?
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

[j-nsp] NTP Reflection

[Richard A Steenbergen]

Dear Juniper,

Please tell me you didn't actually do this. Please tell me that I'm just 
missing something, and that you would never do something so insane. Did 
you guys REALLY ship code that automatically enables an NTP server that 
responds to the world, with no authentication or options to restrict 
access or commands, whenever someone configures the router to be an NTP 
client? Because that's sure what it looks like.

The documentation on the subject is interesting too:

http://www.juniper.net/techpubs/en_US/junos13.1/topics/task/configuration/network-time-protocol-time-server-time-services-configuring.html

Configuring the Router or Switch to Operate in Client Mode:
* Do something

Configuring the Router or Switch to Operate in Server Mode:
* Do the exact same thing

Sigh... I'd be more disappointed, but hey it doesn't crash anything when 
someone uses your routers as an NTP reflection attack amplifier, so I 
suppose you can at least be proud of that.

For anyone who doesn't know what I'm talking about, you might want to 
read:

http://blog.cloudflare.com/understanding-and-mitigating-ntp-based-ddos-attacks
https://isc.sans.edu/forums/diary/NTP+reflection+attack/17300

And then start making sure UDP/123 is blocked in your lo0 firewall 
filters.

-- 
Richard A Steenbergenhttp://www.e-gerbil.net/ras
GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Power adapter spec for AX411?

[Maarten van der Hoek]

Officially they are already

http://www.juniper.net/us/en/products-services/end-of-sale/ax411/

Brgds,

Maarten

-Oorspronkelijk bericht-
Van: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] Namens ashish
verma
Verzonden: maandag 13 januari 2014 13:14
Aan: Mark Menzies
CC: juniper-nsp
Onderwerp: Re: [j-nsp] Power adapter spec for AX411?

btw it seem ax411 will be EOL soon..


On Sun, Jan 12, 2014 at 9:51 PM, Mark Menzies  wrote:

> Same here. POE is the way to go.
>
> Mark Menzies
> sent via mobile device, please excuse errors On 12 Jan 2014 02:14, 
> "OBrien, Will"  wrote:
>
> > I just used PoE. You can get a PoE injector pretty easily.
> >
> > On Jan 11, 2014, at 1:20 PM, Chris Woodfield 
> >  wrote:
> >
> > > Anyone know what type of power adapter (apart from ordering one
> directly
> > from Juniper) I'd need to power an AX411 wireless AP? Or would I be
> better
> > off simply getting an inline POE splitter?
> > >
> > > -C
> > > ___
> > > juniper-nsp mailing list juniper-nsp@puck.nether.net 
> > > https://puck.nether.net/mailman/listinfo/juniper-nsp
> >
> >
> > ___
> > juniper-nsp mailing list juniper-nsp@puck.nether.net 
> > https://puck.nether.net/mailman/listinfo/juniper-nsp
> >
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net 
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Power adapter spec for AX411?

[ashish verma]

btw it seem ax411 will be EOL soon..


On Sun, Jan 12, 2014 at 9:51 PM, Mark Menzies  wrote:

> Same here. POE is the way to go.
>
> Mark Menzies
> sent via mobile device, please excuse errors
> On 12 Jan 2014 02:14, "OBrien, Will"  wrote:
>
> > I just used PoE. You can get a PoE injector pretty easily.
> >
> > On Jan 11, 2014, at 1:20 PM, Chris Woodfield 
> >  wrote:
> >
> > > Anyone know what type of power adapter (apart from ordering one
> directly
> > from Juniper) I’d need to power an AX411 wireless AP? Or would I be
> better
> > off simply getting an inline POE splitter?
> > >
> > > -C
> > > ___
> > > juniper-nsp mailing list juniper-nsp@puck.nether.net
> > > https://puck.nether.net/mailman/listinfo/juniper-nsp
> >
> >
> > ___
> > juniper-nsp mailing list juniper-nsp@puck.nether.net
> > https://puck.nether.net/mailman/listinfo/juniper-nsp
> >
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp