I love the recent Internet of Trash article by Geoff Huston, in particular this bit:

“Move fast and break things” is not a tenable paradigm for this industry today, if it ever was. In the light of our experience with the outcomes of an industry that became fixated on pumping out minimally viable product, it’s a paradigm that heads towards what we would conventionally label as criminal negligence.

Of course it’s not just the Internet-of-Trash. Whole IT is filled with examples of startups and “venerable” companies doing the same thing and boasting about their disruptiveness. Now go and read the whole article ;)

Decades ago I understood the intricacies of AAA on Cisco IOS. These days I wing it and keep throwing spaghetti at the virtual wall until something sticks and I can log in (after all, it’s all in a lab, and I’m interested in routing protocols not interactions with TACACS+ server).

If you’re experiencing similar challenges you might appreciate AAA Deep Dive on Cisco Devices by the one and only Daniel Dib.

It’s amazing how quickly you can deploy new functionality once you have a solid foundation in place. In his latest blog post Adrian Giacometti described how he implemented a security solution that allows network operators to block source IP addresses (identified by security tools) across dozens of firewalls using a bot listening to a Slack channel.

Would you be surprised if I told you we covered similar topics in our automation course? 😇

This is a guest blog post by Matthias Luft, Principal Platform Security Engineer @ Salesforce, and a regular ipSpace.net guest speaker.

A couple of months ago I had the pleasure to publish my first guest post here and, as to be expected from ipspace.net, it triggered some great discussion.

With this input and some open thoughts from the last post, I want to dive into a few more topics.

Dealing with protocols that embed network-layer addresses into application-layer messages (like FTP or SIP) is great fun, more so if the said protocol traverses a NAT device that has to find the IP addresses embedded in application messages while translating the addresses in IP headers. For whatever reason, the content rewriting functionality is called application-level gateway (ALG).

Even when we’re faced with a monstrosity like FTP or SIP that should have been killed with napalm a microsecond after it was created, there’s a proper way of doing things and a fast way of doing things. You could implement a protocol-level proxy that would intercept control-plane sessions… or you could implement a hack that tries to snoop TCP payload without tracking TCP session state.

Not surprisingly, the fast way of doing things usually results in a wonderful attack surface, more so if the attacker is smart enough to construct HTTP requests that look like SIP messages. Enjoy ;)

One of my readers is designing a layer-2-only data center fabric (no SVI interfaces on switches) with stringent security requirements using Cisco Nexus switches, and he wondered whether a host connected to such a fabric could attack a switch, and whether it would be possible to reach the management network in that way.

Do you think it’s possible to reach the MANAGEMENT PLANE from the DATA PLANE? Is it valid to think that there is a potential attack vector that someone can compromise to source traffic from the front of the device (ASIC) through the PCI bus across the CPU to the across the PCI bus to the Platform Controller Hub through the I/O card to spew out the Management Port onto that out-of-band network?

My initial answer was “of course there’s always a conduit from the switching ASIC to the CPU, how would you handle STP/CDP/LLDP otherwise”. I also asked Lukas Krattiger for more details; here’s what he sent me:

Post-quantum cryptography (algorithms resistant to quantum computer attacks) is quickly turning into another steaming pile of hype vigorously explored by various security vendors.

Christoph Jaggi made it his task to debunk at least some of the worst hype, collected information from people implementing real-life solutions in this domain, and wrote an excellent overview article explaining the potential threats, solutions, and current state-of-the art.

You (RFC 6919) OUGHT TO read his article before facing the first vendor presentation on the topic.

Peter Welcher identified the biggest network security hurdle faced by most enterprise IT environments in his comment to Considerations for Host-based Firewalls (Part 1) blog post:

I have NEVER found a customer application team that can tell me all the servers they are using, their IP addresses, let alone the ports they use.

His proposed solution: use software like Tetration (or any other flow collecting tool) to figure out what’s really going on:

One of the readers of the Considerations for Host-Based Firewalls blog post wrote this interesting comment:

Perhaps a paradigm shift is due for firewalls in general? I’m thinking quickly here but wondering if we perhaps just had a protocol by which a host could request upstream firewall(s) to open access inbound on their behalf dynamically, the hosts themselves would then automatically inform the security device what ports they need/want opened upstream.

Well, we have at least two protocols that could fit the bill: Universal Plug and Play and Port Control Protocol (RFC 6887).

This is a guest blog post by Matthias Luft, Principal Platform Security Engineer @ Salesforce, and a regular ipSpace.net guest speaker.

Having spent my career in various roles in IT security, Ivan and I always bounced thoughts on the overlap between networking and security (and, more recently, Cloud/Container) around. One of the hot challenges on that boundary that regularly comes up in network/security discussions is the topic of this blog post: microsegmentation and host-based firewalls (HBFs).

Robert Graham wrote a great article explaining why CEOs don’t care much about cybersecurity or any other non-core infrastructure (including networking, unless you happen to be working for a service provider). It’s a must-read if you want to understand the **** you have to deal with in enterprise environments.

Every now and then a security researcher “discovers” a tunneling protocol designed to be used over a protected transport core and “declares it vulnerable” assuming the attacker can connect to that transport network… even though the protocol was purposefully designed that way, and everyone with a bit of clue knew the whole story years ago (and/or it’s even documented in the RFC).

It was MPLS decades ago, then VXLAN a few years ago, and now someone “found” a “high-impact vulnerability” in GPRS Tunnel Protocol. Recommended countermeasures: whitelist-based IP filtering. Yeah, it’s amazing what a wonderful new tool they found.

Unfortunately (for the rest of us), common sense never generated headlines on Hacker News (or anywhere else).

Brian Krebs wrote an interesting analysis of CIA’s Wikileaks report. In a nutshell, they were a victim of “move fast to get the mission done” shadow IT.

It could have been worse. Someone with a credit card could have started deploying stuff in AWS ;))

Not that anyone would learn anything from the PR nightmare that followed.

On May 14th 2020, Marcel Gamma, tech industry journalist, and editor-in-chief at inside-it.ch and inside-channels.ch, published an article discussing several glaring security vulnerabilities in Silver Peak’s SD-WAN products on inside-it.ch. The original article was written in German; Marcel was kind enough to translate it into English and get permission from his publisher to have the English version published on ipSpace.net.

Security researchers make serious accusations against SD-Wan manufacturer Silver Peak. The latter disagrees. Swiss experts are analyzing the case.

By Marcel Gamma,

Silver Peak is accused of laxity in dealing with security issues and in dealing with security researchers who act within the framework of Responsible Disclosure.

It’s amazing how many people still believe in Security Fairy (the mythical entity that makes your application magically secure), fueling the whole industry of security researchers who happily create excruciatingly detailed talks of how you can use whatever security oversight to wreak havoc (even when the limitations of a technology are clearly spelled out in an RFC).

In the Networks Are Not Secure (part of How Networks Really Work webinar) I described why we should never rely on network infrastructure to provide security, but have to implement it higher up in the application stack.