VLAN tag problem with OpenBSD tcpdump

Looks like the tcpdump/libpcap provided with OpenBSD has a problem with VLAN tagged traffic. The fix is to download both from tcpdump and compile fresh.

Note: usually you WANT to use the OpenBSD provided packages and ports, because someone more knowledgible than you tweaked them to work. Not in this case, though.

http://www.vorant.com/nsmwiki/index.php?title=OS_Anomalies

From #snort-gui:

(05:58:12) jontow: uh.. excellent? openbsd 4.0's tcpdump doesn't support vlan tags?
(05:58:33) jontow: ^:root@volvere:/nsm/manual-pcap# tcpdump -n -v -i xl1 vlan
(05:58:33) jontow: tcpdump: WARNING: xl1: no IPv4 address assigned
(05:58:33) jontow: tcpdump: syntax error
(06:15:07) jontow: yeah, what the shit.. if i compile it from source, too, from tcpdump.org the vlan filter still doesn't work
(06:15:08) jontow: grrr
(06:15:49) jontow: this sensor is useless without it
(06:16:03) jontow: stupid span port on these foundry switches send all packets still-tagged
(06:16:30) jontow: maybe they compiled pcap without vlan support.. :/
(06:34:47) rwatson: jontow: "doesn't work" in what sense? there are a lot of bugs in various IP stacks relating to mixing and matching things like promiscuous mode, hardware assisted vlan tagging, etc.
(06:34:56) rwatson: jontow: if you can't get it to work still, try disabling hardware vlan assist
(06:35:33) rwatson: jontow: this won't help with rule syntax errors, of course. :-)
(06:42:44) helevius: jontow: try naming a vlan to watch, like 'vlan 10'
(06:42:56) helevius: That might make a difference, might not
(06:45:08) helevius: It probably won't
(06:47:05) jontow: it literally is just the syntax
(06:47:18) jontow: it works fine, i've compiled libpcap/tcpdump from the tcpdump.org site and its fine now
(06:47:54) jontow: the bundled one just doesn't include support for vlan tags at all
(06:48:32) jontow: really odd that they didn't do that though.. oversight maybe?
(06:48:49) drape: i know on fbsd some interfaces don't support vlan tags :/. found that out the hard way.
(06:49:00) jontow: thats not a problem -- these do, and its confirmed on freebsd ;)
(06:49:38) jontow: richard; specifying a tag doesn't change the syntax error problem btw :/
(06:49:51) jontow: this means though; that i need to be recompiling snort
(06:49:58) jontow: since i'm sure its linked into the native pcap

iSCSI targets in Ubuntu

No real contribution here: I just followed the directions on the Ubuntu forums

Then I went to the Microsoft web site and searched for 'iscsi driver' and found this link.

Install the software found there or at whatever updated link you find.

By default this will stick the software in your programs menu. (Start button, programs, Microsoft iSCSI Initiator) Read the readme file. It takes you through a couple of steps to test the connection and then make it. In Device Manager, I can see the MS iSCSI Initiator under SCSI and RAID Controllers, and an 'IET Virtual-Disk SCSI Disk Device' under disk drives.
I don't see how to partition and format. The Disk Manager had a problem, because I disabled the Logical Disk Manager services.

Ah, all is well now that I enabled those services. Disk Manager shows the disk, and I can create a partition and format it, just as if it were a local disk.

Just as advertised.

Snort as an IPS

Someone in the local Snort user group asked me,

"Dear James,

Was wondering if you know of anyone who has used snort for line-rate
deep inspection on networks up to about 400 mb data flow.
And if so on what hardware. "

I replied,

"I'll ask around.

I don't have direct experience with this, but I'll share my thoughts anyway.

I don't use it inline for a couple of reasons.

1) separation of policy audit from policy enforcement (conceptual thing)
2) complexity in a firewall is a bad thing imho (luddite thing) There's a history of vulnerabilities in anything that does protocol decodes, because they are tricky.
3) fail-open and default pass less desirable than default block on my stateful firewall

There are certainly reasonable claims to be made in favor.

I believe Sourcefire claims they comfortably handle gigabit rates for their branded Snort appliances. I'm sure you can't use a lot of any -> any rules, though. Some tuning required.

If I were to build such a box, I'd get a Xeon 5100 series, with a 1333 mhz bus, and intel I/OAT compatible cards/chipset to offload some of the tcp/ip overhead. I don't *think* the disk is critical so you could go with a SATA2 drive.

http://www.siliconmechanics.com/i5917/Xeon-Server.php

Sourcefire uses commodity hardware, and thinks they will be able to use Moore's Law to surpass ASIC-based custom hardware. The basic proposition is, can Tippingpoint do R&D and manufacturing better than Intel et. al. ? I talked to a smart booth weasel for Tippingpoint at an expo (the only IPS weasel who knew what he was talking about in a field of 4-5 vendors) who thought they could, with FPGAs.

Since you have to have a higher confidence level in the blocking rules than in alerting rules, you might want to run a separate IDS. You can have a larger ruleset without DoS'ing yourself on a device that simply observes. Any problems it has don't affect the net."

I don't know if I was clear but he can always ask. Some points for clarification: IPS doesn't just watch the bad packets go by. It blocks what it identifies. The problem is, that identification must be more certain than an i.d. that simply generates an alert. Another problem is that behavioral/heuristic analysis will unpredictably alter network performance. The Visible Ops/ITPI folks would scream. Apart from network neat-freaks (to whose ranks I aspire to join), there's a real issue with allowing stimulous of an attacker's choice to alter the behavior of your network defenses. And, inevitably, some fraction of what an IPS blocks is going to be legitimate traffic.

The point about the additional complexity of an IPS is that a dumb, robust stateful firewall is going to be reliable. An IPS does more, has more code, more functions, more flaws. This is mostly, but not entirely, theoretical. Snort has had issues. BlackIce has had issues. I imagine the others have, as well. Ethereal (now Wireshark) and tcpdump have had issues, and these tools do things that an IPS must do. Protocol decodes must either attract really stupid programmers, or be really hard to do. I'm guessing the latter.

The point about the default block is that usually an IPS passes whatever it doesn't recognize as bad. Marcus Ranum explains why "Enumerating Badness" is a broken model. You want your firewall to permit only specific things, and block everything else. So an IPS must not be your only line of defense.

Sometimes I am a dumbass

I made the following post to nagios-users. Note the 50-50 success rate in redacting the snmp community string:

James Affeld wrote:
> When I run just about any kind of SNMP check, I get suitable info at the beginning of the response, but a bunch of junk at the end. It even runs into the next command line. As you might gather, this is done via an ssh connection, using putty.
>
> root@silmec2:/usr/local/nagios/libexec# ./check_snmp -H 10.139.7.1 -o .1.3.6.1.4.1.9.9.48.1.1.1.6.1 -C REDACTED -P 1
> SNMP OK - 17448296 | iso.3.6.1.4.1.9.9.48.1.1.1.6.1=17448296Üjú·ôB¿¹ÈÈÜjú·ÔB¿`B¿¨B¿¢é·;;;;
> root@silmec2:/usr/local/nagios/libexec# PuTTYPuTTYPuTTYPuTTYPuTTY
>
> If I do an snmpwalk vs. that OID, it returns cleanly.
>
> root@silmec2:/usr/local/nagios/libexec# snmpwalk 10.139.7.1 iso.3.6.1.4.1.9.9.48.1.1.1.6.1 -c 55CC0000 -v 1
> SNMPv2-SMI::enterprises.9.9.48.1.1.1.6.1 = Gauge32: 17390392
> root@silmec2:/usr/local/nagios/libexec#
>
>
> I run into the same problem checking a Cisco Catalyst 6009 and HP 2524 switches. Any clues?
>

This string has been retired. I should have been, as well.