Solutions Newsletter - 1st Quarter 2009 - Volume 14 Issue 1

Email to a friend

MultiNet – MultiNet v5.3 is being beta tested. The expected release will be in early calendar 1Q09. New features include:

TCPware - The next release of TCPware will also incorporate the IPS functionality and Ephemeral Port Randomization described in the MultiNet 5.3 new features chart. Other features are under discussion and now is an ideal time for you to submit your enhancement requests to maschio@process.com.

PMDF – The next release of PMDF is being planned. Now is a good time to send your enhancement requests to maschio@process.com. We are tentatively planning to update the out-of-office notices to look like Microsoft Outlook out-of-office assistant. The BerkleyDB (also know as SleepyCat database) will be replaced in the UNIX and Linux platforms, which will improve the stability of PMDF when adding and moving database entries. Now that SPF has been added to PMDF 6.4, we are looking at adding Domain Key (DKIM) as specified in RFC 4871. It a llows the owner of a domain to specify their mail sending policy, e.g., which mail servers they use to send mail from their domain.

PreciseMail Anti-Spam Gateway – Version 3.1 shipped in September. The next release is in the planning phase. Process engineering will implement Advanced Architecture phase 3 and DKIM. Other customer-driven enhancements that have been posted on the pmas email list or requested to technical support are also being reviewed.

Both TCPware and MultiNet’s FTP have been enhanced for higher security allowing for encryption of the communication between the FTP server and client. This is accomplished via support of RFC 4217. In general, FTPS also has better data transfer rates than SFTP. For more information on secure file transfers, read the latest whitepaper: A Comparison of Secure File Transfer Mechanisms : http://www.process.com/tcpip/sft.pdf.

Ever since statistics have been reported by PreciseMail Anti-Spam (PMAS), we have been tracking the incoming spam statistics here at Process Software and some trends have emerged as shown in this graph:

As you can see, spam has been an ever increasing problem. In 2003 as we were building PMAS, spam volumes were becoming high enough so as to really impact the use of email and threaten its very use.

In 2003, spam was quickly rising from 30-50% of incoming mail until late in the year when the volumes approached 80%. In more recent times, spam has risen to over 99% of the incoming mail. Certainly without PMAS, Process and our PMAS customers would be unable to use email.

There are interesting trends to be seen:

All in all, spam remains a major problem, but a manageable problem with high quality anti-spam software such as PreciseMail Anti-Spam.

While we at Process Software strive to create and enhance our products in a high quality manner, as with other software vendors, occasionally bugs do occur causing us to release eco (or patch) kits. Sometimes we will also release enhancements by way of eco kits in between major product releases.

This article details the various ways to learn what ecos have been released.

Info/Announce Lists

Mail lists are maintained for each Process Software product. For each product there is an info-xxx mail list for discussions related to the product and also an xxx-announce list where Process will announce product release and patch/eco information, and occasionally some other important message. The mail lists are:

TCPware-announce@process.com - TCPware TCP/IP stack
MultiNet-announce@process.com - MultiNet TCP/IP stack
SSH-announce@process.com - SSH for OpenVMS
PMAS-announce@process.com - PreciseMail Anti-Spam
PMDF-announce@process.com - PMDF MTA and related modules
VAM-announce@process.com - VMS Authentication Module

You can subscribe to any of these lists by sending an email to the list with -request appended to the list name and the word SUBSCRIBE in the body of the email. For example:

From: myemail@mycompany.com
To: PMAS-announce-request@process.com
Subject: Please add me to the list

SUBSCRIBE

If you are interested in discussions about the products with customers and Process Software you can also subscribe to the info- lists in the same manner. The info lists are named info-PRODUCT@process.com. We also have searchable archives of the info-lists available via the respective product support page on our web site.

List of Critical Patches on the Web:

Links for recommended/critical patches can be found on the web at http://www.process.com/techsupport/patches.html.
For MultiNet and TCPware, patches are ranked based on how critical the issue is. This page lists those with the higher rankings.

Complete lists of patches are available at http://www.process.com/techsupport/eco.html.
You will find links for each product and from there can find the patches you may need. We also always include a list of critical patches in this newsletter.


TCPware and MultiNet ECO Databases

TCPware and MultiNet have searchable databases of the ecos:

TCPware: http://vms.process.com/eco.html
MultiNet: http://www.multinet.process.com/eco.html

Customers can search for ecos based on component, product version, severity, etc. For each eco, you can read the readme file with a full description of the eco. Please note that some ecos in the database may be obsolete or private. We release ecos privately to a specific customer if we can't reproduce the reported problem and can't verify the particular fix or for other special reasons. When the customer confirms that a private fix resolves their issue, we will make it public.

Complete lists of patches are available at http://www.process.com/techsupport/eco.html.

MultiNet

NAMED-070_A052.zip

TCPware

DRIVERS_V582P050.zip

SSH_V582P020.zip

SSH for OpenVMS

SSHVMS-040_A023

PMDF 6.4

Mandatory Patches

ECO: libspf.so, libspfshr.exe
Description: fixes CERT advisory
Release date: 14-OCT-2008
Platforms: VMS, Solaris, Linux
Versions: V6.4

README

Download libspfshr.exe for OpenVMS Alpha
Download libspfshr.exe for OpenVMS IA64
Download libspfshr.exe for OpenVMS VAX
Download libspf.so for Solaris SPARC
Download libspf.so for Solaris X86
Download libspf.so for Linux

Other Patches

ECO: internet.rules
Description: new TLDs added
Release date: 19-NOV-2008
Platforms: all
Versions: all

Download internet.rules

PreciseMail Anti-Spam Gateway

Q. Do you have any tips for rejecting email messages using PreciseMail PTSMTP?

A. For those of you using PMAS PTSMTP, there are some rules you can add to your 00_ALLOWBLOCKLISTS.CF file to reject messages that don't adhere to the SMTP RFCs properly.

The RFCs for SMTP mail don't encourage doing what I'm about to suggest, but there's no denying that they block a *lot* of spam. For most of the rules to follow (and I'll point out the exception), I've never seen a legitimate message rejected.

(These rules can be modified for PMDF sites, but you don't get the benefit of being able to reject messages.)

------------------------------------------------------------

Checking the HELO/EHLO line

The HELO/EHLO command has one parameter, which is *supposed* to be the name of the system initiating the SMTP connection (the client). For example:

 HELO node.example.com 

A lot of spammers, especially spam sent by spambots, do not specify the client's name, but instead will specify the IP address of the server system or, frequently, the string "localhost". PMAS adds the header X-PMAS-External:, which includes the HELO/EHLO command:

 X-PMAS-External: node.example.com [198.115.122.22] (EHLO node.example.com) 

The parts of the header are the reverse DNS name for the sender, the IP address of the sender, and the HELO/EHLO command specified. A spambot line will often look like these:

 X-PMAS-External: node.example.com [198.115.122.22] (EHLO localhost) 

 X-PMAS-External: node.example.com [198.115.122.22] (EHLO 68.152.22.23) 

where "68.152.22.23" is the IP address of the receiving server.

The following rules will reject messages coming in with such HELO commands:

 rule reject header:X-PMAS-External matches_regexp \ 

 ".+\((?:HELO|EHLO)\s+localhost\)" "Bad HELO" 

 rule reject header:X-PMAS-External matches_regexp \ 

 ".+\((?:HELO|EHLO)\s+68\.152\.22\.23\)" "Bad HELO" 

Note that '\' on the "rule" line is a continuation character. If you put the two parts on one line, remove the '\'. Of course, the rules could also be combined into one rule, but the regular expression gets even messier:

 rule reject header:X-PMAS-External matches_regexp \ 

 ".+\((?:HELO|EHLO)\s+(?:localhost|68\.152\.22\.23)\)" "Bad       HELO" 

Obviously, you'd want to supply your own IP address for "68\.152\.22\.23".

Similar discard or quarantine rules could be written to check the Received: headers for PMDF sites not using the PTSMTP proxy server. However, the format of the Received: header will vary and it will depend on PMDF configuration. You will need to contact Process Software for specific help in this area.

Be careful, it is possible that a legitimate system is misconfigured and sends out the wrong HELO command.

------------------------------------------------------------

Requiring a reverse DNS name for the client

This is the rule that you may consider implementing. *Most* legitimate email-sending systems have reverse DNS entries defined (meaning that if you take the IP address and perform a DNS lookup on it, you'll get back a name for the system). A lot of spambots and spammers do *not* have reverse DNS names defined, so the DNS lookup that PMAS does fails, and the X-PMAS-External: line shows "unknown" for the rDNS name:

 X-PMAS-External: unknown [198.115.122.22] (EHLO node.example.com) 

The following rule will reject messages from systems that do not have rDNS names defined:

 rule reject header:X-PMAS-External starts "unknown" \ 

"Reverse DNS for IP address required"

There may be occasional false positives because of this rule, so you may or may not want to implement it.

------------------------------------------------------------

Rejecting SPF "fail"

Section 1.5.7.2 in the Management Guide describes rules to reject, discard, and quarantine messages based on the results of SPF lookups. Messages for which the SPF lookup returns "fail" can be safely rejected, as they're coming from a system not authorized to send mail for that domain.

These are the two rules that I use:

 rule reject header:Received-SPF starts "fail" \ 

"Sender not authorized according to SPF"

 rule discard header:Received-SPF matches_regexp "(?:softfail|temperror)" 

The RFC says that a "softfail" message may be quarantined. "Softfail" can result when the sender isn't authorized, but the defining SPF record does not outright reject the sender.

Q. We'd like to make some changes to the HTML bodypart of the Quarantine Notification messages. I've read the manual and understand what is required (basically, create PMAS_DATA:QUARANTINE_MESSAGE_HTML_ROW.TXT) but is there some way I can test it before the next "PreciseMail Notify" job runs?

A. Yes, you can make a copy of PMAS_QUARANTINE.DAT, edit out everything except for a couple, release the batch job, then put the old file back. You should probably stop the PMAS channel while you do that, unless there really isn't any mail flowing in at that time.

Q. How do I report missed spam?

A. You can report missed spam to the Report-Spam@process.com mailing list.

While we may often see the same spam messages everyone else receives, it is still helpful for us to get these reports as it’s possible that we've never seen a particular type of message.

Usually, we will not reply to Report-Spam posts, but we do look at every one of them. To report missed spam, send the message in its original, unaltered form. Forwarding messages from Outlook or other PC clients is not helpful because the format changes and the client strips out the useful information.

Q. We have a heterogeneous VMS cluster with both Alpha and I64. When I run pmas_compile -v on a cluster member does that propagate changes across the entire cluster? Does the same apply to the auto updates for both SPAM and Sophos?

A. Yes, as long as the cluster members share the same directory.

PMDF

Q. What does a "Y" record in the PMDF connection log signify? Example:

 16-Jan-2008 11:04:37.62 tcp_local - Y 

 TCP|0.0.0.0||200.17.181.103|25 SMTP/urano.cdtn.br/urano.cdtn.br 

A. Y Connection try failed before being established.

Q. Does the J messages get counted in the total messages processed today on the monitoring web page?

A. A message can have both valid and invalid recipients. Valid recipients generate E records, invalid recipients generate J records. If a message has no valid recipients it isn't accepted and doesn't count as a processed message. However, if it has at least one valid recipient, it does get counted. So in some sense there can be J records associated with a message that increments the "processed message" count. But they never make the count any higher.

SSH

Q. I am setting up sftp with a remote non-VMS system. How do I convert the key format?

A. Here is some information on public key authentication when the remote side is running OpenSSH.

The keys used by OpenSSH and MultiNet (and other ssh implementations based on the F-Secure package) are in different formats. You will need to convert the keys to the correct format to use them.

On the Linux side you can use the ssh-keygen -e option to convert OpenSSH keys to the RFC 4716 key file format used by MultiNet. Here is an example that converts the default id_rsa.pub key and then copies it to the MultiNet system -

 # ssh-keygen -ef .ssh/id_rsa.pub > rfc4716.pub 

 # scp rfc4716.pub user@node.example.com:ssh2/rfc4716.pub 

Once this is done the authorization file for the user would need to have a key line added to it to use the new key. For example -

 key rfc4716.pub 

Going the other way you can use the -i option to convert the RFC 4716 to OpenSSH key file format. Here is an example of setting this up -

1.) create a new key pair with -

 $ mu sshkeygen/ssh2/key=key_for_scp 

2.) create a [.ssh2]identification. file that looks like -

 $ type [.ssh2]identification. 

 idkey key_for_scp 

 $ 

4.) Use SCP to copy the key_for_scp.pub file to the other system -

 $ mu scp2 [.ssh2]key_for_scp.pub - 

 "<user>@<server_name>::.ssh/key_for_scp.pub" 

5.) Convert the key from RFC 4716 format to an OpenSSH key file and appended it to the authorization file -

 $ mu ssh/user=<user> <server_name> - 

 "ssh-keygen -i -f .ssh/key_for_scp.pub >> .ssh/authorized_keys2" 

Q. How can SSH access to an arbitrary account be denied?

A. Assuming you want to deny all SSH access for an account (i.e., interactive use, remote command execution, and file transfers), you can grant an identifier to the accounts you want to allow access to (or deny access to, depending on how many of each there are), then use the DENYGROUP or ALLOWGROUP keywords in the config file. For example, you can have "DenyGroups limabeans" in the config file, then for the account(s) you want to restrict, add the rights identifier "limabeans" to it/them.

MultiNet

Q. I'd like to join two sites (actually two organizations) with a secure tunnel using MultiNet IPSEC on an AlphaServer at each site. Selected systems at each site would then be configured with static routes which use their respective "local" AlphaServer as the route to systems at the "remote" site. Can this be done?

A. Yes, Page 11-50 to 11-51 of the MultiNet 5.2 Administrator's Guide contains the following information that should allow you to set up the tunnel between the two sites.

GIF (generic/gateway) interface Usage

The gif interface allows for the creation of Virtual Private Networks (VPNs) by encapsulating the traffic directed to the interface's remote address to within an additional IP header, creating a virtual network. If the traffic over this interface is subject to IPSEC, then the virtual network is private.

Each gif interface has four IP addresses that need to be configured:

The gif is configured with the following commands:

local system:

 $ MultiNet SET/INTERFACE/CREATE GIFn ! n is unit number, compile time       -limited 

 $ MultiNet SET/INTERFACE -GIFn/PROTOCOL=IP/ADDRESS=A.B.C.D/POINT_TO_POINT=E.F.G.H 

 $ MultiNet SET/ROUTE/ADD=(DESTINATION=A.B.C.D,GATEWAY=127.0.0.1) 

 $ MultiNet SET/ROUTE/ADD=(DESTINATION=E.F.G.H,GATEWAY=A.B.C.D) 

 $ MultiNet SET/INTERFACE GIFn/TUNNEL=(DESTINATION=I.J.K.L, -GATEWAY=M.N.O.P) 

remote system:

 $ MultiNet SET/INTERFACE/CREATE GIFn ! n is unit number, compile time –limited 

 $ MultiNet SET/INTERFACE -GIFn/PROTOCOL=IP/ADDRESS=E.F.G.H/POINT_TO_POINT=A.B.C.D 

 $ MultiNet SET/ROUTE/ADD=(DESTINATION=E.F.G.H,GATEWAY=127.0.0.1) 

 $ MultiNet SET/ROUTE/ADD=(DESTINATION=A.B.C.D,GATEWAY=E.F.G.H) 

 $ MultiNet SET/INTERFACE GIFn/TUNNEL=(DESTINATION=M.N.O.P, -GATEWAY=I.J.K.L) 

M.N.O.P is a public IP address (interface) on the local system. I.J.K.L is a public IP address (interface) on the remote system. A.B.C.D is the private network address on the local system. E.F.G.H is the private network address on the remote system. Routing can be set up to pass traffic for other systems through the tunnel. A command procedure could be written to create the tunnel and be used on each side with some minor exchanging of parameters. IPSEC traffic could be statically configured, or managed with the RACOON IPSEC Daemon.

To get rid of the tunnel:

 $ MultiNet SET/INTERFACE/DELETE GIFn !delete tunnel and interface 

 $ MultiNet SET/ROUTE/DELETE=(DESTINATION=A.B.C.D, GATEWAY=127.0.0.1) 

The VPN encapsulates IPv4 traffic within another IPv4 packet (RFC 1853, RFC 2003).

This VPN is not compatible with Microsoft VPN which uses either PPTP (Microsoft Proprietary) or L2TP/IPSec (RFC 2661).

Q. I am using MultiNet 5.2 on an OpenVMS 8.3 AlphaServer. The output of the command " $ multinet show/buffer" at the end reports the following message: " *** 2 BUFFERS ARE MISSING!!! ***". What does it mean?

A. MultiNet 5.2 will report some buffers missing because the MultiNet show command doesn't list (and count) buffers that are used for IPv6 objects. This has been corrected in MultiNet 5.3.

Q. How do I get the outbound IP to look like the cluster alias IP so the NAT works properly?

A. You cannot have outbound connections use the cluster alias IP address. This is one of the reasons why it is suggested that it only be used for connectionless protocols (such as NFS) for automatic failover.

Contacting Process Software

E-mail:
info@process.com - General information
sales@process.com - Sales
international@process.com - International Sales information
support@process.com - Technical Support
careers@process.com - Human Resources
webmaster@process.com - Webmaster

Phone/Fax/Address:
U.S.A./Canada - (800)722-7770

International - (508)879-6994

Fax - (508)879-0042

Mail:
959 Concord Street
Framingham, MA 01701-4682

Home > Newsletters > 1st Quarter 2009 - Volume 14 Issue 1