Free iostat software for linux

ifstat is a tool to report network interface bandwith just like vmstat/iostat do for other system counters. It can monitor local interfaces by polling the kernel counters, or remote hosts interfaces using SNMP.
fstat gathers these statistics from the kernel internal counters, which is highly operating system dependent.
Right now, the following systems are supported:
Linux >= 2.2.0 (through /proc/net/dev file).
FreeBSD >= 2.2 (using the ifmib(4) interface).
Solaris >= 5.6 (using the kstat(3K) interface).
IRIX and OpenBSD (using the SIOCGIFDATA ioctl).
NetBSD and Darwin (using the route(4) sysctl interface).
Other BSDs (using the kvm(3) interface).
Digital Unix (OSF/1), Tru64, and Aix (using the legacy kmem interface).
HP-UX (using the DPLI streams interface).
Win32 native or through Cygwin (using the GetIfTable call).
If the net-snmp (or ucd-snmp) library is available, ifstat can use it to gather statistics from remote equipments (hosts, routers, switches...) or even the local host if a SNMP daemon is running.
ifstats functionnalities can as a static application. To use it, you just have to pass --enable-library while configuring ifstat.
Enhancements:
- Digital Unix (OSF/1) and Tru64 support.
- AIX support (tested on AIX v4.3).
- HP-UX support with DLPI streams interface. (sample code contributed by Jean-Marc Saffroy )
- Win32 support (native or with cygwin) with GetIfTable interface. (sample code contributed by Alexandre Raclot )
- Use net-snmp-config if present to find out SNMP flags.

Dstat project is a versatile replacement for iostat, vmstat and ifstat. Dstat overcomes some of the limitations and adds some extra features.
Dstat allows you to view all of your system resources instantly, you can eg. compare disk usage in combination with interrupts from your IDE controller, or compare the network bandwidth numbers directly with the disk throughput (in the same interval).
Dstat also cleverly gives you the most detailed information in columns and clearly indicates in what magnitude and unit the output is displayed. Less confusion, less mistakes.
Dstat is also unique in letting you aggregate block device throughput for a certain diskset or network bandwidth for a group of interfaces, ie. you can see the throughput for all the block devices that make up a single filesystem or storage system.
You can customize your dstat output from /etc/dstat.conf and you can write your own dstat modules to plug into the dstat output.
Dstats output by default is optimized for being interpreted by humans in real-time, however the new CSV output allows you to store CSV output to a file to be imported later into Gnumeric or Excel to generate graphs.
Main features:
- Combines vmstat, iostat and ifstat information (in exactly the same timeframe)
- Modular design
- Enable/order counters as they make most sense during analysis/troubleshooting
- Easy to extend, add your own counters (please contribute those)
- Can summarize grouped block devices and see total numbers
- Can show interrupts per device
- Very accurate timeframes, no timeshifts when system is stressed
- Shows exact units and limits conversion mistakes
- Indicate different units with different colors
- Show intermediate results when delay > 1
- Written in python so easily extendable for the task at hand
- Allows to export CSV output
- CSV output can be imported in Gnumeric and Excel to make graphs

stephanie is a program for hardening OpenBSD for multiuser environments.

Mmmmm, OpenBSD. Functional, secure, free. With an emphasis on security and integrated cryptography, it carries an excellent reputation for plain old "you-just-cant-hack-this-ness". Not perfect, but nothing is, at least theyre not wearing suits and lying to you.

There are a few roles where i believe OpenBSD fits perfectly. One of these is in multiuser environments, where you have large numbers of possibly malicious users with local access. Here the OpenBSD teams commitment to auditing and fixing code provides a level trust in the environment which is hard to find elsewhere. Also, their efforts to provide integrated cryptography means setting up secure access is easy. So, lets take advantage of the freely available source and tailor it to our specific needs.

Details:

In Phrack 54, route|Mike Schiffman wrote a series of patches for OpenBSD 2.4 for Trusted Path Execution (TPE). Stephanie brings a modified version of these up to speed for OpenBSD 2.8 - 3.0, along with some additional features. A trusted path is one where the parent directory is owned by root and is neither group or other writeable. The TPE works off an internal list of trusted user ids. If a given user tries to execute a file not in a trusted path, and their user id is not in the kernels trusted list, they are denied execution privileges. In real terms, this means they cant download, compile and run krad-sploit.c.

In addition to the TPE, a series of privacy patches came along too. Originally supplied as patches for the individual utilities, these are now implemented through kvm(3), and honour trusted users (ie, trusted users are allowed to see all system information). As a practical example, this means that untrusted users will only be able to see information about processes they own, and the stat tools (netstat, iostat, vmstat, etc) will generally be broken for them. It has been pointed out that by going through trying to kill every possible process id you can find other users processes, but you cant really gain any information on them, so this is not really a great concern.

The original TPE patches had one known way of bypassing the execution restrictions, which was using shell redirection to allow arbitrary interpreted language scripts to be run (perl, sh, etc). This has been fixed up, but could possibly be a big pain in the ass, so please pay attention. When an interpreter is invoked, like most things, it creates a new process group with a job count of one. When a series of commands are connected via the | character on the command line, all the commands belong to the same process group and the job count represents the number of commands eg ps -ax | grep something | awk {print $1} has a job count of three, and the ps, grep and awk processes all belong to the same process group.

The one exception to this is when a user logs in, where we find their shell has its job count set to zero. So how can we use this to prevent shell redirection for a given set of programs? We need to be able to distinguish between ordinary commands and interpreters. At the moment this is done by setting the immutable flag on them. So, in kern_exec(), if we find an untrusted user executing something with the immutable flag set and a job count greater than zero, we flag the process as being potentially dodgy. Then in other system calls we disallow read()ing from fd 0 (stdin) and things like dup2(0, n) if the process has been flagged.

There are two main disadvantages to this. First is the system will need to be brought down to single user mode if the interpreter needs to be patched, and secondly, people will have a hard time suing to an untrusted user. Of course, when a user has shell, they can still type any commands that could otherwise be placed in a shell script, but at the least, this will raise the bar a bit.

Finally, Stephanie brings restricted symbolic links, ala the openwall patches for linux. As time permits, im still working on adding additional features, and will add bits of the openwall stuff i like. The basic goal is to add an extra layer of security without being a monumental pain in the ass to legitimate users, so some things wont be there. I havent added the additional hard link restrictions of the openwall patch, but will do something about this later as time permits.

Installing:

Step by step instructions are presented in the install guide which comes with the source. Read it all first, but its reasonably straight forward. It would be a good idea to read the original article (local copy) if you havent already.

Its distributed under the original two clause BSD license, mess with it all you want, but dont get cranky at me if it breaks something.

You can also read the tpe_adm(8) man page online.