Today, Pluribus released Netvisor 7, which marks another major step forward in our mission to radically simplify deployment and operations for distributed cloud networking. One of the most innovative features of this release is a new suite of monitoring and visibility tools, including FlowTracker and KubeTracker fabric services.
In prior releases, Netvisor ONE OS and the Adaptive Cloud Fabric software could capture flow telemetry for TCP flows only. With the introduction of FlowTracker in R7, Pluribus now provides telemetry on every flow traversing the fabric, including TCP, UDP, ICMP and even infrastructure services flows like DCHP, DNS and more.
Amazingly, this comprehensive flow telemetry is achieved without the need for an expensive external TAP and TAP aggregation overlay infrastructure. The cost of procuring and deploying TAPS to capture packet flows for analysis can be daunting and often results in cost/benefit tradeoffs where TAPS are only installed at certain points in the network. With FlowTracker, that expense and those tradeoffs are eliminated, every flow in the fabric is captured, and flow metadata is exported to tools like our UNUM Insight Analytics platform.
The KubeTracker fabric service is a powerful new capability delivered by the Adaptive Cloud Fabric specifically for network operators Continue reading
Often programmers have assumptions that turn out, to their surprise, to be invalid. From my experience this happens a lot. Every API, technology or system can be abused beyond its limits and break in a miserable way.
It's particularly interesting when basic things used everywhere fail. Recently we've reached such a breaking point in a ubiquitous part of Linux networking: establishing a network connection using the connect()
system call.
Since we are not doing anything special, just establishing TCP and UDP connections, how could anything go wrong? Here's one example: we noticed alerts from a misbehaving server, logged in to check it out and saw:
marek@:~# ssh 127.0.0.1
ssh: connect to host 127.0.0.1 port 22: Cannot assign requested address
You can imagine the face of my colleague who saw that. SSH to localhost refuses to work, while she was already using SSH to connect to that server! On another occasion:
marek@:~# dig cloudflare.com @1.1.1.1
dig: isc_socket_bind: address in use
This time a basic DNS query failed with a weird networking error. Failing DNS is a bad sign!
In both cases the problem was Linux running out of ephemeral ports. When Continue reading
Every time I’m writing netsim-tools release notes I’m amazed at the number of features we managed to put together in just a few weeks.
Here are the goodies from netsim-tools releases 1.1.1 and 1.1.2:
Today we are launching Cloudflare’s paid public bug bounty program. We believe bug bounties are a vital part of every security team’s toolbox and have been working hard on improving and expanding our private bug bounty program over the last few years. The first iteration of our bug bounty was a pure vulnerability disclosure program without cash bounties. In 2018, we added a private bounty program and are now taking the next step to a public program.
Starting today, anyone can report vulnerabilities related to any Cloudflare product to our public bug bounty program, hosted on HackerOne’s platform.
Let's walk through our journey so far.
In 2014, when the company had fewer than 100 employees, we created a responsible disclosure policy to provide a safe place for security researchers to submit potential vulnerabilities to our security team, with some established rules of engagement. A vulnerability disclosure policy is an important first step for a company to take because it is an invitation to researchers to look at company assets without fear of repercussions, provided the researchers follow certain guidelines intended to protect everyone involved. We still stand by that policy and welcome Continue reading
In the first post on a series on privacy and networking, Russ White makes the case that privacy matters not just for infosec, risk management, or compliance, but as a human right.
The post Privacy And Networking: Part 1 – Why Privacy? appeared first on Packet Pushers.
Nprobe includes both a NetFlow v5/v9/IPFIX probe and collector. In a probe mode, nProbe captures […]
The post Nprobe Layer 7 Application Visibility and Optional Plugins first appeared on Brezular's Blog.
Listening is crucial in the design phase of a project. In this video clip, Angela Andrews joined the Day Two Cloud podcast to explain why.
The post If You Don’t Listen, Your Design Will Fail (Video) appeared first on Packet Pushers.
The Project Calico community is one of the most collaborative and supportive communities in the open-source space. Our community has shown great engagement through the years, which has helped us maintain and grow the project.
Thanks to our 200+ contributors from all over the world, Calico Open Source (the solution born out of the project) is powering 1.5M+ nodes daily across 166 countries. Our engineering team is committed to maintaining Calico Open Source as the leading standard for container and Kubernetes networking and security!
Given our community’s passion for Project Calico, we wanted to give its members a chance to inspire others by telling their stories. To this end, we are very excited to announce our new Calico Big Cats ambassador program!
Calico Big Cats is an ambassador program that provides a platform for our community to talk about their experiences with Calico. The goal is to help community members connect, inspire, and share common challenges and ways to overcome these challenges using Calico and other tools.
If you have experience with Project Calico, recognize its value in the open-source networking and security domain, and are passionate about sharing Continue reading
New networking myths are continuously popping up. Here’s a BGP one I encountered a few days ago:
You don’t need IBGP sessions between BGP route reflectors
In general, that’s clearly wrong, as illustrated by this setup:
In my previous two posts I set up a login prompt on a bluetooth serial port and then switched to running SSH on it.
I explicitly did not set up an IP network over bluetooth as I want to minimize the number of configurations (e.g. IP address) and increase the chance of it working when needed.
E.g. firewall misconfiguration or Linux’s various “clever” network managers that tend to wipe out network interface configs would have more of a shared fate with the primary access method (SSH over normal network).
This post is about how to accomplish this more properly.
The problems now being solved are:
It wasn’t entirely reliable. The rfcomm
tool is pretty buggy.
There was no authentication of the Bluetooth channel. Not as much a problem when doing SSH, but if there are passwords then there could be a man-in-the-middle attack.
The server side had to remain discoverable forever. So anyone who scans for nearby bluetooth devices would see your servers, and would be able to connect, possibly brute forcing passwords. Not as much of a problem if running SSH with password authentication turned off, but why broadcast the name of a server if you don’t Continue reading