Friday, October 21, 2022

Azure Security - Overview based on AZ-500

    This post is a review of Azure Security, based on the training provided during the Security Cloud Week for Partners, with focus on the AZ-500 track. I've spent a lot of time on testing different security features based on the labs provided. My initial plan was to subscribe to the SC-100 track, but the lack of labs on that track made me change direction towards AZ-500. 





What does AZ-500 cover?

    The exam covers all aspects of cloud-based security in Microsoft Azure, including protection of identity, access, data, applications and networks. The rich amount of security features is tied closely to the MITRE ATT&CK® framework, which basically describes all the techniques used by modern day security threats. This is a more detailed version of the Cyber Kill Chain developed by Lockheed Martin. The purpose is to master all aspects of Azure security in order to offer protection from all the different steps and techniques used by an attacker. You can learn more about the mapping between Azure Security and MITRE framework on this article

Identity and Access (30-35%)

    The first thing you have to master is identity and access protection. This part has a lot of focus on Azure AD and hybrid identity protection. You have to master things like conditional access, Multi-Factor Authentication, access reviews etc. Once you have mastered all the security related features, you might wonder which ones you should activate for your organization. Microsoft has provided a document describing the security best practices which might come handy. You can find it here.

Implement Platform Protection (15-20%)

    The platform consists of infrastructure and network resources running on Azure. The purpose here is to harden the infrastructure as much as possible, so that we are better protected when the actual attack happens. Topics to master include implementation of security on the perimeter, network, hosts and containers. I've had some challenges with Containers security especially, due to my limited experience with containers, so I expect to put more focus on that part in the near future. If you are implementing platform protection in your environment, you might want to consider best practice articles provided by Microsoft like these: network securitycontainer security.

Secure your data and applications (25-30%)

    Here you will learn a lot about Azure Key Vault, storage, applications and SQL security. The purpose is to protect access to applications, and secure data on rest or in transit. The exam focuses particularly on the Azure Key Vault and overall secret and keys protection. Once you have mastered all the topics you can read what is considered best practice in terms of securing data and applications on these articles: SQLKey VaultApplications

 Manage Security Operations (25-30%)

    Now once you have found out how to protect identity, access, platform, data and applications, you need some way to operate all this security posture you have built. Azure has 3 main tools to simplify operations, basically Azure Monitor, MS Defender for Cloud and Sentinel. AZ-500 helps you with exploring all the features available, but within a limited scope. Sentinel as an example requires much more focus than what is given on the exam. I've found some best practice article on Sentinel here.

Implementation considerations

  One way to implement security is to master all the aspects of the platform provided by Azure and follow their best practice documents. Depending on the specific task or project, you might need to have more focus on specific aspects, but as long as you use their recommendations and best practice documents, you should be good. Operations itself is simplified by all the tools and benchmarks that are already built into the platform. 

  Another approach most companies use to streamline their security is by implementing standard controls, like NIST, CIS etc. Azure has a lot of these regulatory compliance controls built into the Defender for Cloud. You could though make your own decisions and start with the standard itself. If you decide to implement CIS, it can be helpful to use the security guideline built by Microsoft in collaboration with them. You can find it here. It contains all the steps necessary for auditing and implementing the technical CIS controls. 

Conclusion

  Security in Azure and Microsoft generally might be a bit overwhelming due to the large amount of tools, dashboards, manuals. Microsoft is working constantly on simplifying the baseline configurations and consolidating the dashboards, but it's still a work in progress. I've found that attending trainings regularly, reading their best practice documentation and testing as many features as you can is pretty helpful in regard to building the knowledge needed to manage most aspects of security. 


Thursday, September 1, 2022

BGP Filtering Techniques

 

This article describes 3 different techniques to filter inbound BGP routes.

    Let's consider a scenario where we have 2 different companies. The first company has its own DC running OSPF internally with everything in area 0, its own ASN and BGP peering to ISP A. The second company has another DC, which is also running OSPF internally in area 0, with a different ASN and BGP peering to ISP A. 


Fig.1 Topology

    The first company acquires the second one, and we face the challenge to connect the 2 DC environments to each other. As part of the design, we decide to establish direct fiber between the companies. Once this is in place, we would like to have all traffic between the DC's to use this link, instead of going through ISP A. However we notice that the routes from the 80.80.0.0/16 address space learned through BGP and redistributed into OSPF take precedence over the OSPF learned routes. 

    In order to resolve this issue, we need to have some mechanisms in place that prevents routes announced from DC1 to ISP A via eBGP to be learned via BGP and injected back into OSPF in the DC2 and vice versa. You can find the lab file at the end of this post. 

Method 1:  The traditional way of doing it

    The first option is probably also the most obvious. We filter the inbound BGP routes with a prefix-list and a route-map. Let's check how routing towards the public IPv4 subnets looks like in the DC's first. 
R1-DC01# show ip route 80.80.200.0
Routing entry for 80.80.200.0/24
  Known via "ospf 1", distance 110, metric 1
  Tag 65100, type extern 2, forward metric 20
  Last update from 10.100.12.2 on Ethernet0/0, 00:03:57 ago
  Routing Descriptor Blocks:
  * 10.100.12.2, from 10.100.100.2, 00:03:57 ago, via Ethernet0/0
      Route metric is 1, traffic share count is 1
      Route tag 65100

R2-DC01# show ip route 80.80.200.0
Routing entry for 80.80.200.0/24
  Known via "bgp 65001", distance 20, metric 0
  Tag 65100, type external
  Redistributing via ospf 1
  Advertised by ospf 1 subnets
  Last update from 100.100.23.3 00:04:42 ago
  Routing Descriptor Blocks:
  * 100.100.23.3, from 100.100.23.3, 00:04:42 ago
      Route metric is 0, traffic share count is 1
      AS Hops 2
      Route tag 65100

R5-DC02#show ip route 80.80.100.0
Routing entry for 80.80.100.0/24
  Known via "bgp 65002", distance 20, metric 0
  Tag 65100, type external
  Last update from 100.100.45.4 00:10:10 ago
  Routing Descriptor Blocks:
  * 100.100.45.4, from 100.100.45.4, 00:10:10 ago
      Route metric is 0, traffic share count is 1
      AS Hops 2
      Route tag 65100

R6-DC02#show ip route 80.80.100.0
Routing entry for 80.80.100.0/24
  Known via "ospf 1", distance 110, metric 1
  Tag 65100, type extern 2, forward metric 20
  Last update from 10.200.56.5 on Ethernet0/0, 00:00:17 ago
  Routing Descriptor Blocks:
  * 10.200.56.5, from 10.200.200.5, 00:00:17 ago, via Ethernet0/0
      Route metric is 1, traffic share count is 1
      Route tag 65100
    So, we have 2 problems. Edge routers R2 and R5 are injecting the BGP route due to the lower administrative distance of BGP, while the core routers R1 and R6 are injecting it because the metric for the redistributed route from BGP to OSPF is "1", unless if specified manually. We implement the following prefix list and route map on R2 and R5 and apply it to the peering towards R3 and R4 in the inbound direction. 
R2-DC01#
ip prefix-list INTERNAL seq 10 permit 80.80.0.0/16 ge 24
route-map FILTER-IN deny 10
 match ip address prefix-list INTERNAL
route-map FILTER-IN permit 20

router bgp 65001
 bgp log-neighbor-changes
 neighbor 100.100.23.3 remote-as 65100
 address-family ipv4
  network 80.80.100.0 mask 255.255.255.0
  neighbor 100.100.23.3 activate
  neighbor 100.100.23.3 route-map FILTER-IN in


R5-DC02#
ip prefix-list INTERNAL seq 10 permit 80.80.0.0/16 ge 24
route-map FILTER-IN deny 10
 match ip address prefix-list INTERNAL
route-map FILTER-IN permit 20

router bgp 65002
 neighbor 100.100.45.4 remote-as 65100
 address-family ipv4
  network 80.80.200.0 mask 255.255.255.0
  neighbor 100.100.45.4 activate
  neighbor 100.100.45.4 route-map FILTER-IN in
Now let's have a look at the routing table, just to be sure. 
R1-DC01#show ip route 80.80.200.0
Routing entry for 80.80.200.0/24
  Known via "ospf 1", distance 110, metric 20, type extern 2, forward metric 10
  Last update from 10.100.200.6 on Ethernet0/1, 00:05:04 ago
  Routing Descriptor Blocks:
  * 10.100.200.6, from 10.200.200.6, 00:05:04 ago, via Ethernet0/1
      Route metric is 20, traffic share count is 1

R2-DC01#show ip route  80.80.200.0
Routing entry for 80.80.200.0/24
  Known via "ospf 1", distance 110, metric 20, type extern 2, forward metric 20
  Last update from 10.100.12.1 on Ethernet0/0, 00:05:45 ago
  Routing Descriptor Blocks:
  * 10.100.12.1, from 10.200.200.6, 00:05:45 ago, via Ethernet0/0
      Route metric is 20, traffic share count is 1

R5-DC02#show ip route 80.80.100.0
Routing entry for 80.80.100.0/24
  Known via "ospf 1", distance 110, metric 20, type extern 2, forward metric 20
  Last update from 10.200.56.6 on Ethernet0/0, 00:08:54 ago
  Routing Descriptor Blocks:
  * 10.200.56.6, from 10.100.100.1, 00:08:54 ago, via Ethernet0/0
      Route metric is 20, traffic share count is 1

R6-DC02#show ip route 80.80.100.0
Routing entry for 80.80.100.0/24
  Known via "ospf 1", distance 110, metric 20, type extern 2, forward metric 10
  Last update from 10.100.200.1 on Ethernet0/1, 00:09:50 ago
  Routing Descriptor Blocks:
  * 10.100.200.1, from 10.100.100.1, 00:09:50 ago, via Ethernet0/1
      Route metric is 20, traffic share count is 1
    As you can see from the routing tables, we are now using the direct link between the DC's, just as we wanted it. This solution comes though with the challenge of keeping the prefix-list updated. Easy, right? Until when you spend hours trying to find and update some prefix-list or ACL somewhere in the network. 

Method 2:  The well known attribute

    Even though the first method solves the design requirement, we have the challenge of keeping the prefix-list updated. Since we have 1 AS for each DC, we could do the filtration based on the BGP well known attribute ASN. Instead of building a route-map, we just need to create an as-path filter and apply it directly to the peer with a filter list. Let's make it happen. 

Here is how the configuration looks like:
R2-DC01#
ip as-path access-list 1 deny ^65002$
ip as-path access-list 1 permit .*

router bgp 65001
 address-family ipv4
  neighbor 100.100.23.3 filter-list 1 in
 exit-address-family

R5-DC02#
ip as-path access-list 1 deny ^65001$
ip as-path access-list 1 permit .*

router bgp 65002
 address-family ipv4
  neighbor 100.100.45.4 filter-list 1 in

    The end result is the same. The routes containing AS 65002 in the as-path are filtered inbound on R2 and the ones containing AS 65001 are filtered inbound in R5. The final routing table looks exactly the same as the final one on method 1. This method is widely adapted, but we just need to keep in mind that it will filter any routes containing the respective AS on the path. 
 

Method 3: Some magic?

    Well let's say that managment doesn't like route-maps, acl's or filter lists, and they want the whole config to be done within the BGP process. Typical manager, right?  Just find a solution and fix it.

    However, we can use a magic trick, local-as, which makes us appear as if we were members of another AS than the actual one. We will implement the changes on DC2. This is very handy in cases of acquisitions, where we don't want to change our original peering agreements. 

    After the local-as configuration is applied, both the real ASN and the local-as are added to the AS path. In our case, routes transiting ISP A, would have both AS 65001 and 65002 when they reach DC1. The BGP loop prevention mechanism would then drop advertisements inbound on DC01, since the local ASN is part of the AS_Path in a route received through eBGP. Let's have a look at the configuration that is necessary to make this happen. 

First, let's look at the advertisements on R2 and R5:

R2-DC01#show ip bgp 80.80.200.0
BGP routing table entry for 80.80.200.0/24, version 13
Paths: (1 available, best #1, table default)
  Not advertised to any peer
  Refresh Epoch 1
  65100 65002
    100.100.23.3 from 100.100.23.3 (100.100.100.3)
      Origin IGP, localpref 100, valid, external, best
      rx pathid: 0, tx pathid: 0x0

R5-DC02#show ip bgp 80.80.100.0
BGP routing table entry for 80.80.100.0/24, version 22
Paths: (1 available, best #1, table default)
  Not advertised to any peer
  Refresh Epoch 1
  65100 65001
    100.100.45.4 from 100.100.45.4 (100.100.100.4)
      Origin IGP, localpref 100, valid, external, best
      rx pathid: 0, tx pathid: 0x0

    So in this case we see only the ASN of ISP A and the one from the other DC. In order to implement the solution, we need to change the BGP process id on R5, and configure the local-as for the peering towards R4. 

The final config on R5 looks like this:

R5-DC02#show run | se router bgp
router bgp 65001
 bgp log-neighbor-changes
 neighbor 100.100.45.4 remote-as 65100
 neighbor 100.100.45.4 local-as 65002
 !
 address-family ipv4
  neighbor 100.100.45.4 activate
 exit-address-family

    In order to verify the presence of both AS65001 and 65002 on the route advertised from R5, we can use the ISP routers R3 or R4. We can also check that the routes for the 80.80.x.x are no longer pointing towards ISP A on R2 and R5. 

R3-ISP# show ip bgp 80.80.200.0
BGP routing table entry for 80.80.200.0/24, version 17
Paths: (1 available, best #1, table default)
  Advertised to update-groups:
     10
  Refresh Epoch 1
  65002 65001
    100.100.34.4 from 100.100.34.4 (100.100.100.4)
      Origin IGP, metric 20, localpref 100, valid, internal, best

R2-DC01#show ip route 80.80.200.0
Routing entry for 80.80.200.0/24
  Known via "ospf 1", distance 110, metric 20, type extern 2, forward metric 20
  Last update from 10.100.12.1 on Ethernet0/0, 00:11:02 ago
  Routing Descriptor Blocks:
  * 10.100.12.1, from 10.200.200.6, 00:11:02 ago, via Ethernet0/0
      Route metric is 20, traffic share count is 1

R5-DC02#show ip route 80.80.100.0
Routing entry for 80.80.100.0/24
  Known via "ospf 1", distance 110, metric 20, type extern 2, forward metric 20
  Last update from 10.200.56.6 on Ethernet0/0, 00:10:07 ago
  Routing Descriptor Blocks:
  * 10.200.56.6, from 10.100.100.1, 00:10:07 ago, via Ethernet0/0
      Route metric is 20, traffic share count is 1

Conclusion

    We looked at 3 different ways to filter inbound eBGP advertisements and routes, route-maps and prefix-lists, as-path acl and filter-lists, and the magic trick with local-as. All three methods have their ups and downs, but the end result is the same in our specific scenario. 

References


Lab



Tuesday, August 4, 2020

FTDv with FDM on Hyper-V

This article is for them who need a Cisco Firewall in their Hyper-V infrastructure, that can be managed without the ASDM/Java nightmare and offers Next Generation capabilities for modern day threats. During the years, Cisco virtual platforms have always been VMWare oriented, providing a challenge for companies that already have a Hyper-V infrastructure on their premises. One of these platforms is Firepower Threat Defense Virtual (FTDv), which only recently became supported in Azure (version 6.4.0) and is still unsupported in Hyper-V environments. From version 6.5.0 the integrated Firepower Device Manager has been added, which allows for local management of the firewall, without need for FMC. This article explains how to implement FTDv in Hyper-V by using the VHD file provided for Azure.



For this task you need:

  1. VHD Azure image from the Cisco Support portal or your Cisco Partner
  2. 50GB of free space
  3. 4vCPU
  4. 8GB of free Memory

The VM

After downloading the image from Cisco Support, as first step you need to decompress it as it comes in a bzip2 format. You can use Winzip,7zip, the official bzip2 for decompression. Make a folder in your storage, where you want to store the VM and put the VHD file inside that folder.

In order to deploy the VM, we are going to use some PowerShell cmdlet, but you can also follow the normal Wizard from Hyper-V Manager, if you feel more familiar with it. We need to fill in some info before pushing the configuration, which includes the name for the VM, the place where we want it to be stored (-Path), the Generation, and the memory size (-MemoryStartupBytes).


Then we increase the CPU count on the VM


The Azure VHD image comes with 4 NIC's, respectively Management, Diagnostic 0/0, GE0/0 and GE0/1. Where GE0/0 is the outside port and GE0/1 the inside one in the default configuration. To match this configuration, we rename the network card created together with the VM and add a few more.


As last step we need to attach the VHD to the newly created VM


Depending on your environment, you need to attach the NIC's to the respective virtual switch and tag any necessary VLAN's for management, inside subnet and outside.


FTDv Deployment (Fun Part)

The Hyper-V part is now completed, so we fire on the VM and proceed following the console for the installation. Don't get confused by the ASA boot image name. Even though it's probably an ASA on the backend, it's using the FTD image, so you will get a different CLI and FDM instead of ASDM, which is a big improvement.


You might want to have a cup of coffee after this step, as the process takes some time. Especially the database configuration can easily take 30 minutes or more.



When the process is finally done, you will be presented with the login prompt. The credentials for the first login are admin/Admin123. After login, you are required to change your password, setup the IPv4/IPv6 address for the firewall and select if you are going to use a local manager or remote one.



In our case we are interested in FDM, the built in management web interface, so we will choose local management.


As next step we need to login to the management interface from a web browser. After login, you are presented with the Device Setup Wizard. This helps in setting up the outside IP address, Time Settings and License registration. If you don't have a license at this point, you can use the evaluation period, which is valid for 90 days.



If you would like to test all features, you need to open a case with Cisco Global Licensing and ask for a trial license. Your Cisco Partner can help you with this process. If you work for a Cisco Partner, you can send an e-mail to licensing@cisco.com with the following info:

- Product type is [FTD]oSensor type is [Sensor Model]

 - Partner Smart Account Domain ID [Domain] 

 - Partner Smart Account Name [ Account Name] 

 - Partner Smart Virtual Account Name [ Smart Acc Name]

 - Expected Start Date is [ Date ]

This should be the last step, before you are presented with a fully working firewall. To keep the article short I haven't included screenshots for every step, but feel free to PM me if something is not working for you, or you need further details.

Considering that running FTDv on Hyper-V is not officially supported, you might have problems with receiving support related to the virtualization platform. However, I have tested different features, NAT, RAVPN, S2SVPN, as well as the security blades and all work smoothly. Remember that Cisco's support is always customer oriented.

References:


Monday, September 23, 2019

CMNA Certified!



Last week I had the great opportunity of joining the CMNA training in Copenhagen, in what I would say was a hands-on conference. The certification process was quite straight forward and didn't require any advanced networking skills. However, coming from traditional Cisco certifications, I was surprised by the certification technique chosen by Meraki. While most certification exams focus on testing your knowledge and skills in specific topics, Meraki pushed us through a learning process. We had to go through all the Meraki product portfolio in the presentations section, as well as the implementation of technologies like QoS, SD-WAN, Wireless, Layer 7 firewall, motion detection etc. in the lab section.

Whenever you join conferences or trainings, it's important to understand what you take with you at the end of the day. My thoughts about Meraki and the hands-on conference are:

- Simplicity is the key in all Meraki solutions. You can take a bunch of sales, tech nerds and students in a room and make them deploy a multi-branch environment good enough for most companies in DK.  

- What's simple, doesn't have to be limited. Meraki has always embeded technologies only after introducing the highest level of abstraction, as close to the human nature as possible. Despite our mixed technical skills, or lack of them, we were all able to implement a broad range of technologies, which would require days to understand and implement in the old traditional Cisco enviroment. 

- A conference doesn't have to be boring and a training/certification doesn't have to be complicated. If the best of both worlds is mixed: well-prepared presentation sessions and simplified lab experiences, the process itself will provide the best experience for the participants, and the most productive results for the presenting company.