Securing SSH with MFA(Google Auth) on Ubuntu

barcode

This short article will go over how I’m practicing defense in depth to secure my Linux SSH access for critical infrastructure. We will install Google-Auth on a Ubuntu Server-19 and store the Scratch Codes in our LastPass Vault.  LastPass is utilizing my YubiKey which FIDO2, FIDO U2F, one-time password (OTP), OpenPGP and smart card, choice of form factors for desktop or laptop as a form of MFA to authenticate to the cloud service.  For my AuthCodes I will also be using LastPass Authenticator, even though I am installing Google Auth on the Ubuntu instance.  Finally, for those who use SecureCRT, there is one configuration change to make to your saved sessions for ease of use and compatibility.

Last Pass has a free option available and you can find Google Authenticator on your device’s App Store/Play Store. Yubikey is a paid hardware device.

What is MFA?

Multi-factor authentication combines two or more independent credentials: what the user knows (password), what the user has (security token) and what the user is (biometric verification). The goal of MFA is to create a layered defense and make it more difficult for an unauthorized person to access a target such as a physical location, computing device, network or database. If one factor is compromised or broken, the attacker still has at least one more barrier to breach before successfully breaking into the target.

Source: TechTarget

What is Defense in Depth?

Defense in Depth (DiD) is an approach to cybersecurity in which a series of defensive mechanisms are layered in order to protect valuable data and information.

Source: ForcePoint

Lets get started by SSH’ing into your Ubuntu machine. I am performing these steps on a Ubuntu Server 19. There are some additional steps in securing cloud instances, such as Digital Ocean headless droplets. I will not be covering such configuration.

Step 1:  Install G-Auth – The tools for MFA.

htinoco@pi-hole:~$ sudo apt install libpam-google-authenticator

Step 2: Setup MFA on local user account.

htinoco@pi-hole:~$ google-authenticator

At this point, carefully read through the prompts and select the options that make more sense to you. Open your Authenticator App of choice and scan the MFA QR Code that is on your screen.

Now, lets concentrate on properly storing the following information before finishing the configuration.

Your new secret key is: 2445XXXXJ5L6MQ575PXXXXXX
Your verification code is XX29XX
Your emergency scratch codes are:
8659XXXX
7X0672XX
5608XXXX
268233XX
1X890XXX

Store these scratch codes somewhere safe – Do not save these on the same local device, in case of lose or theft. I will save these to my LastPass Vault.

First, lets authenticate to LastPass using YubiKey. This is where the DiD comes in to play – Maybe I’m stretching the DiD definition here, but simply writing these codes down and throwing them in a drawer is not a good backup plan.

Insert the YubiKey to your local machine – Pictured is John Wick, ensuring no dogs are harmed during this blog.

20191012_153753250_iOS.jpg

Now lets authenticate to LastPass  – I have previously setup my YubiKey to work as an MFA device under my LastPass account settings. See documentation on LastPass website for a quick how-to.

lpmfa.PNG

Once fully authenticated, lets store the scratch keys somewhere safe. I personally created a ‘Home Network’ folder inside the ‘SSH KEYS” section labeled “SCRATCH CODES”, sorted by machine host name.

Make sure to put some thought into how want to organize your LastPass Vault.

Okay, lets get back to the nuts n bolts of the MFA configuration for SSH on the Ubuntu server.

Lets edit the SSHd config file and change the default “ChallengeResponseAuthentication” to Yes.

htinoco@pi-hole:~$ sudo nano /etc/ssh/sshd_config

# Change to yes to enable challenge-response passwords (beware issues with
# some PAM modules and threads)
ChallengeResponseAuthentication yes      # Change this default from no to yes!

# Kerberos options
#KerberosAuthentication no
#KerberosOrLocalPasswd yes
#KerberosTicketCleanup yes
#KerberosGetAFSToken no

Next, simply restart the SSH service:

sudo systemctl restart ssh

Now lets edit the PAM file – The LinuxPAM (short for Pluggable Authentication Modules which evolved from the Unix-PAM architecture) is a powerful suite of shared libraries used to dynamically authenticate a user to applications (or services) in a Linux system.

sudo vi /etc/pam.d/sshd

#At the very bottom of the file, add the following line:

auth required pam_google_authenticator.so

That’s it! You can test this feature by simply running ‘ssh localhost’ and you should see the following after authenticating with your password:

htinoco@pi-hole:~$ ssh localhost
Password:
Verification code:                                #<<<<< Very COOL!

Now, as I said, if you’re like me and have hundreds of sessions saved on your SecureCRT application – here is what you’ll need to do to ensure a smooth login with MFA:

 

ssh.PNG

  1. Right click on your saved session for the Ubuntu Server with MFA.
  2. Select Properties
  3. Category: SSH2
  4. Category: Authentication
    1. Select Keyboard Interactive
    2. Select OK.

This will allow for SecureCRT to handle the Verification Code prompt:

mfa2.PNG

There ya have it! you should be logged in now utilizing MFA.

If you ever lose your cell phone with the authenticator app, you can always retrieve the scratch codes from your LastPass Vault that’s encrypted on a cloud service – So it will always be available to you.. make sure you don’t lose your YubiKey the same night..

Always make sure to have a backup!

Thanks for reading,

Hugo Tinoco

 

 

BGP Conditional Advertisement – Palo-Alto NGFW

Conditional Advertisement

Palo Alto BGP Condi Adv Documentation

This article will outline how to configure conditional advertisements when utilizing multiple up-links from a Palo-Alto acting as an edge device on your network. Conditional Advertisement is an advanced routing feature, which is introduced at a Cisco’s CCIE level. I will be re-using the LAB topology from my previous post, as it works perfectly with this scenario.

What is Conditional Advertisement ?

The Border Gateway Protocol (BGP) conditional advertisement feature provides additional control of route advertisement, depending on the existence of other prefixes in the BGP table.

https://www.cisco.com/c/en/us/support/docs/ip/border-gateway-protocol-bgp/16137-cond-adv.html

A defined prefix must exist in the FIB in order to suppress the condition, therefore not advertising the desired routes to the less preferred neighbor. This is useful when you want full and definite control of ingress and egress traffic to your network when multi-homing to different ISPs. Both BGP sessions will be up simultaneously, however until the monitored prefix is no longer found in the route-table, the condition will be suppressed (Not Advertised). Once the prefix is not in the route-table, the condition will be met and the advertisement will be propagated to the secondary, less preferred neighbor.

Topology

ISP 1 = Most Preferred (Monitor received prefix 192.168.100.1/32 from ISP-1-B)

ISP 2 = Less Preferred

ISP 1 will be advertising a loop-back in which the Palo-Alto will monitor (utilizing ping checks). Contact your upstream provider and explain to one of their engineers what you’d like to do and the reason for your request. A simple RFC 1918 loopback /32 can be coordinated between your ISP and your organization to be advertised.  PA’s do not allow a default-route to be monitored as part of the BGP Conditional advertisement. From a service-providers standpoint, this should not be a difficult request although it may take some work, as BOGONS are filtered in and out of global route tables. You don’t have to depend on your service provider advertising a specific route though… feel free to get creative. After all, BGP only looks at the local-fib – you can monitor any route coming from any where (BGP,OSPF,ISIS).


Lets get to business! – Here is the advertisement routes from ISP-1 Router – (preferred ISP) – We somehow managed to get the ISP to advertise 192.168.100.1/32 and we will monitor this prefix under our cond-adv tab/bgp process on our edge PA.

adv-routes

Now, lets verify our IMPORT statement on our Palo-Alto. We are only allowing a default-route and prefix 192.168.100.1/32.

import-statement.PNG


Lets talk about the EXPORT side. Create export statements specifying the Public IP of your public facing servers, etc. Even though we are advertising to both peers, the conditional advertisement SUPPRESSES the advertisement. At this point, since the condition hasn’t been configured, normal BGP behavior will send the routes to both peers.

Also, create a DENY policy to prevent any other routes from advertising (expected BGP behavior to re-advertise to other eBGP peers). Pay close attention to the ‘Used By’ section.

I’m selecting both PEERS to advertise the public route 2.2.2.2/32 and the DENY action for the ‘no-routes’ This is a common practice and the beauty of BGP; the full control. Put your security hat on and think of these export policies as actual firewall security policies. They are read from top to bottom in this case.

no-routes

  1. Create an interface LOOPBACK, if the IP is a /32. Otherwise, create a secondary subnet on a L3 Interface. This is important as the default behavior of the PA will affect our advertisement.
  2. Create a re-distribution and specify either a profile or simply input the prefix.
    1. Redistribution is required as we’re literally bringing in a directly connected interface (Loopback) or a IP from an interface into BGP.

Lets select the “Conditional ADV” tab now.

It’s very important to specify the “USED BY” as the SECONDARY, LESS PREFERRED peer. Otherwise, this won’t work. As you can see, I have selected “ISP-2” as it’s my secondary peer. The “Non Exist Filters” specifies the IP Prefix that I am monitoring from ISP-1. If that peer session were to drop, the prefix 192.168.100.1/32 would disappear from my routing table, therefore the condition would be triggered and the route would be advertised to the Secondary-Peer, “ISP-2”.

cond-1

Below, is the “Advertise Filters” tab. Here you will input the Public Server IP that you want to control advertisement of.  What this says, “Used By” – The peer that the prefix will be advertised to, once the ‘Non Exist Filters” prefix is non-existent in the routing table. cond-2

This out put displays the condition being SUPPRESSED, since the prefix 192.168.100.1/32 is PRESENT in the routing table.

admin@PA-VM> show routing protocol bgp loc-rib
VIRTUAL ROUTER: default (id 1)
==========
Prefix Nexthop Peer Weight LocPrf Org MED flap AS-Path
0.0.0.0/0 172.16.65.0 WAN-ISP-1 0 100 i/c 0 0 64511
*192.168.100.1/32 172.16.65.0 WAN-ISP-1 0 100 i/c 0 0 64511
*0.0.0.0/0 172.16.64.0 WAN-ISP-2 0 200 i/c 0 0 64496
*192.168.1.0/24 192.168.1.2 Core-Router 0 100 igp 0 0
*2.2.2.2/32 Local 0 100 i/c 0 0

total routes shown: 5

admin@PA-VM> show routing protocol bgp policy cond-adv
VIRTUAL ROUTER: default (id 1)
==========
Peer/Group: WAN-ISP-2
Suppress condition met: yes
Suppress condition (Non-exist filter):
name: Loop-to-monitor
AFI: bgpAfiIpv4
SAFI: unicast
Destination: 192.168.100.1
hit count: 17
Route filter (Advertise filter):
name: Routes-To-Advertise
AFI: bgpAfiIpv4
SAFI: unicast
Destination: 2.2.2.2
hit count: 3
———-
Peer/Group: ISP-2
Suppress condition met: yes
Suppress condition (Non-exist filter):
name: Loop-to-monitor
AFI: bgpAfiIpv4
SAFI: unicast
Destination: 192.168.100.1
hit count: 17
Route filter (Advertise filter):
name: Routes-To-Advertise
AFI: bgpAfiIpv4
SAFI: unicast
Destination: 2.2.2.2
hit count: 3
———-

Now, I will shut down the Peering Session from the BGP edge router at ISP-1. This will pull the prefix 192.168.100.1/32 from the Routing Table on the Palo Alto and will meet the condition, therefore advertising the public server IP out the Secondary-Peering session, ISP-2.

admin@PA-VM> show routing protocol bgp loc-rib
VIRTUAL ROUTER: default (id 1)
==========
Prefix Nexthop Peer Weight LocPrf Org MED flap AS-Path
*0.0.0.0/0 172.16.64.0 WAN-ISP-2 0 200 i/c 0 0 64496
*192.168.1.0/24 192.168.1.2 Core-Router 0 100 igp 0 0
*2.2.2.2/32 Local 0 100 i/c 0 0

total routes shown: 3

admin@PA-VM> show routing protocol bgp policy cond-adv
VIRTUAL ROUTER: default (id 1)
==========
Peer/Group: WAN-ISP-2
Suppress condition met: no
Suppress condition (Non-exist filter):
name: Loop-to-monitor
AFI: bgpAfiIpv4
SAFI: unicast
Destination: 192.168.100.1
hit count: 19
Route filter (Advertise filter):
name: Routes-To-Advertise
AFI: bgpAfiIpv4
SAFI: unicast
Destination: 2.2.2.2
hit count: 3
———-
Peer/Group: ISP-2
Suppress condition met: no
Suppress condition (Non-exist filter):
name: Loop-to-monitor
AFI: bgpAfiIpv4
SAFI: unicast
Destination: 192.168.100.1
hit count: 19
Route filter (Advertise filter):
name: Routes-To-Advertise
AFI: bgpAfiIpv4
SAFI: unicast
Destination: 2.2.2.2
hit count: 3
———-

Keep in mind that BGP offers many knobs to traffic-engineer IN-bound and OUT-bound traffic. Utilizing MED is a way to steer traffic inbound, although – this will work only when dual-homing to the same ISP AND must be enabled/allowed by the upstream ISP.

When the MED option isn’t viable, utilizing pre-pend will utilize AS-PATH as a way to discourage upstream routers from selecting the less-desired route.

Also, keep in mind that most providers will have BGP communities they will share with their customers. Make sure to review this with your upstream provider and find out what is the best option for you. Finally, never forgot about old-faithful for outbound-exiting traffic.: Local-pref.

Dual ISPs BGP – Palo Alto Networks

 

Topology

Network Topology

 

First things first! I passed the BGP Exam for the Nokia SRA Certification. I am now planning to deviate a bit and obtain my Sec+ and see where that takes me.. Anyways..

I’ve been very interested in Palo Alto Networks lately and I’m low-key starting to think about the certification path for PA.  I want to take some time and go over a Dual ISP connection utilizing a PA at the edge. I’m hoping to provide some insight from both a Service Provider  and Enterprise standpoint. The goal is to have a highly redundant WAN connection utilizing the PA.

Something I want to start keeping in mind:

64496 – 64511 16 bit Reserved for use in documenation & sample code. [RFC5398]

Topology:

ISP 1 ( AS 64511 ) will be adveritising a default-route via 172.16.65.0/31 interconnect with the PA on eth1/4.

ISP 2 ( AS 64496 ) will be adveritising a default-route via 172.16.64.0/31 interconnect with the PA on eth1/1.

The Enterprise LAN will be peering with the PA via iBGP on Gi0/0 and eth1/7 on the PA from Autonomous System 64500

—————————————————————————————————————————————————————-

From ISP 1 – a VPRN (VRF) 100 is configured, advertising a default-route.

From ISP 2 – a VPRN (VRF) 200 is configured, advertising a default-route.

Here is a snippet from the Nokia VRF that’s providing internet service connection to the Palo Alto. A similar configuration exisist on the ISP 1 router.

nokiabgp.PNG

—————————————————————————————————————————————————————-

From the Palo Alto – The initial steps to take are the following:

1. Create an “Untrust” zone. This zone will be facing the Internet (ISP1 & ISP2).

Normally, I would suggest micro-segmenting these zones, but this requires a bit more policy creation. Example would be, 1 zone for ISP 1 and a different zone for ISP 2 for an absolute zero-trust architecture.

2. Create a Management Profile which simply allows ICMP (pings) for troubleshooting and verification purposes.

Here is what the Layer 3 Interfaces look like:

interfaces-PA

We should have IP connectivity between our Palo-Alto and both of our ISP’s! We’re officially connected to the internet… sort of.

Now for the fun stuff, BGP connections!

Lets start with the Palo-Altos.

  1. Select the  “Virtual Routers’ setion under the Network tab.
  2. Select the “BGP” tab.
  3. ENABLE the BGP protocol by checking the box.
  4. Assign a Router ID. This can be one of the two IP’s on the interfaces facing our WAN services or a loopback (preffered).
  5. Input your local AS Number.
  6. Make sure to UN-CHECK “Reject Default Route”
    1. Both ISP’s will be advertising us Default-Routes. We’ll select one with BGP techniqures as a primary.
  7. Make sure to CHECK “Install Route”
    1. This is necessary if we want to install routes from BGP / Local FIB into the Global Routing Table on the Palo Alto.
  8. Depending on what model Palo-Alto you have, I would suggest creating a BFD profile and enabling this on your WAN connection for a fast-fail over detection to minimize downtime for your internal users.
    1. To create a BFD Profile:
      1. Network > Network Profiles > BFD Profile.
  9. This should be enough for the “General” Tab.

let’s move over to the “Peer Group”

  1. Add a new Peer Group, lets call this ISP 1 – Re-create the steps for ISP 2.
    1. Name: ISP 1
    2. Type: EBGP
  2. Add a new peer.
    1. Name: WAN-ISP-1
    2. Peer-AS: 64511
    3. Select the appropriate Interface / IP Address
    4. Input the appropriate /31 peer IP of the WAN connection.
    5. Under Advanced, make sure the Inherit Protocol’s Global BFD Porifle is selected.
    6. Select OK and commit.

Here is what the BGP Peer Group section should look like at this point:

bgp.PNG

Now, verify our BFD sessions..

bgp

All looks good!  Lets verify we’re seeing a default-route from both peers:

def

From the Local-RIB (And the Route Table) under the “More Runtime Stats” we are installing the default-route from our peer at ISP 1 – 172.16.65.0.

What if that peer is a 1G connection, but our Peer at ISP 2 should be our Primary WAN interface, as it’s a 10G interface? Let’s play with BGP now.

First, lets make sure all our outgoing traffic is going out or preffered exit path ( ISP 2) – let’s change our Local Pref on routes from ISP 2 to be more prefferd over ISP 1.

Navigate to BGP > Import and Add a new policy.

  1. Create a new rule that’s used by ISP-2.
  2. Under the Match tab, select the “From Peer’ – “WAN-ISP-2.”
  3. Unde the Action tab, up the Local Preference to 200 and select OK .
  4. Repeat the steps above and hard set the LP to 100 on WAN-ISP-1.
  5. Commit and let’s compare the route-table from our previous snippet.

Here is the Local-RIB, selecting the default-route from ISP-2.

newrib.PNG

And verifying the Global Route Table as our preffered exit point:

rt-pref

Looks good! All traffic is now routing out 172.16.64.0, which is our preffered 10G WAN interface to ISP-2.

Now how do we influence traffic to come into our AS via ISP 2 in hopes of avoiding asymmetrical routing? Well.. we can prepend if we’re advertising routes or advertise a more specific route to the prefferred neighbor and aggregate the routes advertised to the less preffered neighbor. The MED values are not helpful in this case, as we are peering with two separate providers.

We won’t worry about this for now, as we are not adveritisng any public routes to our providers, we simply need internet for our business.

Lets go ahead and redestribute the default route to our Enterprise core router.

But first.. lets peer with it.

I established a peering session with our Enterprise router and set it inside the “Trust” zone.

  • This is just an example design. Depending on the business, a Router will be at the edge and the firewall will sit behind it which is not true in this scenario.

The BGP session has been established with our Enterprise Cisco Router.

A new Peer Group should be created with a peer defined as the internal router.

ibgp.PNG

ENT-ROUTER#show ip bgp summary
BGP router identifier 192.168.1.2, local AS number 64500
BGP table version is 1, main routing table version 1
1 network entries using 144 bytes of memory
1 path entries using 80 bytes of memory
1/0 BGP path/bestpath attribute entries using 152 bytes of memory
1 BGP AS-PATH entries using 24 bytes of memory
0 BGP route-map cache entries using 0 bytes of memory
0 BGP filter-list cache entries using 0 bytes of memory
BGP using 400 total bytes of memory
BGP activity 1/0 prefixes, 1/0 paths, scan interval 60 secs

Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
192.168.1.1 4 64500 4 4 1 0 0 00:00:21 1

  • An internal BGP session isn’t necessary, as a static default route would be plenty. However, for lab purposes lets continue with more BGP FUN.

We can create static routes that point the two /31 interconnects to our directly connected interface from our Cisco to the Palo. This way, the default route that’s re-advertised by default is actually installed into our routing table.

Network Next Hop Metric LocPrf Weight Path
* i 0.0.0.0 172.16.64.0 200 0 64496 ?

Total number of prefixes 1
ENT-ROUTER#

Again, we’re not installing this route, because our local router has no idea where 172.16.64.0 lives.

Create the two static routes for 172.16.64.0/31 and 172.16.65.0/31 and the magic happens:

cisco

 

Our Enterprise router now has a way out to the world! Don’t forget to create the inter-zone policy to allow traffic from the Trust to Untrust zone. Also, in a real deployment – there will be a NAT rule out to the inter-webz on the PA, but that’s out of scope for this lab, as I wanted to focus attention to the WAN facing configuration on the Palo Alto.

Palo Alto Documentation on NAT

 

Software Defined – BGP (ExaBGP, Postman, FLASK, Python3)

Hello,

I am currently studying for the BGP exam of the Nokia SRA certification path – while doing so, I have found an interesting way to manipulate my BGP routes – I gotta give credit to ThePacketGeek for all their information which made this possible for me.

I’m utilizing several different tools to quickly advertise routes into my EVE-NG Lab topology, which are the following:

  1. Exa-BGP : Exa-Networks GitHub
  2. PostMan : PostMan
  3. RSUB to quickly edit text from through ssh tunel on a remote server : Rsub
  4. Python3
  5. Ubuntu VM
  6. FLASK

I’ve installed UbuntuVM which is on the same network as my EVE-NG topology. Assuming you have a general understanding of the architecture, I’m going to dive right in. I’ve got a Nokia 7750 SR – VPRN with a dot1q sap facing a switch which allows a TCP connection to establish across the link to my VM hosting ExaBGP – All of this is hosted on the same physical server.

  • ExaBGP
    • Install ExaBGP with PIP3.
    • Create a configuration file for  ExaBGP to connect to your router.
      • sudo vi /etc/exabgp/conf.ini

——————————————————————————————————————————–

process announce-routes {
run /usr/bin/python3.6m /home/htinoco/exampl.py;
encoder json;
}
process http-api {
run /usr/bin/python3.6m /home/htinoco/exabg-flask/http_api.py;
encoder json;
}

neighbor 10.0.0.200 { # Remote Peer
router-id 10.0.0.25; # Local router-id
local-address 10.0.0.25; # Local update-source
local-as 65001; # local AS
peer-as 65000; # Peer’s AS

api {
processes [announce-routes, http-api]; #Running multiple processes, python3 script and HTTP API(FLASK)

}


 

Here is the python script I’m calling under the ‘announce-routes’ process, which is ponting to /home/htinoco/exampl.py;

#!/usr/bin/env python3
#Change this to the correct python version you’re using.

from __future__ import print_function

from sys import stdout
from time import sleep

#Static routes I want to always announce when I start ExaBGP
messages = [
‘announce route 250.10.0.0/24 next-hop self’,
‘announce route 120.20.0.0/24 next-hop self’,
‘announce route 110.20.0.0/24 next-hop self’,
‘announce route 150.20.0.1/24 next-hop self’,
‘announce route 100.10.1.0/24 next-hop self’,
]

sleep(5)

#Iterate through messages
for message in messages:
stdout.write(message + ‘\n’)
stdout.flush()
sleep(1)

#Loop endlessly to allow ExaBGP to continue running
while True:
sleep(1)

Now, there is also another process I’m calling, which is my FLASK app.

Here is my flask app:

from flask import Flask, request
from sys import stdout

app = Flask(__name__)

# Setup a command route to listen for prefix advertisements
@app.route(‘/’, methods=[‘POST’])
def command():
command = request.form[‘command’]
stdout.write(‘%s\n’ % command)
stdout.flush()
return ‘%s\n’ % command

@app.route(‘/shutdown’, methods=[‘POST’])
def shutdown():
shutdown_server()
return ‘Server shutting down…’

#The param localhost is applied so we can reach the api remotely –

if __name__ == ‘__main__’:
app.run(host=”localhost”, port=7000, debug=True)

#Example POSTS using postman / (BODY/KEY:COMMAND/VALUE=)
#announce route 100.10.0.0/16 next-hop 172.16.2.202 med 500
#announce route 100.20.0.0/16 next-hop 172.16.2.202 origin incomplete as-path [100 200 400]
#announce route 100.30.0.0/16 next-hop 172.16.2.202 med 200 origin egp
#announce route 100.40.0.0/16 next-hop 172.16.1.2/32 community [65000:666]

 

We are ready to roll! – navigate to /etc/exabgp and lets launch exabgp using the conf.ini file we created –

htinoco@ubuntu-server:/etc/exabgp$ exabgp conf.ini

 

Here is the output after starting exabgp:

: * Serving Flask app “http_api” ( lazy loading )
* Running on http://0:7000/ (Press CTRL+C to quit)
* Restarting with stat
* Debugger is active!
* Debugger PIN: 157-288-415
04:35:45 | 2699 | api | route added to neighbor 10.0.0.200 local-ip 10.0.0.25 local-as 65001 peer-as 65000 router-id 10.0.0.25 family-allowed in-open : 100.10.0.0/24 next-hop self
04:35:46 | 2699 | api | route added to neighbor 10.0.0.200 local-ip 10.0.0.25 local-as 65001 peer-as 65000 router-id 10.0.0.25 family-allowed in-open : 200.20.0.0/24 next-hop self
04:35:47 | 2699 | api | route added to neighbor 10.0.0.200 local-ip 10.0.0.25 local-as 65001 peer-as 65000 router-id 10.0.0.25 family-allowed in-open : 210.20.0.0/24 next-hop self
04:35:48 | 2699 | api | route added to neighbor 10.0.0.200 local-ip 10.0.0.25 local-as 65001 peer-as 65000 router-id 10.0.0.25 family-allowed in-open : 220.20.0.1/24 next-hop self
04:35:49 | 2699 | api | route added to neighbor 10.0.0.200 local-ip 10.0.0.25 local-as 65001 peer-as 65000 router-id 10.0.0.25 family-allowed in-open : 240.20.1.1/24 next-hop self

We see the static routes advertisted to our BGP neighbor, from our python script.

We can now open up Postman and POST new routes as we please.

postman

In this example, I’m using “POST” and KEY “command” (review the flask-app code)

to annoucne the route : announce route 44.44.24.4/32 next-hop self community [65000:666]

The out put from exabg tail process:

04:40:10 | 2699 | api | route added to neighbor 10.0.0.200 local-ip 10.0.0.25 local-as 65001 peer-as 65000 router-id 10.0.0.25 family-allowed in-open : 44.44.23.4/32 next-hop self community 65000:666

Now lets verify that I am seeing this route on my 7750 SR router that has the BGP session established with ExaBGP.

32.PNG

There they are! The static routes from our python script and the freshly announced /32 route utilizing the API POST method.

Now we have a SUPER EASY! way to pump routes into our lab environemnt (Or production) in order to test policies, verify proper traffic patterns, correct route installment, etc. The possibilities are endless! I am going to use this to for many other tests, such as applying MED, route manipulation with communities and just more general policy based routing.

DDoS Mitigation – RTBH – Blackhole Community

I’m working on a mini-series of videos to demonstrate a common practice with Service Provider networks in regards to DDoS Mitigation. A quick google search and you can find PDF documents from ISP’s all over the world with detailed BGP communities they accept and how they manipulate traffic through their particular AS.

A BGP community string is simply a way to control policy routing through your upstream provider network. The community string in which I’ve been concentrating on is the common “Blackhole” community. This community is advertised to upstream providers to instruct the ISP to discard all traffic to the destination prefix before it is routed to the customer. It is common practice to allow this community. Inquire with your provider for the BGP community document to better understand the way in which you can manipulate  upstream traffic to your advantage.

This lab was mostly rooted from personal projects I’m undergoing but also a great excuse to start pushing the limits of my new EVE-NG server.  I’m really enjoying the interface and the ease-of-use.

Here is the part 1 of the video series. More to come, stay tuned..!

Nokia: Service Router – Default Originate Replica (Cisco BGP Command)

A simple overview on how to re-create the Cisco BGP ‘default-originate’ command for a default route advertisement from a Nokia Service Provider perspective (IPv4/IPv6.)

There are several ways to advertise a default route in the Cisco environment – here is a quick summary:

  1. The first option is what we will attempt to replicate from a Nokia Service Router perspective. Advertising a default route PER BGP Peer instance. This is a more controlled way of advertising.
    ‘neighbor X.Y.X.Y default-originate’ Again, this doesn’t require an active default route to be present or redistributed. This will generate and propagate to the specified neighbor only.
  2. Adding a “network 0.0.0.0” command under the address family for your BGP routing instance to advertise to ALL neighbors. Remember: This requires an present /0 route in the FIB.
  3. Redistribution – from a currently active default route in the routing table of an IGP. Hence, redistribute – (Almost the same as option 2)
  4. “Default-information originate” – This command will GENERATE a default route to ALL BGP neighbors under the family. An active default route is NOT required to be present under another routing instance in order to propagate the new default route to all BGP peers

—————————–

The topology will be a Cisco edge device dual-homed to a Nokia PE devices from ISP XYZ. NOTE: There is currently no route map prepending the AS, but we are load balancing.

 

The topology will be a Cisco edge device dual-homed to a Nokia PE devices from ISP XYZ. NOTE: There is currently no route map prepending the AS, but we are load balancing.

topology

Here is the configuration from the Cisco Edge Device (CustomerSiteB):

Capture.PNG

Not much in configuration. Standard BGP session to an ISP (without authentication)  – Note the BFD configuration for the peers for a fast failover. Will do a blog post about this in the upcoming weeks, which I will demonstrate the fast-external-fallover command as well.

Currently, we are not learning any BGP routes from our ISP.  Here is the configuration from the Nokia PE devices R5/R6.  (Only showing one side, as they are extremely similar, with only varying subnets)

vprn

Creating a Prefix-List:

Lets begin the process to simulate the default-route advertisement.

Note: add prefix ::/0 exact for IPv6 & family ipv6 under the policy statement.

We’ll start by configuring a prefix list on our PE devices (R5/R6):pflist.PNG

Next, we create a Policy Statement:

default.PNG

Make sure to COMMIT the changes!

Adding the policy statement under the BGP configuration inside the VRFs.

/configure service vprn 100 # Example VRF

  • #Create a Black Hole/ Null Route to discard any unwanted/un-routable traffic.
    static-route ::/0 black-hole
    static-route 0.0.0.0/0 black-hole

Add the new “Default Originate” policy statement we created earlier to the the BGP Group of your customer as an export statement.

export.PNG

At this point we should be advertising ONLY a default route to our BGP neighbor.

From our PE device, a quick “show router 100 bgp neighbor 175.175.1.2 advertised-route” will display the following:

advertised.PNG

I will go ahead and replicate this policy statement on both VPRN’s on R5/R6 – Our Nokia PE devices for the Dual-Homed BGP Customer and apply the export statement to the BGP peer.

A look at “show ip route bgp” on the CustomerSiteB Cisco edge device shows us the two paths (thanks to the the load balancing, ‘maximum-paths 2’ configuration):

ecmp.PNG

Now we are learning a default route from both uplinks to our dual-homed ISP connection. Failover should be seamless at this point, although having two default routes is prob not what you want – this is a simple example of how to accomplish a default-originate command, which doesn’t exist on the Nokia environment.

Site-to-Site IPSec over MPLS VPN

I want to start by saying I’ve over complicated everything because, well, it’s my lab and it’s fun for me. Depending on customer needs, a simple MPLS L2 VRF and an IPSEC tunnel on top would be sufficient, unless the sites also require internet service by the Service Provider delivering the VRF. In a simple MPLS VPN where the service simply connects sites to sites, the IP addresses are not advertised and could be a lot more secure than over the internet. Another advantage of utilizing an MPLS VPN is the ease of troubleshooting for the customer – the service traverses only one provider – not through the internet.

Lets take a deep dive at what an IPSEC tunnel looks like from an Enterprise perspective over a service provider MPLS L2/L3 VPN, not only from the CustomerSites but what actually happens inside the ServiceProvider network? In this case, we’ll be going from a statically configured site, which is Site-A on the left (Topology A below). The configuration is a Static L3 MPLS VRF provisioned with a Nokia Routed-VPLS utilizing a VRRP for Router-Redundancy (R2/R3). This is a common configuration provided by Service Providers to customers.
The MPLS VRF goes across the MPLS Core Network and terminates on R6 and R5. Both of these sites are participating in the same VRF (VPRN 100) and have an eBGP session set up to the CustomerSiteB on the right side.

A few key notes:
I’ve set up an AS-Path prepend from the Customer Router at Site B facing the eBGP session on R5 at 175.175.1.1.
The Customer Site B router is currently load balancing across both eBGP neighbors to take full advantage of the dual-homed configuation.

site-to-siteipsecovermpls

Topology A.

MPLS Security?

An MPLS VPN (L2 or L3) Is secure to a certain degree. MPLS VPNs do not encrypt packets across the network, which makes it susceptible to eavesdropping by intruders.

Here is a wireshark capture without IPSEC between CustomerSiteA and R1. The traffic shows icmp request from CustomerSiteB to the Lo0 of CustomerSiteA.  As you can see, there is no encryption by the Service Provider and the service being delivered could easily be sniffed. How much do you trust your Service Provider?

Continue reading “Site-to-Site IPSec over MPLS VPN”