- Contacts
- Mobile Computing
- Solutions for email
- The NHS
- Security Solutions
- Remote Access SSL VPN
- Password & Identity Management
- Internet Firewall
- Secure DNS Server
- Document Collaboration
- Web Content Management
- E-commerce
- Alumni Membership
- Network File Encryption
- USB Memory Drives
- Smart Cards & Single Signon
- Aladdin eToken
- URL Web Filter
- Fault Tolerant IP
- SSL Acceleration
- Tape Backup
- Network Storage
- Wireless Networking
- Domain Names
- Resources
- Site
SQL Slammer Worm : Technically Speaking
Firewall's Baseline Protection
Isn't it obvious that every internet facing system should have some boundary control mechanism in place? a Firewall for example?. Well ok that's true but a firewall that lets undesirable traffic through to the 'protected' systems is no firewall at all.
For the worm to have had such a widespread and significant effect on the Internet as a whole, it must be the case that thousands of SQL servers, in all their various guises, were either exposed directly, i.e. without any boundary control mechanisms, or behind a badly configured firewall which let the UDP / 1434 traffic through from infected systems.
No matter how much we believe our firewall's are secure and actually it is obvious they are not! how can anyone justify placing any kind of sensitive data on a web server?
What ever your platform or web server, IBM; Microsoft; Apache that you chose to deploy, you have to assume that any such system placed in such a hostile environment as the Internet, will be compromised at some point. The patch isn't the issue! We have the basic architecture wrong!
Database Connectivity
A typical scenario involves intimate connectivity between the user interface on the web server and the back end data using some form of data connection, e.g. port 1433 running some form of application layer such as Microsoft's ADO. Compromise the web server and the intruder now has direct access to the database, consider the implications of a simple SQL statement 'DROP ALL'.
In many instances the database engine is actually on the web server, the system architect believing that a simplified snapshot of the corporate database located there is significantly safer that allowing the web server to connect directly to the main database itself. However, once compromised that server would probably deliver the means to gain access to the back end database as well as the local snapshot.
Hopefully the architect will assume that the hosting of the database engine on the same machine as the web server is both inefficient as well as a security risk and will split these functions across two or more machines. In some cases they may even decide that it would be better to locate the servers on different zones on the firewall. This is innefective as a countermeasure; the risk is brought about by the connectivity at the SQL level.