Junos
Highlighted
Junos

BGP Communities, Firewalls Rules and SCUs oh my....

‎04-29-2020 03:22 PM

Hello all, 

 

So we are trying to combat a spam problem. We already retroactively block smtp related ports automatically but it seems most people lie anyways and we get tons of reports. Currently we just null the ip as the reports come in but it seems we are getting more and more everyday. We have a way to pull the /32 from the abuse reports coming in. So we could make a prefix-list and add the dest port blocks and done.

The issue i have is currently we have a ddos-mitigation script that adds and removes prefixes via netconf and there has been a couple of times we experienced "ghosting". We would delete even the entire PL and still that range no longer there would still be blocked. Two options fixed that, rename the PL to something else and change the configs or Bounce/reboot REs. 

 

My idea for the title is this. I can have a script pull the ips from the API. The script would then push the IPs to Quagga. Quagga would then add a special community eg. 25666.

Over on the MX side It would have import policy to from community 256666 then add a source-class,Setting pref 254, then accept. In the firewall rule for input on core switches connected to the mx do from source-class then dest-port 25,487, etc then discard with an ultimate accept at the end of all the rules. 

Few things happen when i tried this. Leaving the next-hop without directive basically nulls the ip. Setting self makes it work but the rule for port blocking doesn't. Setting discard/reject same as no directive nulls ip. However, I set the next-hop IP as the next-hop it would be from our IBGP sessions and the server works and the port blocking works. I'm at a loss how to get around this but i'd like to make it work.

If all the IPs were next-hop the same core IP i would just set this and call it a win. However, we have multiple core aggregates and they all report different next-hops for different blocks connected to the same mx. Also i also noticed that when setting next-hop self it made the route hidden and had "unusable" tagged. If there is a way to still use that for my source-class that would be awesome.

 

Here is my build:

SCU:
set policy-options policy-statement SCU-SMTP-COP term IMPORT from community SMTP-COP
set policy-options policy-statement SCU-SMTP-COP term IMPORT then source-class SMTP-COP
set policy-options policy-statement SCU-SMTP-COP term IMPORT then accept
set routing-options forwarding-table export SCU-SMTP-COP

Community:
set policy-options community SMTP-COP members ASN:25666

BGP:
set protocols bgp group SMTP-COP type internal
set protocols bgp group SMTP-COP local-address *MX-lo0*
set protocols bgp group SMTP-COP neighbor *QuggaIP* description SMTP-COP
set protocols bgp group SMTP-COP neighbor *QuggaIP* import POL-IMPORT-SMTP-COP
set protocols bgp group SMTP-COP neighbor *QuggaIP* family inet unicast
set protocols bgp group SMTP-COP neighbor *QuggaIP* export POL-REJECT-ALL

BGP Policies:
set policy-options policy-statement POL-IMPORT-SMTP-COP term 10-T-SPAM-COP-PREFIXES from community SMTP-COP
set policy-options policy-statement POL-IMPORT-SMTP-COP term 10-T-SPAM-COP-PREFIXES then preference 254
set policy-options policy-statement POL-IMPORT-SMTP-COP term 10-T-SPAM-COP-PREFIXES then next-hop *CoreSwitch-to-test-ip*
set policy-options policy-statement POL-IMPORT-SMTP-COP term 10-T-SPAM-COP-PREFIXES then accept
set policy-options policy-statement POL-IMPORT-SMTP-COP then reject
set policy-options policy-statement POL-REJECT-ALL then reject

Filter for INPUT on Coreswitch:
set firewall family inet filter FLTR-CORESW-IN term 1-T-SMTP-COP from source-class SMTP-COP
set firewall family inet filter FLTR-CORESW-IN term 1-T-SMTP-COP from destination-port 25
set firewall family inet filter FLTR-CORESW-IN term 1-T-SMTP-COP from destination-port 465
set firewall family inet filter FLTR-CORESW-IN term 1-T-SMTP-COP from destination-port 587
set firewall family inet filter FLTR-CORESW-IN term 1-T-SMTP-COP then discard
set firewall family inet filter FLTR-CORESW-IN term LAST then accept

 

Any input or direction would be awesome.

 

Again the firewall input rule works when i use a prefix-list so my desired result can be obtained. I just have bad experiences with prefix lists and don't feel like revisiting scripts and configs all the time.

 

Thanks!

1 REPLY 1
Highlighted
Junos

Re: BGP Communities, Firewalls Rules and SCUs oh my....

[ Edited ]
‎04-29-2020 08:50 PM

Hello,

You came to the right place to ask these sorts of questions Smiley Happy

I had the same idea back in 2017 and came up with  a couple of working solutions.

 


@xfxchilde33 wrote:

 Leaving the next-hop without directive basically nulls the ip. Setting self makes it work but the rule for port blocking doesn't. Setting discard/reject same as no directive nulls ip. However, I set the next-hop IP as the next-hop it would be from our IBGP sessions and the server works and the port blocking works. I'm at a loss how to get around this but i'd like to make it work.

If all the IPs were next-hop the same core IP i would just set this and call it a win. However, we have multiple core aggregates and they all report different next-hops for different blocks connected to the same mx. Also i also noticed that when setting next-hop self it made the route hidden and had "unusable" tagged. If there is a way to still use that for my source-class that would be awesome.

 

 

Here are my solutions for You:

 

I. SCU, without BGP Flowspec:

If You want to keep Your SCU setup in place, You need to set the next-hop (on import to MX or on export from Quagga) to the network address or broadcast address of the CIDR block the /32 belongs to.

Example being:

1/ You want to block SMTP ports for 203.0.113.113/32

2/ The CIDR block for 203.0.113.113 is 203.0.113.0/24

3/ You need to write a script (to be executed on Quagga box before announce or on MX after import) to lookup and set BGP protocol nexthop for 203.0.113.113/32 route to be 203.0.113.0, or altternatively 203.0.113.0.255.

4/ The above assumes You don't deaggregate 203.0.113.0/24 somewhere else in Your network down to 203.0.113.0/25 + 203.0.113.0.128/25 or smaller blocks.

 

II. You could also utilize the "static flow routes" on MX using NETCONF instead of BGP

https://www.juniper.net/documentation/en_US/junos/topics/reference/configuration-statement/flow-edit...

 

 

III. BGP flowspec

You just need to enable "family inetflow" between Quagga and MX, and configure Quagga box to build BGP flowspec route from each /32 and send this BGP flowspec route to MX. 

https://www.juniper.net/documentation/en_US/day-one-books/DO_BGP_FLowspec.pdf

 

HTH

Thx

Alex

_____________________________________________________________________

Please ask Your Juniper account team about Juniper Professional Services offerings.
Juniper PS can design, test & build the network/part of the network as per Your requirements

+++++++++++++++++++++++++++++++++++++++++++++

Accept as Solution = cool !
Accept as Solution+Kudo = You are a Star !