Intrusion Detection with Snort 142
| Intrusion Detection with Snort | |
| author | Jack Koziol |
| pages | 400 |
| publisher | Sams |
| rating | 9 |
| reviewer | Eric Stats |
| ISBN | 157870281X |
| summary | Handbook on the open source Intrusion |
What Koziol implies throughout Intrusion Detection with Snort, but never states outright, is that Snort holds an inherent advantage over closed source IDSs, in that the IDS itself can be tailored and customized for each individual deployment to a level not possible for closed source competitors. If you have had the displeasure of working with a rigid, uncustomizable, IDS you already know where this is going ...
In order for an IDS to be effective, or in some high-bandwidth cases, even usable, detailed network and business context must be applied to the IDS. In a nutshell, IDSs are not as plug-and-play as firewalls or other security applications. For example, if you know you are not running any HTTP traffic on the segment where the IDS is sniffing, you may not want your IDS to waste cycles looking for attacks on Apache. On the other hand, you may feel that the mere presence of HTTP traffic may indicate something innately suspicious, so it is of value to watch for any HTTP traffic. It all depends on what you feel are legitimate threats to the network you are attempting to protect. Snort gives you the power to "watch" for specific attacks, protocol anomalies, or other chatter that has no legitimate business running on your network. Other closed source IDSs don't, or can't, have the same flexibility. Only Snort can implement something as detailed as "Send a page to the CISO's phone if this particular subnet attacks these Apache servers with the chunked encoding exploit."
With Snort, novices can easily write attack signatures (called rules) enable or disable specific protocol decoders, and detect advanced attacks such as exploits utilizing polymorphic shellcode. Without this level of flexibility, you are likely to be flooded with alerts that are not relevant, or, even worse, miss an actual attack that causes irreparable data loss.
Like many open source applications, Snort's biggest downfall has been documentation. Who wants to write boring user manuals when he can write code, right? Well, that's all fine and dandy for Snort developers, but folks that want to actually use all of the neat features can't, unless you tell them they are there, and how to use them. Intrusion Detection with Snort bridges this gap, and offers a clear, concise, guideline that helps plan, implement and maintain Snort-based IDS.
Another oft-cited problem with Snort that Intrusion Detection with Snort addresses is the lack of Snort features that are not directly related to intrusion detection. In essence, Snort's developers have concentrated on creating the world's best application for detecting unauthorized activity, and left everything else to other applications. If you want to organize and manage the alerts generated by Snort you have to use another application (ACID). If you desire alerts via email or pager you need another tool (swatch or syslog-ng). If you want to centrally manage attack signatures for multiple Snort installations, guess what? You need another tool (IDS Policy Manager or SnortCenter). Finding, installing, and getting all of these tools to work right can be frustrating, so Koziol walks us through these issues, and in the end we have an IDS rivaling the expensive commercial solutions.
On to the nitty-gritty of the book. Essentially, this book is organized into logical three sections, even though the author did not choose to make these demarcations in print. The first section introduces us to intrusion detection in general and features of Snort. The second section is a detailed installation guide, which walks through setting up and installing the various components of a distributed Snort setup. The final section focuses on post-installation and maintenance tasks, as well as advanced topics.
In the first section, the different breeds of IDS (Host and Network) are honestly presented, Koziol acknowledging in great detail some of the major shortcomings of IDS technology. The book then moves to describing Snort in great detail in an unbiased fashion. Other books on this subject written by Snort contributors are less forthcoming with Snort's disadvantages. The inner workings of Snort (such as packet decoders and libpcap) and the largely undocumented preprocessors are described in detail, giving tons real world examples. The examples are somewhat current, and describe exploits commonly found 6-18 months ago. Although the actual exploits found in the wild may change over time, the strategies for discovering them with Snort should remain relatively constant. The book then moves into the activities required in planning for a Snort-based IDS installation. Some of this is common sense for experienced security practitioners, such as establishing an incident response plan (the "Oh shit, I've been hacked, what do I do now!?!?"), but is relevant for novices. Other topics introduced in this section are:
Sensor placement: where to place an IDS from a network design perspective for maximum benefit.
Inserting a sensor into an in place network: covers using taps, span ports, and dedicated hubs.
Specific hardware and OS considerations: basically, why a flavor of Unix is best for Snort.
Creating a unidirectional sniffing cable: allows network traffic to flow in a single direction, minimizing risk to an IDS segment.
The second section is a detailed guide to building a distributed or 3-tiered Snort IDS. Getting the three components, the sensor (where Snort is actually installed), the server (database, alert management, and reporting server), and the analyst console (secure place to access other components and store config files and scripts) up and working on Linux takes up the bulk of this section. The analyst console chapter walks through the ever-popular Analysis Console for Intrusion Databases (ACID). Attention is paid to configuring a secured setup that encrypts traffic between the various sensors, servers, and consoles. Various packages and tools are described, as well as condensing all of the Snort tiers onto one physical box. Installing and configuring on Windows is covered as well, although this choice of setup is not as thoroughly explained as the others. The third and final section picks up where most books that deal with a specific application or software package too often leave off, namely, keeping the damn thing working. A chapter is dedicated to tuning Snort, and what thresholds can be configured to maximize benefit and performance. Getting real-time alerting via email working with ancillary tools, is covered in a dedicated chapter. Developing a targeted ruleset (a set of automagically generated signatures that will only detect attacks that have the potential to be successful) using a custom shell script is described.
A very important topic in Snort administration, writing custom rules (attack signatures) gets its own chapter. The syntax for creating rules is clearly described, followed by concrete examples. The book works through writing rules by reading through raw packet captures (last year's Slapper worm is a particularly good example). This is followed by upgrading and managing rules, which is highly useful if you have a number of Snort installations to manage. Finally, Intrusion Detection with Snort closes with a chapter on advanced topics. The advanced topics chapter primarily covers the latest fad 'Intrusion Prevention.' Snort can be made into an IPS device via packet scrubbing or shunting. For packet scrubbing, the Snort Inline patch is used and the box is placed in between a trusted and untrusted network, dropping packets that match specifically created rules. Shunting is accomplished with SnortSam, which basically sends a request to a border router or firewall to block an attacking IP address for a predetermined period of time.
Overall Jack Koziol's Intrusion Detection with Snort is a viable text for learning Intrusion Detection with the worlds premier open source IDS, even if it is light on diagrams and pictures, but it still comes highly recommended from this reviewer.
You can purchase Intrusion Detection with Snort from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
Sounds like a good book to have... (Score:5, Insightful)
Re:Sounds like a good book to have... (Score:5, Insightful)
Security six months down the line might be totally different if some other group start a cooler IDS on SF.NET.
Re:Sounds like a good book to have... (Score:5, Interesting)
Point being that I don't think Snort is going away any time soon.
Re:Sounds like a good book to have... (Score:5, Insightful)
The truth is, Snort is to IDS as Apache is to http servers.
Re:Sounds like a good book to have... (Score:1)
Snort is to IDS what mysql is to SQL servers. Pretty good, and free when the commercial options are terribly expensive and largely overkill for most situations.
Apache is the dominant option. Snort is far from it.
(though your original point is valid)
Re:Sounds like a good book to have... (Score:2)
Re:Sounds like a good book to have... (Score:1)
Re:Sounds like a good book to have... (Score:1)
Security six months down the line might be totally different if some other group start a cooler IDS on SF.NET.
Yeah, we better just bury our heads in the sand rather than try to be proactive on security, 'cause, like Barbie(R) would say, "Security is hard".
I think you wrote your post solely to be a contrarian and to appear to the ignorant as being wise. Your comment offers absolutely nothing of substance to the issue.
Snort is the greatest! (Score:2, Informative)
Other Snort books (Score:5, Informative)
Snort 2.0 Intrusion Detection [amazon.com]
Which is the one I helped out with, and:
Snort 2.0 : The Complete Guide to Intrusion Detection [amazon.com]
which isn't out yet. The Syngress book came out really well. Jeff, Dragos, and Jed are all really sharp guys, so I don't doubt their book will be good too, but it's not out quite yet.
The book I helped on has been getting really good reviews on Amazon, and sales have been great. It was written by some great guys from the Snort community, notably Brian Caswell who runs snort.org [snort.org] and Jay Beale, who people will probably recognize from the Bastille project.
Re:Other Snort books (Score:2, Interesting)
Just wanted to add my .02 to the mention about Snort 2.0 Intrusion Detection from Syngress. I was brand new to Snort, boss came home from a confrence and he heard people were using Snort and wondered why we weren't. So I picked up the book and it was a great book to learn. Also comments from the Snort mailing list are another great place to learn more information. But you all probablly know that stuff already
Re:Other Snort books - How do they compare? (Score:1)
kc
Re:Other Snort books - How do they compare? (Score:1)
I haven't read the other book, but like I stated earlier it is an interesting read, great ideas and was a great book for teaching me how to use Snort.
I was a brand new person to Snort and it got me up and rolling. I am now using RedHat 8.0, MySQL, and ACID in my small company and things go quite smoothly.
The book has my recomendation to it. Was better then googling for everything.
One Problem (Score:3, Informative)
Other than that, the snort engine can pretty much detect anything that has a signature to it.
Re:One Problem (Score:5, Informative)
This isn't really a problem per se (Score:5, Insightful)
I don't necessarily want an IDS to run around correcting or cleaning things... it's usefulness is in the fact it's a watchdog. It's light and focused, with elegance in simplicity despite capability.
Sorry, that's not entirely correct. (Score:5, Interesting)
If you want your traffic "cleaned" then you must use Snort in combination with IPTables as an inline [google.com] firewall. This allows Snort to drop, block, reroute, malicious traffic. At this point, Snort is no longer an IDS but, is instead an Intrusion Prevention System(IPS), the latest buzzword acronym to infest the IT world.
Problem (Score:1)
Otherwise, you'd be vulnerable to root exploits [secunia.com], which might not be the happiest moment of your security career.
Re:Problem (Score:1)
Re:One Problem (Score:1)
Here's a simple script that you can pipe your network traffic through to solve most problems:
s:<HTML><HEAD><TITLE>Slashdot.* </HTML>: <HTML><BODY>GET BACK TO WORK, NOW!!!!</BODY></HTML>
Re:One Problem (Score:4, Interesting)
Check out Hogwash [sourceforge.net]
Also, a buddy of mine hacked hogwash to support IP tables [prismnet.com] a while back (no extra hogwash box necessary).
Re:One Problem (Score:1)
Re:One Problem (Score:2)
You're right, it is a BIG thing, and a good one
The biggest trap for young players with intrusion detection is to configure your IDS to do all sorts of funky lock-down things every time it detects a problem.
What happens when Joe BadGuy figures out that a certain type of probe on your swerver shuts down smtp for thirty minutes? That's right, he probes your server in that way once every 25. Insta
Snort, Tripwire, Etc... (Score:5, Insightful)
Personal computer security is laughable these days. Run snort, use snort, and tell others to run snort, and other free security software packages out there.
Hell buy a copy of this book and lend it to fellow admins, it can only help, let me repeat it can only help.
Not trying to be a troll, but remember not everyone is "Slashdot Savvy" and "in tune" with the hipster software. This is a tried and true program that is so uber documented they're writing books about it, you can't go wrong, seriously.
Re:Snort, Tripwire, Etc... (Score:5, Informative)
Snort runs just dandy on Windows 2000. So that's not an excuse to not run an IDS.
I do wish there was an open free tripwire version for windows. For that you need to shell out the bucks.
Re:Snort, Tripwire, Etc... (Score:1)
http://www.cs.tut.fi/~rammer/aide.html [cs.tut.fi]
<genie voice>I GRANT YOU YOUR WISH.</genie voice>
MOD PARENT UP! GREAT LINK. INFORMATIVE. (Score:2)
Not 64bit Clean (Score:1)
I have an OpenBSD firewall on an Alpha Station 200, in which I tried to run snort. Well snort would crash shortly after startup. When I took a closer look it seems the crash was caused by trying put pointers into int. I can't believe programmers in this day can't get sizeof(void*) != sizeof(int) on all machines.
Anyways I started to try to fix this but the problem was too wide spread in the code that I ran out of time. Which makes me wonder if they make such a simple mistake so common what other bugs cou
Re:Not 64bit Clean (Score:2)
uhm... on a 64 bit machine ints should be 64 bit... ints are variable sized depending on the architechture of the machine. During my 3½ second google research before posting I couln't find a reference to back me up but IIRC sizeof(void*) is always == sizeof(int). What is much more likely is that the snort code is using some WORD macro (__int32 or something) in stead of int. So the solution should be t
Re:Not 64bit Clean (Score:2)
Nope. On Alpha Linux, in any case, sizeof(int) == 4 while sizeof(void*) == 8. Now sizeof(long) == 8, so you could force a pointer into a long if you wanted to. But the C standard doesn't even guarantee that a long is big enough. Writing code that makes such assumptions shows that the author has a bit more to learn about C, or just doesn't care about portability.
Re:Not 64bit Clean (Score:2, Interesting)
The reason you couldn't find a reference to back you up is because as edhall pointed out sizeof(void*) is not guaranteed to be sizeof(int). For example on an Alpha machine:
You will notice the plain 'unsigned' there, that's the problem in snort. You really wouldn't want plain ints to be 64bit anyways for performance reasons. I wish you were right and they just used a typedef in their header files but they don't. For example snort for
Re:Not 64bit Clean (Score:2)
in the spirit for trying to find easy solutions: have you tried
#define unsigned unsigned long
#define int long
This has the potential to break a lot of code, but it just might work...
Re:Snort, Tripwire, Etc... (Score:1, Interesting)
Clearly, an IDS can be part of a well-designed network, and Snort certainly seems like a decent IDS, especially when you look at the cost. However, there are circumstances in which it (or any other IDS) just don't add enough security to be worth the administrative burden and additional risk. For a small office where the only services exposed to the Net are SMTP and HTTP, running on boxen with a mature, proven IP stack and a decent OS (think OpenBSD), set
Re:Snort, Tripwire, Etc... (Score:2)
Snort has had 2(?)remote vulnerabilities in the last year which gave the attacker the same rights as the snort process (which on too many machines runs as root).
Snort listens and processes data from an assumed hostile environment and it is not unreasonable to assume that as applications like snort grow in popularity the more they will be specifically targetted for a) detection/evasion, b) compromise, or c) DoS.
People who are not "Slashdot Savvy" probably won't be able to stay ahead of th
Snort Vulns (Score:2)
Re:Snort, Tripwire, Etc... (Score:2)
Not so fast there buddy. Snort has had remote [securityfocus.com] vulnerabilities in the past. Tripwire isn't perfect [securityfocus.com] either.
The simple fact is that any additional piece of software increases your risk. You must assess this and do what is appropriate for your particular situation.
Re:Snort, Tripwire, Etc... (Score:1)
clarkconnect (Score:5, Informative)
one thing, you need some relatively decent hardware for it to work, as it chews significant processing power sorting thru your packets, and even more cpu time to sort thru all your logs and generate an intrusion detection report.
on my k6-2 500mhz firewall with 256mb ram on my home cable connection, it takes ~30 minutes at 100% cpu to generate a report
Re:clarkconnect (Score:2)
If you'd rather conserve CPU time than get your report earler, try looking into the nice command.
Cobalt Raqs are a similar spec to your machine, and I don't want my co-lo box dying due to non-serving tasks. Solution is to nice just about everything - box stays responsive, and the reports still arrive. Just a little later, that's all.
Cheers,
Ian
Re:clarkconnect (Score:1)
however one thing I dont think I can change is the power Snort uses on a minute by minute basis. If I am transferring across my cable modem at its full potential (3mbit down, 256k up) then snort takes on average about 25% cpu contstantly according to top. I also run 'ntop' in the backgroud (it generat
Re:clarkconnect (Score:1)
I undforutuantely am only experienced in running a little firewall/router pre-made distro on my home lan.
and, in actuality i disabled snort recently, to see if there was any chance my network latency in online gaming, and in general, would improve by taking snort out of the picture
i didnt notice any difference really, so I think i will re-enable snort. but i dont know what good it is really doing me, the o
good book. (Score:4, Interesting)
To be honest, I only noticed this book because it had Bruce Perens' name on it). It is a good book, regardless of what you think of Bruce (does anybody *not* like him? why?). It's concise and the included scripts look like they do what you need them to do. They also go over what the scripts do, how they work, etc.
Natch, the scripts are available online, so no need to retype them in.
Re:good book. (Score:5, Informative)
Bruce
I run snort+mysql+ACID+snortcenter... (Score:5, Informative)
A note on Firewalls (Score:5, Insightful)
Fun Quote from the Chunking Exploit File (Score:5, Funny)
* --- heh, this is a middle finger to all those open source, anti-"m$"
* idiots... slashdot hippies...
LOL
It runs on Windows too (Score:5, Informative)
Re:It runs on Windows too (Score:1)
--
Re:It runs on Windows too (Score:2)
It gets my vote (Score:5, Informative)
Google is great, but there is nothing like picking up a well-organized resource book, especially when tying other modules (like ACID, MySQL, etc.) into the mix. Besides, when you can see information in a single, coherent, organized form, you are able to get a much better feel for the big picture, instead of just the pieces of the puzzle as separate components.
And it never hurts to have a bookshelf packed with technical reference manuals behind your desk for then the PHBs walk in ;-)
yeah.. but.. (Score:5, Interesting)
Snort is for pussies! (Score:5, Funny)
IDS (Snort) Training with SANS (Score:3, Informative)
The first couple days covered TCP/IP packet composition and attacks. There were then a couple of days about installing and using Snort (taught by Marty Roesch, creater of Snort). Really taught how to use and get value out of your IDS, including a lot of real world examples from people who use it in sites attacked a lot more frequently than mine.
Highly Recommended.
http://www.sans.org [sans.org]
well, it's in smoothwall (Score:3, Informative)
Apache and intrusion attempts (Score:2, Interesting)
Re:Apache and intrusion attempts (Score:2)
Re:Apache and intrusion attempts (Score:5, Informative)
Heh, they aren't guys, they're worms. The persistent ones probably share two or three octets of your IP address. The default.ida attacks are from Code Red variants and the cmd.exe attacks are from Nimda. Both attack IPs somewhat randomly but are weighted to attack 'nearby' IPs far more frequently. It was a very effective tactic, too.
Those are unpatched infected IIS servers doing that. It's really sad. Code Red almost went away for a few months but now I'm getting more Code Red hits than Nimda, but I see both every day. The SQL Slammer worm is still a daily occurrence, too.
(TCP port 1433 three SYNs in a row).
My 'intrusion detection' so far is from Apache and ipchains logs. I think I'll install Snort because I'm curious how many NetBIOS attacks I'm getting.
Correction re: Slammer (Score:2)
(TCP port 1433 three SYNs in a row).
While everything else you said was bang on, Slammer actually uses port 1434, and doesn't use SYNs, as it travels over UDP.
If you're seeing repeated TCP attempts at 1433, it may be a worm or it may be someone messing with you, but it most certainly is not Slammer.
Re:Correction re: Slammer (Score:2)
The SQL Slammer worm [cert.org] (I thought it was 3 tries in a row, but not in today's logs):
May 29 16:03:10 (myhostname) kernel: Packet log: input DENY eth0 PROTO=17 66.108.147.93:1339 xxx.xxx.xxx.xxx:1434 L=404 S=0x00 I=62109 F=0x0000 T=110 (#12)
Here's the TCP 1433 one. (Aha, this was Spida [cert.org].) This may be the 3-in-a-
mod_alias... (Score:1)
I've heard of people redirecting code red attacks to servers setup to cleanse them. Perhaps this is only an urban legend, but a damn clever/funny one at that!
Another Snort book that's Open Source (Score:5, Informative)
Also, the source to the first two books in my series is now online at phptr.com/perens [phptr.com].
Thanks
Bruce
Re:Another Snort book that's Open Source (Score:1)
Seriously though, I'm sure Mr. Perens book is excellent, I have it on order. The other books in his series are excellent.
All in all, these books on Snort should heighten awareness on security matters and hopefully deliver some useful, pratical, and necessary security skills to IT workers in general. It's in everyones best interest; so when you are finished with the book, hand it over to a friend or coworker!
i've always wanted to know.. (Score:2, Interesting)
Re:i've always wanted to know.. (Score:1)
snort is the weakest link (Score:1, Insightful)
seriously consider the security issues if running
snort. The code has been plagued with security
issues from day one. It is practically beta code.
I know if i ran snort on x86 linux, i would
consider that my weakest link out of all
my services. i know that one heap overflow exploit
is proably circling hands right now.
funny, your security tools are the most likely
avenue of getting hacked right now.
ironic
Re:snort is the weakest link (Score:2)
Snort 2.0 is apparently not vulnerable to this exploit.
Good heads-up, though.
Oops - forgot... (Score:1)
A carefully set up system should not be exploitable (though it may be vulnerable).
There's no reason to allow outbound connections from the snort box, except to the logging / other snort related servers, which should be protected separately anyway.
Thus even an exploit that sets up an outgoing connection should be covered.
That way, no information can leack back to t
Re:snort is the weakest link (Score:1)
You're full of shit.
And you don't even have the balls to post as anything but an AC [finchhaven.com]
feh..
t_t_b
Re:snort is the weakest link (Score:3, Insightful)
Then I wonder what you have to say about the end of this advisory [cert.org] from CERT. Note at the bottom when it says:
Why so many IDS deployments fail.... (Score:4, Insightful)
This hits the nail right on the proverbial head. So many articles in the security industry focus on "IDS failures" [sans.org]. If you don't know your network, servers, routers, and what they should be doing, you can't implement IDS effectively.
Very important topic, Im glad this point so often missed made it into this book. Should be a good read.
Re:Why so many IDS deployments fail.... (Score:2)
Cable modem license (Score:2, Interesting)
Re:Cable modem license (Score:1, Insightful)
If they insist you can't, ask them to buy your computer, THEN they can tell you what you an't run on it....
Re:Cable modem license (Score:2)
Sniff, sniff away (Score:3, Insightful)
What I'd be more concerned about, and someone else touched upon here, is that your cable ISP is running a really ancient setup. Basically, you and everyone else on your node are on effectively a flat ethernet, and all traffic that go
Snort as part of Henwen (Score:1)
Re:Snort as part of Henwen (Score:2)
Re:Snort as part of Henwen (Score:1)
Chah to IDS! (Score:1)
Sounds good.... (Score:2, Interesting)
The basics won't change much, but I wonder.
I wonder if the book covers some of the great addons available like acid, barnyard, and snortsnarf?
Is this covered??? switching and viruses (Score:1, Interesting)
2. Using it to detect virus signatures on the network?
Re:Is this covered??? switching and viruses (Score:1)
If they are all hung from one or two switches, then setting up a couple of monitor ports and dropping them to a hub would allow you to run with a single snort box.
Otherwise, you may have to run one snort per switch, and centralise the logging.
As for virus sigs, I'd rather trust a dedicated virus scanner, unless you know someone who's prepared to open up their virus sig database to you and mail you with new sigs every time there's a new virus.
It's not desi
More importantly... (Score:1)
1. Run snort (after reading said book)
2. ???
3. PROFIT!!!!
You need HISTORY to develop good detection rules (Score:3, Insightful)
Snort and the other intrusion detection systems perform to varying degrees at monitoring corporate resources resources and alerting personnel when something is amiss, according to the rulesets they've been given. The article assumes the rulesets are known in advance: your work is to take those rulesets and implement them in Snort or your favorite IDS.
The real world isn't so simple. IT personnel can only guess at all the possible security problems with the network equipment, hardware, server software, clients, external network connections, malicious hackers and information thiefs out there -- as well those rare dishonest insiders. A more effective security implementation includes plenty of logging, and subsequent log analysis.
Logs are easy to generate for all varieties of hardware and software. Collecting and centralizing log data lets you:
Having the history lets an organization more effectively implement the "detailed network and business context" within the real-time IDS solutions.
Of course, the real problem is the $2 million for the Oracle DB to manage all that log data. And querying all that history is a bear. And the DBAs, the software developers, etc. to manage that log history. I've heard that addamark's log management system [addamark.com] (LMS) is a good alternative. Someone told me their product replaced a DB2 cluster at one organization after a two-hour DB2 query took three minutes on an Addamark cluster. The cost savings, storage capacity, and log compression were phenomenal too.
Are there other log centralizing solutions out there you've heard of? Addamark seems to work because it's not a full-fledged traditional DB, but optimized for this log management problem -- can a traditional DB keep pace?
Open source business model will win out in the end (Score:1)
Very interesting point. It looks like, at least for IDS, the open source business model will always win out. How can you make an application truely customizable if you don't have source-level access? In situations where adaptability is important or even critical, such as IDS, the open source model will always
Building an Ethernet Tap (Score:4, Interesting)
I have no spanning capabilities on my switch and I'm not about to put some $40 CompUSA hub on my production network so the only real choice for me is an ethernet tap. However, I'm having a very difficult time finding schematics for building a 100Mbit ethernet tap. The best I could find is this brief PDF [snort.org] that discusses a bi-directional tap. Unfortunately, this method also requires a spanning port on a switch.
I've found commercial ethernet taps [comcraftfr.com] for sale but they all cost upwards of $400. Surely there is a way to build one of these in a home workshop. Does anyone have schematics?
Chris
Re:Building an Ethernet Tap (Score:1)
If you are a hardware snob then go out and buy an expensive hub to the specifications you desire. All the big boys make them.
Re:Building an Ethernet Tap (Score:2)
I've done something similar and it works great.
Re:Building an Ethernet Tap (Score:2)
Hopefully a good learning tool... (Score:1)
Re:Snort sucks anyway... (Score:5, Funny)
So I guess installing MS Windows Servers and Workstations on the network is out of question?
Re:Snort sucks anyway... (Score:1)
Re:Snort sucks anyway... (Score:3, Informative)
http://www.securityfocus.com/archive/1
Using any plugins? You've probably got more than one:
http://www.securityfocus.com/archive/1/318 669
And this is just going back to April.
So, in conclusion, you have a remote root 'sploit on your network and "wouldnt even know its there unless I told you".
Re:Snort sucks anyway... (Score:1, Informative)
Re:Snort sucks anyway... (Score:1)
From the advisory:
"For the unstable distribution (sid) these problems have been fixed in version 2.0.0-1."
Show me a package that hasn't had a vulnerability or bug at some point. Then go take a valium, it sounds like you need one.