Mailing List Archive

On Wed, 20 Jun 2012, Morgan McLean wrote:

> I have a /24 I want to announce, but I don't actually have it anywhere on
> the network. I NAT some of its IP's on the SRX that has the BGP session
> with our providers.
>
> I've been using static routes with the discard flag, but I don't really
> like the way the SRX handles traffic. It still creates sessions for traffic
> destined to IP's not used anywhere (hitting the static route) and can be
> easily dos'd because of this.

I'm curious what you mean by 'dos' in this scenario. You can use an
aggregate to tell the router to advertise the /24 as long as at least a
portion of it exists in your IGP.

> Is there a better way to just tell our providers hey, we have this range?

If you're multi-homed (you didn't say, so I'm not sure), you need to
announce prefixes using BGP. If you're not multi-homed, you could have
your upstream provider announce the /24 for you, and statically route it
to you, but that doesn't change the fact that you would get traffic for
all of the addresses in that range.

You could also use a firewall filter to throw away packets that are
destined for addresses/ranges that you're not using in that /24.

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

> I have a /24 I want to announce, but I don't actually have it anywhere on
> the network. I NAT some of its IP's on the SRX that has the BGP session
> with our providers.
Static discard is really the best way. Aggregate/generate routes are
also theoretically possible, but if you are not sure you really need
some sort of external dynamism, it's better to nail it down with static
— less chances to have your routes damped somewhere after an internal
link flap.
>
> I've been using static routes with the discard flag, but I don't really
> like the way the SRX handles traffic. It still creates sessions for traffic
> destined to IP's not used anywhere (hitting the static route) and can be
> easily dos'd because of this.
I saw such a thing a couple of times and it was not because SRX handles
traffic wrongly, but due to some sort of misconfiguration. If a packet
fell under the discard route, the session would not be created
(otherwise you caught a real showstopper bug, but I don't much believe
in this, to be honest). Moreover, in order to have a session established
you also need a security policy permit.

1. Check the route where the packets actually fall under with "show
security flow session session-identifier <xxxx>". Very likely that your
packets actually fall under a longer specific route. Say, automatically
generated for proxy-arp or something like.

2. Check the zones, from and to which the sessions are established,
which policy permits the traffic. As of what you describe, policies
should block such traffic anyway.

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

On Wed, Jun 20, 2012 at 10:14 PM, Morgan McLean <wrx230@gmail.com> wrote:

> I have a /24 I want to announce, but I don't actually have it anywhere on
> the network. I NAT some of its IP's on the SRX that has the BGP session
> with our providers.
>
> I've been using static routes with the discard flag, but I don't really
> like the way the SRX handles traffic. It still creates sessions for traffic
> destined to IP's not used anywhere (hitting the static route) and can be
> easily dos'd because of this.
>
> Is there a better way to just tell our providers hey, we have this range?
>
>
It sounds like you're using the SRX as an edge router with a BGP session
upstream?

I don't have this architecture here, but I had the same problem. I had my
edge router announce the /24 to the BGP upstreams, and my SRX announce the
/24 via OSPF to the MX.

Unfortunately, one of my IPs was hammered, and filled up the session table
with invalid sessions. That's the real issue, at least in my case, was
that even invalid sessions were taking a session, and prohibiting
legitimate traffic from flowing.

The solution was only to announce from SRX to MX (edge router) the /32s
that were actually in use.

I suppose that a firewall filter may help on your ingress ports to only
permit the traffic to the /32s that are actually in use, but I can't say
from experience if this will happen before a session is created, even in
invalid state.

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

The static discard works just fine, but from what from I recall a simple
static route would not insert the ATOMIC_AGGREGATE into BGP.

For example to advertise 192.168.1.0/24 with ATOMIC_AGGREGATE.

set routing-options static route 192.168.1.1/32 discard (contributing
route)
set routing-options aggregate route 192.168.1/24 as-path atomic-aggregate
(atomic aggregate)

Thank you,

--
Doug Hanks - JNCIE-ENT #213, JNCIE-SP #875
Sr. Systems Engineer
Juniper Networks


On 6/22/12 4:26 AM, "EXT - plunin@senetsy.ru" <plunin@senetsy.ru> wrote:

>
>
>> I have a /24 I want to announce, but I don't actually have it anywhere
>>on
>> the network. I NAT some of its IP's on the SRX that has the BGP session
>> with our providers.
>Static discard is really the best way. Aggregate/generate routes are
>also theoretically possible, but if you are not sure you really need
>some sort of external dynamism, it's better to nail it down with static
>‹ less chances to have your routes damped somewhere after an internal
>link flap.
>>
>> I've been using static routes with the discard flag, but I don't really
>> like the way the SRX handles traffic. It still creates sessions for
>>traffic
>> destined to IP's not used anywhere (hitting the static route) and can be
>> easily dos'd because of this.
>I saw such a thing a couple of times and it was not because SRX handles
>traffic wrongly, but due to some sort of misconfiguration. If a packet
>fell under the discard route, the session would not be created
>(otherwise you caught a real showstopper bug, but I don't much believe
>in this, to be honest). Moreover, in order to have a session established
>you also need a security policy permit.
>
>1. Check the route where the packets actually fall under with "show
>security flow session session-identifier <xxxx>". Very likely that your
>packets actually fall under a longer specific route. Say, automatically
>generated for proxy-arp or something like.
>
>2. Check the zones, from and to which the sessions are established,
>which policy permits the traffic. As of what you describe, policies
>should block such traffic anyway.
>
>_______________________________________________
>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

What protocol do these aggregates show up under? Not static?

Morgan

Sent from my iPhone

On Jun 22, 2012, at 9:15 AM, Doug Hanks <dhanks@juniper.net> wrote:

> The static discard works just fine, but from what from I recall a simple
> static route would not insert the ATOMIC_AGGREGATE into BGP.
>
> For example to advertise 192.168.1.0/24 with ATOMIC_AGGREGATE.
>
> set routing-options static route 192.168.1.1/32 discard (contributing
> route)
> set routing-options aggregate route 192.168.1/24 as-path atomic-aggregate
> (atomic aggregate)
>
> Thank you,
>
> --
> Doug Hanks - JNCIE-ENT #213, JNCIE-SP #875
> Sr. Systems Engineer
> Juniper Networks
>
>
> On 6/22/12 4:26 AM, "EXT - plunin@senetsy.ru" <plunin@senetsy.ru> wrote:
>
>>
>>
>>> I have a /24 I want to announce, but I don't actually have it anywhere
>>> on
>>> the network. I NAT some of its IP's on the SRX that has the BGP session
>>> with our providers.
>> Static discard is really the best way. Aggregate/generate routes are
>> also theoretically possible, but if you are not sure you really need
>> some sort of external dynamism, it's better to nail it down with static
>> ‹ less chances to have your routes damped somewhere after an internal
>> link flap.
>>>
>>> I've been using static routes with the discard flag, but I don't really
>>> like the way the SRX handles traffic. It still creates sessions for
>>> traffic
>>> destined to IP's not used anywhere (hitting the static route) and can be
>>> easily dos'd because of this.
>> I saw such a thing a couple of times and it was not because SRX handles
>> traffic wrongly, but due to some sort of misconfiguration. If a packet
>> fell under the discard route, the session would not be created
>> (otherwise you caught a real showstopper bug, but I don't much believe
>> in this, to be honest). Moreover, in order to have a session established
>> you also need a security policy permit.
>>
>> 1. Check the route where the packets actually fall under with "show
>> security flow session session-identifier <xxxx>". Very likely that your
>> packets actually fall under a longer specific route. Say, automatically
>> generated for proxy-arp or something like.
>>
>> 2. Check the zones, from and to which the sessions are established,
>> which policy permits the traffic. As of what you describe, policies
>> should block such traffic anyway.
>>
>> _______________________________________________
>> 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

This is exactly what happened. The session table filled up. One of our security guys took down our edge 650 cluster from a single unix box out on the net.

Sent from my iPhone

On Jun 22, 2012, at 4:39 AM, "Scott T. Cameron" <routehero@gmail.com> wrote:

> On Wed, Jun 20, 2012 at 10:14 PM, Morgan McLean <wrx230@gmail.com> wrote:
>
>> I have a /24 I want to announce, but I don't actually have it anywhere on
>> the network. I NAT some of its IP's on the SRX that has the BGP session
>> with our providers.
>>
>> I've been using static routes with the discard flag, but I don't really
>> like the way the SRX handles traffic. It still creates sessions for traffic
>> destined to IP's not used anywhere (hitting the static route) and can be
>> easily dos'd because of this.
>>
>> Is there a better way to just tell our providers hey, we have this range?
>>
>>
> It sounds like you're using the SRX as an edge router with a BGP session
> upstream?
>
> I don't have this architecture here, but I had the same problem. I had my
> edge router announce the /24 to the BGP upstreams, and my SRX announce the
> /24 via OSPF to the MX.
>
> Unfortunately, one of my IPs was hammered, and filled up the session table
> with invalid sessions. That's the real issue, at least in my case, was
> that even invalid sessions were taking a session, and prohibiting
> legitimate traffic from flowing.
>
> The solution was only to announce from SRX to MX (edge router) the /32s
> that were actually in use.
>
> I suppose that a firewall filter may help on your ingress ports to only
> permit the traffic to the /32s that are actually in use, but I can't say
> from experience if this will happen before a session is created, even in
> invalid state.
>
> Scott
> _______________________________________________
> 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

On 6/22/12 9:49 AM, Morgan Mclean wrote:
> This is exactly what happened. The session table filled up. One of our security guys took down our edge 650 cluster from a single unix box out on the net.
This is what happens when you use a stateful box for an internet router.

a router with a covering aggreate and some knowledge of the more
specifc on the interior would inexpensively discard traffic bound for
unreachable destinations.
>
> Sent from my iPhone
>
> On Jun 22, 2012, at 4:39 AM, "Scott T. Cameron" <routehero@gmail.com> wrote:
>
>> On Wed, Jun 20, 2012 at 10:14 PM, Morgan McLean <wrx230@gmail.com> wrote:
>>
>>> I have a /24 I want to announce, but I don't actually have it anywhere on
>>> the network. I NAT some of its IP's on the SRX that has the BGP session
>>> with our providers.
>>>
>>> I've been using static routes with the discard flag, but I don't really
>>> like the way the SRX handles traffic. It still creates sessions for traffic
>>> destined to IP's not used anywhere (hitting the static route) and can be
>>> easily dos'd because of this.
>>>
>>> Is there a better way to just tell our providers hey, we have this range?
>>>
>>>
>> It sounds like you're using the SRX as an edge router with a BGP session
>> upstream?
>>
>> I don't have this architecture here, but I had the same problem. I had my
>> edge router announce the /24 to the BGP upstreams, and my SRX announce the
>> /24 via OSPF to the MX.
>>
>> Unfortunately, one of my IPs was hammered, and filled up the session table
>> with invalid sessions. That's the real issue, at least in my case, was
>> that even invalid sessions were taking a session, and prohibiting
>> legitimate traffic from flowing.
>>
>> The solution was only to announce from SRX to MX (edge router) the /32s
>> that were actually in use.
>>
>> I suppose that a firewall filter may help on your ingress ports to only
>> permit the traffic to the /32s that are actually in use, but I can't say
>> from experience if this will happen before a session is created, even in
>> invalid state.
>>
>> Scott
>> _______________________________________________
>> 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

Actually, we used mx80's as our Internet routers. What do you suppose I use to handle my firewalling, ipsec and nat?

Thank you everyone, I will pop back to this thread when I change things up and have our security guy test again.

Sent from my iPhone

On Jun 22, 2012, at 9:39 PM, joel jaeggli <joelja@bogus.com> wrote:

> On 6/22/12 9:49 AM, Morgan Mclean wrote:
>> This is exactly what happened. The session table filled up. One of our security guys took down our edge 650 cluster from a single unix box out on the net.
> This is what happens when you use a stateful box for an internet router.
>
> a router with a covering aggreate and some knowledge of the more specifc on the interior would inexpensively discard traffic bound for unreachable destinations.
>>
>> Sent from my iPhone
>>
>> On Jun 22, 2012, at 4:39 AM, "Scott T. Cameron" <routehero@gmail.com> wrote:
>>
>>> On Wed, Jun 20, 2012 at 10:14 PM, Morgan McLean <wrx230@gmail.com> wrote:
>>>
>>>> I have a /24 I want to announce, but I don't actually have it anywhere on
>>>> the network. I NAT some of its IP's on the SRX that has the BGP session
>>>> with our providers.
>>>>
>>>> I've been using static routes with the discard flag, but I don't really
>>>> like the way the SRX handles traffic. It still creates sessions for traffic
>>>> destined to IP's not used anywhere (hitting the static route) and can be
>>>> easily dos'd because of this.
>>>>
>>>> Is there a better way to just tell our providers hey, we have this range?
>>>>
>>>>
>>> It sounds like you're using the SRX as an edge router with a BGP session
>>> upstream?
>>>
>>> I don't have this architecture here, but I had the same problem. I had my
>>> edge router announce the /24 to the BGP upstreams, and my SRX announce the
>>> /24 via OSPF to the MX.
>>>
>>> Unfortunately, one of my IPs was hammered, and filled up the session table
>>> with invalid sessions. That's the real issue, at least in my case, was
>>> that even invalid sessions were taking a session, and prohibiting
>>> legitimate traffic from flowing.
>>>
>>> The solution was only to announce from SRX to MX (edge router) the /32s
>>> that were actually in use.
>>>
>>> I suppose that a firewall filter may help on your ingress ports to only
>>> permit the traffic to the /32s that are actually in use, but I can't say
>>> from experience if this will happen before a session is created, even in
>>> invalid state.
>>>
>>> Scott
>>> _______________________________________________
>>> 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

Generally you only want to bring traffic down to your SRX that can actually
be used. There's no reason to advertise a /24 to your MX via IGP when
you're only actually using a /27 -- the leftover is just going to take up
sessions through random internet scans, etc.

Forcing advertisements of /32 from SRX to MX has some administrative
overhead, but is generally worth it. I have a policy that matches my /24
orlonger, and inject /32 static discard routes. The only bother is
remembering to inject the /32 when a new NAT address is being used.

Even so, some SRX nodes have a really low session count.

- My SRX240: 128k
- My SRX3400: 400k
- My SRX5600: 1M per PIC (3M total in my config)

The MX can be used to drop traffic to a specific IP that's causing your SRX
trouble, or rate limit, etc. The MX has no problem dropping high volume
traffic.

You can also configure the session timeouts to be more reasonable for
applications in your environment. I think the default for TCP is 15
minutes -- maybe you don't need that.

Scott


On Sat, Jun 23, 2012 at 2:41 AM, Morgan Mclean <wrx230@gmail.com> wrote:

> Actually, we used mx80's as our Internet routers. What do you suppose I
> use to handle my firewalling, ipsec and nat?
>
> Thank you everyone, I will pop back to this thread when I change things up
> and have our security guy test again.
>
> Sent from my iPhone
>
> On Jun 22, 2012, at 9:39 PM, joel jaeggli <joelja@bogus.com> wrote:
>
> > On 6/22/12 9:49 AM, Morgan Mclean wrote:
> >> This is exactly what happened. The session table filled up. One of our
> security guys took down our edge 650 cluster from a single unix box out on
> the net.
> > This is what happens when you use a stateful box for an internet router.
> >
> > a router with a covering aggreate and some knowledge of the more
> specifc on the interior would inexpensively discard traffic bound for
> unreachable destinations.
> >>
> >> Sent from my iPhone
> >>
> >> On Jun 22, 2012, at 4:39 AM, "Scott T. Cameron" <routehero@gmail.com>
> wrote:
> >>
> >>> On Wed, Jun 20, 2012 at 10:14 PM, Morgan McLean <wrx230@gmail.com>
> wrote:
> >>>
> >>>> I have a /24 I want to announce, but I don't actually have it
> anywhere on
> >>>> the network. I NAT some of its IP's on the SRX that has the BGP
> session
> >>>> with our providers.
> >>>>
> >>>> I've been using static routes with the discard flag, but I don't
> really
> >>>> like the way the SRX handles traffic. It still creates sessions for
> traffic
> >>>> destined to IP's not used anywhere (hitting the static route) and can
> be
> >>>> easily dos'd because of this.
> >>>>
> >>>> Is there a better way to just tell our providers hey, we have this
> range?
> >>>>
> >>>>
> >>> It sounds like you're using the SRX as an edge router with a BGP
> session
> >>> upstream?
> >>>
> >>> I don't have this architecture here, but I had the same problem. I
> had my
> >>> edge router announce the /24 to the BGP upstreams, and my SRX announce
> the
> >>> /24 via OSPF to the MX.
> >>>
> >>> Unfortunately, one of my IPs was hammered, and filled up the session
> table
> >>> with invalid sessions. That's the real issue, at least in my case, was
> >>> that even invalid sessions were taking a session, and prohibiting
> >>> legitimate traffic from flowing.
> >>>
> >>> The solution was only to announce from SRX to MX (edge router) the /32s
> >>> that were actually in use.
> >>>
> >>> I suppose that a firewall filter may help on your ingress ports to only
> >>> permit the traffic to the /32s that are actually in use, but I can't
> say
> >>> from experience if this will happen before a session is created, even
> in
> >>> invalid state.
> >>>
> >>> Scott
> >>> _______________________________________________
> >>> 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

Sorry for the top post... Seems phone vendors haven't figured out how to create a decent email editor on a phone yet.

When I worked at Arbor, we always recommended that customers would front end anything maintaining state (i.e. a SFW) with something that didn't (i.e. a Router) and to use Stateless ACLs to allow through only that which was absolutely required in order to allow stateful devices further downstream to perform their duties more efficiently.

Then customers buy something like a Juniper SRX in an attempt to collapse their network (routing & firewalling) and believe that they are now back to front ending everything with a stateful device.

The beauty of the SRX device is that while it is a stateful device, traffic arriving on interfaces can still be processed by stateless FFs which get processed before handing it off to the the stateful FW module and consuming precious recources on the SPCs.

So by all means, collapse your network if you need to, use a single box for routing and firewall if your design warrants it, but make sure you still use common sense and deploy it in a manner that is consistent with best current practices and will safeguard your network without itself becoming a bottleneck.

Stefan Fouant
GPG Key ID: 0xB4C956EC

Sent from my HTC EVO.

----- Reply message -----
From: "joel jaeggli" <joelja@bogus.com>
Date: Sat, Jun 23, 2012 12:39 am
Subject: [j-nsp] Whats the best way to announce an IP range in BGP? Doesn't physically exist anywhere.
To: "Morgan Mclean" <wrx230@gmail.com>
Cc: "juniper-nsp@puck.nether.net" <juniper-nsp@puck.nether.net>


On 6/22/12 9:49 AM, Morgan Mclean wrote:
> This is exactly what happened. The session table filled up. One of our security guys took down our edge 650 cluster from a single unix box out on the net.
This is what happens when you use a stateful box for an internet router.

a router with a covering aggreate and some knowledge of the more
specifc on the interior would inexpensively discard traffic bound for
unreachable destinations.
>
> Sent from my iPhone
>
> On Jun 22, 2012, at 4:39 AM, "Scott T. Cameron" <routehero@gmail.com> wrote:
>
>> On Wed, Jun 20, 2012 at 10:14 PM, Morgan McLean <wrx230@gmail.com> wrote:
>>
>>> I have a /24 I want to announce, but I don't actually have it anywhere on
>>> the network. I NAT some of its IP's on the SRX that has the BGP session
>>> with our providers.
>>>
>>> I've been using static routes with the discard flag, but I don't really
>>> like the way the SRX handles traffic. It still creates sessions for traffic
>>> destined to IP's not used anywhere (hitting the static route) and can be
>>> easily dos'd because of this.
>>>
>>> Is there a better way to just tell our providers hey, we have this range?
>>>
>>>
>> It sounds like you're using the SRX as an edge router with a BGP session
>> upstream?
>>
>> I don't have this architecture here, but I had the same problem. I had my
>> edge router announce the /24 to the BGP upstreams, and my SRX announce the
>> /24 via OSPF to the MX.
>>
>> Unfortunately, one of my IPs was hammered, and filled up the session table
>> with invalid sessions. That's the real issue, at least in my case, was
>> that even invalid sessions were taking a session, and prohibiting
>> legitimate traffic from flowing.
>>
>> The solution was only to announce from SRX to MX (edge router) the /32s
>> that were actually in use.
>>
>> I suppose that a firewall filter may help on your ingress ports to only
>> permit the traffic to the /32s that are actually in use, but I can't say
>> from experience if this will happen before a session is created, even in
>> invalid state.
>>
>> Scott
>> _______________________________________________
>> 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

>> This is exactly what happened. The session table filled up. One of
>> our security guys took down our edge 650 cluster from a single unix
>> box out on the net.
> This is what happens when you use a stateful box for an internet router.
>
> a router with a covering aggreate and some knowledge of the more
> specifc on the interior would inexpensively discard traffic bound for
> unreachable destinations.

1. First, sorry for writing this once again, but it's just not the case.
Any more or less smart stateful device, whether SRX or anything else,
must not create session states for packets falling under a discard
route. And SRX does not, I checked. Filling up the session table is
caused by either a bug or (rather) a design/config mistake.

2. There is nothing wrong in the idea of using a firewall as a single
border device for both stateful-processing and ASBR in most networks
where a statful edge-device is needed and all external links are
terminated in a single site.

3. This particular problem has nothing to do with BGP or any other
routing. Even if Morgan had an MX at the edge and SRX behind it, this
same thing would happen as well. He would use, say, /27 as a source NAT
pool on SRX and announce it to the MX via IGP or iBGP, using actually
the same means to create the route itself (static discard, aggregate,
whatever). What will happen if an external host initiates a session
towards an IP in this prefix? If the firewall creates sessions for such
packets, what the firewall is needed at all?
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

On Mon, Jun 25, 2012 at 6:56 AM, Pavel Lunin <plunin@senetsy.ru> wrote:

>
>
> >> This is exactly what happened. The session table filled up. One of
> >> our security guys took down our edge 650 cluster from a single unix
> >> box out on the net.
> > This is what happens when you use a stateful box for an internet router.
> >
> > a router with a covering aggreate and some knowledge of the more
> > specifc on the interior would inexpensively discard traffic bound for
> > unreachable destinations.
>
> 1. First, sorry for writing this once again, but it's just not the case.
> Any more or less smart stateful device, whether SRX or anything else,
> must not create session states for packets falling under a discard
> route. And SRX does not, I checked. Filling up the session table is
> caused by either a bug or (rather) a design/config mistake.


I'm not sure I agree with this assessment.

The SRX is very quick at disposing of invalid sessions, generally.
However, it is easily susceptible to DDOS if you let it reach the session
table.

Here's some quick POC code:

http://pastebin.com/FjgavSwn

You can run this against some non-operational IPs, but present via, say,
discard route in your config. You will see the invalid sessions rise
dramatically via 'show sec flow sess sum'.

I am no expert, but you can see how quickly this could be abused by someone
who was intent on disrupting your network -- and they wouldn't have to use
cheap perl code to do the job.

Malicious user aside, a legitimate application trying to hit an invalid IP
would give the same result. Self-made DDOS are very common in my
experience. In one case, we had an "updater" application which would
update drivers and software for our hardware. It was installed on millions
of computers. One day, the service was shutdown and new software was
distributed with the products. Many users, however, never updated, and the
software was very aggressive in calling home. Without knowing this, a /24
was pulled down to the SRX, and the updater instantly filled the session
table.

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

While it's true that like all flow based devices the session table is
susceptible to session table attacks. There are some major built in
protection schemes put into place to limit the effectiveness and
protect the SRX. For the record your proof of concept would take a lot
of pps to fill up the session table given that it's UDP and UDP has a
default time out of 60 seconds...

You have source/destination based session limiting screens which are
highly effective and handled in hardware. Syn flood protection, udp
flood protection and others. Additionally you have the option to
include aggressive age out of idle sessions in the event of the
session table reaching the upper limits of capacity. In that event the
session table will start aggressively removing idle sessions until it
reaches a proper session table size.

While no single feature is a silver bullet there are at least a good
amount of options in the way of protecting your SRX session table and
the SRX itself. Hardening your device to such attacks is critical if
you are going to have any level of access in putting the SRX as your
outside internet facing device.

I 100% agree with Stefan by the way, using stateless firewall filters
for a layered approach is also recommended if you plan on replacing
your DIA router. For the record, using such stateless firewall filters
there is no session built there is no passing go. The packet is just
dropped to /dev/null (or null0 depending how you look at it). No
session is ever created for traffic dropped by a firewall filter.

I hope this helps,
-Tim Eberhard

On Mon, Jun 25, 2012 at 7:06 AM, Scott T. Cameron <routehero@gmail.com> wrote:
> On Mon, Jun 25, 2012 at 6:56 AM, Pavel Lunin <plunin@senetsy.ru> wrote:
>
>>
>>
>> >> This is exactly what happened. The session table filled up. One of
>> >> our security guys took down our edge 650 cluster from a single unix
>> >> box out on the net.
>> > This is what happens when you use a stateful box for an internet router.
>> >
>> > a  router with a covering aggreate and some knowledge of the more
>> > specifc on the interior would inexpensively discard traffic bound for
>> > unreachable destinations.
>>
>> 1. First, sorry for writing this once again, but it's just not the case.
>> Any more or less smart stateful device, whether SRX or anything else,
>> must not create session states for packets falling under a discard
>> route. And SRX does not, I checked. Filling up the session table is
>> caused by either a bug or (rather) a design/config mistake.
>
>
> I'm not sure I agree with this assessment.
>
> The SRX is very quick at disposing of invalid sessions, generally.
>  However, it is easily susceptible to DDOS if you let it reach the session
> table.
>
> Here's some quick POC code:
>
> http://pastebin.com/FjgavSwn
>
> You can run this against some non-operational IPs, but present via, say,
> discard route in your config.  You will see the invalid sessions rise
> dramatically via 'show sec flow sess sum'.
>
> I am no expert, but you can see how quickly this could be abused by someone
> who was intent on disrupting your network -- and they wouldn't have to use
> cheap perl code to do the job.
>
> Malicious user aside, a legitimate application trying to hit an invalid IP
> would give the same result.  Self-made DDOS are very common in my
> experience.  In one case, we had an "updater" application which would
> update drivers and software for our hardware.  It was installed on millions
> of computers.  One day, the service was shutdown and new software was
> distributed with the products.  Many users, however, never updated, and the
> software was very aggressive in calling home.  Without knowing this, a /24
> was pulled down to the SRX, and the updater instantly filled the session
> table.
>
> Scott
> _______________________________________________
> 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

25.06.2012 16:06, Scott T. Cameron:
>
> 1. First, sorry for writing this once again, but it's just not the
> case.
> Any more or less smart stateful device, whether SRX or anything else,
> must not create session states for packets falling under a discard
> route. And SRX does not, I checked. Filling up the session table is
> caused by either a bug or (rather) a design/config mistake.
>
>
>
> I'm not sure I agree with this assessment.
>
> The SRX is very quick at disposing of invalid sessions, generally.
> However, it is easily susceptible to DDOS if you let it reach the
> session table.
>
> Here's some quick POC code:
>
> http://pastebin.com/FjgavSwn
>
> You can run this against some non-operational IPs, but present via,
> say, discard route in your config. You will see the invalid sessions
> rise dramatically via 'show sec flow sess sum'.

Hm.

The test itself is not that complex and I've just checked it. Just wrote
a 10.1.1.0/24 discard and tried to ping it with -f option.

Yes, the number of invalidates sessions increases in the "show flow sec
sess sum" output, buy here is what happens in flow-trace:

> Jun 26 14:13:25
> 14:13:25.049336:CID-0:RT:<10.0.0.17/2031->10.1.1.20/6175;1> matched
> filter 1:
> Jun 26 14:13:25 14:13:25.049336:CID-0:RT:packet [84] ipid = 0, @4092e624
> Jun 26 14:13:25 14:13:25.049336:CID-0:RT:---- flow_process_pkt: (thd
> 2): flow_ctxt type 14, common flag 0x0, mbuf 0x4092e400, rtbl_idx = 0
> Jun 26 14:13:25 14:13:25.049336:CID-0:RT: flow process pak fast ifl 71
> in_ifp ge-0/0/0.6
> Jun 26 14:13:25 14:13:25.049336:CID-0:RT:
> ge-0/0/0.6:10.0.0.17->10.1.1.20, icmp, (8/0)
> Jun 26 14:13:25 14:13:25.049336:CID-0:RT: find flow: table 0x4354f9b8,
> hash 55925(0xffff), sa 10.0.0.17, da 10.1.1.20, sp 2031, dp 6175,
> proto 1, tok 6
> Jun 26 14:13:25 14:13:25.049336:CID-0:RT: no session found, start
> first path. in_tunnel - 0, from_cp_flag - 0
> Jun 26 14:13:25 14:13:25.049336:CID-0:RT: flow_first_create_session
> Jun 26 14:13:25 14:13:25.049774:CID-0:RT: flow_first_in_dst_nat: in
> <ge-0/0/0.6>, out <N/A> dst_adr 10.1.1.20, sp 2031, dp 6175
> Jun 26 14:13:25 14:13:25.049814:CID-0:RT: chose interface ge-0/0/0.6
> as incoming nat if.
> Jun 26 14:13:25 14:13:25.049814:CID-0:RT:flow_first_rule_dst_xlate:
> DST no-xlate: 0.0.0.0(0) to 10.1.1.20(6175)
> Jun 26 14:13:25 14:13:25.049814:CID-0:RT:flow_first_routing: vr_id 0,
> call flow_route_lookup(): src_ip 10.0.0.17, x_dst_ip 10.1.1.20, in ifp
> ge-0/0/0.6, out ifp N/A sp 2031, dp 6175, ip_proto 1, tos 0
> Jun 26 14:13:25 14:13:25.049814:CID-0:RT:Doing DESTINATION addr
> route-lookup
> Jun 26 14:13:25 14:13:25.049814:CID-0:RT: packet dropped, no route to
> dest
> Jun 26 14:13:25 14:13:25.049814:CID-0:RT:flow_first_routing: DEST
> route-lookup failed, dropping pkt and not creating session nh: 0
> Jun 26 14:13:25 14:13:25.049814:CID-0:RT: flow find session returns
> error.
> Jun 26 14:13:25 14:13:25.049814:CID-0:RT: ----- flow_process_pkt rc
> 0x7 (fp rc -1)

Yes, this eats some centeral point resources on SRX-HE or its software
analogue for Branch-SRX. Of course, some resources are also consumed for
internal NPC-SPC forwarding, etc. But I'd say it's rather CPU-cycles,
not the session table memory. Of course, if we issue "show security flow
session destination-prefix 10.1.1.0/24", there are no records in the table.

However it is still less resource intensive than, say, processing
packets for which there is an explicit (or implicit) deny policy. And
this is what stateful firewalls are invented for.

So, I agree, any stateful device has a grater potential of being DoSed
than a router. Just because this risk is proportional to the number of
elementary operations, the device performs with a packet, and, by
definition, stateful device is more fragile here.

But, again, it does not depend on the firewall's routing role. It is a
general cost of using a stateful device.

> Malicious user aside, a legitimate application trying to hit an
> invalid IP would give the same result.
Real-life example is even simpler. Any source NAT box (CGN, enterprise,
whatever). It has, say, a NAT pool, which is also defined as a static
discard and announced upsteam using some routing protocol (does not
matter which). All the IPs are used for NAT, so there are no unused
addresses. Users/subscribers behind NAT use torrents, and, of course,
there are lots of sessions from outside users, trying to establish
connections with your subscribers behind NAT. And the same thing
happens: packets come to the NAT device and fall under the discard route.

Yep, it's a good idea to use devices performing route lookups in
dedicated hardware for massive-scale NAT deployments. Also some
additional techniques like stateless filters and early-aging. And common
sense, as Stefan said.

But it has nothing to do with routing (sorry :)

Moreover. Imagine you don't have a static discard route for NAT pool and
no dynamic routing is used at all. Just a static route for the NAT pool
on the upstream device, pointing to the NAT device, and a static default
on the NAT device towards the uplink. What will happen? A packet will
also come to the NAT device, which will perform a route lookup (same
operations as we saw above) but it will find a route --- default. It
means it will go ahead and check the zones, policies, etc (more
resources consumed). Much funnier thing will happen if you have (for
some reason) a permitting policy from untrust to untrust (or however you
call it). On MS-PIC-based NAT box this will also give you a loop, if you
don't care.

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