I’ve just posted a piece on subnetting over on my study page. As with all my study pieces it’s first and foremost a reference for myself when I drop packets and can’t remember how to do something (in this case subnetting), but I also try and make the write-ups useful to others.

Let me know what you guys think.

[ Understanding Subnetting | dmiessler.com/study ]

I’ve been obsessed with an idea for a while now of a networking and security tool that captures network data once and makes that data available to any kind of tool that asks for it. It’s not my idea; an buddy of mine named Eric, who I’ve since lost touch with, told me about it over lunch at Maggiano’s many years ago. I’ve been thinking about it ever since.

Anyway, Richard Bejtlich just put up an interesting post about something similar. One of his readers asked him whether he’d thought of a single capture box that runs multiple applications. This is not the same as , but the idea is the same: capture the data once, re-use it many times.

But the way I see this playing out is more like an interface to the data running on a single box, which is accessed from many separate tools, rather than multiple applications running on the capture box itself. Storage is getting cheaper all the time, as are computing resources, so the idea here for these boxes would be to:

1. Capture ALL traffic for a given segment (full packet captures).
2. Store it for as long as needed.
3. Present an open, agnostic interface to the data, including real-time and/or historic views.

Richard actually mentioned a couple of options that I’m not familiar with, Solara Networks and Endace Ninja. I’ll have to check into them.

Another interesting idea that was brought up was the power of taps. The problem there is that it’s only real-time and the storage bit would still fall onto multiple systems. It just seems so wasteful to have multiple network and security tools all over the network creating their own copies of packet data. Especially when they’re often stored in a proprietary format.

Imagine (John Lennon style) if they all spoke a single data retrieval protocol where you could ask a common interface for raw, untainted packet data — but at a particular level. So one security product could just ask for port data via one type of query, and another one could ask for flow data, and another could be pulling a full replay of all layers. The cool part would be that the output of the query would be a filtered data stream that was uniquely useful to the requesting application.

So if FooSecurityApp just needed flow data it could build a query to the Network Data Interface (NDI?) that only returned flow data, and in a clean, universal (compressed?) format. The idea being that it would save tons of bandwidth by giving you just what you needed.

And if a security tool decided it needed to see byte 13 of the TCP header on everything leaving the network from one machine, last Thursday between 1400 and 1430, it could build a query to get just that (and any requisite context, of course). Very little data would come back relative to pulling everything and filtering at the requesting app.

Anyway, that’s taking it to an extreme but it seems like an interesting idea, if nothing else.

Thoughts?

Just for reference…

Source port(s):

Switch# config t
Switch(config)# monitor session 1 source interface fastethernet 0/1
Switch(config)# monitor session 1 source interface fastethernet 0/2
Switch(config)# monitor session 1 source interface fastethernet 0/3
Switch(config)# monitor session 1 source interface fastethernet 0/4
(however many you want to monitor)

Destination port:

Switch(config)# monitor session 1 destination interface fastethernet 0/24

…then exit and:

Switch# show monitor session 1

It’ll show you what all ports are being monitored (sources) and what port to sniff on (destination). Fin.:

It’s like Hot or Not, but for network diagrams.

[ Link: Rate My Network Diagram ]

Uh, yeah…this is sick bandwidth. Here in my apartment, no less.

I just finished a micro-tutorial on getting networking up in Linux (using a static IP) from the command line.

[ Link: How To Configure A Static IP In Linux From The Command Line ]

Why would I say this when their offerings thus far have been somewhat lackluster? Easy, they have the room to stumble. As long as they hold onto their infrastructure dominance they’ll remain in the ultimate postion as far as security goes.

Ultimately, security is going to take place at dozens and hundreds of places in a corporate environment at the same time. The entity that controls the most of those is going to have the most potential for domaince. That entity, right now and for the forseeable future, is Cisco.

Many who are new to networking and security wonder what it means to have “ports” open on your computer. Some get rather anxious when an online port scan reveals that something’s open on their system. What follows is a silly, but hopefully memorable way for beginners to remember how nework ports work.

Houses, Windows, and Midgets

Imagine a house with many, many windows. And imagine that all these windows are spring-loaded so they slam shut when they aren’t being actively held open. Also within the house are a number of midgets. Each one is able to talk to people outside the house temporarily, but only through an open window.

Well, ports on a computer — just like spring-loaded windows — are also closed by default. They don’t just stay open on their own. The second someone stops holding one open, it slams shut. So when you do find one that is open, your mission is to find out what little midget program is holding it that way.

Don’t worry about the port. It can’t stay open by itself. Instead, focus on the midget.

For that task you can use a program from Foundstone called Fport. It’ll give you the name of the midget program so you can find him and tell him to get the hell out of your window. Once he’s gone, i.e. you’ve shut down the program, the port will be closed again.:

I’ve just added a brief ICMP primer to my /study area.

> An ICMP Primer 

Last Friday I went to my first 2600 meeting. It was, of course, here in New York City — home of the original meetings. The group started small and grew to around 40, which the regulars said was a weak showing.

We pushed through the awkwardness (which wasn’t helped by our being dressed in business attire) and were able to mingle pretty easily. I got to speak with one guy who was something of a regular/leader on a range of topics, most noteworthy of which was a brief discussion of assassins-mace weapons.

The main conversation I had was with a very cool guy who does graphic design and has a background in programming. We discussed all kinds of stuff, including how we both hated those who write HTML but don’t take the time to learn how to do so correctly.

Meetings end in the final group going downtown for dinner, which we did. There it was a bit more difficult to blend in because the group was just a bunch of friends. It was pretty clear to me that they were going to raz us when we left because of how we dressed, but I think they might have a few good things to say as well.

Overall it was a really good experience. I intend to go back for the December meeting.