Ansible - Command vs Shell

 If you need a shell environment, use the shell module. 

Command:

ansible <host in inventory> -m ansible.builtin.shell -a '<shell command>'

Example

-ansible webservers -m ansible.builtin.shell -a 'mkdir MyTestFolder'

Can we have a hybrid cloud strategy for OT ?

Let's give you directly the answer. It's yes, but! 

Moving Operational Technology (OT) applications to the cloud while implementing a hybrid cloud strategy involves careful planning, a focus on security and compliance, and a phased approach to minimize disruptions. Here's a step-by-step guide on how to do it:

• Assessment and Planning:

Inventory and Prioritization: Identify and categorize your existing OT applications. Determine which applications are suitable for cloud migration based on factors like data sensitivity, security requirements, and performance considerations.

• Design Your Hybrid Cloud Architecture:

Select a Cloud Service Model: Decide whether you'll use Infrastructure as a Service (IaaS), Platform as a Service (PaaS), or a combination of both. The choice depends on your application requirements and expertise. Choose Cloud Providers: Select cloud providers that align with your specific needs. Consider factors like regional data centers, compliance certifications, and pricing.

Network Connectivity: Ensure you have a reliable, secure, and low-latency connection between your on-premises OT environment and the cloud.

• Security and Compliance:

Data Security: Implement encryption for data at rest and in transit. Utilize Identity and Access Management (IAM) and role-based access control to manage user permissions.

Compliance: Ensure your cloud solution complies with industry-specific regulations (e.g., NIST, IEC 62443) and follows best practices for OT security.

• Application Migration:

Rehost, Refactor, or Redesign: Choose the migration approach that best fits your applications. Rehosting (lift and shift) is the quickest but may not be the most efficient. Refactoring or redesigning for cloud-native services can lead to better performance and cost optimization.

Testing: Extensively test applications in the cloud to ensure they perform as expected. Consider using staging environments to minimize potential downtime.

• Monitoring and Optimization:

Cloud Monitoring Tools: Implement cloud monitoring tools and services to keep an eye on the performance, security, and cost of your cloud-based OT applications.

Cost Management: Regularly review and optimize your cloud costs, adjusting resources as needed to avoid unnecessary expenses.

• Training and Documentation:

Train your OT staff on cloud technologies and best practices. Document your cloud setup, configurations, and procedures for future reference.

Remember that moving OT applications to the cloud is a complex process, and it should be done with the utmost care due to the critical nature of many OT systems. 

How to apply Zero trust to a Legacy OT system ?

Applying zero trust to a legacy OT (Operational Technology) system can be challenging, but it is still possible. Here are some steps that can be taken to apply zero trust principles to a legacy OT system:

1. Identify the assets: The first step is to identify all the assets in the legacy OT system. This includes hardware, software, and data.

2. Map the data flows: Map the data flows within the legacy OT system to understand how data is exchanged between different assets.

3. Define the security perimeter: Once the assets and data flows have been identified, define the security perimeter for the legacy OT system. This involves defining the boundaries of the system and what assets and data are considered part of the system.

4. Implement access controls: Implement access controls based on the principle of least privilege. This involves granting users and devices access only to the specific assets and data they need to perform their job functions.

5. Monitor and log all activities: Implement monitoring and logging of all activities within the legacy OT system. This will help detect and respond to any security incidents.

6. Implement security controls: Implement security controls such as firewalls, intrusion detection systems, and data encryption to secure the legacy OT system.

7. Update and patch legacy systems: If possible, update and patch the legacy OT system to improve its security posture. This may involve replacing or upgrading legacy hardware and software components.

8. Conduct regular security assessments: Conduct regular security assessments of the legacy OT system to identify and address any vulnerabilities

Applying zero trust to a legacy OT system may require a phased approach and a combination of technical and organizational measures. It is important to involve all stakeholders, including IT and OT teams, in the planning and implementation of zero trust measures to ensure their success.

IT/OT Convergence - Not only a technical challenge!

The convergence of IT (Information Technology) and OT (Operational Technology) can present several challenges:

• Management: in most of the company, IT and OT systems were managed by different teams, with different skills and expertise. It can be difficult to ensure that the two teams are being managed effectively and that the IT and OT engineers are working together effectively.
• Compliance and regulation: IT and OT have different compliance and regulatory requirements. It can be difficult to ensure that both systems are meeting all relevant standards.
• Understanding and process: both teams are talking different languages and have different expectations. There is long a learning curve to take in consideration if you start this journe. IT must understand OT and the other way around. This understanding must not be limited to technical aspects. The process must also be taken in consideration. For example, ITIL processes are not well known by most of the OT Teams.

For the reasons listed above, it's important to build a strong governance. You should have a dedicated team in charge of the convergence process, with clear roles and responsibilities and the right level of expertise in IT and OT.

And maybe the most important. A trust must be created between both teams.

 

How to use the Ansible Vault ?

 If your are using a clear password in your YAML file, you can encrypt the file via Ansible-vault.

• How to encrypt the credentials ?

#ansible-vault encrypt MyCredentials.yml

New Vault password: <Enter the password and stored in a safe place>
Confirm New Vault password: <Enter the same password>
 Encryption successful

• How to view the encrypted credentials ?

#ansible-vault view MyCredentials.yml

Vault password: <Enter the password previously chosen>

• How to change data in your file (for example your credentials) ?

decrypt the file MyCredentials.yml

User@Ansible-Host:~/> ansible-vault decrypt MyCredentials.yml
Vault password: <known_key>
Decryption successful

Edit the file with your preferred editor (vim/nano) by changing the data.

Then encrypt the file again

User@Ansible-Host:~/> ansible-vault encrypt MyCredentials.yml
New Vault password: <known_key>
Confirm New Vault password: <known_key>
Encryption successful

2023 - New Posts - I'm back

 After a big pause, I have decided to share again my experience. I will publish more articles on several topics and no more just the network. The following areas will be covered:

• IT/OT Convergence. For this specific area, I would like to cover the technical challenges but also the organization changes which brings this convergence.
• IoT 4.0 and cybersecurity.
• Advanced firewalling.
• Ansible and Automation.

BGP Conditional Advertisement

This BGP feature is able to filter a subnet advertisement based on a certain match (AS-PATH, subnet in the routing table...). In our example below, we can image that AS100 is an ISP1 and AS200 is an ISP2. In most of the case, we monitor only the status of the interface which is directly connected. But in our case, we will monitor the presence of the subnet 20.20.20.0/24 which is advertised by the ISP1.
By default, we only advertise the subnet 50.50.50.0/24 to ISP1 and if the subnet 20.20.20.0/24 disappears, we announce it also to ISP2. We can typically use this feature when ISP2 is more expensive than ISP1.

• Configuration:

R1:
interface Loopback50
 ip address 50.50.50.50 255.255.255.0
!
interface Ethernet0/0
 ip address 192.168.50.1 255.255.255.0
!
interface Ethernet0/1
 ip address 192.168.150.1 255.255.255.0
!
router bgp 50
 network 50.50.50.0 mask 255.255.255.0
 neighbor 192.168.50.2 remote-as 100
 neighbor 192.168.150.3 remote-as 200
 neighbor 192.168.150.3 advertise-map NOT_ANNOUNCE_R3 non-exist-map ADVERTISE
!
ip prefix-list LO20 seq 5 permit 20.20.20.0/24
!
ip prefix-list LO50 seq 5 permit 50.50.50.0/24
!
route-map NOT_ANNOUNCE_R3 permit 10
 match ip address prefix-list LO50
!
route-map ADVERTISE permit 10
 match ip address prefix-list LO20
R2:
interface Loopback20
 ip address 20.20.20.20 255.255.255.0
!
interface Ethernet0/0
 ip address 192.168.50.2 255.255.255.0
!
interface Ethernet0/1
 ip address 192.168.100.2 255.255.255.0
!
router bgp 100
 network 20.20.20.0 mask 255.255.255.0
 neighbor 192.168.50.1 remote-as 50
 neighbor 192.168.100.3 remote-as 200
R3:
interface Ethernet0/0
 ip address 192.168.100.3 255.255.255.0
!
interface Ethernet0/1
 ip address 192.168.200.3 255.255.255.0
!
interface Ethernet0/2
 ip address 192.168.150.3 255.255.255.0
!
router bgp 200
 neighbor 192.168.100.2 remote-as 100
 neighbor 192.168.150.1 remote-as 50

• Initial behavior:

R3 sees subnet 50.50.50.0/24 only from R3
R3#sho ip bgp
     Network          Next Hop            Metric LocPrf Weight Path
 *   20.20.20.0/24    192.168.150.1                          0 50 100 i
 *>                   192.168.100.2            0             0 100 i
 *>  50.50.50.0/24    192.168.100.2                          0 100 50 i
We can check that R1 is not advertising the subnet to R3:
R1#sho ip bgp neighbors 192.168.150.3 advertised-routes
     Network          Next Hop            Metric LocPrf Weight Path
 *>  20.20.20.0/24    192.168.50.2             0             0 100 i
R1#sho ip bgp neighbors 192.168.50.2 advertised-routes
     Network          Next Hop            Metric LocPrf Weight Path
 *>  50.50.50.0/24    0.0.0.0                  0         32768 i
R1#sho ip bgp neighbors 192.168.150.3 | in Conditio
  Condition-map ADVERTISE, Advertise-map NOT_ANNOUNCE_R3, status: Withdraw

• Now the subnet 20.20.20.0/24 is removed from the routing table:

R2#int lo20
shut

We can check that R1 is now advertising the subnet to R3:
R1#sho ip bgp neighbors 192.168.150.3 | in Conditio
  Condition-map ADVERTISE, Advertise-map NOT_ANNOUNCE_R3, status: Advertise
R1#sho ip bgp neighbors 192.168.150.3 advertised-routes
     Network          Next Hop            Metric LocPrf Weight Path
 *>  50.50.50.0/24    0.0.0.0                  0         32768 i

R3#sho ip bgp
BGP table version is 18, local router ID is 192.168.200.3
 *>  50.50.50.0/24    192.168.150.1            0             0 50 i
 *                    192.168.100.2                          0 100 50 i

Simple regular expression Cisco CLI (AND)

This small memo explains just how to use a show command pipe command to get a AND regular expression. For example :
show interface status | inculde textA AND textB

In order to perform this action, you can use this expression:
show  interfaces status | in textA.*textB

Example, show all interface Gi1/2/ which are connected:
show  interfaces status | in Gi1/2/.*connected

BGP MED routing decision - Always-compare-med

MED (Multi-Exit Discriminator) is used to influence routing decision. By default, a router which receives MED attribute from neighbors, only compares it if they are coming from the same AS. As you can see in the diagram below:

• R3 send to R4 a MED of 50 for subnet 172.16.1.0/24
• R2 send to R5 a MED of 100 for subnet 172.16.1.0/24
• The lowest MED is the preferred path

In a first step, the configuration below has been applied:

R1:

interface Loopback1

ip address 172.16.1.1 255.255.255.0

router bgp 50

bgp log-neighbor-changes

network 172.16.1.0 mask 255.255.255.0

neighbor 10.1.1.2 remote-as 100

neighbor 10.1.3.3 remote-as 200

R2:

router bgp 100

bgp log-neighbor-changes

neighbor 10.1.1.1 remote-as 50

neighbor 10.1.2.3 remote-as 200

neighbor 10.1.4.4 remote-as 300

neighbor 10.1.4.4 route-map MED out

!

access-list 1 permit 172.16.1.0 0.0.0.255

!

route-map MED permit 10

match ip address 1

set metric 100

!

route-map MED permit 20

R3:

router bgp 200

bgp log-neighbor-changes

neighbor 10.1.2.2 remote-as 100

neighbor 10.1.3.1 remote-as 50

neighbor 10.1.5.4 remote-as 300

neighbor 10.1.5.4 route-map MED out

!

access-list 1 permit 172.16.1.0 0.0.0.255

!

route-map MED permit 10

match ip address 1

set metric 50

!

route-map MED permit 20

R4:

router bgp 300

bgp log-neighbor-changes

neighbor 10.1.4.2 remote-as 100

neighbor 10.1.5.3 remote-as 200

MED is seen in R4 but R4 set R2 has next-hop. R4 doesn't compare MED because information is coming from 2 different ASs. R2 is used due to the fact that he has the lowest Router-id 10.1.4.2.

R4#sho ip bgp 172.16.1.0

BGP routing table entry for 172.16.1.0/24, version 2

Paths: (2 available, best #1, table default)

  Advertised to update-groups:

     3

  Refresh Epoch 1

  100 50

    10.1.4.2 from 10.1.4.2 (10.1.4.2)

      Origin IGP, metric 100, localpref 100, valid, external, best

  Refresh Epoch 1

  200 50

    10.1.5.3 from 10.1.5.3 (10.1.5.3)

      Origin IGP, metric 50, localpref 100, valid, external

Now, we add the command 'bgp always-compare-med' on R4:

R4:

router bgp 300

bgp always-compare-med

As you can, R4 has now choosen R3 for the next-hop. MED is used:

R4#sho ip bgp 172.16.1.0

BGP routing table entry for 172.16.1.0/24, version 2

Paths: (2 available, best #1, table default)

  Advertised to update-groups:

     4

  Refresh Epoch 1

  200 50

    10.1.5.3 from 10.1.5.3 (10.1.5.3)

      Origin IGP, metric 50, localpref 100, valid, external, best

  Refresh Epoch 1

  100 50

    10.1.4.2 from 10.1.4.2 (10.1.4.2)

      Origin IGP, metric 100, localpref 100, valid, external

Enable or disable ECN (Explicit Congestion Notification) on Windows

The TCP protocol can detect network congestion with different mechanisms:

• packets loss
• timeouts
• duplicate acknowledgments 

In order to avoid this behavior on a saturated link, TCP ECN  can be enable (on by default on Windows 2012 server). TCP ECN are generated by the network in order to signal to the receiver that the network component is close to drop packets. The receiver can notify the sender to slow down the traffic rate. This mechanisms can react faster than the traditional TCP timeout or DUP ack.

You can use the following command to enable it on Windows:
C:\Windows\system32>netsh int tcp set global ecncapability=enabled
Ok.
Verify:
C:\Windows\system32>netsh int tcp show global
Querying active state...

TCP Global Parameters
----------------------------------------------
Receive-Side Scaling State          : enabled
Chimney Offload State               : automatic
NetDMA State                        : enabled
Direct Cache Acess (DCA)            : disabled
Receive Window Auto-Tuning Level    : normal
Add-On Congestion Control Provider  : none
ECN Capability                      : enabled
RFC 1323 Timestamps                 : disabled
Disable:
C:\Windows\system32>netsh int tcp set global ecncapability=disabled
Ok.

Influence routing decision with BGP Community

You can use community as a flag in order to mark a route. Upstream routers will use these flags to define routing policy. In the schema below, you can image that AS 100 is a customer site and AS 200 is a service provider. We have negotiated with the provider that:

• Traffic destined to routes with a community 100 have to pass by R3
• Traffic destined to routes with a community 200 have to pass by R2

In order to realize this, R1 marks routes with a community field, R2 and R3 modify the local_pref to follow the rules aboves.

In our case:

•  Lo1 will be 'marked' with a community 200:100 by R1
•  Lo2 will be 'marked' with a community 200:200 by R1
• Route with a community 200:100 will have a local_pref of 1000 (R3). 
• Route with a community 200:200 will have a local_pref of 500 (R2).

Configuration

R1:

interface Loopback1

 ip address 172.16.1.1 255.255.255.0

!

interface Loopback2

 ip address 172.16.2.1 255.255.255.0

!

router bgp 100

 bgp log-neighbor-changes

 network 172.16.1.0 mask 255.255.255.0

 network 172.16.2.0 mask 255.255.255.0

 neighbor 10.1.1.2 remote-as 200

 neighbor 10.1.1.2 send-community

 neighbor 10.1.1.2 route-map Peer-R2 out

 neighbor 10.1.2.3 remote-as 200

 neighbor 10.1.2.3 send-community

 neighbor 10.1.2.3 route-map Peer-R3 out

!

ip access-list standard LO1

 permit 172.16.1.0 0.0.0.255

ip access-list standard LO2

 permit 172.16.2.0 0.0.0.255

!

route-map Peer-R3 permit 10

 match ip address LO2

 set community 200:200

route-map Peer-R3 permit 15

 match ip address LO1

 set community 200:100

!

route-map Peer-R3 permit 20

!

route-map Peer-R2 permit 10

 match ip address LO1

 set community 200:100

!

route-map Peer-R2 permit 15

 match ip address LO2

 set community 200:200

!

route-map Peer-R2 permit 20

R2:

router bgp 200

 bgp log-neighbor-changes

 neighbor 10.1.1.1 remote-as 100

 neighbor 10.1.1.1 next-hop-self

 neighbor 10.1.1.1 route-map Peer-R1 in

 neighbor 20.1.1.3 remote-as 200

 neighbor 20.1.1.3 next-hop-self

 neighbor 20.1.2.4 remote-as 200

 neighbor 20.1.2.4 next-hop-self

!

ip bgp-community new-format

ip community-list 1 permit 200:200

!

route-map Peer-R1 permit 10

 match community 1

 set local-preference 500

!

route-map Peer-R1 permit 20

R3:

router bgp 200

 bgp log-neighbor-changes

 neighbor 10.1.2.1 remote-as 100

 neighbor 10.1.2.1 route-map Peer-R1 in

 neighbor 20.1.1.2 remote-as 200

 neighbor 20.1.1.2 next-hop-self

 neighbor 20.1.3.4 remote-as 200

 neighbor 20.1.3.4 next-hop-self

!

ip forward-protocol nd

!

ip bgp-community new-format

ip community-list 1 permit 200:100

!

route-map Peer-R1 permit 10

 match community 1

 set local-preference 1000

!

route-map Peer-R1 permit 20

Validation

Check that routes are flags on R2:

R2#sho ip bgp 172.16.1.0

BGP routing table entry for 172.16.1.0/24, version 6

Paths: (2 available, best #1, table default)

  Advertised to update-groups:

     2

  Refresh Epoch 1

  100

    20.1.1.3 from 20.1.1.3 (20.1.3.3)

      Origin IGP, metric 0, localpref 1000, valid, internal, best

  Refresh Epoch 1

  100

    10.1.1.1 from 10.1.1.1 (172.16.2.1)

      Origin IGP, metric 0, localpref 100, valid, external

      Community: 200:100

R2#sho ip bgp 172.16.2.0

BGP routing table entry for 172.16.2.0/24, version 3

Paths: (1 available, best #1, table default)

  Advertised to update-groups:

     3

  Refresh Epoch 1

  100

    10.1.1.1 from 10.1.1.1 (172.16.2.1)

      Origin IGP, metric 0, localpref 500, valid, external, best

      Community: 200:200

Check policies applied by R2 and R3 on R4:

R4#sho ip bgp

BGP table version is 9, local router ID is 20.1.3.4

Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,

              r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,

              x best-external, a additional-path, c RIB-compressed,

Origin codes: i - IGP, e - EGP, ? - incomplete

RPKI validation codes: V valid, I invalid, N Not found

     Network          Next Hop            Metric LocPrf Weight Path

 *>i 172.16.1.0/24    20.1.3.3                 0   1000      0 100 i

 *>i 172.16.2.0/24    20.1.2.2                 0    500      0 100 i

DMVPN - Dynamic routing tips reminder

Example - How to configure Site-to-site VPN with IOS router

• Router 1 (Left):

crypto isakmp policy 10

 encr aes 256

 authentication pre-share

 group 5

crypto isakmp key CISCO address 10.10.20.3

!

!

crypto ipsec transform-set My-Set esp-aes 192 esp-sha-hmac

!

crypto map MyMap 10 ipsec-isakmp

 set peer 10.10.20.3

 set transform-set My-Set

 match address R1_TO_R3

!

interface FastEthernet0/0

 ip address 10.10.10.1 255.255.255.0

 crypto map MyMap

!

interface FastEthernet0/1

 ip address 172.16.1.1 255.255.255.0

!

router ospf 10

 router-id 1.1.1.1

 log-adjacency-changes

 network 0.0.0.0 255.255.255.255 area 0

!

ip access-list extended R1_TO_R3

 permit ip 172.16.1.0 0.0.0.255 172.16.3.0 0.0.0.255

• Router 3 (Right):

crypto isakmp policy 10

 encr aes 256

 authentication pre-share

 group 5

crypto isakmp key CISCO address 10.10.10.1

!

!

crypto ipsec transform-set My-Set esp-aes 192 esp-sha-hmac

!

crypto map MyMap 10 ipsec-isakmp

 set peer 10.10.10.1

 set transform-set My-Set

 match address R3_TO_R1

!

interface FastEthernet0/0

 ip address 172.16.3.3 255.255.255.0

!

interface FastEthernet0/1

 ip address 10.10.20.3 255.255.255.0

 crypto map MyMap

!

router ospf 10

 router-id 3.3.3.3

 log-adjacency-changes

 network 0.0.0.0 255.255.255.255 area 0

!

ip access-list extended R3_TO_R1

 permit ip 172.16.3.0 0.0.0.255 172.16.1.0 0.0.0.255

• Validation:

Router3#show  crypto ipsec sa

interface: FastEthernet0/1

    Crypto map tag: MyMap, local addr 10.10.20.3

   protected vrf: (none)

   local  ident (addr/mask/prot/port): (172.16.3.0/255.255.255.0/0/0)

   remote ident (addr/mask/prot/port): (172.16.1.0/255.255.255.0/0/0)

   current_peer 10.10.10.1 port 500

     PERMIT, flags={origin_is_acl,}

    #pkts encaps: 3242, #pkts encrypt: 3242, #pkts digest: 3242

    #pkts decaps: 3242, #pkts decrypt: 3242, #pkts verify: 3242

    #pkts compressed: 0, #pkts decompressed: 0

Router3#show  crypto isakmp sa

IPv4 Crypto ISAKMP SA

dst             src             state          conn-id slot status

10.10.10.1      10.10.20.3      QM_IDLE           1002    0 ACTIVE

Command to see all floatings routes

With the classic 'show ip route static', the backup floating route is not seen in the display:

Router#show  ip route static
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2
       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
       ia - IS-IS inter area, * - candidate default, U - per-user static route
       o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP
       + - replicated route, % - next hop override

Gateway of last resort is 10.10.2.1 to network 0.0.0.0

S*    0.0.0.0/0 [1/0] via 10.10.2.1

In order to see both routes, active and non-active route, we have to use the command 'show ip static route'. With this command, both routes and metrics are seen:

Router#show ip static route
Codes: M - Manual static, A - AAA download, N - IP NAT, D - DHCP,
       G - GPRS, V - Crypto VPN, C - CASA, P - Channel interface proces
       B - BootP, S - Service selection gateway
       DN - Default Network, T - Tracking object
       L - TL1, E - OER, I - iEdge
       D1 - Dot1x Vlan Network, K - MWAM Route
       PP - PPP default route, MR - MRIPv6, SS - SSLVPN
       H - IPe Host, ID - IPe Domain Broadcast
       U - User GPRS, TE - MPLS Traffic-eng, LI - LIIN
       IR - ICMP Redirect
Codes in []: A - active, N - non-active, B - BFD-tracked, D - Not Track

Static local RIB for default

M  0.0.0.0/0 [1/0] via 10.10.2.1 [A]
M            [5/0] via 10.10.25.1 [N]