Slashdot Mirror

Three years ago, Apple introduced 3D Touch for the iPhone 6s and 6s Plus, a pressure-sensitive feature that uses capacitive sensors integrated into the smartphone's display to sense three degrees of pressure in a user's touch and respond differently based on the amount of pressure exerted. It's a neat idea as it has allowed users to interact with the user interface in a completely new way. Now, with the release of the new iPhone XR, Apple seems to be on the way to phasing it out. The Verge reports: While both the new iPhone XS and XS Max include 3D Touch, Apple has chosen not to include the feature on the iPhone XR. Yes, that phone is cheaper, and Apple had to strip out some features, but 3D Touch has been included on iPhones in that price range since it was introduced not too long ago, so this feels less like necessary cost savings and more like planned omission. There have always been a few core problems with 3D Touch. For one, its use often amounted to the right click of a mouse, which is funny coming from the company that famously refused to put a dedicated right button on its mice or trackpads. And selecting from those right click options was rarely faster or a substantially more useful way of getting something done than just tapping the button and manually navigating to where you needed to go. People also didn't know the feature was there. The iPhone did little to train users on 3D Touch. And even the people who knew it was there had no way to tell which icons supported it without just 3D pressing everything to see what happened.

Apple isn't entirely removing the concept of 3D Touch from the iPhone XR. Instead, the phone will include something Apple is calling Haptic Touch, which will make a click when you activate a button's secondary feature by pressing and holding it. But that replacement underscores just how useless 3D Touch has really become: it's not more than a very, very fancy long press. That's something phones have always been capable of. And despite the name, I've found long press features to be faster and easier to use than their 3D Touch equivalent. Instagram, for instance, lets you preview photos with a 3D Touch on the iPhone or a long press on Android. I find the Android version to be simpler and quicker. Here's what Apple's marketing leader, Phil Schiller, had to say about the feature back in 2015 when it was first introduced: "'Engineering-wise, the hardware to build a display that does what [3D Touch] does is unbelievably hard,' says Schiller. 'And we're going to waste a whole year of engineering -- really, two -- at a tremendous amount of cost and investment in manufacturing if it doesn't do something that [people] are going to use. If it's just a demo feature and a month later nobody is really using it, this is a huge waste of engineering talent.'"

An anonymous reader writes: A test of seven OEM laptops running Windows has shown consistent privacy and security issues, including an interesting revelation that the McAfee Antivirus running on six of them is using web beacons to serve ads and possibly even track users online. The seven laptops – Lenovo Flex 3, Lenovo G50-80 (UK version), HP Envy, HP Stream x360 (Microsoft Signature Edition), HP Stream (UK version), Acer Aspire F15 (UK version), and Dell Inspiron 14 (Canada version) – have been tested by the security research team of Duo Security by simply sniffing the traffic sent from and to them once they have been taken out of the box, plugged in, and connected to a network.

Shalendra Chhabra writes "Jonathan Zdziarski has been fighting spam since before the first MIT spam conference in 2003, and has now released a full-on technical book, Ending Spam, on spam filtering. Ending Spam covers how the current and near-future crop of heuristic and statistical filters actually work under the hood, and how you can most effectively use such filters to protect your inbox." Read on for the rest of Chhabra's review. Ending Spam: Bayesian Content Filtering and the Art of Statistical Language Classification author Jonathan A. Zdziarski pages 312 publisher No Starch Press rating 8 reviewer Shalendra Chhabra ISBN 1593270526 summary Very Good Book Covering Statistical Models and Techniques Implemented in Current Spam Filters

Spam (unsolicited commercial email) and phishing (fraudulent emails) are causing losses of billions of dollars to businesses. Many initiatives are currently underway for fighting this challenge. On the legal front, a Virginia court recently sentenced a prolific spammer, Jeremy Jaynes, to nine years in prison, and a Nigerian court sentenced a woman to two and a half years for phishing. Michigan and Utah have both passed laws creating "do-not-contact" registries in July/August 2005, covering e-mail addresses, instant messaging addresses and telephone numbers. Technical initiatives to fight spam include server- or client-side spam filtering, using Lists (Blacklists, Whitelists, Greylists), Email Authentication Standards (IIM, DK, DKIM, SPF, SenderID), and emerging sender reputation and accreditation services.

Ending Spam is the first book explaining the fine details of the theoretical models and machine-learning algorithms implemented in these filters. The book is divided into three parts: introduction to spam filtering, fundamentals of statistical filtering, and advanced concepts of statistical filtering.

The first section of the book discusses the history of spam, spam kings, different approaches for fighting spam such as blacklisting, whitelisting, heuristic filtering, challenge response, throttling, collaborative filtering, Authenticated SMTP, Sender Policy Framework and SenderID, spammer fingerprinting, etc. However, the author omitted any mention of locally-sensitive hash functions (such as Nilsimsa Hash) to counter spammers' random insertion of words, the use of CAPTCHA (Completely Automated Public Turing Test to Tell Computers and Humans Apart), Greylisting, Identified Internet Mail, and Domain Keys (now Domain Keys Identified Mail).

In the next chapter, the author clearly explains various components of a Language Classifier Pipeline, including the Historical Dataset (aka wordlist, database, dictionary, filter memory), Tokenizer, and the Analysis Engine with its feedback loop. However, the process flow of a language classifier could have been more generalized, e.g. incorporating an initial text-to-text transformer. This chapter also covers the advantages and disadvantages of various training modes for filters, such as Train Everything (TEFT), Train-on-Error (TOE), and Train Until No Errors (TUNE). This part concludes with the description of Paul Graham's famous spam-filtering technique using Bayesian classification (as described in "A Plan for Spam"), Gary Robinson's Geometric Mean Test, Fisher-Robinsons Inverse Chi Square (including the source code for the inversion function), and some other tricks for optimizing spam- filtering accuracy.

The second part of this book deals with the fundamentals of statistical filtering. The author explains HTML and Base64 encoding, followed by a detailed description of tokenization techniques (e.g. Sparse Binary Polynomial Hashing). Then there's a discussion of the various tricks that spammers use for penetrating filters. Although these tactics are mentioned in John Graham-Cumming's "Spammers Compendium," Jonathan has very elegantly explained why some tricks work for spammers and some don't. This part concludes by addressing some of the resource, storage and scaling concerns raised by the large number of features generated from tokenization techniques.

The third part of this book deals with advanced concepts of statistical filtering. This includes the testing criteria for measuring accuracy of an email filter, and some advanced tokenization concepts, e.g. chained tokens (taking word-pairs and phrases into account, instead of individual words) generated using a sliding 5-byte window as mentioned in Sparse Binary Polynomial Hashing. The next chapter describes the Markovian Model implemented in the CRM114 Discriminator, but the author fails to describe different weighting schemes for features implemented in the Markovian-based version of CRM114. The author then describes the Bayesian Noise Reduction Technique for purging "out of context" data from the mail text. This chapter concludes with a very nice summary of collaborative algorithms and techniques, such as Message Innoculation, Streamlined Blackhole List, Fingerprinting, Automatic Whitelisting, URL Blacklisting, and Honeypot email addresses for snaring spammers' address harvesting bots.

The most interesting part of this book is the appendix, where the author presents interviews with John Graham-Cumming of POPFile, Brian Burton of SpamProbe, Marty Lamb of TarProxy, Bill Yerazunis of CRM114 Discriminator, and Jonathan Zdziarski of DSPAM (himself). I loved this section.

The salient points of the book: it's very easy to read; each chapter begins with a very thought-provoking introduction, and concludes with a crisp "final thoughts" section. The number of technical errors are very few in this print, and the illustrations are of good quality. Since the book is geared more toward the Bayesian and statistical generation of spam filters, the absence of certain spam-busting technologies is acceptable. However, a noticeable omission is the lack of discussion about measuring spam-filter accuracy, and what impact this has on setting filtration thresholds. A section on the economics of tradeoffs, and the use of a Receiver Operating Characteristic curve (ROC) would have been very helpful.

Overall, by putting together Ending Spam, Jonathan Zdziarski has made another significant contribution (after DSPAM) to the anti-spam community. Whether you are a system administrator, anti-spam researcher, engineer or a newbie interested in fighting spam, this book is a great reference.

William S Yerazunis and Richard Jowsey also contributed to this review. Shalendra Chhabra is a Graduate Student in Department of Computer Science and Engineering at University of California, Riverside. He is on the development team of CRM114 Discriminator and has presented his work at MIT Spam Conference 2005, Cisco Systems, and Stanford University. You can purchase Ending Spam: Bayesian Content Filtering and the Art of Statistical Language Classification from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

pallmall1 writes "The Inquirer has an official statement from Intel claiming the Computerworld Today Australia story from May 27th was incorrect, and the Pentium D and the 945 chipsets do not have unannounced DRM technology embedded in them. The statement says Intel products support or will support several copy protection schemes such as Macrovision, DTCP-IP, COPP, HDCP, CGMS-A, and others. The statement concludes: 'While Intel continues to work with the industry to support other content protection technologies, we have not added any unannounced DRM technologies in either the Pentium D processor or the Intel 945 Express Chipset family.' The Intel Chip with DRM story has been previously reported on Slashdot. Update: 06/05 20:12 GMT by Z : Fixed the Macrovision link.

pallmall1 writes "The Inquirer has an official statement from Intel claiming the Computerworld Today Australia story from May 27th was incorrect, and the Pentium D and the 945 chipsets do not have unannounced DRM technology embedded in them. The statement says Intel products support or will support several copy protection schemes such as Macrovision, DTCP-IP, COPP, HDCP, CGMS-A, and others. The statement concludes: 'While Intel continues to work with the industry to support other content protection technologies, we have not added any unannounced DRM technologies in either the Pentium D processor or the Intel 945 Express Chipset family.' The Intel Chip with DRM story has been previously reported on Slashdot. Update: 06/05 20:12 GMT by Z : Fixed the Macrovision link.

dsginter asks: "This year's spring Networld+Interop has ended with little fanfare. However, I noticed that a small nugget slipped between the cracks - HD video-conferencing. Two different manufacturers demonstrated such products which means that we'll probably have interoperability soon. After seeing the massive pricing estimates for such products, I couldn't help but think that I should try my hand at my own HD product (a Mac Mini, some H.264, a pinch of AAC and the glue that is H.323 or SIP). However, I'm missing one piece - a small, 720P camera for video acquisition. I've scoured Google but can't come up with anything suitable. Is there an answer? HD video-conferencing is an important step in complete communication between remote parties. While there will be those that joke about the possibilities, it is important to remember that the bulk of business travel still happens for the sake of face-to-face communication. HD video-conferencing might prove to be a panacea."

Corey Nachreiner writes "Until recently, I considered myself a Google power-user; so much so that I often call Google my "second brain." Whenever I stumble upon a computing dilemma I can't solve, I submit an advanced query to my second brain, Google, and let it supply the answers. That's why I was So There when Johnny Long released his recent book, Google Hacking for Penetration Testers . I heard Johnny's lively, light-hearted presentation to a packed house at the BlackHat Briefings last summer in Las Vegas. It was the hit of the show, but in one hour he could only present a few of his startling findings about Google hacking. After reading Johnny's book, I've learned a ton more and realized I wasn't quite as Google-savvy as I thought. As with my real brain, I've only been using about ten percent of my Google-brain's capacity." Read on for the rest of Nachreiner's review. Google Hacking for Penetration Testers author Johnny Long pages 448 publisher Syngress rating 8 reviewer Corey Nachreiner ISBN 1931836361 summary Google's dark and dork sides exposed; despite the title, useful for everyone who'd like to get the most out of google.

According to its cover, Johnny Long's book focuses primarily on revealing the "Dark Side" of Google -- a promise it delivers in spades. But I can also heartily recommend Google Hacking to newbies who simply want to learn how to harness Google's full potential.

The first few chapters of the book walk you through Google's interfaces and features, then introduce you to Google's advanced operators and techniques you can use to refine your Google searches. Instead of submitting basic searches that leave you arduously parsing hundreds of results for your desired answer, you quickly learn to submit powerful queries that almost instantly yield the results you intend. Even as an experienced Google user, I learned a lot from Google Hacking's early chapters. For Google neophytes, this alone makes the book worth its price.

However, we all know Slashdotters really want this book in order to learn how hackers misuse Google. Well, you won't be disappointed. As soon as Long has taught you to submit advanced queries, he wastes no time in showing you the techniques l33t Google hax0rs use to exploit the search engine's power. For example, did you know you can use Google as a free proxy server? By submitting a specially-crafted, English-to-English translation query, you can capitalize on Google's translation service to anonymously submit all your Web requests. This simple hack just scratches the surface of Google's malicious potential.

Most Web surfers don't realize the sheer amount of extremely sensitive information available for the harvesting on the Internet. In that sense, Google Hacking is eye-popping. Do you want to find misconfigured Web servers that publicly list their directory contents? A quick Google search does the trick. Or, suppose you found some new exploit code that only works against a particular version of IIS 5.0. Submit a quick Google query for a helpful list of possible targets. Do you want to harvest user logins, passwords (for example, mySQL passwords in a connect.inc file), credit card numbers, social security numbers or any other potentially damaging tidbit that Web users and administrators accidentally leak onto the Internet? Google Hacking shows you how, with highly refined searches gleaned from the community contributing to the Google Hacking database (GHDB) found on Long's Web site.

While Long's book discloses these and many other potentially malicious Google searching techniques, it does so responsibly, with the goal of prevention in mind. Only the less damaging search strings are fully revealed. Long saves the juicier (read: more dangerous) hacks for your own discovery. Long even obfuscates the sensitive results of the more damaging search strings in order to protect the innocent incompetents he refers to as "googledorks." After showing you how hackers subvert Google to their malicious intent, Long dedicates a chapter to how Web administrators can configure their Web servers securely in order to prevent sensitive data from making it into a Google Hacker's clutches.

Though I've gushed about the book so far, I will quibble with its inconsistent tone. Some of its chapters target readers having different levels of technical understanding. While the book starts out in a voice easy enough for even the most novice user to understand, some of the later chapters, on topics such as document grinding, database digging, and query automation, jump drastically and use language and techniques that only programmers or Unix power-users would understand. In addition, the humor that made Johnny's live presentation so memorable shows up in his book, but in scant supply; frankly, more jokes would be welcome.

But these negatives are mere nits. Whether you're a penetration tester wanting to exploit Google, a Web administrator wanting to protect yourself from information leaks, or even a newbie wanting to harness Google's full potential, Google Hacking for Penetration Testers makes an excellent resource. If you, too, use Google as a second brain, pick up Johnny Long's book and learn how to exploit this powerful search engine to its full capacity.

Corey Nachreiner, Network Security Analyst for WatchGuard's LiveSecurity Service, writes about network security on the free RSS news feed, WatchGuard Wire (browsable version, RSS feed.) You can purchase Google Hacking for Penetration Testers from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

direktorjb writes "I have an urgent need to connect about 6 users in Baghdad and another 6 in Kuwait to an AS400 app (5250 emulation) back in the states. Is anyone aware of a decent ISP in those regions? If I cant get a reliable ISP (and therefore a solid VPN connection), what are my other choices? Should I check out VSAT?"

urgent asks: "In March of 2002, Ask Slashdot ran this article, wherein advice on 'hardware to digitize the VGA output of a PC' was sought. Most of the responses seemed to assume that remote administration of PC's/servers was the end goal. If you've got control of the software and/or hardware, it's pretty clear there are easier solutions for that. On the other had, there are many legacy and embedded systems where it would be nice to monitor and record display output. For instance, integrating old computerized factory equipment into a SCADA system, or recording old embedded maritime and medical displays (hint: jobs). My dream hardware would be a dongle that connected to a VGA out and could be polled over ethernet or CAN."

Barkmullz asks: "Working closesly with a public safety department in my town, we have been thinking of implementing a mobile wireless network. This would, theoretically, allow public safety officers to send and received data (such as CAD) while in a moving or stationary vehicle. One of the requirements is to be able to move across multiple wireless networks. There are several vendors that offer such technology, like the Cisco 3200 Mobile Access Router. Even though we have a fairly good idea of what needs to be done, we are experiencing difficulty in finding good examples of other implementations of this kind. Sure, there is Seal Beach, Buffalo Grove, Lufthansa and others, but they are more sales-pitches than in-depth white papers. Security is, naturally, of great concern to us. However, due to funding constraints we are planning to use the publicly available 802.11x for the most part, use EAP or Cisco's LEAP and a RADIUS server for authentication, along with TKIP for encryption (aka WPA). Has anyone dealt with a wireless network of this type? If so what were some of your challenges and what are your recommendations for implementation?"

Barkmullz asks: "Working closesly with a public safety department in my town, we have been thinking of implementing a mobile wireless network. This would, theoretically, allow public safety officers to send and received data (such as CAD) while in a moving or stationary vehicle. One of the requirements is to be able to move across multiple wireless networks. There are several vendors that offer such technology, like the Cisco 3200 Mobile Access Router. Even though we have a fairly good idea of what needs to be done, we are experiencing difficulty in finding good examples of other implementations of this kind. Sure, there is Seal Beach, Buffalo Grove, Lufthansa and others, but they are more sales-pitches than in-depth white papers. Security is, naturally, of great concern to us. However, due to funding constraints we are planning to use the publicly available 802.11x for the most part, use EAP or Cisco's LEAP and a RADIUS server for authentication, along with TKIP for encryption (aka WPA). Has anyone dealt with a wireless network of this type? If so what were some of your challenges and what are your recommendations for implementation?"

Barkmullz asks: "Working closesly with a public safety department in my town, we have been thinking of implementing a mobile wireless network. This would, theoretically, allow public safety officers to send and received data (such as CAD) while in a moving or stationary vehicle. One of the requirements is to be able to move across multiple wireless networks. There are several vendors that offer such technology, like the Cisco 3200 Mobile Access Router. Even though we have a fairly good idea of what needs to be done, we are experiencing difficulty in finding good examples of other implementations of this kind. Sure, there is Seal Beach, Buffalo Grove, Lufthansa and others, but they are more sales-pitches than in-depth white papers. Security is, naturally, of great concern to us. However, due to funding constraints we are planning to use the publicly available 802.11x for the most part, use EAP or Cisco's LEAP and a RADIUS server for authentication, along with TKIP for encryption (aka WPA). Has anyone dealt with a wireless network of this type? If so what were some of your challenges and what are your recommendations for implementation?"

Barkmullz asks: "Working closesly with a public safety department in my town, we have been thinking of implementing a mobile wireless network. This would, theoretically, allow public safety officers to send and received data (such as CAD) while in a moving or stationary vehicle. One of the requirements is to be able to move across multiple wireless networks. There are several vendors that offer such technology, like the Cisco 3200 Mobile Access Router. Even though we have a fairly good idea of what needs to be done, we are experiencing difficulty in finding good examples of other implementations of this kind. Sure, there is Seal Beach, Buffalo Grove, Lufthansa and others, but they are more sales-pitches than in-depth white papers. Security is, naturally, of great concern to us. However, due to funding constraints we are planning to use the publicly available 802.11x for the most part, use EAP or Cisco's LEAP and a RADIUS server for authentication, along with TKIP for encryption (aka WPA). Has anyone dealt with a wireless network of this type? If so what were some of your challenges and what are your recommendations for implementation?"

penciling_in writes "John Patrick, former vice president of Internet technology at IBM, says 'ENUM is a really big deal'. Here is what he has to say on CircleID about this: 'Basically, ENUM is a protocol that will make it possible to converge the Public Switched Telephone Network (PSTN) and the Internet. In other words, a telephone number can get you to a Web service -- telephone number in, URL out. The idea can be extremely useful when you consider that most telephones are limited to twelve keys on a keypad. Every try to enter your alphanumeric login ID and password to a web site on a cell phone or Personal Digital Assistant? It is next to impossible! The biggest impact of ENUM will probably be for Voice Over IP (VoIP). In fact, it could be the tipping point.'"

MFS! writes "Long-time C|Net reporter and Politech operator Declan McCullagh has been contacted by the FBI, according to his most recent article. The FBI requests that he retain all records regarding his talks with Adrian Lamo. The problem? The FBI's letter was sent under the auspices of a law which applies only to internet service providers. Says Declan, "Perhaps I'd be immune from the FBI's demands if I used an Underwood No. 5 typewriter instead." Does writing online now qualify one as an ISP?"

ninejaguar asks: "Slashdot did an article on an Open Source product called Prevayler, which could theoretically resolve all the problems associated with OO's rough courtship with Relational databases. Slashdot covered Prevayler when it was still 1.x. Despite fear, doubt, and memory concerns, it has reached 2.0 alpha. Is anyone currently using this non-database solution in production? If so, has it sped development because of the lack of OO-to-RDBMS complexity? Was there a significant learning curve to speak of? The LGPL'd product could be incorporated into proprietary commercial software, and few might know about it. Is anyone considering using it in a transactional environment where speed is the paramount need? And, are there any objections to using Prevayler that haven't been answered at the Prevayler wiki? Would those who use MySQL find Prevayler to be a better solution because it's tiny (less than 100kb), 3000 times faster and is inherently ACID compliant?" Update: 09/24 19:25 GMT by C :Quite a few broken links, now fixed.

"We've used relational databases for years despite incompatibilities in SQL implementation. Accessing them from an OOP paradigm has been so tedious, that Object-Relational mapping technologies have sprouted all over the Open Source landscape. Some competing examples and models are Hibernate, OJB, TJDO, XORM, and Castor; which in turn have supporting frameworks such as Spring and SQLExecutor. Because SQL is the dominant form of interfacing with the data in an RDBMS, there's now a specification to offer it a friendlier OO face.

Most of the above, including the SQL-variants, arguably appear to add yet another layer of complexity (even if only at the integration level) where they should be taking complexity away. These solutions are put together by some very smart people, but it's inescapable to get that feeling someone is missing the forest (simple answer) because all the trees (incompatible models) are in the way. If there are so many after-the-fact solutions attempting to simplify relational database access and manipulation from OO, isn't it reasonable to think that there is something generally wrong with trying to cobble-together two disparate concepts with what are essentially high-caliber hacks? Is Prevayler a better way?"

ninejaguar asks: "Slashdot did an article on an Open Source product called Prevayler, which could theoretically resolve all the problems associated with OO's rough courtship with Relational databases. Slashdot covered Prevayler when it was still 1.x. Despite fear, doubt, and memory concerns, it has reached 2.0 alpha. Is anyone currently using this non-database solution in production? If so, has it sped development because of the lack of OO-to-RDBMS complexity? Was there a significant learning curve to speak of? The LGPL'd product could be incorporated into proprietary commercial software, and few might know about it. Is anyone considering using it in a transactional environment where speed is the paramount need? And, are there any objections to using Prevayler that haven't been answered at the Prevayler wiki? Would those who use MySQL find Prevayler to be a better solution because it's tiny (less than 100kb), 3000 times faster and is inherently ACID compliant?" Update: 09/24 19:25 GMT by C :Quite a few broken links, now fixed.

"We've used relational databases for years despite incompatibilities in SQL implementation. Accessing them from an OOP paradigm has been so tedious, that Object-Relational mapping technologies have sprouted all over the Open Source landscape. Some competing examples and models are Hibernate, OJB, TJDO, XORM, and Castor; which in turn have supporting frameworks such as Spring and SQLExecutor. Because SQL is the dominant form of interfacing with the data in an RDBMS, there's now a specification to offer it a friendlier OO face.

Most of the above, including the SQL-variants, arguably appear to add yet another layer of complexity (even if only at the integration level) where they should be taking complexity away. These solutions are put together by some very smart people, but it's inescapable to get that feeling someone is missing the forest (simple answer) because all the trees (incompatible models) are in the way. If there are so many after-the-fact solutions attempting to simplify relational database access and manipulation from OO, isn't it reasonable to think that there is something generally wrong with trying to cobble-together two disparate concepts with what are essentially high-caliber hacks? Is Prevayler a better way?"

Eric Stats writes "Working as a Network Engineer for web-hosting company that prides itself on uptime and network availability, and moonlighting as a part-time Linux administrator, my managers and clients are starting to expect a level of information security knowledge from me. I decided that if I wanted to take my career to the next level, I needed to develop some security-specific skills. I heard a lot about the open source Intrusion Detection System (IDS), Snort from friends and co-workers (mostly that it was a pain to get running, and an even bigger pain to understand what it was doing)." To get past those frustrations, Eric looked at two more books on Snort (and compares them to the already-reviewed Intrusion Detection with Snort ); read on below for his take on what each offers. Intrusion Detection with SNORT: Advanced IDS Techniques Using SNORT, Apache, MySQL, PHP, and ACID; Intrusion Detection with Snort; Snort 2.0 Intrusion Detection author (See each) pages (See each) publisher (See each) rating (See each) reviewer Eric Stats ISBN (See each) summary (See each)

I ran Snort at home for a while, using the online docs, but I could never get a handle on which output plugin to use (When to log? When to alert?), how to email alerts to myself (I later found out Snort doesn't natively do this), and how to create signatures from packet captures (no online docs at all for this). When I did get The Pig running, it filled up my log directory with thousands of small alert files, which ended up being in tcpdump format. This frustrated the hell out of me, so I decided I needed to find a good book on Snort, as the online docs simply did not describe how to use Snort from start to finish.

In the past few months, an assortment of books have come out on Snort. Because it has begun to eclipse closed-source, multimillion dollar IDSes in terms of raw performance and features, much attention is currently focused on Snort. Naturally, when an open source project achieves this level of notoriety, publishers, venture capitalists, and corporations want to get in on the game. The flood of Snort books is a testament to this, but it doesn't mean they were all created equally. This book review covers the three books on Snort currently available (we will see another two Snort books later this winter). It covers what is good about them, what is bad, and who the target audience is for each. If you are looking to learn intrusion detection the open source way, or simply do not have a million-dollar IT security budget, these books are a good starting point.

Each of these three books serves a different purpose and consequently is appropriate for a different reader. In summary, Rafeeq Rehman's Intrusion Detection with Snort: Advanced IDS Techniques Using SNORT, Apache, MySQL, PHP, and ACID presents a concise, quick-start guidebook to getting Snort up and running fast. He doesn't delve into the details of Snort, and this book makes a perfect choice for a reader who wants to get The Pig up and running quickly and move on to something else.

The whole gaggle of authors that put together Snort 2.0 Intrusion Detection created a much-needed user manual for Snort. This book makes for good desktop reference, but assumes you understand the core concepts of intrusion detection, or have significant field experience with Snort. It is also somewhat convoluted to read; I suppose it's inevitable when you have 12 authors working on a single book, it is going to come out somewhat disjointed and jumbled. If I hadn't read the other two books first, I doubt I would have been able to piece together what this book is talking about in places. (Such as referring to Barnyard logs in one chapter and "unified binary format" in another; how is the reader going to know they are the same?)

Lastly, Jack Koziol's Intrusion Detection with Snort is a guidebook for using Snort in the real world, either on small networks or in large corporate settings. Like any security tool, Snort is only as effective as its operator. Snort can do an enormous number of things, but if you don't understand the "how and why" you aren't going to be able to apply your knowledge in unexpected, different, or new situations. Koziol's book bridges the gap and teaches you the nitty-gritty Snort details not found in online docs, as well as how to apply your newfound IDS knowledge in practice. This book does lack in terms of screenshots and diagrams, which can be frustrating at points. Instead of a paragraph of text, a simple diagram would have sufficed.

Intrusion Detection with SNORT: Advanced IDS Techniques Using SNORT, Apache, MySQL, PHP, and ACID author Rafeeq Rehman pages 288 publisher Prentice Hall rating 7/10 ISBN 0131407333

I first picked up Rehman's Intrusion Detection with Snort: Advanced IDS Techniques Using SNORT, Apache, MySQL, PHP, and ACID. Rehman's book is also a member of the Bruce Perens Open Source Series. All of the books in his series are published under the OPL. Overall, Rehman's book served as a good intro to Snort. I followed the examples, used some of the custom startup and log-rotation scripts, and got Snort working for the first time. I also learned of ACID, which is a PHP-based GUI for Snort, put out by Carnegie Mellon's CERT/CC. It makes managing alerts from Snort much less time-intensive. It was an exciting experience, but the book left me in the dark on a number of concepts that I knew I needed to learn. I still didn't understand what I was getting out of Snort; I had so many alerts I couldn't "tune out the noise." I didn't know when to use log or alert plugins, so I just turned on both for safety's sake. I also found that Snort was dropping packets (meaning it wasn't able to keep up with the traffic load going to my webservers hosted at home), but didn't find any way to fix this problem. This setup was fine for experimenting at home, but I didn't feel I would be able to use Snort in a mission-critical corporate setting yet.

Intrusion Detection with Snort author Jack Koziol pages 400 publisher SAMS Publishing rating 9/10 ISBN 157870281X

I thumbed through Jack Koziol's Intrusion Detection with Snort at the bookstore, and it seemed to have some more detailed descriptions of using Snort. It also had a lot of the planning, deployment, and maintenance activities you never think of until you are faced with one at 2 a.m. (such as how to upgrade Snort in an organized manner after a vicious integer overflow exploit is released for a core Snort component). It is also the most popular Snort book, so I figured I would buy it. When I took it home, I learned where to place Snort on a network, and what advantages and disadvantages there are to different IDS sensor placement strategies, something I had never considered.

Koziol's book also had the technical detail I was in desperate need of. I learned how to use Barnyard to spool alerts, which keeps Snort from dropping packets. I got to write my own attack signatures from scratch by using Ethereal packet captures in an controlled lab environment. I created a targeted ruleset; it enables specific attack signatures based on what I actually have running on my network, simply using nmap and some complicated perl scripts. The targeted ruleset went a long way to reducing false alerts, and is now a selling product from the Snort commercial vendor, Sourcefire. I finally got email alerts working using syslog-ng with Snort. The book ends with some more advanced content, namely using Snort as an Intrusion Prevention device. You can setup Snort to block packets that match a signature, using Inline Snort, or you can have Snort reconfigure routers and firewalls to block offending IP addresses, using SnortSam. I've experimented with Inline Snort as part of a honeypot, but, as the author points out, this is not yet production-safe, as it can easily be used by attackers to disrupt network availability.

Snort 2.0 Intrusion Detection authors Jay Beale, Anne Carasik, Aidan Carty, Scott Dentler, Adam M. Doxtater, Wally Eaton, Jeremy Faircloth, James C. Foster, Vitaly Osipov, Jeffrey Posluns, Ryan Russell, Brian Caswell pages 485 publisher Syngress rating 4/10 ISBN 1931836744

The final Snort book in this review is Snort 2.0 Intrusion Detection. This book has a lot of the screenshots and figures that the Koziol and Rehman books leaves out. It also contains a lot of useful diagrams, about one for every other page, and a CD-ROM with all of the Snort source and a pdf version of the book. This book, and the Koziol book, cover Snort version 2.0, which isn't all that much different from version 1.9 covered in the Rehman book. Still, it is nice to have the most up-to-date documentation, but it doesn't make the Rehman book any less effective. This book has the most reference material in it, over 500 pages' worth, and it has very organized user manual-like descriptions of important Snort components (preprocessors, output plugins, and rules). Keep in mind that this book was created more as a user manual rather than an implementer's guide. You aren't going to see planning, deployment, and maintenance activities as well as technical deployment examples, as in the Koziol book. And, you aren't going to find a concise quick-start guide such as the Rehman book.

In summary, you aren't going to find anything in this book that isn't in the other two. What you will find is lengthy descriptions, and a lot more screenshots. As stated before, Snort 2.0 Intrusion Detection was written by 12 different people (one of them a Sourcefire employee and Snort.org website maintainer, Brian Caswell). This is obviously done by the publisher to get the book out as fast as possible, which is important for technology book publishers as books are outdated quickly, but has the end result of a disjointed book that contradicts itself in many areas. An example: one author stresses how deadly important it is for us to only use the latest Snort version, while another tells us to use the CDROM that comes with the book, which contains an outdated version of Snort.

You can clearly tell a different authors worked on different chapters, as the style and format change frequently. You can also tell that the authors didn't talk to each other much, as you will find one author referring to something in one chapter (unified binary format) that he expected to have been explained in a previous chapter. In print, the concept was not explained until later, which can be really frustrating if you are not a Snort pro. Additionally, there are enough grammatical errors in the book to be distracting, and, much like a vendor-provided user manual, the chapters don't logically flow from one to the next. If you do purchase this book, this slashdotter would recommend it as a supplement to either the Rehman or Koziol book.

You can purchase Intrusion Detection with SNORT: Advanced IDS Techniques Using SNORT, Apache, MySQL, PHP, and ACID , Intrusion Detection with Snort , and Snort 2.0 Intrusion Detection from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

On Saturday night, Virgil and Acidus, two young security researchers, were scheduled to give a talk at Interz0ne II on security flaws they'd found in a popular ID card system for universities. It's run by Blackboard, formerly by AT&T, and you may know it as OneCard, CampusWide, or BuzzCard. On Saturday, instead of the talk, attendees got to hear an Interz0ne official read the Cease and Desist letter sent by corporate lawyers. The DMCA, among other federal laws including the Economic Espionage Act, were given as the reasons for shutting down the talk (but -- update -- see the P.P.S below). I spoke with Virgil this morning.

Virgil was there two years ago when Dmitri Sklyarov was arrested and led away in handcuffs at Def Con 9. He's not in handcuffs now, but in speaking to me, he had to stop and think about everything he said, and every third answer was "I really shouldn't talk about that."

The DMCA is largely to thank for that. Section 1201 states that no one "shall circumvent a technological measure that effectively controls access to a work," and that no one "shall... offer to the public... any technology" to do so. Blackboard Inc., whose card system is called the Blackboard Transaction System and known to end users under various names, uses a network of card readers and a central server, and they communicate over RS-485 and Internet Protocol -- using, or so they apparently claim, measures that effectively control access.

For the record, none of what I learned about the Blackboard technology was from him or Acidus after the restraining order was sent. I spoke to other people, who have not been served with a restraining order. Google has a less enlightening mirror of the slide titles from this weekend's PowerPoint presentation and a more enlightening mirror of Acidus's "CampusWide FAQ" from last July. And, most enlightening of all, this mirror has an updated version with details on what they figured out how to do and what their talk was going to be about (click "CampusWide" for the text description, the PowerPoint slides, and Acidus's timeline of the last year).

At many schools, Blackboard's system is the ID: you swipe your card for your meal plan at the cafeteria, to get into your dorm, maybe even to get your final exam.

A swipe at a vending machine will get you a soda -- a money transaction from your campus debit account. When you use a swipe to do laundry and make copies, money has to be involved. Blackboard even notes that they can set up a merchant network on- and off-campus: "a cashless, safe, and secure way to transact on and around campus while offering parents the assurance that their funds will be spent within a university-approved network." (Emphasis added. Maybe readers who go to schools that use such a system can expand on how that system is used.)

The kicker, of course, is that this network is not very secure, or at least Blackboard doesn't think it's as secure as... well, as lawyers. One anonymous Slashdot submitter wrote that: "The authentication system is so weak that [Virgil and Acidus] have been able to create a drop in replacement for the CampusWide network debit card readers used on coke machines on campus."

Virgil couldn't provide me any details about what he had learned about the system. Based on the mirrors, it looks like a man-in-the-middle replay attack -- which is a pretty simple attack, repeating messages sniffed over the RS-485 protocol, or even over IP -- can have effects like convincing a Coke machine to dispense free product. Or, it's claimed, the attacker can create a temporary card, with no name attached, and free money in its account. Hmmmmm.

Or, more ominously, someone else's identification might be sniffed, and then replayed from a security terminal. If a thief gained entrance to a building by sending the message "open the door, my name is John Doe," the real John Doe might be sorely inconvenienced the next morning.

So, if you're a student at a school that uses Blackboard, do you feel more secure now that the DMCA has tried to stop you from learning about its security flaws?

If you're a parent putting money into a Blackboard-based debit account, do you feel more confident of its safety now that this information is ostensibly hidden?

This card system has been installed on many campuses and its roots go back almost twenty years. My guess is that replacing the card-reading hardware would be necessary to improve the security of these devices. Obviously, Blackboard would be hard-pressed to replace thousands of hardware devices at all its locations, even if they'd started in late 2001 when Acidus claims he called to tell them of the flaws he'd found (and "was blown off").

So, assuming that's not possible -- is the DMCA a viable tool to ensure security?

P.S. Virgil tells me that he has a good lawyer. They are scheduled to argue on Thursday that the restraining order not be made permanent. Slashdot will keep you apprised of what happens in our Slashback stories... stay tuned.

P.P.S. Update: 04/15 02:30 GMT by J : Now online are the restraining order, which just lists the six things that Acidus and Virgil are not to do, and the more detailed Complaint. Now that these are available, as Declan McCullagh points out, it turns out the DMCA was only in the lawyers' threatening letter and not considered as part of the Complaint itself. I'm not sure why it would be included in the letter -- some of the language of the Georgia Computer Systems Protection Act is similar, and who knows, Section 1201 might be mentioned later on, as this case progresses. Maybe the lawyers are just keeping their options open. Meanwhile, I love this part of the Complaint:

"Mr. Hoffman openly acknowledges on his website that 'I am a hacker.' His website then defends the process of hacking. See Exhibit B."

Reader samjam sent in an interesting piece about his dream handheld PC, sort of a cross between a subnotebook and a wireless web pad, with the kitchen sink thrown in. Mmmmm, light-emitting polymers. I can't decide if this kind of thing is right around the corner or just a fantasy - after all, normal notebook computers sell, and at a nice high premium - and web pads are less than successful - why would anyone spend the money to develop a device like this? samjam writes: "My dream handheld is not available though some things come close. The technology is becoming available.

Though it may take a few months, here is what I would put together if I had the chance. Including Bluetooth, IButtons, solar panels and light emitting polymer screens...

For links to other linux handhelds, try linuxdevices.com.

My ideal handheld is the size of an A4 pad of paper, so I have to hold it on my left forearm with the fingers of my left hand curled over the end. A4 gives me plenty of screen space for watching real TV, reading real books, writing real emails, browsing real web pages and doing some real showing off.

The front cover is a solar panel, but I can't decide if the cells should be on the inside or the outside to help charge it while I use it or while I'm not using it. Hard one that.

The screen is not heavy-breakable LCD but LEP (brief technical primer, more on Google) or perhaps Xerox Electronic Paper seemingly available under the name Gyricon, pictures here and slight details here.

The choice of processor doesn't bother me much; I'd like to think there are many versions available of my handheld by many manufacturers (to drive the price down) and so many processors will be available but let's pretend the first release will run on a Transmeta just to keep excitement running high.

60 GB or so should be plenty of disk space, 2.5" IDE to keep weight down.

Input via stylus or sticky finger of course, with support for Graffiti, as used on the Palm and many others, also Quickwriting as featured on Slashdot as well as regular handwriting recognition (take your pick) and other pluggable input modules with popup keyboard for those times when you just can't manage to input a tilde (~) or backtick (`) properly.

Connectivity will be provided via a multitide of USB ports (where real keyboards can be plugged), Bluetooth (useless link) in action (good link), wireless ethernet as well as perhaps as many as 4 PCMCIA slots for things that change a lot like GPRS adaptors &c, or radio and TV tuner cards. Yeah! Why not add some Compact Flash while I'm at it? And boring 100 base T ethernet.

In fact I'm going to use the mobile phone card, along with my sound system to make the whole thing into a mobile phone for voice, not just data access. Talking of phones, the built in web cam can be used for video conferencing with (for example) Gnophone.

Better stick some firewire ports on there, too, for good measure, along with a few IRDA ports pointing in a few different directions for those more subversive inter-classroom networks as well as controlling my grannies telly to show off. And talking to my old non-bluetooth mobile which I can't afford to upgrade cos I spent it all on my handheld.

It will have integrated Ibutton support for security and authentification, maybe even built into the BIOS.

What more do I need? Oh yes, an Operating System. Pick your own.

I shall be running Linux with Ximian Gnome because it looks cool (and Bill Gates was nearly right, eye candy counts for a lot if only not to distract you by means of ugliness). I will be running redhat because I find up2date (or redhat channels of RedCarpet) invaluable effort-free way to remove those exploits, and I will finally get round to playing with Rebol.

The first thing I will need to develop is some network scavenging software to grab internet connectivity where it can for syncing imap folders and news, updating "offline web pages" [yikes! MS concept there]. Code to hi-jack available SMTP relays (*cough*). Does this smell a bit like Jini or something like it? I'll need to register my changing location for Gnophone so callers can find me. Perhaps the first thing for company visitors in the future will be to checkin their Ideal Handheld to the company network.

I will load all my favourite books into it as well as the entire classical Mormon works, copies of conference talks Doctrines of Salvation, Journal of Discourses etc, along with the Bible, Book of Mormon, and all of Project Gutenberg.

What will you do with yours? Have I missed any gizmos out? Or gadgets even?"

Reader samjam sent in an interesting piece about his dream handheld PC, sort of a cross between a subnotebook and a wireless web pad, with the kitchen sink thrown in. Mmmmm, light-emitting polymers. I can't decide if this kind of thing is right around the corner or just a fantasy - after all, normal notebook computers sell, and at a nice high premium - and web pads are less than successful - why would anyone spend the money to develop a device like this? samjam writes: "My dream handheld is not available though some things come close. The technology is becoming available.

Though it may take a few months, here is what I would put together if I had the chance. Including Bluetooth, IButtons, solar panels and light emitting polymer screens...

For links to other linux handhelds, try linuxdevices.com.

My ideal handheld is the size of an A4 pad of paper, so I have to hold it on my left forearm with the fingers of my left hand curled over the end. A4 gives me plenty of screen space for watching real TV, reading real books, writing real emails, browsing real web pages and doing some real showing off.

The front cover is a solar panel, but I can't decide if the cells should be on the inside or the outside to help charge it while I use it or while I'm not using it. Hard one that.

The screen is not heavy-breakable LCD but LEP (brief technical primer, more on Google) or perhaps Xerox Electronic Paper seemingly available under the name Gyricon, pictures here and slight details here.

The choice of processor doesn't bother me much; I'd like to think there are many versions available of my handheld by many manufacturers (to drive the price down) and so many processors will be available but let's pretend the first release will run on a Transmeta just to keep excitement running high.

60 GB or so should be plenty of disk space, 2.5" IDE to keep weight down.

Input via stylus or sticky finger of course, with support for Graffiti, as used on the Palm and many others, also Quickwriting as featured on Slashdot as well as regular handwriting recognition (take your pick) and other pluggable input modules with popup keyboard for those times when you just can't manage to input a tilde (~) or backtick (`) properly.

Connectivity will be provided via a multitide of USB ports (where real keyboards can be plugged), Bluetooth (useless link) in action (good link), wireless ethernet as well as perhaps as many as 4 PCMCIA slots for things that change a lot like GPRS adaptors &c, or radio and TV tuner cards. Yeah! Why not add some Compact Flash while I'm at it? And boring 100 base T ethernet.

In fact I'm going to use the mobile phone card, along with my sound system to make the whole thing into a mobile phone for voice, not just data access. Talking of phones, the built in web cam can be used for video conferencing with (for example) Gnophone.

Better stick some firewire ports on there, too, for good measure, along with a few IRDA ports pointing in a few different directions for those more subversive inter-classroom networks as well as controlling my grannies telly to show off. And talking to my old non-bluetooth mobile which I can't afford to upgrade cos I spent it all on my handheld.

It will have integrated Ibutton support for security and authentification, maybe even built into the BIOS.

What more do I need? Oh yes, an Operating System. Pick your own.

I shall be running Linux with Ximian Gnome because it looks cool (and Bill Gates was nearly right, eye candy counts for a lot if only not to distract you by means of ugliness). I will be running redhat because I find up2date (or redhat channels of RedCarpet) invaluable effort-free way to remove those exploits, and I will finally get round to playing with Rebol.

The first thing I will need to develop is some network scavenging software to grab internet connectivity where it can for syncing imap folders and news, updating "offline web pages" [yikes! MS concept there]. Code to hi-jack available SMTP relays (*cough*). Does this smell a bit like Jini or something like it? I'll need to register my changing location for Gnophone so callers can find me. Perhaps the first thing for company visitors in the future will be to checkin their Ideal Handheld to the company network.

I will load all my favourite books into it as well as the entire classical Mormon works, copies of conference talks Doctrines of Salvation, Journal of Discourses etc, along with the Bible, Book of Mormon, and all of Project Gutenberg.

What will you do with yours? Have I missed any gizmos out? Or gadgets even?"