Thanks for “Stealthful Sniffing, Intrusion Detection and Logging” [LJ, October 2002, also available at www.linuxjournal.com/article/6222]. That is a clever use of Snort, particularly as a means to send logs to a remote host. Just a couple of comments as I read through the article. In the Sidebar titled “LAN Segments, Hubs and Switches” on page 38, it is not impossible to send logs to the Snort logging host from a distant segment. Just ensure the Snort host is attached to a valid IP subnet, and give the subnet's router a static ARP entry that associates the Snort host's MAC address to an unused IP address that is valid for the Snort host's subnet. With the method of logging outlined in the article, it may still be possible to compromise the integrity of the Snort logging host. An attacker may be able to send their own log messages, which may be used either to overflow the logging disk or to attack a potential vulnerability in Snort's capture/parsing logic (if there ever was one).
Mick Bauer replies: Even a stealth logger is vulnerable to denial-of-service (DoS) attacks and sniffer-specific application exploits. But in practical terms, neither of these strikes me as a huge risk. I think it would be pointless for an attacker to aim specifically to take out a stealth logger via a DoS attack; that amount of traffic probably would also take out the system you're actually trying to attack without being logged. On the other hand, we should keep in mind that the “stealth sniffing” technique is intended to mitigate the specific threat of attacks against the logger's local TCP/IP stack and applications. I do think it's useful for that and effectively raises the bar considerably against would-be log-tamperers. However, these are good observations.
I really enjoyed the article “Memory Leak Detection in Embedded Systems” that appeared in the September 2002 issue of Linux Journal. Lately I have been doing a lot of C++ development with the DB2 UDB Administrative API, and detecting memory leaks in both my code and IBM's is useful for debugging purposes. Please feature more articles that address these types of C++ development topics in 2003. An overview of compiler and compiler tools (g++, Intel compilers, etc.) tools would be one article in particular I would like to see run.
—Kevin Wittmer, Senior Software Developer, Expand Beyond, Chicago, Illinois
Watch for an article on the Intel C and C++ compiler next issue.
I recently purchased the new Red Hat 8.0. I have been following Red Hat since 5.1 and have purchased 6.0, 6.1, 7.2 and downloaded 7.3. I find the new desktop, Bluecurve, to be a true bastardization of both Gnome and KDE. Red Hat has removed all of the character from Gnome and KDE and smudged the windowing into their own proprietary look and feel. Konqueror is not the default browser in the KDE menu, and CUPS is not installed by default. If I want to go into KDE, I want KDE. If I want Gnome, give me Gnome, not some smudging of the two. On the other hand, the beauty of open source is that you can do what you want with it as long as you publish the source code, and that is what Red Hat has done. Good for them. But, Bluecurve should be called BLUE-SMUDGE.
—Tom Amon, IT Tech
I love the magazine and enjoy it and sharing GNU/Linux with everyone I know. When I got started with GNU/Linux I looked to books and mags to help me, and what really helped me were any tidbits of information that I could get. Marcel's sections are a blast to read, and maybe something like that more directed to newbies would help other new people in their exploration of GNU/Linux.
If you enjoy sharing your knowledge, please visit our web site (www.linuxjournal.com) for an author's guide, and send us an article proposal.
The key for the EXCLAMATION MARK (!) should be shifted to the key left of the number one (1). This will facilitate typing of the EXCLAMATION MARK (!) without using the Shift key. This is necessary because EXCLAMATION MARK (!) is used very often while typing any text. The key for the QUESTION MARK (?) should be brought down below on the same key on which it is available presently, so that Shift key need not be pressed. The OBLIQUE symbol (/) is very rarely required. Lastly, the INDICATOR LIGHT ON for the CAPS LOCK key, pressed for typing ALL CAPS, is not enough to highlight the same. The INDICATOR LIGHT should not be constant. Instead, it should go on blinking, preferably with a “BEEP BEEP” sound so as to attract the attention of the USER, so that he undoes it after his need to type ALL CAPS is over. I hope, the above-mentioned suggestions are worthy of due consideration and if possible, implementation.
—DR. C.H. AWALGAONKAR
See man xmodmap for how to remap any key to any character.
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- Stunnel Security for Oracle
- SourceClear Open
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- SUSE LLC's SUSE Manager
- My +1 Sword of Productivity
- Managing Linux Using Puppet
- Google's SwiftShader Released
- Non-Linux FOSS: Caffeine!
- Parsing an RSS News Feed with a Bash Script
- Doing for User Space What We Did for Kernel Space
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide