Securing your network traffic

If you want to start some exciting discussion in a security forum, just say you use telnet: you’ll find that every admin knows that telnet is insecure, that one should use OpenSSH or similar to encrypt the traffic, and that telnet should be banned from the server environment entirely.

However, telnet is not the only server that transmits its passwords in the clear. There are a lot of others. Here’s a list I came up with:

• FTP
• HTTP
• IMAP
• IPP
• LDAP
• LPD
• NFS
• POP3
• rsync
• SMTP
• SNMP
• syslog
• VNC
• X11
• XDMCP

I won’t cover all of these here (more about these items can be found in my book) but I do want to cover just a few.

Consider, for example, the mail protocols: SMTP, POP3, and IMAP. SSL encryption is available with all three – but do you use it? And what about your logins to your mailbox at your ISP? Every time you login, your password to your mailbox goes across the wire in the clear.

What about NFS – particularly NFS home directories? If you have unencrypted secrets in your home directory, then these items will be transmitted across the network in the clear as well. What about private SSH keys? Unfortunately, there is no way to encrypt NFS traffic.

VNC is another one to watch for: if you type passwords for your root logins over VNC – even if you are using SSH in your VNC session – the passwords are in the clear. The only way to secure VNC entirely is to use an SSH tunnel to encrypt it.

X11 is insecure in the same way, but presents special problems. However, OpenSSH handles X transparently through the use of special tunnels just for X.

syslog is another unencrypted service; do you have passwords put into the system logs? What about secret doings of your servers? How much information leakage can you handle? Unfortunately, syslog is another service that cannot be secured unless you use something such as syslog-ng which permits you to use TCP (and thus, an OpenSSH tunnel).

LDAP on OpenVMS

HP introduced LDAP support for password authentication in OpenVMS 8.3, which is fantastic. However, when looking for documentation about how it is configured and implemented, one comes up short – there is a dearth of information to be found.

Thanks to Hoffman Labs, this is no longer the case: their article on LDAP exposes the configuration details of ACME LDAP on OpenVMS quite nicely. They have the technical details as well as the README from the ACME LDAP add-on posted there; I’ll try to summarize installation and configuration concisely here.

ACME is the Authentication and Credential Management Extensions, which appear to be an architecture for creating plugins for authentication and so forth, like PAM (the Pluggable Authentication Modules) for UNIX. ACME appears to have been introduced in OpenVMS 8.3.

ACME LDAP is perhaps the most visible of the first of these extensions. This, perhaps, explains its dearth of publically accessible documentation. Currently, ACME LDAP has these features:

• Support for TLS/SSL
• Support for StartTLS
• Support for Active Directory
• Support for Netscape “expired password” mechanisms

ACME LDAP also has these restrictions:

• Still requires local username; password only is checked against LDAP
• Characters in usernames and passwords are restricted to ISO 8859-1 eight bit characters; UTF-8 support not present.
• Characters in passwords used in Active Directory are restricted to ISO 8859-1 7-bit ASCII characters.

Each user account to be authenticated with LDAP must exist on the system (in the SYSUAF file) and must have the EXTAUTH flag set.

To use ACME LDAP, you must configure the SYS$STARTUP:LDAPACME$CONFIG-STD.INI file. The file can be started by copying the LDAPACME$CONFIG-STD.INI_TEMPLATE file:

$ COPY SYS$STARTUP:LDAPACME$CONFIG-STD.INI_TEMPLATE SYS$STARTUP:LDAPACME$CONFIG-STD.INI

An example LDAPACME$CONFIG-STD.INI may look like this:

server = roux.zko.hp.com
port = 636
port_security = ssl
bind_dn = uid=acme-admin,ou=people,dc=acme,dc=mycompany,dc=com
bind_password = swordfish
base_dn = ou=people,dc=acme,dc=mycompany,dc=com
login_attribute = uid
scope = sub
ca_file = sys$manager:acme_ca.crt

This example is suitable for the Red Hat Directory Server (also known as the Fedora Directory Server).

The LDAP Persona extension must also be loaded using the MCR utility:

$ MCR SYSMAN
SYSMAN> SYS_LOADABLE ADD LDAPACME LDAPACME$EXT
SYSMAN> exit

$ @SYS$UPDATE:VMS$SYSTEM_IMAGES.COM

Following the load of the LDAP Persona extension, the system must be rebooted:

$ @SYS$SYSTEM:SHUTDOWN

If there are no errors during startup, then the LDAP Persona extension was loaded correctly.

Change the SYS$MANAGER:ACME$START.COM file to contain a pointer to the initialization file and to start the LDAP extension automatically.

Add the following definition line to ACME$START.COM:

$ DEFINE/SYSTEM/EXECUTIVE LDAPACME$INIT SYS$STARTUP:LDAPACME$CONFIG-STD.INI

To start the server at ACME load time, add this line:

$ @SYS$STARTUP:LDAPACME$STARTUP-STD ! LDAP

Finally, configure the system to start the ACME subsystem by adding this line to SYS$MANAGER:SYSTART_VMS.COM:

$ SET SERVER ACME/RESTART

The description from Hoffman Labs is a perfect example of how community support works!

Update: A nice description (from the VMS Help subsystem) of the ACME server can be found here; it describes SET SERVER ACME_SERVER.