Re: [j-nsp] [EXT] Re: Decoding DDOS messages
On Wed, 18 Mar 2020 at 20:09, Chuck Anderson wrote: > I disagree that they would be any good at it--it would likely be filled with > the same holes as we've seen here given network vendors' poor history in this > area (see bad filters taking out IS-IS, IPv6 ND, and NFS traffic on EX4500 > switches for example). As this thread points out, getting the filters right > is hard. If they were hardcoded by Juniper, that would just make them opaque > and unchangeable. We'd all benefit from much more transparency and sharing > of experiences. Juniper has hidden group which is applied to your config, default lo0 filter could come from there, when not configured. And it could evolve via JTAC. It can consume information no external site can consume. -- ++ytti ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] [EXT] Re: Decoding DDOS messages
On Wed, Mar 18, 2020 at 06:36:58PM +0200, Saku Ytti wrote: > On Wed, 18 Mar 2020 at 18:30, John Kristoff wrote: > > > Yep, I get all that. I can tighten that up. Care to show us how you > > do loopback filters? > > It is situational, it's hard to come up with one-size-fits-all. One > approach would be basic skeleton, on top of which people then expand > what they need, which would likely be also then broken. Another option > would be to write exhaustive one, but exhaustive one necessarily has > compromises, so then people who don't need everything still take those > compromises. > Really Juniper would be in the best position to automatically generate > lo0 filter when none is provided, which would be really really good, > not optimal, but really good. Bit of like generated-LPTS. I disagree that they would be any good at it--it would likely be filled with the same holes as we've seen here given network vendors' poor history in this area (see bad filters taking out IS-IS, IPv6 ND, and NFS traffic on EX4500 switches for example). As this thread points out, getting the filters right is hard. If they were hardcoded by Juniper, that would just make them opaque and unchangeable. We'd all benefit from much more transparency and sharing of experiences. > I'm not sure if there is a utility in public template. But it's > something that I do occasionally think about, not just Junos or just > firewall, but also BGP, to show how to normalise BGP behaviour (no one > knows what their BGP policy is very accurately, as in almost every > case BGP policy is 'what ever is vendor default', and when you have > multivendor network, you have different policy in different devices). The utility is in documenting best practices and concepts in how the public template works so that it can be adjusted as necessary. Having something documented, then claiming "that is wrong" without providing concrete corrections/suggestions is not helpful, especially if everyone out there is using the CYMRU templates or the MX book because that is the best information available. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] [EXT] Re: Decoding DDOS messages
On Wed, 18 Mar 2020 at 18:53, Chuck Anderson wrote: > 49125-65535, 1024-49124 could have something listening in them. > > Thanks, this is useful. From the BSD shell it appears to be 49160-65535: You are correct. I debated between the sysctl or standard, and I'm not sure if I made the right call by going standard. At the time my justification was, what if this is platform dependent, and I didn't want to do the work to figure out if it's always 49160 in every platfrom and junos and ended up with more liberal standard ephemeral range. -- ++ytti ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] [EXT] Re: Decoding DDOS messages
On Wed, Mar 18, 2020 at 06:33:11PM +0200, Saku Ytti wrote:
> On Wed, 18 Mar 2020 at 18:28, Chuck Anderson wrote:
>
> > term bgp-inbound {
> > from {
> > source-prefix-list {
> > bgp-neighbors-v4;
> > }
> > protocol tcp;
> > source-port 1024-65535;
> This is immaterial, you don't care what this SPORT is. Be liberal.
True--the peer controls it so it doesn't matter what it is.
> > term bgp-replies {
> > from {
> > source-prefix-list {
> > bgp-neighbors-v4;
> > }
> > protocol tcp;
> > source-port bgp;
> > destination-port 1024-65535;
> This you care very much, and ephemeral range in your device is
> 49125-65535, 1024-49124 could have something listening in them.
Thanks, this is useful. From the BSD shell it appears to be 49160-65535:
% sysctl -a | grep -E 'portrange.*(first|last)'
net.inet.ip.portrange.lowfirst: 1023
net.inet.ip.portrange.lowlast: 647
net.inet.ip.portrange.first: 49160
net.inet.ip.portrange.last: 65535
net.inet.ip.portrange.hifirst: 49160
net.inet.ip.portrange.hilast: 65535
> If you are in position where you only have customers and RR, no peers
> or anything else where there is no 'owner'. You should set your
> customer BGP to passive, so customer _always_ starts the BGP, you will
> never try to start it. Equally you should set your RR to passive, so
> clients always connect to RR, RR never.
> This will allow greatly simplified filters for BGP, much safer, as
> well as trivial way to police iBGP and eBGP separately, in times when
> dddos-protection was not available.
Good idea.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] [EXT] Re: Decoding DDOS messages
On Wed, 18 Mar 2020 at 18:28, Chuck Anderson wrote:
> term bgp-inbound {
> from {
> source-prefix-list {
> bgp-neighbors-v4;
> }
> protocol tcp;
> source-port 1024-65535;
This is immaterial, you don't care what this SPORT is. Be liberal.
> term bgp-replies {
> from {
> source-prefix-list {
> bgp-neighbors-v4;
> }
> protocol tcp;
> source-port bgp;
> destination-port 1024-65535;
This you care very much, and ephemeral range in your device is
49125-65535, 1024-49124 could have something listening in them.
If you are in position where you only have customers and RR, no peers
or anything else where there is no 'owner'. You should set your
customer BGP to passive, so customer _always_ starts the BGP, you will
never try to start it. Equally you should set your RR to passive, so
clients always connect to RR, RR never.
This will allow greatly simplified filters for BGP, much safer, as
well as trivial way to police iBGP and eBGP separately, in times when
dddos-protection was not available.
--
++ytti
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] [EXT] Re: Decoding DDOS messages
On Wed, Mar 18, 2020 at 11:16:54AM -0500, John Kristoff wrote:
> On Wed, 18 Mar 2020 16:02:09 +
> Saku Ytti wrote:
>
> > It is completely broken, you use 'port' so you expose every port in your
> > system.
>
> Ha, OK thanks. I think that would require some not so easy spoofing
> unless I'm missing something. We can convert any statement that just
> uses port to directional, which I think will require additional rules
> to tighten it up. Feel free to submit example configs.
To bypass your filter, just SSH using source port 179 (bgp), destination port
22, and you are in (as long as you are a BGP neighbor for this specific term):
filter loopback-v4 {
term bgp {
from {
source-prefix-list {
bgp-neighbors-v4;
}
protocol tcp;
port bgp;
}
then {
count bgp;
accept;
}
}
Fix:
/* allow inbound BGP connections */
term bgp-inbound {
from {
source-prefix-list {
bgp-neighbors-v4;
}
protocol tcp;
source-port 1024-65535;
destination-port bgp;
}
then {
count bgp;
accept;
}
}
/* allow reply packets to outbound BGP connections */
term bgp-replies {
from {
source-prefix-list {
bgp-neighbors-v4;
}
protocol tcp;
source-port bgp;
destination-port 1024-65535;
tcp-established;
}
then {
count bgp-replies;
accept;
}
}
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
