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.

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.

Catch 2022: Networking Ice Bucket Challenge

A sample topology

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! 🎆

Solo.io Brings ‘Docker-Like Experience’ to eBPF with BumbleBee

Service mesh integration software provider BumbleBee, a new open source project that it extended Berkeley Packet Filter (eBPF) in order to “shortcut the HTTP stack,” said Solo.io CEO and founder BPF Type Format (BTF), explained Levine, “(along with some smarts added to clang) enables the BPF program loader to fix the BPF byte code to work correctly on different versions of the kernel. For example, if a BPF program accesses a struct, clang now stores all these struct access in a special location in the BPF program binary. libbpf can go to each of these struct accesses, and use BTF information from the current kernel (obtained at runtime) to fix these accesses to the correct offset.” BumbleBee to the Rescue With the addition of BTF, Solo.io created BumbleBee, which not only uses BTF to parse and bring to the user space the maps of eBPF programs, but also uses the get started.

Getting Certificate Details from HashiCorp Vault

It seems there are lots of tutorials on setting up a PKI (public key infrastructure) using HashiCorp Vault. What I’ve found missing from most of these tutorials, however, is how to get details on certificates issued by a Vault-driven PKI after the initial creation. For example, someone other than you issued a certificate, but now you need to get the details for said certificate. How is that done? In this post, I’ll show you a couple ways to get details on certificates issued and stored in HashiCorp Vault.

For the commands and API calls I’ve shared below, I’m using “pki” as the name/path you (or someone else) assigned to a PKI secrets engine within Vault. If you’re using a different name/path, then be sure to substitute the correct name/path as appropriate.

To use the Vault CLI to see the list of certificates issued by Vault, you can use this command:

vault list pki/certs

This will return a list of the serial numbers of the certificates issued by this PKI. Looking at just serial numbers isn’t terribly helpful, though. To get more details, you first need to read the certificate details (note singular “cert” here versus plural “certs” in the previous Continue reading

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.

Read more …

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.

Read more …

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.

IP Addressing through 2021s

Time for another annual roundup from the world of IP addresses. Let's see what has changed in the past 12 months in addressing the Internet and look at how IP address allocation information can inform us of the changing nature of the network itself.

2021 IT Blog Awards finalist!

I was surprised but very honoured to learn that my blog was selected as a finalist in the IT Blog Awards. I started this blog to help with my learning during a personal research project and to contribute to the open-source networking community as best I could. I never imagined that someone else might consider it for an honour such as this!

If you have gotten value from reading this blog, please go to the IT Blog Awards voting page and vote for the “Open Source Routing and Network Simulation” blog. Thank you so much!

1 … 568 569 570 571 572 … 3,816