Archive

Category Archives for "Networking"

Using AI for Attack Attribution

While I was hanging out at Cisco Live last week, I had a fun conversation with someone about the use of AI in security. We’ve seen a lot of companies jump in to add AI-enabled services to their platforms and offerings. I’m not going to spend time debating the merits of it or trying to argue for AI versus machine learning (ML). What I do want to talk about is something that I feel might be a little overlooked when it comes to using AI in security research.

Whodunnit?

After a big breach notification or a report that something has been exposed there are two separate races that start. The most visible is the one to patch the exploit and contain the damage. Figure out what’s broken and fix it so there’s no more threat of attack. The other race involves figuring out who is responsible for causing the issue.

Attribution is something that security researchers value highly in the post-mortem of an attack. If the attack is the first of its kind the researchers want to know who caused it. They want to see if the attackers are someone new on the scene that have developed new tools and Continue reading

Red Hat Launches OpenStack Platform 17.1 with Enhanced Security

VANCOUVER — At OpenStack Platform 17.1. This release is the product of the company’s ongoing commitment to support telecoms as they build their next-generation 5G network infrastructures. In addition to bridging existing 4G technologies with emerging 5G networks, the platform enables advanced use cases like Red Hat OpenShift, the company’s

Heavy Networking 685: Opengear With Zero Trust Approach in the Out of Band (sponsored)

Remote operation of infrastructure has renewed importance in the era of remote working. Opengear offers secure, zero trust and segmented methods to reach serial & LAN ports plus GUI interfaces. You can add observability agents like Thousand Eyes into containers so that your worst day becomes just another day.

The post Heavy Networking 685: Opengear With Zero Trust Approach in the Out of Band (sponsored) appeared first on Packet Pushers.

AWS customers struggle for hours after a major outage

Amazon Web Services (AWS) on Tuesday said its North Virginia (US-East-1) region faced disruption in services for nearly four hours, affecting thousands of customers.“Between 11:49 AM PDT and 3:37 PM PDT, we experienced increased error rates and latencies for multiple AWS Services in the US-EAST-1 region,” AWS wrote on its health status page, adding that at least 104 of its services were affected during the outage.AWS services that were malfunctioning during these four hours included the likes of AWS Management Console, Amazon SageMaker, AWS Glue, Amazon Connect, AWS Fargate, and Amazon GuardDuty.To read this article in full, please click here

EIGRP Stub Routers

Years ago I wrote an article describing how EIGRP stub routers work and how you should use them in redundant remote sites to make sure link- or node failures don’t result in partial connectivity. That article is now available on ipSpace.net; I hope at least someone will find it useful. I know it’s about ancient technology, but then people are still running COBOL on mainframes.

EIGRP Stub Routers

Years ago I wrote an article describing how EIGRP stub routers work and how you should use them in redundant remote sites to make sure link- or node failures don’t result in partial connectivity. That article is now available on ipSpace.net; I hope at least someone will find it useful. I know it’s about ancient technology, but then people are still running COBOL on mainframes.

Sharing, compressing and password-protecting files on Linux

Keeping your files private from anyone but those with superuser (root) access is easy on Linux. File permissions provide everything you need. By default, you'll have a username and primary group assigned to your account, and you can use the chmod (change mode) command to control what anyone else can view or change.(If permissions like "750" and "rwxr-x---" don't ring any bells for you, check out these posts for insights into how file permissions work on Linux: A deeper dive into Linux permissions and Unix: beyond group and everyone else)To read this article in full, please click here

Sharing, compressing and password-protecting files on Linux

Keeping your files private from anyone but those with superuser (root) access is easy on Linux. File permissions provide everything you need. By default, you'll have a username and primary group assigned to your account, and you can use the chmod (change mode) command to control what anyone else can view or change.(If permissions like "750" and "rwxr-x---" don't ring any bells for you, check out these posts for insights into how file permissions work on Linux: A deeper dive into Linux permissions and Unix: beyond group and everyone else)To read this article in full, please click here

How to secure the cluster in an air gap environment with Calico Cloud

The concern about securing the clusters has grown exponentially and one of the ways to secure it is by isolating the cluster from the Internet to lower the risk of eventual attack. Enterprises that deal with confidential customer data and work with regulatory agencies, such as financial and insurance institutions, require air gap environments for their clusters to create highly secure environments.

What’s an air gap?

The air gap is a security configuration in which the cluster, network, or workload will not have access to the Internet, unless it is explicitly authorized to do so. It is a highly controlled environment and prevents the cluster from establishing external connections without prior authorizations.

The diagram below shows an air gap network:

 

In a containerized environment, the cluster needs to pull the images for spinning up containers and it is usually done by pulling the images from a repository located on the cloud or Internet. However, as the air gap network doesn’t have access to the Internet, pulling images from the Internet is not possible. To address this situation, it is necessary to create a private registry/repository in the air gap network and pull all required images for the cluster into Continue reading

NVA Part V: NVA Redundancy with Azure Internal Load Balancer – On-Prem Connec

 Introduction


In Chapter Five, we deployed an internal load balancer (ILB) in the vnet-hub. It was attached to the subnet 10.0.0.0/24, where it obtained the frontend IP (FIP) 10.0.1.6. Next, we created a backend pool and associated our NVAs with it. Finally, we bound the frontend IP 10.0.1.6 to the backend pool to complete the ILB setup.


Next, in vnet-spoke1, we created a route table called rt-spoke1. This route table contained a user-defined route (UDR) for 10.2.0.0/24 (vnet-spoke2) with the next-hop set as 10.0.1.6. We attached this route table to the subnet 10.1.0.0/24. Similarly, in vnet-spoke2, we implemented a user-defined route for 10.1.0.0/24 (vnet-spoke1). By configuring these UDRs, we ensured that the spoke-to-spoke traffic would pass through the ILB and one of the NVAs on vnet-hub. Note that in this design, the Virtual Network Gateway is not required for spoke-to-spoke traffic.


In this chapter, we will add a Virtual Network Gateway (VGW) into the topology and establish an IPsec VPN connection between the on-premises network edge router and VGW. Additionally, we will deploy a new route table called "rt-gw-snet" where we add routing entries to the spoke VNets with the next-hop IP address 10.0.1.6 (ILB's frontend IP). Besides, we will add a routing entry 10.3.0.0/16 > 10.0.1.6 into the existing route tables on vnet-spoke-1 and vnet-spoke-2 (not shown in figure 6-1). This configuration will ensure that the spoke to spoke and spoke to on-prem flows are directed through one of the Network Virtual Appliances (NVAs) via ILB. The NVAs use the default route table, where the VGW propagates all the routes learned from VPN peers. However, we do not propagate routes from the default route table into the "rt-gw-snet" and "rt-prod-1" route tables. To enable the spoke VNets to use the VGW on the hub VNet, we allow it in VNet peering configurations.


  1. The administrator of the mgmt-pc opens an SSH session to vm-prod-1. The connection initiation begins with the TCP three-way handshake. The TCP SYN message is transmitted over the VPN connection to the Virtual Gateway (VGW) located on the vnet-hub. Upon receiving the message, the VGW first decrypts it and performs a routing lookup. The destination IP address, 10.1.0.4, matches the highlighted routing entry in the route table rt-gw-snet.
  2. The VGW determines the location (the IP address of the hosting server) of 10.1.0.6, encapsulates the message with tunnel headers, and forwards it to an Internal Load Balancer (ILB) using the destination IP address 10.1.0.6 in the tunnel header.
  3. The Internal Load Balancer receives the TCP SYN message. As the destination IP address in the tunnel header matches one of its frontend IPs, the ILB decapsulates the packet. It then checks which backend pool (BEP) is associated with the frontend IP (FIP) 10.0.1.6 to determine to which VMs it can forward the TCP SYN message. Using a hash algorithm (in our example, the 5-tuple), the ILB selects a VM from the backend pool members, in this case, NVA2. The ILB performs a location lookup for the IP address 10.1.0.5, encapsulates the TCP SYN message with tunnel headers, and finally sends it to NVA2.
  4. The message reaches the hosting server of NVA2, which removes the encapsulation since the destination IP in the tunnel header belongs to itself. Based on the Syn flag set in the TCP header, the packet is identified as the first packet of the flow. Since this is the initial packet of the flow, there is no flow entry programmed into the Generic Flow Table (GFT) related to this connection. The parser component generates a metadata file from the L3 and L4 headers of the message, which then is processed by the Virtual Filtering Platform (VFP) layers associated with NVA2. Following the VFP processing, the TCP SYN message is passed to NVA2, and the GFT is updated with flow information and associated actions (Allow and Encapsulation instructions). Besides, the VFP process creates a corresponding entry for the return packets into the GFT (reversed source and destination IPs and ports). Please refer to the first chapter for more detailed information on VFP processes.
  5. We do not have any pre-routing or post-routing policies configured on either NVA. As a result, NVA2 simply routes the traffic out of the eth0 interface based on its routing table. The ingress TCP SYN message has already been processed by the VFP layers, and the GFT has been updated accordingly. Consequently, the egress packet can be forwarded based on the GFT without the need for additional processing by the VFP layers.
  6. Subsequently, the encapsulated TCP SYN message is transmitted over VNet peering to vm-prod-1, located on vnet-spoke-1. Upon reaching the hosting server of vm-prod-1, the packet is processed in a similar manner as we observed with NVA. The encapsulation is removed, and the packet undergoes the same VFP processing steps as before.


Figure 6-1: ILB Example Topology.

Continue reading
1 … 211 212 213 214 215 … 3,455