Slashdot is powered by your submissions, so send in your scoop


Forgot your password?
Check out the new SourceForge HTML5 internet speed test! No Flash necessary and runs on all devices. ×

Submission + - After 5 years of development, Sagan 1.0.0 is released. (saganio)

Beave writes: Sagan works very similar to Intrusion Detection System (IDS) engines like Snort and Suricata. However, rather than analyzing network packets, Sagan analyzes “logs” for malicious activity. Due to Sagan's multi-threaded nature, the analysis, detection, and correlation is done in 100% real time. Champ Clark III and his team have been working hard to develop and support Sagan since 2010 in efforts to release the best open source (GNU/GPLv2) log analysis engine in the space.

Submission + - Sagan 0.2.1 released (

Beave writes: "Sagan is an open source (GNU/GPLv2) high performance, real-time log analysis & correlation engine. It is written in C and uses a multi-threaded architecture to deliver high performance log & event analysis. The Sagan structure and Sagan rules work similarly to the Sourcefire “Snort” IDS engine. This was intentionally done to maintain compatibility with rule management software (oinkmaster/pulledpork/etc) and allows Sagan to correlate log events with your Snort IDS/IPS system. Since Sagan can write to Snort IDS/IPS databases via unified2/barnyard2 or direct SQL access, it is compatible with all Snort “consoles”. For example, Sagan is compatible with Snorby [], Sguil [] and the Prelude IDS framework! For more information, please visit the Sagan web site:"

Submission + - Building wireless IDS systems (with open source) (

Beave writes: Open source Intrusion Detection Systems (IDS) have been around in the 'wired' world for some time. What about research into 'wireless IDS' systems? This paper describes how to 'roll your own' wireless IDS system using nothing but open source software (Sagan, Kismet, Snort, Snorby, hostapd, etc). What's also unique about this article is that it focuses on building a wireless IDS system that'll report back to a single, unified console for threat analysis. Using the ideas presented in this article, you'll not only be able to detect wireless attacks (layer 2), but attacks at the network layer as well.

Submission + - Sagan:Correlating securiy events with system logs. (

Beave writes: Sagan uses a 'Snort like' engine and rule sets to watch system events to let you know when 'bad things' are happening. Unlike similar software, Sagan takes these 'bad things' and stores them into a Snort database for correlation with Snort events. For example, Snort alerts that a virus has entered the network. Sagan alerts that the virus was quarantined from the Windows event log. Both events are stored into the same Snort database for correlation. Now your Intrusion Detection/Prevention (IDS/IPS) system(s)' data and Sagan events are easily viewable with any Snort compatible management console. Since Sagan uses a 'Snort like' rule set, it is compatible with Snort back-end rule management software. Not a 'Snort' users? Sagan also supports multiple output formats that any network administrator will find useful. Sagan is an *nix based open source product released by Softwink, Inc.

Submission + - A 'Snort like' way of dealing with system logs.... (

Beave writes: Sagan' is a new, open source way of dealing with system logs. Rather than Sagan storing events into 'yet another database', it can store log events into a
Snort database. This means that your Intrusion Detection/Prevention (IDS/IPS) system(s) data and log data are in the same place. This enables a single console, like Snorby or BASE, to view not only your IDS/IPS data, but your log (syslog/snmp/etc) data as well!

Sagan will attempt correlate the data for you. Sagan also uses 'Snort like' rule sets, which means it is compatible with Snort rule set management software.
Not a Snort user? That's okay since Sagan supports multiple output formats that any network administrator will find useful

GNU is Not Unix

New LLVM Debugger Subproject Already Faster Than GDB 174

kthreadd writes "The LLVM project is now working on a debugger called LLDB that's already faster than GDB and could be a possible alternative in the future for C, C++, and Objective-C developers. With the ongoing success of Clang and other LLVM subprojects, are the days of GNU as the mainstream free and open development toolchain passé?" LLVM stands for Low Level Virtual Machine; Wikipedia as usual has a good explanation of the parent project.

Submission + - Adrian Lamo interview about US Military/Wikileaks (

Beave writes: Last week, Wired ran an article about how Adrian Lamo ("ex-hacker") exposed SPC Bradley Manning as the source of the infamous "Collateral Murder" videos. This is an interesting podcast where Adrian Lamo, in his own words, explains why he did it. Some really interesting questions come up.

Comment Old news... (Score 1) 139

I'll be interested to read the details, but 2 out of the 3 things have been known for quite some time. The 'caller ID' spoofing trick has been known for _years_. The concept they are touting is known as "back spoofing". I've had friends doing this for a long time. However - there's one problem. No call cell phone associate caller ID with a phone. Yes, back spoofing works great - with _land lines_, but it's always that accurate with cell phones. So, "finding" the cell number that way isn't very reliable. If I have a boost mobile number, bought in cash, under a fake name you'll be out of luck. That is, the caller ID name (CNAM) won't be associated with it in the first place _and_ I gave all fake information to begin with. About the voice mail. Not a big deal. This was reported 6 or more years ago. The idea is that you spoof your targets number with their cell number. The Telco side "sees" this as a call from the cell and drops you into their voicemail system. Some telco's have fixed this, other haven't. It's been a known flaw for years and years. You don't use CID for authentication exactly for this reason. If possible, PIN protect your voicemail will stop these types of attacks (if possible). Anyways, the article is interesting, but several factors must fall into place or this attack won't work.

Submission + - Telco SMTP-SMS/MMS gateways lack TLS/encryption. (

Beave writes: Cell phone companies have provided SMTP (e-mail) to SMS/MMS gateways for quite some time. SMS and MMS is being used more and more for "secure" communications. For example, your bank might SMS you your checking account balance. These applications use more advanced, and more costly, "corporate" level SMS/MMS appliances/systems or so we hope. Where does that leave a developer who doesn't have that sort of budget, but still needs a "secure" (as it can be) SMS/MMS capable delivery system? Do some cell phone SMTP gateways to SMS/MMS support TLS/SSL (encryption) at the SMTP (e-mail) level? If so, which carriers? This article looks at that and a few other interesting issues in delivering "secure" content via SMS/MMS to cell phones.

Slashdot Top Deals

An inclined plane is a slope up. -- Willard Espy, "An Almanac of Words at Play"