Uno-Code

This morning I saw that libexpat was upgraded to 2.0.0. I simply emerged that and I thought all was good, but within minutes, I saw issues with my PHP CLI apps having problem. I noticed that expat was a USE flag, and I need to rebuild PHP against the new libexpat. No problem, so I did that. Shortly after, I noticed that Apache's logresolve2 was complaining as well. At this point, I thought I would do a revdep-rebuild, since there clearly are reverse dependency issues.

This generated the oneshot emerges that needed to be rebuilt on the system, and I was on my way. On another box running kdelibs and gnome packages... this was a whole different story.

I was seeing various messages similar to these during rebuilds:

This post, I wanted to talk about fail2ban, and how you can use it for more than just blocking common SSH brute force login attempts. You see mention of this as a common defense for that, but since I access my servers from a static IP, I have strict port 22 iptable rules allowing certain IPs. I understand if you have dynamic IP or have the need to travel (and don't have VPN) that this is not an option, and fail2ban is your ticket to protect yourself.

One thing that I've been working on over the years, is to lessen my server load and services from annoying requests. These requests will sap your server of resources and can drastically hamper it's performance. Some great techniques is to use Snort in conjunction with snortsam and the bleeding rule set. One set of rules will block spamhaus IPs for 72 hours. These rules are updated daily, so we can adapt with the changing spam IPs. Why bother with this? Simple, this lessens the interaction of my mail MTA (postfix + mysql). Each requests ties resources from postfix, and I burn mysql connections performing mailbox lookups. If the IP is a know spamhaus IP, snortsam will add this to iptables drop and postfix/mysql isn't bothered with this 'bad' traffic.

This small list of upload protections is geared towards a LAMP environment (Linux Apache Mysql PHP). Each web server and or language will have similar traits, but the tips listed below may not apply depending on your situation.

1. Don't allow uploads. Sorry, that I even need to say this, but if your application doesn't need upload handling, then configure the server to disallow the upload entirely server-side. This prevents the possibility of harmful scripts (test apps, free ware, etc) that could be exploited in the future.

2. Check MIME type server-side. Don't rely on $_SERVER['file']['type'] or by simply checking the file extension in the name! The 'type' should be untrusted since that is defined by the browser and can be easily spoofed. It's much better to allow the upload to /tmp and then use a server-side process to check the MIME type using `file` and comparing that to your allowed MIME type list. This can easily be done by using PEAR's fileinfo package using finfo_file(). Also, if you're expecting images only, you could also optionally use exif_imagetype() to extract image information. I personally like using exif_imagetype() vs. getimagesize().

Ah, so today the openssh/istate error relating with the rsync/scp is now resolved. The Gentoo folks were able to roll in 4.6_p1-r4 into portage. It's not 'stable' so you're going to need to use the x86 keyword (depending on your arch). Or you can simply add this version to /etc/portage/package.keywords

Here is the official changelog on this version:

Looks like they fixed the LDAP requirement bug in with p1-r3. This was related if you had a ldap as a USE flag. You would see an error similar to this:

I wanted to see if they addressed the istate bug that I mentioned in the last post, so I did a simple scp, and saw the following in the logs:

After upgrading to net-misc/openssh-4.6_p1-r2 this morning, I'm starting to see the following messages in the logs. This only seems to appear after rsync/ssh transactions.

I noticed a post in the forums and bug listed.. so hopefully, we'll get a fix relatively soon. I'll keep you posted on what I find out. If any of you are Gentoo people, try to see if you're seeing the same results and contribute to the bug report or forum post. I think if we all chime in, we can get a push on fixing things.

Yesterday, I talked about NetGong and their network management software. With today's sponsored post, I'd like to about another suite of tools by the same company called NetInfo.

NetInfo is a collection of some basic network related tools. Linux users are very familiar with these, possibly using them every day like myself. The application is similar to NetGong. It's a small compact application (as it should be) that performs basic tasks like ping, trace, lookup, finger, whois. NetInfo as with NetGong is for Windows based platforms only (supported by all flavors of Windows from Win95 to Vista). Along with basic tools, it has a nice browser (that shows HTML markup -- not rendered) and a port scanner. The scanner is nice for something quick and dirty (which is what's usually needed for your own network), but I would still recommend nmap for anything super serious.

I'm always interested in networking management software. I've played with a few from Cacti, Samhain, NMS, Nagios and to simple uptime tools like Mon. All of these are Linux based, but with this sponsored post, I'd like to talk about a Windows based solution called NetGong.

NetGong use to be IPMonitor but changed their name to reflect a new emphasis on notification technology. What I'm not 100% clear on is how does it monitor? Does it need a agent installed on each client, or does it simply touch services to see if they're up (similar to Mon).

Today, I decided to update some of my boxes, one of my boxes is a VM-ware server host running on top of Gentoo. That host has two clients, another Gentoo server and a 2003 Windows server. Both of the Gentoo servers needed to go to 2.6.21-r4 kernels, so I thought this would be a good time to do it.

On the host I emerged gentoo-sources, ran make oldconfig and compiled the kernel. Afte the kernel was compiled, I ran 'module-rebuild -X rebuild' to rebuild all modules that need to be compiled against the latest sources. Sure enough it stated that it needed vmware-modules (as expected) and it rebuilt that.

I rebooted the server and everything appeard good, except that my guest boxes were not coming up. I open vmware-server-console to take a look and immediately received an error when trying to power them on. Here is what the logs looked like:

Quick check on MX using nslookup. I'm basically doing this for a reference for myself. I had some weirdness with MX in my zone. I noticed the following message in the logs:

To lookup MX vis nslookup, simply type nslookup, then 'enter'. At this point you should be in the nslookup shell. Next, set the type (set type=MX) then the domain you're looking for.