Slashdot Mirror

No, we can't secure the whole internet. What we can do, however, is make highly critical segments more secure. Part of that is physical security, part of it is better monitoring infrastructure, such as fiber tap splitters off to an IDS system at a backbone peering point. vendors such as Net Optics make just such a device, among others.

It would probably make more sense to run new lines, or light up some dark fiber, and move all the government stuff onto that, then have a few border crossings, like peerage points, where "real" internet access can be controlled and monitored to prevent breach of systems which aren't already on separate networks. They might do that already, I can't really say for sure.

Although, it still doesn't keep some random employee from doing something stupid on the inside, you can at least mitigate the impact. Then maybe, just leave much of the rest of the infrastructure as-is and have fend for ourselves, or whatever.

But yeah, we can just be picky and pedantic instead of just agreeing that there's a point of "good enough" that's more secure than what we have but less secure than just not having the system in the first place, or locking it away in a concrete bunker with no power.

You could also get a network tap. I've had my eye on the Teeny Tap for a while.

Helevius

Helevius

I've tried nearly every sniffer (open-source or commercial) that has been available for the past 10 or so years.
Having the right tools for the right job is so important. Here's my list of good vs. bad in the packet capture world:

Good:
1) Running 'tcpdump -vvens0 -w file.cap' will basically give anyone anything they need, period
2) arpwatch, just to have a nice list of MAC2IP's
3) argus (already mentioned here)
4) snort (although I suggest the commercial Sourcefire instead). However, `unified logging' in snort (e.g. mudpit or barnyard), along with cerebus and logtopcap can scale snort to large-installations
5) ourmon is the best pcap visualization tool out there. it's BPF+RRDTool, so it basically rules
6) After you gzip the pcap file, scp it to your Windows/Linux desktop and run Ethereal to analyze in-depth
7) NAI SnifferPro "Expert" mode is sometimes useful instead of Ethereal. However, it's not worth the money even if you have money to burn
8) tcptrace is VERY useful to run on your saved tcpdump pcap files
9) Bro, ngrep, and dsniff are well-written, albeit somewhat security-specific
10) iftop and tcpdstat ala ddittrich's preso's

Bad:
1) SnifferPro, Network Observer, Fluke, et al
2) ntop (although their website is very cool for info on packet capture)
3) ntop look-a-likes like darkstat
4) pastmon doesn't really work yet, but looks promising
5) Cisco Netflow and SPAN ports. I highly recommend Internap FCP, argus, or Bro instead of Netflow. I also highly recommend NetOptics port aggregator taps over SPAN ports, however SPAN is better than nothing

A lot of people were confusing packet creation with packet capture. For more information on packet creation, see packetfoo [PDF]

-Lucas

There are many, and there have been many ways to utilize fiber for years. As I indicated above, a NIC is not a NIC, I have found the Tigon 3 to be most effective at keeping utilization low under load. If you think a D-Link is going to perform, you would be mistaken, I would venture to guess that in the right situation, with the right packet size, and the right amount of ingress, a more capable 100 mbit controller from 3COM or Intel would outperform a D-Link (which uses a national semiconductor ASIC I believe, that's a guess, but I wont bother to find out because I don't care about D-Link).

I also touched on ingress traffic and live lock in interrupt driven kernels. It's a real problem. Also, speed is relative to packet size (jumbo packets), interrupts coalescence and tcp checksumming offload.

I find that fiber's performance does not denigrate at all as you approach maximum limit in length. I find that Copper is sensitive to RF, and, while gigabit does not have this notion of crossover because it uses all 4 pairs, I hate the idea of crossovers at all (most GE cards now do auto MDX for 10/100).

As I also indicated, there are usually fiber uplinks on switches, as seen here. It has 48 ports, and two fiber ports. [$1300 bucks]. This is a typical use, as is suggested by the design. Clearly it is wise to use the 10/100 to connect to got to workstations, and here, we see a switch with 24 10/100/1000 ports (Cu), and uplink ports, which can be SM or MM fiber. [$2300]

I would say one would use fiber to connect switches to one another, basically deprecating "spanning" style switches, where one must get proprietary cables and whatnot. This gives the flexibility of moving switches far away, and these switches above have options for single mode which can drastically increase range, making cross-corporate-campus communications as trivial as laying the fiber down and very cheap compared to the days of old when repeaters were used.

I work with a 10/100/1000 combo copper fiber switch, and Alteon 180, and we use that to aggregate switches that span out copper to the lab of machines we use to test various things. I find fiber a joy to work with, and tapping fiber connections is far easier. The aforementioned switch would cost in and about $15,000 new, but on Ebay who knows. Clearly fiber to the desktop is not the intent of using fiber, but not using for backbones is the right choice. Flexible transceivers, cables which are priced right when you want to go far distances, and it isn't subject to RF noise, and is easy to tap - and cheap. The taps for tapping single or multimode fiber [70/30 split] are about $600. The taps for gigabit copper are way over that price (this just came out - its neat, and cutting edge, but according to hearsay not at all easy to do because of the 4 channel system GigE Cu uses).

So fiber switches are expensive. But they are good, the can aggregate lots of things from far away, and they are generally newer, always managed. The cheapest 100% fiber switches are in the $4000 range, usually starting at 8 ports.

So is fiber for gamers? No. Is fiber a cheap way to hook up your client machines or low bandwidth servers? No. Is it useful to span switches distances near and far, and to allow certain high volume servers excellent access to bandwidth, and be tappable easily and cheaply, yes! I have been very pleased with both the original AceNIC and the Tigon 3 controllers, and the Alteon switches.

Fiber is essentially a distance giver, and most of the NIC I pointed out in my original post have the same ASIC for both the GigE Cu and the Fiber rendition of the card, but I have found that fiber is more reliable, easier to push to the theoretical maximum speeds for a given packet size. I would probably buy going forward Cu 10/100/1000 switches, and span them with fiber uplinks and aggregate them into a fiber switch and give critical routers and servers access to that aggregate switch.

Another thing to pay attention to when buying switches, is the switching fabric. A lot of cheaper switches out there cant handle every single port going full duplex and 1000 mbit. This is where the fabric becomes the theoretical limiter. Be careful of garbage brands, stick to Intel, 3Com, Sun, Cisco, Extreme, Juniper, Foundry and beefy vendors. Intel and 3COM may be seen as cheesy and cheap to hang with the more scaleable vendors, but they build decent stuff for basic use.

There are many, and there have been many ways to utilize fiber for years. As I indicated above, a NIC is not a NIC, I have found the Tigon 3 to be most effective at keeping utilization low under load. If you think a D-Link is going to perform, you would be mistaken, I would venture to guess that in the right situation, with the right packet size, and the right amount of ingress, a more capable 100 mbit controller from 3COM or Intel would outperform a D-Link (which uses a national semiconductor ASIC I believe, that's a guess, but I wont bother to find out because I don't care about D-Link).

I also touched on ingress traffic and live lock in interrupt driven kernels. It's a real problem. Also, speed is relative to packet size (jumbo packets), interrupts coalescence and tcp checksumming offload.

I find that fiber's performance does not denigrate at all as you approach maximum limit in length. I find that Copper is sensitive to RF, and, while gigabit does not have this notion of crossover because it uses all 4 pairs, I hate the idea of crossovers at all (most GE cards now do auto MDX for 10/100).

As I also indicated, there are usually fiber uplinks on switches, as seen here. It has 48 ports, and two fiber ports. [$1300 bucks]. This is a typical use, as is suggested by the design. Clearly it is wise to use the 10/100 to connect to got to workstations, and here, we see a switch with 24 10/100/1000 ports (Cu), and uplink ports, which can be SM or MM fiber. [$2300]

I would say one would use fiber to connect switches to one another, basically deprecating "spanning" style switches, where one must get proprietary cables and whatnot. This gives the flexibility of moving switches far away, and these switches above have options for single mode which can drastically increase range, making cross-corporate-campus communications as trivial as laying the fiber down and very cheap compared to the days of old when repeaters were used.

I work with a 10/100/1000 combo copper fiber switch, and Alteon 180, and we use that to aggregate switches that span out copper to the lab of machines we use to test various things. I find fiber a joy to work with, and tapping fiber connections is far easier. The aforementioned switch would cost in and about $15,000 new, but on Ebay who knows. Clearly fiber to the desktop is not the intent of using fiber, but not using for backbones is the right choice. Flexible transceivers, cables which are priced right when you want to go far distances, and it isn't subject to RF noise, and is easy to tap - and cheap. The taps for tapping single or multimode fiber [70/30 split] are about $600. The taps for gigabit copper are way over that price (this just came out - its neat, and cutting edge, but according to hearsay not at all easy to do because of the 4 channel system GigE Cu uses).

So fiber switches are expensive. But they are good, the can aggregate lots of things from far away, and they are generally newer, always managed. The cheapest 100% fiber switches are in the $4000 range, usually starting at 8 ports.

So is fiber for gamers? No. Is fiber a cheap way to hook up your client machines or low bandwidth servers? No. Is it useful to span switches distances near and far, and to allow certain high volume servers excellent access to bandwidth, and be tappable easily and cheaply, yes! I have been very pleased with both the original AceNIC and the Tigon 3 controllers, and the Alteon switches.

Fiber is essentially a distance giver, and most of the NIC I pointed out in my original post have the same ASIC for both the GigE Cu and the Fiber rendition of the card, but I have found that fiber is more reliable, easier to push to the theoretical maximum speeds for a given packet size. I would probably buy going forward Cu 10/100/1000 switches, and span them with fiber uplinks and aggregate them into a fiber switch and give critical routers and servers access to that aggregate switch.

Another thing to pay attention to when buying switches, is the switching fabric. A lot of cheaper switches out there cant handle every single port going full duplex and 1000 mbit. This is where the fabric becomes the theoretical limiter. Be careful of garbage brands, stick to Intel, 3Com, Sun, Cisco, Extreme, Juniper, Foundry and beefy vendors. Intel and 3COM may be seen as cheesy and cheap to hang with the more scaleable vendors, but they build decent stuff for basic use.