This article is basically a follow-up to the last article where I mentioned how to configure Shorewall to limit the number of connections per IP to SSH in order to restrict Brute-Force attempts against SSH. This article will provide a howto for setting up a generic per-IP rate limit that can be reused for multiple ports, services and connections with different limits depending on how you configure the rules. This would allow you to, for example, setup SSH with a 3 connection per IP each minute limit, and also setup FTP with 4 connections per IP per minute to help guard against brute force attacks directed at an FTP server as well.

A new netfilter called recent has been added to IPTables and newer versions of Shorewall can actually use this netfilter for varied functionality. This article will basically talk about how to use this netfilter to protect against Brute Force attacks against SSH which is a current issue as Linux gets more popular. While SSH itself is fairly secure against most of these scripted attacks, they are still fairly annoying for most admins who monitor systems because they take up space in the log files and all the extra "noise" can possibly be used to mask a successful attempt to compromise a system.

At any rate, it is possible to restrict the number of attempts that each IP gets to connect on particular ports. While this could also be used to build a DOS protection scheme, it is particularly useful in protecting against unrestricted Brute Force attacks against SSH. Now, on to the details:

Desktop Linux highlights a story from an author who moved his elderly mother and father from Windows to Linux. "The author explains how he moved his elderly parents from a problematic Windows XP desktop system to Mandriva PowerPack 10, leaving spyware, viruses, slow performance, and myriad other problems behind."

You thought God, capital punishment, and fur pillows were controversial? Try sitting down with database designers and asking them to define a relational database. And as long as you don’t mind a little blood on the carpet, try arguing that MySQL isn’t even a database system, leave alone relational.

The gist of criticisms have gone like this: “Don’t make me laugh. MySQL is not a transaction database. It’s good in that it’s fast, it can query information and assemble that information, but that’s about it.” Stored procedures, views, and other features were often listed as missing from MySQL and proof points of its inferiority as an enterprise choice. As Zack Urlocker, MySQL’s Marketing vice president, remarks: “People’s perceptions are sometimes locked into earlier versions of MySQL.” The curious divided screen—MySQL’s enormous user base of 5 million users from free downloads and 5,000 paying customers—and perceptions that MySQL is still too much a work in progress—has not deterred MySQL’s developers from working for progress toward enhancements and tools.

And now that MySQL 5.0 is getting readied for prime-time (Urlocker says 5.0 is targeted for production in Q2), old perceptions could be looking even lamer.

One of the hottest topics in all of IT today is the subject of virtualization. While it has been around for some time, it has just recently started to garner the attention of the biggest names in tech. Everyone from Intel and AMD, to Microsoft, Sun, and virtually every commercial Linux vendor has either current or planned support for virtualization. So what is it, and why is everyone so head over heels about it?

Virtualization comes chiefly in two forms, hardware or software virtualization. The most well known is likely hardware emulation. In this type of virtualization, the host OS provides a layer which translates the usual system functions of the guest OS. For example, VMware running on Linux but also running a Windows OS inside the application. In this situation, VMware intercepts the calls Windows makes to the actual physical hardware and translates those calls into a manner in which the Linux kernel can understand. So if Windows says it needs access to the BIOS or video card, VMware steps in and takes the message then acts as a translator and asks the Linux kernel to please provide the needed information or run the processes, once that information or process is complete then VMware must take the translation back in the other direction, from Linux to Windows. The guest OS is provided with a complete, virtual environment in which to carry out its duties. This environment can even be made to emulate hardware that the host OS doesn't even have access to (such as a PDP-10 emulator allowing ancient Unix code code to run on top of Linux). As you can see, this type of virtualization has one inherent flaw, guest OS's will never be as fast or responsive as the host due to the translation that must occur. This limitation with emulation has been worked around and made to be a relatively small enough issue that many still rely on such solutions. This issue of speed, or the lack thereof, was much more significant in the past due to physically slower hardware. Even with todays hardware, the difference can be quite noticeable for some applications. Therefore, this type of virtualization has always been considered by many as more of a workaround than a perfect solution. Luckily, hardware virtualization technology did not stop with emulation. But we'll get back to that shortly.