Dutch athletes warned to keep phones and laptops out of China | Reuters
Cybersecurity in sport
Want To Create Content? Consider The Packet Pushers’ Community Blog And Newsletter
If you’ve got “Create Content” as a 2022 goal but aren’t sure how to start, consider the Packet Pushers’ Community blog or our Human Infrastructure newsletter. We welcome articles from folks in networking and IT who have ideas to share or the inclination to write, but don’t have the interest in setting up their own […]
The post Want To Create Content? Consider The Packet Pushers’ Community Blog And Newsletter appeared first on Packet Pushers.
6 East-West Security Myths Busted
With the world at our fingertips via a simple Google search, it can sometimes be tough to figure out what’s fact and what’s fiction. Whether you’re an expert, novice, or beginner in the tech world, time should be spent putting capabilities and terms into action – rather than trying to piece them together and understand them like a Sudoku puzzle. That’s why we’re going to debunk six major East-West security myths for you – so you can get back to the good stuff.
1. East-West security is the monitoring and inspection of traffic moving medially within the network perimeter, working to identify and block threats and enable access rights.
Busted. East-West security does all of the fancy stuff mentioned, with one very important difference: it moves laterally through the network perimeter. This is a key understanding, since East-West security operates on the premise that threat factors will eventually find a way through next-generation firewalls – which means all internal network traffic is vulnerable.
2. A traditional firewall that manages North-South traffic can handle a modern network breach by itself.
Busted. While it’s important to have North-South security in place (filtering the traffic that is exiting and entering the network), it cannot protect the network on its own Continue reading
Day Two Cloud 129: Practical Advice On Optimizing Cloud Costs
Optimizing cloud costs means more than looking at your bill and hunting down unused instances. It's about understanding the full lifecycle of cloud workloads, dealing with management that wants predictable spending even as your actual usage varies, and setting up repeatable processes. Guests Fred Chagnon and Jeremy Roberts, both at Info-Tech Research Group, offer practical advice for optimizing your cloud spending.
The post Day Two Cloud 129: Practical Advice On Optimizing Cloud Costs appeared first on Packet Pushers.
Day Two Cloud 129: Practical Advice On Optimizing Cloud Costs
Optimizing cloud costs means more than looking at your bill and hunting down unused instances. It's about understanding the full lifecycle of cloud workloads, dealing with management that wants predictable spending even as your actual usage varies, and setting up repeatable processes. Guests Fred Chagnon and Jeremy Roberts, both at Info-Tech Research Group, offer practical advice for optimizing your cloud spending.Catch 2022: Networking Ice Bucket Challenge
At the start of this exciting new year of 2022, I figured this might be a good time to introduce a new challenge:
Using Netsim-Tools, build the most complicated virtual network topology that still allows host A to ping host B
Anything goes — and if you have to extend the tooling to make things work, even better. Varying latency and occasional packet loss are acceptable, but there needs to be at least 1 ping reply being delivered to A.
For example, how about multi-vendor EVPN-VXLAN over SRv6 with MACsec encryption and Traffic Engineering?
Happy 2022 networking everyone! 🎆
Feedback: Recursive BGP Next Hop Resolution
The Recursive BGP Next Hops: an RFC 4271 Quirk blog post generated tons of feedback (thanks a million to everyone writing a comment on my blog or LinkedIn).
Starting with Robert Razsuk who managed to track down the original email that triggered the (maybe dubious) text in RFC 4271:
The text in section 5.1.3 was not really targeting to prohibit load balancing. Keep in mind that it is FIB layer which constructs actual forwarding paths.
The text has been suggested by Tom Petch in discussion about BGP advertising valid paths or even paths it actually installs in the RIB/FIB. The entire section 5.1.3 is about rules when advertising paths by BGP.
Feedback: Recursive BGP Next Hop Resolution
The Recursive BGP Next Hops: an RFC 4271 Quirk blog post generated tons of feedback (thanks a million to everyone writing a comment on my blog or LinkedIn).
Starting with Robert Razsuk who managed to track down the original email that triggered the (maybe dubious) text in RFC 4271:
The text in section 5.1.3 was not really targeting to prohibit load balancing. Keep in mind that it is FIB layer which constructs actual forwarding paths.
The text has been suggested by Tom Petch in discussion about BGP advertising valid paths or even paths it actually installs in the RIB/FIB. The entire section 5.1.3 is about rules when advertising paths by BGP.
Cisco SDA and Security Part IV – micro-segmentation in SDA continued (some more)
In this post, we will look at how to leverage SXP tunnels in ISE to achieve a specific use case.
Cisco SDA and Security Part III – micro-segmentation in SDA continued
In this post, we look at how SGACLs are pushed to NADs, with clear packet captures and packet walks. We also see how SGTs are added to the VXLAN header.
Cisco SDA and Security Part II – micro-segmentation in SDA
In this post, we look at microsegmentation in Cisco’s SD-Access fabric, using SGTs.
Cisco SDA and Security Part I – macro segmentation in SDA
In this post, we will look at macro segmentation in Cisco’s SD-Access.
I Can Hardly Contain(erize) Myself!
Happy New Year! Last year I wrote a series of blogs under the “Infrastructure as Software” banner exploring how to build a Django three-tiered application from pyATS that parsed network state data. Now that I’ve built a working Django application locally the challenge is to make it available to others. README After I had built […]
The post I Can Hardly Contain(erize) Myself! appeared first on Packet Pushers.
Why cloud native requires a holistic approach to security and observability
Like any great technology, the interest in and adoption of Kubernetes (an excellent way to orchestrate your workloads, by the way) took off as cloud native and containerization grew in popularity. With that came a lot of confusion. Everyone was using Kubernetes to move their workloads, but as they went through their journey to deployment, they weren’t thinking about security until they got to production. While this might seem like the intuitive thing to do, it doesn’t work in Kubernetes.
With Kubernetes, you can’t wait until the end when you’re ready to move workloads to production; you need to think about security early on. If security is not thought through in a system like Kubernetes, workloads are left vulnerable and you will not end up with a solution that is effective.
Why is this? What makes cloud native so different? Let’s take a look at some of the differences to understand why they warrant a more holistic approach to security and observability for cloud-native applications, whether in Kubernetes or another environment.
Cloud native: Origins, key differences, and challenges
What we’re used to (if we remove cloud native from the equation) is having a client-server architecture, where servers are running Continue reading
Aws Advanced Networking — Enhanced Networking — 3— Intel 82599 VF
The first two posts covered SRIOV/ ENA settings and use-cases, the next one in the series is about using Intel 82599 Virtual Functions adapter.
Post 1: https://r2079.wordpress.com/2021/12/28/enhanced-networking-1-sriov-aws/
Post 2: https://r2079.wordpress.com/2022/01/08/enhanced-networking-2-verifying-ena/
https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/sriov-networking.html
Instance Types: Select from the following supported instance types: C3, C4, D2, I2, M4 (excluding m4.16xlarge), and R3.
How can we verify:
At instance Level:
aws ec2 describe-instance-attribute --instance-id i-xx --attribute sriovNetSupport
[cloudshell-user@ip-10-0-119-152 ~]$ aws ec2 describe-instance-attribute --instance-id i-xx --attribute sriovNetSupport
{
"InstanceId": "i-xx",
"SriovNetSupport": {
"Value": "simple" -> Simple indicates its enabled, if not enabled its empty
}
}At an AMI Level
aws ec2 describe-images --image-id ami-07d8796a2b0f8d29c --query "Images[].EnaSupport"
[cloudshell-user@ip-10-0-119-152 ~]$ aws ec2 describe-images --image-id ami-07d8796a2b0f8d29c --query "Images[].SriovNetSupport"
[
"simple"
]At an Interface Level
ubuntu@ip-172-31-25-23:~$ ethtool -i ens3
driver: ixgbevf
version: 4.1.0-k
firmware-version:
expansion-rom-version:
bus-info: 0000:00:03.0
supports-statistics: yes
supports-test: yes
supports-eeprom-access: no
supports-register-dump: yes
supports-priv-flags: yes
ubuntu@ip-172-31-25-23:~$Latest Ubuntu HVM and Amazon Linux AMI have drivers for Enhanced Networking, IXGBEVF module and required modules for sriovNetSupport.
There is also the best practices Github guide for ENA Linux best practices and operating system optimisation.
https://github.com/amzn/amzn-drivers/blob/master/kernel/linux/ena/ENA_Linux_Best_Practices.rst
Heavy Networking 612: Cloud-Native Kubernetes Networking For CSPs (Sponsored)
Heavy Networking explores big ideas around service provider and cloud provider network services in 2022, both how they collide and are complementary. Our sponsor is Juniper Networks. We also get an update on Juniper’s Contrail product, a software-defined networking platform that now includes native integration with Kubernetes.
The post Heavy Networking 612: Cloud-Native Kubernetes Networking For CSPs (Sponsored) appeared first on Packet Pushers.