How To Set Up Centralized Security Policy Management Across Multiple Remote Proxy Servers With SafeSquid

Enterprises with multiple geographically distributed locations, face challenges in enforcing a universal Internet Access Policy across the enterprise. Usually, each location deploy their own preferred  content filtering solution, and hence can not synchronize the Corporate Internet Access Policy (CIAP) globally. SafeSquid's Multi-Proxy or Master-Slave feature allows you to enforce your CIAP universally across the enterprise, irrespective of the geographical location of a remote office. Master-Slave configuration ensures that policies are enforced globally, and that any changes made to the policies on the Master SafeSquid server, get synchronized to all the Slave servers across the Enterprise, in real-time, thereby greatly reducing an Administrators management overheads. SafeSquid's Master-Slave feature is so granular, that you can define unique user authentication mechanism for each location, unique access policies for a specific location, exclude or include locations a policy should apply to, create granular access policies based on the group a user belongs to, and much more. Master-Slave can be implemented, irrespective of whether the Enterprise has a common Internet Gateway or a distributed one.

Master-Slave in a central gateway scenario

Master-Slave in a distributed gateway scenario

A Master server can be set up in the normal way you would set up a stand alone server, and you do not have to do anything extra during the installation, except ensure that the Slave servers are able to access SafeSquid interface, either on a private internal connection, or via the Internet. For allowing access to SafeSquid Interface via Internet, you will have to make the Master server listen on a static (live) internet IP. Next, you need to make the Master server listen on an additional port on which to allow access only to the SafeSquid interface, other than the port on which it will server the users. Then create entries in the Access Restrictions section, to allow the slave servers to access the interface. If the remote locations have static internet IPs too, it would help in securing access to the Interface based on the IP of the locations, and not from anywhere else.

Suppose the Master SafeSquid is listening on port 8080 (default). Now, you need to make it to listen on port 8081 too, and allow access only to the web interface on this port. To make SafeSquid listen on port 8081, go to Config > Network settings and create the following entry -

Next, click on 'Save settings' in the Top Menu of the interface, save the settings, and restart SafeSquid service. When SafeSquid starts this time, it will listen on both, port 8080 and 8081. Next, you need to create an entry under Access Restrictions, to allow access only to the SafeSquid interface, on port 8081.

The above entry means that the proxy will accept requests on the specified interface (IP=152.23.163.10 which is supposed to be the static IP, and PORT=8081) from the specified source 'IP Address' (from any source IP if left blank) and allow them access to the web interface (Access=config). It will additionally apply a profile 'SLAVES' to such requests.

Note: The entries in Access Restrictions are applied from top-to-bottom hierarchy. The first entry that matches is applied, and the rest are ignored. Hence, all IP based entries should precede non-IP based rules, else the entry will never be applied.

At each of the remote locations, while installing SafeSquid, you will need to define the IP:PORT of the Master server, from where the Slave can fetch the configuration file, for synchronization. based on the above example, this would be 152.23.163.10:8081, the IP and port that is configured on the Master server to allow access to Slave servers.

Master Proxy Configuration Section in SafeSquid for Windows Installation

Synchronization Time Setting in SafeSquid for Windows

Master Proxy Configuration Section in SafeSquid for Linux Installation

Synchronization Time Setting in SafeSquid for Linux

By default, these values are a blank in both SafeSquid for Windows and Linux. You need to change this to 152.23.163.10:8081. The polling interval in seconds, at which the Slave should request configuration updates from the Master server, is by default set to 60 seconds. You can change it to any acceptable value.

Another point to note during the installation, is to define a unique HOSTNAME for each SafeSquid Slave. You can either specify the HOSTNAME during the installation, or leave it blank, and later specify it from the SafeSquid Interface > General Section. Specifying a unique HOSTNAME will help you later, for defining granular policies based on these hostnames.

Once done, when the SafeSquid Slave server starts, it will fetch the configuration file from the Master Server, and then update itself again every 60 seconds. You can verify if the Slave is properly synchronizing with the Master, from the 'View log entries' in the Slave web interface. You should find entries similar to the below screen shot -

You can use the unique HOSTNAME of a Slave server, to create granular polices, that should apply to specific Slave servers. For example, if you would like a Slave server, with hostname PROXY3, to authenticate users from an LDAP / Active Directory Server within its network, all you need to do is specify the hostname of slave server in the entry that you create in the LDAP Configuration section, with its local authenticating server details. This way, you can configure a unique authenticating server for each slave server. 

Similarly, you can create unique profiles too, that should apply to specific slave servers, by defining their hostname, in the 'Proxy host' field. This field supports regular expressions, so you can create a profile to cover multiple slave servers, e.g. (PROXY3|PROXY5|PROXY8)

You can then use the profiles so created, in any of the filtering sections; like URL Filtering, Mime Filter, Keyword Filter, etc. for defining granular access policies.

Download: You can download SafeSquid free editions from here.

Also see: Other SafeSquid howtos 

Oracle or MySQL, Which Provides More Security?

Oracle and MySQL are the two pioneers in database technology at present, Now Oracle Corporation has bought MySQL company itself. Both Oracle and MySQL provide their own unique, remarkable and state of the art methodology in data storage and retrieval. Oracle has a leading advantage over MySQL in this field of database because it has been around for more than a decade. Most of the advanced data storage and sql functions were introduced by oracle which was later adopted by others like MySQL in their systems which makes them a tough competitor even though oracle has years of experience. The advantages that MySQL has over oracle are that, the MySQL being an open source software, it is an application which is under constant improvement. So who outperforms the other? For getting answer for the question we need to take into consideration some criteria which can be used to compare both and end up in a conclusion. Security features can be considered as one such criterion. So let's see some of the security features that oracle and MySQL provide in their systems.

First to start of with, some of the security features that oracle provides in their systems are as follows

1.Oracle DB vault:
This is a new feature that the oracle has added lately in their new release, the 11g. This provides advance privileges to users, improved access control and more informative services like how, where and when the applications or the users access the database.

2.Oracle Advance security transparent data encryption (TDE):
This facility provides data injection without causing major changes in the application code.

3. Audit Vault:
This provides advance book keeping services. This includes reporting, consolidations, alerting functionality and protection of audit data.

4. 'Transparent' data encryption:
Transparent data encryption provides encoding and decoding of data when it is read to and from an authorized user. The users are not aware of these encoding and decoding and also the application don't have to be modified to cope up with this security feature.

Now that some of the oracle security measures had been discussed, then moving on to MySQL some of the security features that MySQL provides are:

1.Access control list(ACL):
This is the main security feature that MySQL provides. ACL provides the database users with varying level of access to database and tables, and the operation are controlled according to certain levels that has been predefined. For example, in a MySQL system the operation like select, update, insert and delete can be set for users in such a way that the user can only perform the operation which has been set by the administrator.

2. 'SSL' Encrypted Connections
Secure socket layer provides secure communication between two clients. The MySQL provides additional encryption features by making use of the SSL. The communications are more secure by the use of this feature.

These are the security features that both oracle and MySQL provides. These features are under constant development which would improve as time progresses and the data storage will become more secure in the future.

Microsoft SQL Server 2000 Security

The SANS Institute Page 1 of 6 Microsoft SQL Server 2000 Security The following is a checklist of security guidelines to follow in securing Microsoft SQL Server 2000. It is divided into categories: 1) Setup and General Issues, 2) Authentication, Users and Logins, 3) Permissions, 4) Logging, and 5) Applications. Within each category, the guidelines are described as Mandatory, Recommended or Paranoid; these labels are intended to help you prioritize your actions and to weigh the relative importance of each …

Setup and General Issues • [Mandatory] The Internet firewall should block all packets going to or coming from the database servers. Consider regulating traffic from the internal LAN as well. SQL Server primarily uses TCP 1433 for data sessions and UDP 1434 for pre-session handshaking. But be aware that SQL Server can also use UDP 137, TCP 139 and TCP 135. • [Mandatory] Stay abreast of the latest Service Packs and hotfixes, and install them as soon as feasible; however, do not blindly install Service Packs or hotfixes without first testing them on non-production servers, and without first backing up the production server. Keep in mind that SQL Server has Service Packs separate from the operating system’s Service Packs. • [Mandatory] Physically secure database servers and their backup media in locked, access-controlled rooms. Provide electronic surveillance when appropriate. • [Mandatory] In general, disable services or features of SQL Server that you are not currently using, such as SQL Mail. • [Mandatory] Scan the database server with the Microsoft Baseline Security Analyzer (MBSA) or similar auditing tool to reveal common insecurities. • [Mandatory] Regularly audit all shared folders on the database server to ensure that all permissions are minimal and that none of the shares are unnecessary. Be especially wary of shared folders that permit Write access. • [Mandatory] When replicating databases over the Internet, set up a router-to- router Virtual Private Networking (VPN) tunnel to connect the two LANs. When replicating over untrusted internal networks, use IPSec to encrypt the replication traffic. • [Mandatory] Assign a long and complex password to the SQL Server service account (preferably 25 characters or more, with 15 characters the minimum)….. • [Mandatory] The setup program for SQL Server should have done this already, but set the NTFS permissions on all database-related files, including the SQL Server binaries, to permit only Read & Execute to Authenticated Users, and Full Control for System, Administrators and the SQL Server service account. If you change the SQL Server service account, do it using Enterprise Manager so that permissions will be changed automatically. • [Mandatory] Use NTFS audit settings (SACLs) to track failed access to database-related files. • [Mandatory] The setup program for SQL Server should have done this already, but, on the following registry keys, remove all permissions for the Everyone group and grant Full Control to the SQL Server service account and local Administrators, then audit all failed access and all successful writes to them as well: HKLM\Software\Microsoft\MSSQLServer (for a default instance) or HKLM\Software\Microsoft\Microsoft SQL Server\ Instancename (for a named instance, if any). • [Mandatory] Delegate authority over the server and its databases by utilizing fixed server and database roles appropriately, or by creating your own custom roles, so that excessive power is not being placed in the hands of those who don’t need it. In short, do not simply place everyone in the sysadmin role out of convenience. • [Mandatory] All database and server management scripts should be stored in an access-controlled NTFS folder. Audit all access. Scripts should not contain hard- coded passwords. Consider digitally signing these scripts using the Windows Script Host (WSH) 5.6 or later, and warn on the attempted execution of scripts that fail signature verification. • [Recommended] Disable cross-database ownership chaining (KB810474). It is disabled by default after SP3 is applied to SQL Server 2000. • [Recommended] Regularly audit what the Public role has access to. This role is roughly equivalent to the Everyone group in the operating system. Remove or limit the rights of the Public role whenever possible, but do not explicitly deny permissions for it (simply remove them). • [Recommended] Regularly audit who has Execute permission on all stored procedures, especially xp_cmdshell. The Guest and Public logins rarely need the Execute permission. When in doubt, grant permission only to the sysadmin role. • [Recommended] When using UDL files, assign restrictive NTFS permissions and audit all access to the files. Avoid storing passwords in UDL files by using Integrated Windows authentication.