Sybase Configuration

1. Enable auditing.

   Sybase does not install the auditing components by default. It is worth configuring the auditing facility because you never know when you'll need it, even for the diagnosis of routine problems, let alone security issues.

   Auditing is covered in depth in Chapter 12 of the Sybase ASE System Administration Guide, and we recommend that you read that chapter before proceeding, but briefly :

   You can use the auditinit program or the installsecurity sql script to install the auditing capability.

   You can check if auditing is already installed by running

    sp_configure 'auditing' 

   You can specify up to eight tables to store audit information; these tables are called sysaudits_01, sysaudits_02, and so on. Sybase recommends that you use at least two tables on separate devices so that audit logs can be archived from one table while another table is being written to.

   You can define threshold procedures for each audit segment, to copy the data from the audit segment to some other, archive location. Use sp_addthreshold to add the procedure.

   You can define the size of the audit queuethis is the number of audit records that Sybase can hold in memory before flushing the queue out to disk. This should be tuned to an appropriate value for your configurationlow values will mean more disk access, high values will mean better performance but an increased risk of the data in the queue being lost in the event of a server crash.

   You should specify what you want to happen if an audit device is full, using the "suspend audit when device full" setting. Set this to 1 if you want to halt the audit process and all user processes that cause an audit event if the device is full; set it to 0 if you want older audit tables to be overwritten automatically.

   Should you need to, you can enable and disable auditing using the auditing option to sp_configure; 1 enables auditing and 0 disables it.

   Once auditing is correctly configured, you can control what gets logged using the sp_audit procedure. Run sp_audit without a parameter to list the current settings.

   As previously noted, having a good audit log can really help to diagnose problems even in routine, everyday use. It is invaluable when trying to diagnose security problems, but you must have some sensible procedural framework around the manner in which you use the logs if you want to get the most out of your audit logs.

2. Disable xp_cmdshell.

   The easiest way for an attacker to compromise a system running Sybase is to use the xp_cmdshell extended stored procedure. If you aren't using it, xp_cmdshell should be removed.

   In addition, it might be helpful to set the xp_cmdshell context to 1, if it was set to some other value. This will force xp_cmdshell to use the security context of the currently logged-in user, which must be an administrator under Windows NT. On other platforms if xp_cmdshell context is set to 1, xp_cmdshell will succeed only if Sybase was started by a user with superuser privilege. If "xp_cmdshell context" is set to 0, xp_cmdshell will execute in the security context of the user that Sybase is running as; this may pose a serious security risk.

   To drop the xp_cmdshell extended stored procedure, run

    exec sp_dropextendedproc 'xp_cmdshell' 

   There is little point in dropping xp_cmdshell if you do not also delete the sybsysesp library that contains it unfortunately , the library also contains other extended stored procedures that may be useful to you: xp_freedll, xp_logevent, and xp_enumgroups.

3. Disable Java if possible.

   As detailed in previous chapters, the Java support in Sybase, while an exceptionally powerful feature, can be abused by an attacker. If you are not using the Java feature of Sybase, disable it using

    sp_configure 'enable java', 0 

   You will need to restart the Sybase server after changing this configuration setting.

4. Disable filesystem proxy table support if possible.

   The extensive filesystem interaction features in Sybase present an extremely useful feature in some situations but could pose a serious security problem; if you are not using themand they are currently enabledyou should disable them.

   To see if the filesystem proxy table support is enabled, use

    sp_configure 'enable file access' 

5. Don't install test databases/clear test data.

   If you have installed any test databases (none are installed by default), you should delete them.

6. Use strong authentication.

   Sybase has the ability to integrate with Kerberos, Windows NT Lan Manager, and DCE for authentication, encryption, and data integrity. If possible, one of these mechanisms should be used rather than the mechanism built into Sybase. These mechanisms provide true enterprise-class user management and offer a greatly improved level of security over the default behavior. For a full description of how to interface Sybase and these third-party authentication, encryption, and integrity mechanisms, see Chapter 14 of the Sybase System administration guide.