I often find myself needing to protect sensitive data, and usually turn to OpenSSL for help. OpenSSL support a plethora of symmetric key encryption algorithms (AES, DES3, Blowfish, RC4), and comes with a variety of Operating Systems. To encrypt a file named private, we can pass one of the available symmetric key algorithms to OpenSSL:
$ openssl aes-256-ecb -in private -out private.aes256
enter aes-256-ecb encryption password:
Verifying - enter aes-256-ecb encryption password:
$ ls private
private private.aes256
To decrypt the file private.aes256, the symmetric key algorithm and decryption option can be passed to OpenSSL:
$ openssl aes-256-ecb -d -in private.aes256 | tail -5
enter aes-256-ecb decryption password:
pop 109/tcp
pop3 110/tcp
imap 143/tcp
imaps 993/tcp
pop3s 995/tcp
As you can see, private wasn’t so private after all :) You can get a full list of available symmetric key ciphers by appending the help flag to openssl. If you are interesting in learning about more practical uses for OpenSSL, check out my article Real World Uses For OpenSSL.
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/sendmail.cf). 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=127.0.0.1” to each entry, sendmail will only listen for new connections on the loopback interface:
O DaemonPortOptions=Addr=127.0.0.1,Port=25,Name=MTA
O DaemonPortOptions=Addr=127.0.0.1,Port=587,Name=MSA, M=E
Once the changes are integrated into the sendmail.cf file ( hand editing the sendmail.cf 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)'
127.0.0.1.25 0 0 49152 0 LISTEN
127.0.0.1.587 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 …
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
L-deps:
B-deps:
R-deps:
Archs: any
Port: ald-0.1.5a
Path: devel/ald
Info: Assembly Language Debugger
Maint: Patrick Alken
Index: devel
L-deps:
B-deps:
R-deps:
Archs: i386
This is super useful for locating all ports that match a specific purpose (e.g., all debugging utilities).
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 :)
When OpenLDAP is configured to log connection information, a RESULT entry is written with the status (e.g., success or failure) of the last BIND:
$ grep RESULT openldap.log | head -1
Dec 28 21:05:01 winnie slapd[7101]: [ID 217296 local4.debug] conn=25
op=0 RESULT tag=97 err=0 text=
The “err=” string contains zero if the BIND was successful, and an error code if the BIND didn’t complete successfully. The error codes are defined in “LDAPResult.h,” which is included with the OpenLDAP source code. When a BIND fails because the credentials were invalid, the error string will contain the value 49:
$ grep "err=49" openldap.log | head -1
Dec 29 12:22:00 winnie slapd[7101]: [ID 217296 local4.debug] conn=27
op=0 RESULT tag=97 err=49 text=
To get the DN that tried to BIND, you can grep the connection number (the value after conn=) out of the OpenLDAP logfile:
$ grep "conn=27.BIND" openldap.log
Dec 29 12:22:00 winnie slapd[7101]: [ID 347666 local4.debug] conn=27
op=0 BIND dn="cn=mail,dc=synackfin,dc=com" method=128
You can get the IP address of the host that initiated the BIND by grepping the connection id, along with the ACCEPT keyword, from the OpenLDAP logfile:
$ grep "conn=27.ACCEPT" openldap.log
Dec 29 12:22:00 winnie slapd[7101]: [ID 848112 local4.debug] conn=27
fd=11 ACCEPT from IP=192.168.1.2:39749 (IP=192.168.1.2:636)
This is useful for tracking down folks who are poking around your directory server.