Slashdot Mirror

2003-03-04 20:28:07 New Snort vulnerabillity (articles,news) (rejected)

Normally, I wouldn't complain. Rather I would assume my submission was rejected because an earlier or better written one had been accepted. But, it looks like they just want to ignore this one.

Get your Snort update here.

2003-03-04 20:28:07 New Snort vulnerabillity (articles,news) (rejected)

Normally, I wouldn't complain. Rather I would assume my submission was rejected because an earlier or better written one had been accepted. But, it looks like they just want to ignore this one.

Get your Snort update here.

--

This is off-topic, but here is a very interesting experiment for you to try....

In the 1940's and 50's McGraw-Hill published a series called the National Nuclear Energy Series. Google for list of the titles. A number of them have been classified but a few haven't. Next proceed to google each individual title you were able to find.

Make sure you have a network monitoring/logging utility such as snort to watch your net traffic. Within 48 hours or so you should see a number of cool probes come in from off-shore CIA and NSA shell corps. They really like the Bahamas, probably nice and warm.

P.S. this isn't a troll or joke, you have been warned.

Better still would be a reverse honeypot - an app that catches outgoing requests, tests them against a database of known offending addresses and/or ports, and (optionally) tricks the offending application into thinking it has successfully phoned home.

For something like this you need not a firewall but an IDS, an Intrusion Detection System, with correct signatures of traffic you want to detect. I would suggest Snort (there's an MS Windows port), a great free software IDS released under the GPL 2+. It won't change the traffic, but it will detect it (you have to use signatures matching traffic patterns of known spyware or even something very general, but disable Web attacks rules and other which you don't need to look for).

To fool application you would need not only some firewall/router rules to redirect the traffic somewhere else, like to your own machine, but you would also need this machine to speak the right protocol, which may be much harder than useful, or even impossible without altering the spyware binaries. I would personally rather not use spyware at all instead of mounting such attacks against their communication. If I wanted to write spyware, I'd use valid HTTP on port 80 to call home, which wouldn't differ from normal WWW traffic, or ICMP ECHO_REQUEST/ECHO_RESPONSE, etc. The problem is that if you have any network connection at all, the covert channels will always be possible.

But if you really want to try intercepting and altering the spyware traffic, which may be fun after all, you may want to take a look at such tools as ngrep, tcpdump, netsed, netcat, etc. If you want to look for open ports on your machine, use nmap. Use Nessus if you want to test for many different vulnerabilities.

Better still would be a reverse honeypot - an app that catches outgoing requests, tests them against a database of known offending addresses and/or ports, and (optionally) tricks the offending application into thinking it has successfully phoned home.

For something like this you need not a firewall but an IDS, an Intrusion Detection System, with correct signatures of traffic you want to detect. I would suggest Snort (there's an MS Windows port), a great free software IDS released under the GPL 2+. It won't change the traffic, but it will detect it (you have to use signatures matching traffic patterns of known spyware or even something very general, but disable Web attacks rules and other which you don't need to look for).

To fool application you would need not only some firewall/router rules to redirect the traffic somewhere else, like to your own machine, but you would also need this machine to speak the right protocol, which may be much harder than useful, or even impossible without altering the spyware binaries. I would personally rather not use spyware at all instead of mounting such attacks against their communication. If I wanted to write spyware, I'd use valid HTTP on port 80 to call home, which wouldn't differ from normal WWW traffic, or ICMP ECHO_REQUEST/ECHO_RESPONSE, etc. The problem is that if you have any network connection at all, the covert channels will always be possible.

But if you really want to try intercepting and altering the spyware traffic, which may be fun after all, you may want to take a look at such tools as ngrep, tcpdump, netsed, netcat, etc. If you want to look for open ports on your machine, use nmap. Use Nessus if you want to test for many different vulnerabilities.

a company i used to work for used symantec's intruder alert on the inside of our network monitoring our servers and snort outside outside of the firewall in a dmz monitoring traffic going to the firewall.

I agree that chroot isn't the best sandbox out there. I prefer Virtual Machines, although they're a little more resource intensive (& not free).

I've been considering running a machine with two interfaces but not assigning it any IP addresses, at least for the "host" OS. Then, I could run one or more servers within virtual machines. For instance, the firewall VM would have access to both interfaces, and have IP addresses on them both. DNS and DHCP servers would only need a LAN interface.

I'd need a decent processor with lots of RAM to pull this off, but imagine the possibilities. Running snort in the host OS on the WAN port would give me stealth IDS capabilities. Running it on the LAN port listening for packets on port 514 would give me a stealth syslogger. Since there's no IP addresses to access the host OS, there's no target to hack!

Now, lets take it a step further and imagine this scenario: The stealth IDS detects with some certainty that my BIND DNS server was once again compromised and a hax0r l0ser is launching a DDoS attack from it. Since the IDS is running on the host OS, it shuts down the offending VM, restores the VM's disk to a known good one and restarts it. Insta-restore!

One other method I've been contemplating that I consider somewhere between VMs and chroots is running the servers under User-mode Linux. I haven't had a chance to play with that yet, so don't know the security imiplications. I can't imagine it would be worse than chroot, and it wouldn't tie up resources as much as VMs do.

1) The author cited as fact that the age of the operating system is directly related to its security, without any kind of proof. This makes sense at first glance, but it ultimatly glosses over the fact that both OSes are in constant development. New features are added every day. This might make sense if, after developing the system, all the time after that was spent patching and debugging, but this isn't the case.

2) The author has no concept of service vs. system. Most vulnerabilites are in sevices, not at the kernel level. All Linux is just a kernel. Packages are added to make a usable Linux distro.

3) The author cites number of bugtraq entries as a way of gauging relative security, without considering the severity. Also, bugs, like those reported to Security Focus aren't the only vectors of compromise

4) Open source software, by virtue of being free, allows an administrator to install much more security software for his dollar. Firewalls, IDSes, advanced cryptographic file systems, HIDS, and virus scanners can all be downloaded for free.

I don't think this has a chance. If you look at software for intrusion detection, you'll see that researchers hav put in many, MANY years of research trying to pick up 'strange' network traffic. But it just didn't work. They couldn't get it useable, no matter what smart technologies they used (neural nets, petri nets, complicated statistical methods).

Then along comes a guy who just tries to pick up certain, well-known strings from the network stream and voila, a sort of virus scanner for networktraffic. Works like a charm, with low false positives. See also here, but there are others.

Snort is an Network Intrusion Detection System (NIDS) which is open source, and fast.

The rules are the signatures Snort uses to detect "attacks" or other activities that match a given rule.

Check the snort page for some good, detailed information on how to do this (mySQL logging) and much more.
Here's one way: Snort Installation Manual

Lee

Unfortunately, the NIC can still introduce errors and whatnot onto the segment

Not if you use a one-way ethernet cable.

There's a better article about SNORT and ACID on LinuxWorld. Also, if you want to investigate SNORT, check out the following links:

• CERT's HOWTO on ACID and SNORT
• SNORT's manual on installing SNORT, MySQL, ACID on RedHat
• A variety of deployment guides provided by SNORT
• A collection of various IDS documents and white papers, including a good piece by Marcus Ranum on benchmarking

There's a better article about SNORT and ACID on LinuxWorld. Also, if you want to investigate SNORT, check out the following links:

• CERT's HOWTO on ACID and SNORT
• SNORT's manual on installing SNORT, MySQL, ACID on RedHat
• A variety of deployment guides provided by SNORT
• A collection of various IDS documents and white papers, including a good piece by Marcus Ranum on benchmarking

There's a better article about SNORT and ACID on LinuxWorld. Also, if you want to investigate SNORT, check out the following links:

• CERT's HOWTO on ACID and SNORT
• SNORT's manual on installing SNORT, MySQL, ACID on RedHat
• A variety of deployment guides provided by SNORT
• A collection of various IDS documents and white papers, including a good piece by Marcus Ranum on benchmarking

There's a program called Snort that does packet sniffing and intrusion detection, among other things. It's at snort.org.
That and good ol' P.G.P.

Out of all the "hack attempts" in the last 2 days my works network has had about 95% IIS hack attempts with the rest ssh/rpc probes or anonymous ftp attempts (which could be to exploit either OS or just someone looking for pub ftp sites).

This info courtesy of snort.

While usually we do have slightly more ssh/rpc attempts than this the amount of IIS exploits is never less than 75% of all the breakin attempts we have. I'd attribute most of these attacks to worms.

Hardly scientific I know (unfortunately the snort box was reinstalled 2 days ago so I can't give many figures except from memory) but in my opinion the article is wack.

To wit, we've used all of the products they complain endlessly about, and all I can say is RTFM. All of the problems they encounter are either configuration problems or worse, PEBKAC.

If you want to really learn about IDS, and you don't have the budget to buy a commercial IDS, download a copy of snort and learn for yourself. This report strikes as the type of complaing you get from an IT customer that wants to buy a product, turn it on, never configure it and expect it to magically work.

By now, readers with security expertise probably are asking why we didn't tune the IDSs to reduce the chatter and improve our chances of seeing real attacks. The short answer is that we did, or at least we tried to (emphasis added). Including setup time, this project stretched along three months; and during that period we worked on these systems almost every day.

Wow! What a revelation! You mean you have to know what you're doing and it actually takes time to configure these powerful tools?! In a word, DUH. IDS'es must be tuned. IT products must be configured properly. These things take time, sometimes a lot of time. The core of their complaints revolve around their inability to do either of these things well. Given that lots of people manage to do this effectively everyday and have been for years and years, we're left to conclude that these reporters were not up to the task. And here it is:

Don't expect IDSs to be plug-and-play devices.

Futhermore, all of IT is an ongoing process. A big, circular, ongoing process that requires competent personnel to manage, maintain, tune, test, patch, configure , deploy and yes, spend TIME on. Anyone that expects to be able to deploy close to a dozen different IDS products as plug and play devices into a production network in 90 days with questionable expertise is fooling themselves.

To be effective, they require a lot of tuning, and a fair amount of security expertise (emphasis added). They'll also require willingness to spend a lot of time sifting through reports, at least until the configuration is tuned properly. Even then, IDSs will require constant updating as new attacks appear. IDSs can be lifesavers and invaluable educational tools - but only for those with a lot of patience and a willingness to learn.

The Analysis Console for Intrusion Databases (ACID) is a PHP-based analysis engine to search and process a database of security events generated by various IDSes, firewalls, and network monitoring tools. The features currently include:

• Query-builder and search interface for finding alerts matching on alert meta information (e.g. signature, detection time) as well as the underlying network evidence (e.g. source/destination address, ports, payload, or flags).

• Packet viewer (decoder) will graphically display the layer-3 and layer-4 packet information of logged alerts

• Alert management by providing constructs to logically group alerts to create incidents (alert groups), deleting the handled alerts or false positives, exporting to email for collaboration, or archiving of alerts to transfer them between alert databases.

• Chart and statistics generation based on time, sensor, signature, protocol, IP address, TCP/UDP ports, or classification

ACID has the ability to analyze a wide variety of events which are post-processed into its database. Tools exist for the following formats:

• using Snort (www.snort.org)
• Snort alerts
• tcpdump binary logs

using logsnorter ( www.snort.org/downloads/logsnorter-0.2.tar.gz)

• Cisco PIX
• ipchains
• iptables
• ipfw

The Analysis Console for Intrusion Databases (ACID) is a PHP-based analysis engine to search and process a database of security events generated by various IDSes, firewalls, and network monitoring tools. The features currently include:

• Query-builder and search interface for finding alerts matching on alert meta information (e.g. signature, detection time) as well as the underlying network evidence (e.g. source/destination address, ports, payload, or flags).

• Packet viewer (decoder) will graphically display the layer-3 and layer-4 packet information of logged alerts

• Alert management by providing constructs to logically group alerts to create incidents (alert groups), deleting the handled alerts or false positives, exporting to email for collaboration, or archiving of alerts to transfer them between alert databases.

• Chart and statistics generation based on time, sensor, signature, protocol, IP address, TCP/UDP ports, or classification

ACID has the ability to analyze a wide variety of events which are post-processed into its database. Tools exist for the following formats:

• using Snort (www.snort.org)
• Snort alerts
• tcpdump binary logs

using logsnorter ( www.snort.org/downloads/logsnorter-0.2.tar.gz)

• Cisco PIX
• ipchains
• iptables
• ipfw

1. setup a box with default installation of an older distro
2. turn on extensive logging
3. connect to the internet
4. wait...
5. when cracked, do forensic analysis

Just in case you were somewhat serious, yes! You can use a load balancer and tap even 1 Gb traffic.

No NAT? So am I to understand that you are going live to the net with real IPs or is your debian firewall taking care of NAT for you? Either way, the situation you described is a network sniffer's wet dream. At this point I would assume that at least one if not more of the boxes on this net are compromised and actively capturing traffic. I suggest you learn a bit of Nessus trickery and thouroughly assess all of your systems. Steve Gibson is a joke, sorry to disappoint you but his service is flawed to the core. Try host based firewalls for *all* of your systems, mabe included a bit of Snort in there as well. But seriously, try Nessus from home one night on your network, the admin apparently will not notice and you will be horrified at the results more than likely.

I wonder how long it will be before they start informing Snort users that certian configurations may request licensing fees be payed for patent 20010041989.

Btw, those that are conserned with licensing pop-under patents may also be aware of:
20020046087 Method of drawing attention to advertisements

DShield currently employs as little filtering of incoming reports as possible. Most reports are sent anonymously. We do not know if these logs are truthful, or if the firewall configuration was correct. DShield.org will attempt to protect the identity of the submitter. If you have a question regarding a specific target or source IP, please send an e-mail to info@dshield.org.

I really wish people would get the terminology correct. Spafford posted a good definition over twelve years ago. A quick and dirty definition: Viruses (virii?) generally require human interaction (open an email, click on a link, etc) while worms propagate on their own, exploiting vulnerabilites within an application or operating system.

With that said, it only makes sense that CodeRed (a worm) wouldn't make the top ten list of viruses. I doubt any true worm could ever make some top ten list when compared with large virus infections. Viruses infect workstations (PCs) while worms (generally) infect servers. Last time I checked, there were a whole lot more PCs than servers, thus a much bigger chance of infection. Furthermore, CodeRed's (a worm) impact was limited by that wonderful thing called Open Disclosure. No, M$ will never admit to this, but as a security professional who does network security monitoring, I know my clients would have been severly impacted if signatures hadn't been available for our sensors (insert shameless plug) a month prior to CodeRed (a worm!!) being released. Virus signatures, on the other hand, tend to be created after a virus has been let loose in the wild and has already impacted users.

Bammkkkk

Going through my Snort logs, I find that I'm hit by CodeRed (I and II) and a number of Nimda variants at least 4 times per day. (This is extreamly better than 4 months ago!) As a good Netizen, I inform the ISPs as soon as I'm notified of an attack (often within an hour).

I've found that university administration is often on top of it before I contact them, while some large ISPs take forever. After getting attacked by one IP at US West Minneapolis several times per day for a week, I blocked their entire network at the firewall. For some reason, the NNNNNNNNNN variation of Code Red seems to be very popular this week, though. I don't know if this is all that bad a thing. Idiots who don't patch their bone head machines "from a certain company" are going to be hurt where it counts.

>Or compromise the servers where you get your .debs.
>...
>Obviously nobody would have installed (and be updating) a package called "rootkit," but the scripts could be piggybacked on any security update.

First, it doesn't have to be installed through the updates to the server. It's probably actually easier to find some misconfig'd server or vulnerable daemon out there, establish remote access, and install the rootkit from ther. But you do have a point and that's why I just subscribe to bugtraq, etc. and never trust things like the .deb/.rpm updates.

Second, why worry about a rootkit when the underlying problem is how they get IN before the rootkit. I would definitely reccomend looking at securing-debian-howtofor those of you who are unsure of your debian security.

If the only problem were a rootkit changing binaries and installing a backdoor, then all an admin has to do is put a firewall in front of the server and control all the ports so that any unsolicited traffic from getting to the "unknown" daemon listening on port xyz plus stop ALL unsolicited tcp/udp/icmp traffic from leaving the server unless a handshake was completed. Most stateful pcket filters can do this. If your real paranoid, put an IDS (ie: snort www.snort.org) between the server and the outside to look for irregular activity. Worried about one of your services? Find a Proxy to inspect the connections. Worried about corrupt binaries? Install an integrity checker (ie:tripwire. www.tripwire.org)

Obviously, securing a server will require much more than this. Check out Sans.org. But AT A MINIMUM, the above should have been in place already. Hope that helps at least somebody out there.

We had way too many false positives with their Scanner and Realsecure, even had an ISS guy onsite for a few days. Still, too many problems. With vendor support that... well... is a pain in the *@&%#$ to deal with we switched to Snort and Nessus . Much easier to manage and the false positives went to almost nothing. I'm not even going to start on the Managed firewall crap!

For example, consider that you are currently in an environment that you have connectivity out to the world, but it is monitored. Once you connect, won't some fraction of the "anonomized" traffic come through you?

At some point, if you are trying to view a website with potentially objectionable material, a clear connection has to come from somewhere, and if someone else's connection comes from you, the gestapo could come looking for you.

Once I started looking at Snort, I became very afraid of what is possible. NIDS is a wonderful thing, but if used in the wrong way it could become a good tool for someone wanting to be big brother....

-Jeff

In a bold marketing effort to help squelch concerns that Comcastis collecting and reselling customers web surfing habits, Comcast has updated their I want it campaign. The companies new slogan will be Comcast: We just want your pr0n. When asked how the new slogan was chosen, Comcast responded that
"SCORE! Get the lotion" was already being used by Snort in their kickass-porn rule set.

Or run something like SNORT, to watch for teltales about the protocol (connect strings, etc) and kill it regardless of the port...

How about running web servers booted off cd-rom getting all of their content dynamically by calling java servlets against a remote machine using the secure xfer methods covered in yesterday's secure credit card transfer discussion?

There are a couple of good reasons why this unlikely to be a workable solution. First, this requires almost double the equipment (a two-tier minimum), and it requires the front-end servers to have some type of read-only storage, which most server appliances (like the Netra X1) don't have.

Second, keeping the systems patched and up-to-date (which will still be imporant) is even more of a chore, as you can't just install patch foo -- you need to install the patch on a clean system, make a bootable CD, and then go physically insert the CD and reboot the machine to install the patch. In terms of administrator time, this is completely unacceptable.

Third, it requires that you use JSP (and possibly EJB); things like PHP and Perl won't work with this kind of set-up. As nice as JSP+EJB can be for building complex and stateful web applications, it's really lousy for doing simple things like customer-feedback forms and the like.

Fourth, the applications on the second-tier server are still open to exploit, as is the OS on the external server -- it's possible to crack and root a machine even if it has a read-only root filesystem.

Fifth and finally, it completely violates the KISS principle (Keep It Simple, S*). More machines means more overhead for the admins, higher operating costs; and, most importantly, a more complex system. One of those little rules-of-thumb is that the more complex a system becomes, the more easily it will fail.

Something like a serial cable into the "servlet server" with a non-TCP/IP listener on the serial port. At max speed 115KB serial is like a 1Mbit connection. The web servers won't have IP access to the content server, and can't be defaced. Don't have to care about snort logs, tripwire -- all that happy hoo ha.
Want to run a bunch of web servers for load balancing? put an 8-port digiboard in the servlet server.


I fail to see where a 115Kb/s serial connection is equal to a 1Mb/s link; I would suggest checking the numbers again, as I'm pretty sure that the latter is about ten times as fast as the former, and requires less processor overhead -- serial connections consume much more CPU time than ethernet ones.

Snort and tripwire are very useful tools, and whether or not you have a "secure" setup, it's a good idea to run them. Snort is an extremely capable IDS (Intrusion Detection System), and if your uebersecure system is cracked, can provide valuable logs to find the attacker (and the original security hole). Furthermore, it's always a fun thing to watch the IIS exploit attacks pile up against your smug little Apache server...

HTH. HAND.

See: www.snort.org/docs/faq.html

• Q: Why does snort report "Packet loss statistics are unavailable under Linux"?

  A: The Linux IP stack doesn't report lost packet stats. This may be changing in version 2.4 of Linux, but for now you just don't get them. Try one of the BSDs, they work just fine. This also has been recently fixed with the 2.4 kernel in the new version of libpcap... upgrade kernels and libpcap and it should now work.

That's packet loss ***statistics***, not a statement about packet loss.

This is in the context of Linux generally, not RedHat specifically...

There is *no* other mention of "packet loss" and "Linux" together anywhere in the FAQ.

The *only* reference to "RedHat" itself, anywhere in the FAQ, is the very long-standing advice to upgrade to the current version of libpcap. This advice itself has become pretty much irrelevant for anyone running one of the more recent distros, anyway.

Honestly!

People running their little agendas!

Ya'd think they'd try to put a little more substance in 'em...

...of course, maybe they assume that no one who knows any better will be reading /. these days.

t_t_b

It would be nice to know that Guardent is contributing to the respective projects that are being implemented on this device (IPTables, Snort, Nessus), but I haven't been able to find any ackknowledgement of it on either Nessus's thanks page or in the credits for Snort.

Certainly they've got people working for them who have the know-how to add substancial features to the projects and it would be nice to know that they're not just freeriding on the software for the managed services platform that this device really is.

I just got in from a busy day and what do I find but a little Snort action on ole Slashdot...

So, I've got a few comments about the comments:

Snort signatures and the quality thereof. Anyone who complains about the quality of Snort signatures is a lazy bastard, they're open source and easy to modify, if you find that much wrong with them make the appropriate changes and mail them back to me or Brian Caswell, our own official Snort Rules Nazi. Just because we write Snort sigs doesn't mean you have to use them, the original concept behind Snort and the rules files that came with the distro was that the users could look at examples of how to write them and develop their own set for the site they were protecting. This has gotten way out of hand over the past three years and has blossomed into the approximately 1300 rules we have now. The quality isn't always the best, but we're working on it (and if you've been tracking them over the past 6 months they've gotten much better.

Performance. People from ISS talking about the superior performance of their solution is laughable, it's been shown repeatedly in third party IDS roundups that Snort performs on par with or better than almost all of the other commercially available NIDS solutions out there. In fact, I know of one large entertainment company that sank a decent chunk of money into hardware that's running Snort at OC-12 speeds on their network successfully with no packet loss at all. Moral of the story? IDS performance is tied directly to the configuration and horsepower of the sensor hardware. No big revelations there. The fact of the matter is that's Snort's capabilities and performance keep increasing as we continue to develop it. We're also about to revisit some major architectural components of the system as we begin development on Snort 2.0 this month, but that's a different topic...

Love Snort but need a commercial company to back it? Check out Sourcefire, a company that I founded this year precisely to do that. We are selling network IDS appliances complete with a web-based GUI, data analysis console, and full blown configuration management system built in. We're also working on a Management Console appliance that will allow you to deploy and manage a distributed Snort NIDS infrastructure and manage all the data that comes out of the system and perform multi-sensor correlation.

Rapid response. When the shit hits the fan on the Internet, Snort is usually the leader in getting out new sigs to the user community. Case in point, the W32/Voyager MS SQL worm that recently came out, we were the first with sigs to pick it up.

So in the end, Snort gives you speed and accuracy (in that I mean you can identify specific exploits very precisely), has an active development and user community and is flexible to meet users needs. I think that this is a really good combo for most people's needs. Now that Sourcefire is out there, I think that the needs of "pro" users can be satisfied as well as those of the open source world.

On the other hand I might be biased, as I did write the thing... ;)

-Marty

Hi, I currently work in the UC Davis sec lab (current project(s): HACQIT).

The basic problem with all IDS is in the confidence level of determining if something is an attack or just random garbage. Also, IDS have to be fast. If there's too much traffic (if you've been /.'d), you may not be able to check all attacks. Some methodogies start from the approach that deviating from a set of known safe operations is considered suspect. Other IDSes approach it from checking against a known-attack database. We're currently working on genetic algorithms and expert systems to correlate sensors and systems to detect and respond to attacks. The best approach I've seen is a complete kernel-level instrumentation of all system calls that's transparent and mostly undetectable. It would probably be DoS-able as well. The main prob is that you realy gotta have another comp to offload IDS checking.

Right now, nearly all IDSes are extremely primitive and consist of nothing more than snort rules and Perl scripts that call ipchains or something.

Btw, I went to RAID 2001 this year (hosted at UCD), it was fairly interesting.

Hi, I currently work in the UC Davis sec lab (current project(s): HACQIT).

The basic problem with all IDS is in the confidence level of determining if something is an attack or just random garbage. Also, IDS have to be fast. If there's too much traffic (if you've been /.'d), you may not be able to check all attacks. Some methodogies start from the approach that deviating from a set of known safe operations is considered suspect. Other IDSes approach it from checking against a known-attack database. We're currently working on genetic algorithms and expert systems to correlate sensors and systems to detect and respond to attacks. The best approach I've seen is a complete kernel-level instrumentation of all system calls that's transparent and mostly undetectable. It would probably be DoS-able as well. The main prob is that you realy gotta have another comp to offload IDS checking.

Right now, nearly all IDSes are extremely primitive and consist of nothing more than snort rules and Perl scripts that call ipchains or something.

Btw, I went to RAID 2001 this year (hosted at UCD), it was fairly interesting.

SECURITY FIX: fix buffer overflow reading queue file in lpd

For those running OpenBSD, especially as a gateway/firewall/NAT box, this is an important fix. I am running 2.9 with this patch added, and my snort logs tell me (judging from the number of attempts) that this exploit is a fairly commonly tried one. In November alone, there were at least 30 lpd overflow attempts on my machine. Granted, not most people have lpd open to the world, but I can imagine a few people might want to do remote printing from work, etc.

any decent os, whether it is linux, *bsd, BE, Windows, or whatever can be made secure if you actually take the time to set it up properly.

i know it's tempting for all the [insert your OS of choice] zealots to waive their flags when another OS becomes known to have a security exploit. but for fucks sake, just because wu has a hole in it, doen't mean that the entire OS is scrap.

oh by the way -

SNORT is a NIDS (network intrusion detection system) that could help you detect and prevent a good deal of network attacks. IIRC, it has some windows plugins too.

DEMARC is a web-based console for SNORT, plus a pretty good host/service monitor.

All we need is to see it in action, and soon thereafter Snort will be able to detect it. Once there is a Snort rule to detect it, all you need is Hogwash and it won't be able to get anywhere near you. Or, at least past your firewall. I believe IPFilter is working on a similar feature to Hogwash, which can block packets based on Snort rules.

Hmm, Snort has signatures written for all of these =)

Unfortunately the article seems to have disappeared but you might have better luck finding it than I did.

Is it really worth to pay $3,000 for a distro with an Intrusion Detection System like snort configured ?

Too bad they don't take snort logs.

Please let me quote from DShield's Linux Clients page:

"If you are using Snort, download dshield_snort.pl. or the snort portscan format client: snort_portscan.pl"

Ok, I am aware of the ideas put for in the article, so I will comment to your post rather than the outer realm. I disagree with the thing just based on my personal experience, not some initial responce of "nah, is isn't that way since I didn't think before I posted."

Am I saying I have a mathematical proof that what the article says is wrong: no. Do I think it could still be hapening: yes.

However, I wrote a packet sniffer for a class and posted it on my own little corner of the world (not on the school's site so don't think that helped me). Near as I can see no one links to me about it, yet I'm #13 on google's search if you look for "packet sniffer." I know I never paid a dime, and I don't see anyone linking to me (juding by server logs and the refer url) and I think I've reached a kinda high placement for just being a kid and posting a sniffer.

I come in ahead of snort and many other sniffers I played with in creating mine. So don't you think corporate america would snuff out a little sniffer like me?

In many municipalities it's illegal to posess 'burgulary tools' which condist of such things as vary large screw drivers, and other comonly available items. Generally the laws are envorced in cases where a specific selection of multiple burgulary tools are posessed by one person.

Does this mean that I can posess BackOrafice but if I posess backOrafice and an installation of Snort or something, then I'm a hacker rather than a System Administrator? Where would such a line be drawn?

--CTH

--

• Operating System: Although OpenBSD is generally regarded as the best Freenix in terms of security, GNU/Linux is under more active development, faster, more user friendly and supports far more software packages and types of hardware than OpenBSD (sorry Theo, much respect...). I, along with most of the other admins and users are more familiar with a GNU environment. The distribution we use is Debian. I chose Debian for several reasons: free (libre and gratis), strong package system and reliability. It hasn't let me down. I do prefer Slackware on my personal box, since the -current tree is more stable than Debian's unstable. However, Debian's package system is nicer and provides many things that Slackware lacks (I may abandon Slackware as soon as Debian supports XF4 and kernel 2.4 by default in stable). Debian also keeps up to date on security issues.
• Kernel: We now run a Linux 2.4 kernel. Although most security tools/patches are 2.2 only, the mature (READ: usable) ones have been ported to kernel 2.4. I'm confident that more will follow. 2.2 is dead. We have disabled modules entirely in our kernel to prevent hax0ring and to avoid using modules (does anyone else hate them?). We only have a few drivers enabled. Besides helping performance, this protects against hostile code injection into the kernel. It is possible for a clever coder to inject code into a non-modular kernel, but most rootkits use kernel modules. Not allowing kernel modules and using 2.4, prevents us from using some really cool security tools like LOMAC. However, I found that LOMAC did not play nicely with OpenWall's Secure Linux patch (or cron, or init or getty ...). When Lomac behaves nicer, it will be added (I'd also like to see it as a patch rather than a module). Currently, we are using the GetRewted.net patch which provides lots of security enhancements. We may be adding more secure kernel additions such as the NSA's Security Enhanced Linux. However, at this time, we feel that the current kernel security model is both secure and usable. If you have any neat kernel goodies we might like, tell us.
• Firewall: Note that we are NOT running any sort of real firewall. We feel that the extra kernel overhead of the firewall hurts performance and adds needless complexity to the server. Since we are NOT trusting local (ie: users with shell access) anyway, we feel that a firewall is basically useless since Linux's TCP/IP stack is already fault-tolerant, mature and robust. We augmented the TCP/IP stack with this shell script to limit our vulnerability to DoS attacks. Firewalling services should not be needed if your services are secure (run with minimal priviliges and SECURE by design and condiguration). Eventually we may drop an OpenBSD or Linux 2.4 firewall in front of the server as a measure for restricting local users ability to portscan, DoS and exploit remote hosts.
• Authentication / Login: Remote interactive sessions are only supported over ssh (and we run OpenSSH). Telnet is not allowed. Rhosts authentication is not allowed. I've looked at forcing people to use S/Keys, but it is a real pain in the ass on both ends. We are currently allowing FTP in. When I'm confident that all the users can get a good graphical scp/sftp client for their platform, I'll kill FTP. Since I'm not relying on trusting local users anyway, this is more a security concern for individual users. I'm considering locking some users who don't use their shells out of real shell access.
• Users: I only make accounts for people I know personally. I also monitor user login s and their activity using whowatch and process accounting. I'm suspicious of logins from weird hosts. I also use PAM to set resource limits.
• Monitoring: We watch out for network nastiness with Snort which is an AWESOME IDS. We monitor its logs and other system activity with Psionic's LogCheck. Occasionally, I'll audit the machines for weird ports using nmap and Nessus, both of which are REALLY nice. I'll also routinely verify system integrity using a combination of Tripwire and chkrootkit, on a system booted from a known CLEAN floppy containing the tools.