Binding sendmail to the loopback interface

The sendmail SMTP server comes with the vast majority of UNIX Operating systems, and is configured to listen for new connections on TCP ports *.25 (SMTP) and *.587 (MSP) by default. For workstation and servers that aren’t responsible for mail delivery, this can cause chaos when a new sendmail exploit is released into the wild. This behavior can be changed by adjusting the “DaemonPortOptions” in the sendmail configuration file (usually /etc/mail/ The default configuration looks similar to the following:

O DaemonPortOptions=Name=MTA-v4, Family=inet
O DaemonPortOptions=Port=587, Name=MSA, M=E

If we add “Addr=” to each entry, sendmail will only listen for new connections on the loopback interface:

O DaemonPortOptions=Addr=,Port=25,Name=MTA
O DaemonPortOptions=Addr=,Port=587,Name=MSA, M=E

Once the changes are integrated into the file ( hand editing the file or using M4 macros ), sendmail needs to be restarted. Once sendmail is restarted, we can view the new behavior with the netstat command:

$ netstat -an | egrep LISTEN | egrep ‘(25|587)’ *.* 0 0 49152 0 LISTEN *.* 0 0 49152 0 LISTEN

Back in the sendmail 8.10/8.11 days, a smart relay could be used to forward mail, alleviating the need to run sendmail as a daemon. I am still trying to find a way to revert back to the old behavior, but the MSP seems to cause some issues when smart relays are in use. More to come …

Searching the OpenBSD ports tree

The OpenBSD ports collection comes with 1000s of software packages, and is organized as a hierarchical directory structure. Locating specific ports can sometimes be tricky, especially when the port name doesn’t contain a descriptive name. To deal with these situations, the global Makefile supports a serach keyword:

$ cd /usr/ports

$ make search key=”debug” 2>&1 |more
Port: electricfence-2.0.5
Path: devel/ElectricFence
Info: library providing malloc debugging via VM protection
Maint: Niklas Hallqvist
Index: devel
Archs: any

Port: ald-0.1.5a
Path: devel/ald
Info: Assembly Language Debugger
Maint: Patrick Alken
Index: devel
Archs: i386

This is super useful for locating all ports that match a specific purpose (e.g., all debugging utilities).

Finding free space in Veritas diskgroups

The Veritas volume manager (VxVM) provides logical volume management capabilites across a variety of platforms. As you create new volumes, it is often helpful to know how much free space is available. You can find free space using two methods. The first method utilizes vxdg’s “free” option:

$ vxdg -g oradg free

GROUP        DISK         DEVICE       TAG          OFFSET    LENGTH    FLAGS
oradg        c3t20d1      c3t20d1s2    c3t20d1      104848640 1536      -
oradg        c3t20d3      c3t20d3s2    c3t20d3      104848640 1536      -
oradg        c3t20d5      c3t20d5s2    c3t20d5      104848640 1536      -
oradg        c3t20d7      c3t20d7s2    c3t20d7      104848640 1536      -
oradg        c3t20d9      c3t20d9s2    c3t20d9      104848640 1536      -

The “LENGTH” column displays the number of 512-byte blocks available on each disk drive in the disk group “oradg.”. If you don’t feel like using bc(1) to turn blocks into kilobytes, you can use vxassist’s “maxsize” option to print the number of blocks and Megabytes available:

$ vxassist -g oradg maxsize layout=concat
Maximum volume size: 6144 (3Mb)

Now to find out what to do with 3 MB of disk storage :)