Raz-Lee Supports SSL in i5/OS Firewall

Published: October 9, 2007

by Alex Woodie

Raz-Lee Security has added support for Secure Sockets Layer (SSL) encryption in iSecurity Firewall, the firewall component of its iSecurity suite that controls access to OS/400 and i5/OS assets via exit points, object-level security, IP packet filtering, user- and group-level security, and other techniques. Support for SSL encryption will make it easier to incorporate iSecurity into the corporate data center without degrading performance, according to Raz-Lee.

Earlier this month, Raz-Lee announced that support for SSL in iSecurity Firewall will bring several advantages, the most important being that users can now adopt specific user-to-port network rules for users of common network services, such as ODBC, FTP, Telnet, Signon, Remote Access, and DDM servers.

What's more, they can do so without requiring the use of the port restriction capabilities of i5/OS, which can bring several disadvantages, the company says.

"Until Raz-Lee implemented SSL support in Firewall, the only way to implement user-to-port rules was to use the OS/400 port-restriction capabilities," says Shmuel Zailer, CEO of Raz-Lee Security. "As a result, companies needing to define service-to-branch office rules often found that this resulted in unacceptable performance degradation."

Another detriment to using i5/OS' port-restriction capabilities is that it requires a relatively high level of technical knowledge, Zailer says. As a result, it "is often very risky, as a slight error may disconnect users from the system!" i5/OS port restriction does not have simulation capabilities, which can make it harder to set up, and its logging file is not part of the standard log files provided by the operating system, the company says.

In a Raz-Lee technology brief available on its Web site, the company says it added SSL support to iSecurity Firewall to satisfy the requirements of one of its customers that was struggling to enforce the use of SSL with ODBC connections among its various subsidiaries.

Some of the customer's subsidiaries had IP addresses that supported the use of SSL, and others did not. The company wanted to make sure that any of the subsidiaries that had the SSL capability were forced to use that SSL capability, while allowing the subsidiaries without the SSL capability to continue to access ODBC with their unprotected connections.

                     Post this story to del.icio.us
               Post this story to Digg
    Post this story to Slashdot