David Piniella

Good ol’ MACSec.

First, I posted a quick and dirty notes-for-myself, MACSec how-to for Juniper.

Then, I posted a similar MACSec howto for Cisco. So here’s a miscellany of different macsec implementations.

Let’s say you want to run your own router, because your Layer 8 & 9 specialists mandate it, here MACSec on linux.

Here’s a guy who did cisco-switch-to-cisco-switch macsec over an mpls link between a cisco and juniper router (because macsec works at layer 1 and thus you need to fake layer 1 via MLPS). So that’s a thing.

Here’s the Extreme Network’s MACSec implementation:

set macsec port mka enable tg.1.1
set macsec pre-shared-key port tg.1.1 ckn foo cak passphrase bar

HP switches macsec config

Brocade MACSec details and also a Brocade sample config of MACSec.

from the “when your only tool is a hammer, everything looks like a nail” files, comes this amusing tidbit: http://www.shellntel.com/blog/2016/6/7/weaponizing-nessus

Cloudflare on how they’re mitigating reflection attacks. The tl;dr: optimized crypto (elliptic curve instead of RSA) for signing DNSSEC, refusing the ANY request and keeping responses with the constraints of a 512-byte UDP packet to mitigate amplification.

Detecting DNS Tunnelling via PacketBeat and Watcher and Elasticsearch

RandomDNS for randomizing use of DNSCrypt

This is pretty great: https://github.com/sleuthkit/hadoop_framework/wiki

tl;dr for the impatient: sleuthkit forensic analysis foisted onto a hadoop framework for faster processing of large amounts of data

I haven’t had to use sleuthkit/autopsy in a few years but this is a nice bit of amalgamation.

A while back I did notes for MACSec on Juniper devices and here’s the Cisco equivalent of the 802.1AE (“MAC Sec”) implementation

1. Your Cisco device needs to be running either an IP Base or IP Services image. MACSec is not happening otherwise.
2. switch# cts credentials id trustsec password mypassword
3. en then, conf t, then int Gig1/1 (or whatever)
4. switch(config-if)# cts man
   % Enabling macsec on Gi1/1 (may take a few seconds)…
   switch(config-if-cts-manual)#no propagate sgt
   switch(config-if-cts-manual)#sap pmk abc123 mode-list gcm-encrypt
   switch(config-if-cts-manual)#no shut

Where abc123 is your shared secret. I believe this is analogous to Juniper’s cak. You can do this to aggregated links (“port-channel” for you Cisco folks) but you have to do it before you aggregate the trunks together into a single logical interface. E.g., do this on Gig1/1 and Gig1/2 and then create int Port-channel1 (channel-group 1 mode on in the interface config)

Notes:

mode-list options are:

• gcm-encrypt (authentication and encryption)
• gmac (auth, no encrypt)
• null (encapsulation only; no auth, no encryption)

Gotchas:

• to use 802.1x (cts dot1x) as opposed to cts man above, you have to enable 802.1x globally on each device.
• if you select gcm as the sap mode, you need an additional macsec license from cisco (as well as the ipbase or ipservices image/license). if you select gcm without the license, the interface goes into link-down state.

Debugging:

show cts credentials

show macsec summary

show macsec interface

show authentication sessions interface gigabitethernet1/1

Additional reading:

The actual Cisco doc (this is for a cat4500 but translates well most places) http://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst4500/15-1/XE_330SG/configuration/guide/config/swmacsec.html (here’s one for 3750/3560)

http://www.petenetlive.com/KB/Article/0001000.htm

http://www.virtualpackets.com/cisco-trustsec-switch-to-switch-link-security-manual-mode/

via http://topchicksdigengineeringguys.blogspot.com/2015/03/the-inconvenient-message-detection-imd.html

Steganography that requires computing effort. Steganography is the idea of hiding data in the unimportant bits of an image. This is an old idea. The new twist is that with ‘Inconvenient Message Detection’ (IMD) that data can only be found if the decoder does an amount of computational work that’s decided by the encoder.

Let’s look at how this solved our problem: If some people use IMD, it makes every image suspect. When a mass-observer wants to see what communication is going on, they must use compute power to check every image. Furthermore, because the compute effort needed to find an image is set by the encoder, it is uncertain to the mass-observer; they never knows for certain if they’ve worked hard enough. By contrast, the intended recipient of a message presumably got the single datum that a message exists in some public image and will put in as much compute effort as is needed to find the data in that single image. Having every image on the internet be a potential carrier of secrets makes the mass observation of communication meta-data expensive and uncertain.

Furthermore, even a individual under direct observation can increase their protection with IMD. An individual may own thousands of images of which only one contains an secret. Until the secret is found by an observer, the individual has plausible denyability of the secret’s existence. The observer may even give up before spending the necessary compute effort to find it. This increases their resistance to coercion.

The Chinese government is not only being deceitful with IP addresses, they’ve also begun cracking down on a mechanism that lets its citizens avoid the bullshit: VPN. Grass Mud Horse!

This action, combined with the DDoS floods, is beneficial to a government that’s intent on isolating its citizens from the free and open Internet. They make it hard to get a packet out of China, but even if you succeed, it’s likely to be blocked by a server that’s been victim of their DDoS.

On the surface, this seems like a good strategy for creating your own private Internet: a network where no packets can enter the west or leave the east.

via furbo.org · Grass Mud Horse.

I’ve been seeing a lot of probes in my logs — mostly search engines, but a fair bit that wasn’t — from China. And here you go.

The old joke goes: I don’t make mistakes. I thought I did once, but I was wrong.

But here’s how to save yourself from mistakes when configuring a JunOS or IOS device:

JUNOS is easy, “commit check”, “commit confirmed” and the handy “rollback”. Frankly, if you’re on a JUNOS device, you should already know about these.

But how to do the same on IOS? Cisco’s configurations happen as soon as you hit enter on the config, right?

Here’s how:

• The brute force method: “reload in 5”. Write your proposed changes in notepad++ (or notepad.exe if you insist). Login to the device that you’re going to change, and before you do any of your changes, run “reload in 5”. Then, make your changes. If you did something boneheaded that will disable the device or your connection to it, the device will reload from it’s start-config in 5 minutes, effectively erasing your running-config.

Of course, if this is a shared device, you’ve taken everyone offline for the time it takes the device to reboot. Or maybe you don’t want your config saved to start-config as a security measure*. So what do you do in order to prevent a reboot and still maintain the ability to revert a recently made change? Ah, you’ll be wanting the somewhat more sophisticated method 2:

• First, turn on archive:

cisco-router#configure terminal
cisco-router(config)#archive

then configure a path for where it’ll be stored and save that:

cisco-router(config-archive)#path usbflash0:backup-config
cisco-router(config-archive)#end
cisco-router#write mem

Now you should be able to use “configure terminal revert time 5” which is IOS’ functional equivalent of JUNOS’ “commit confirmed 5”:

cisco-router#conf t revert time 5

Here it will tell you that your config is being backed up to where you told it to and that the config will be rolled back in 5 minutes. So make your changes:

cisco-router(config)#int gig 0/0

cisco-router(config-if)# shutdown

If everything is good, “configure confirm” to keep the change:

cisco-router(config-if)#configure confirm

For the truly worried, use both methods: “reload in 10” and “revert in 5”. If the revert doesn’t work, the reload will (this will still take down the router, but hey…)

The full capture of voice traffic began in February of 2011 for “Skype in” and “Skype out” calls—calls between a Skype user and a land line or cellphone through a gateway to the public switched telephone network (PSTN), captured through warranted taps into Microsoft’s gateways. But in July of 2011, the NSA added the capability of capturing peer-to-peer Skype communications—meaning that the NSA gained the ability to capture peer-to-peer traffic and decrypt it using keys provided by Microsoft through the PRISM warrant request.

via Newly published NSA documents show agency could grab all Skype traffic | Ars Technica.

An Unprecedented Look at Stuxnet, the World’s First Digital Weapon | WIRED.