There are many ways to hack a Web server. One cannot assume that database servers are unassailable fortresses. So what should one do if a Web server which derives data from a database needs to be made accessible? The most obvious answer to this question is to run like hell to a calmer job. Luckily there are other, more rational answers. This article attempts to show the reader how to find the answers.
Microsoft SQL Server is a popular and robust environment for many applications that use databases – it features excellent multi-access capabilities, comprehensive security coverage and can easily be transported to other database platforms. This article aims to identify certain types of risks that might result from inappropriate management of the Microsoft SQL Server.
Your primary goal as an administrator is to ensure secure access to the database on the server. Access to databases can be controlled by “pure” access mechanisms incorporated in the Database Management System itself, or also enhanced by mechanisms that are external to the database server.
When you think of version 6, the “next generation” of the Internet Protocol, your first thought is probably more available addresses. Indeed, the primary reason for developing a new version of IP was the anticipated critical shortage of addresses under the 32 bit addressing scheme of version 4. However, IPv6 provides for more than just an increase in the number of available addresses. It is also designed to provide for better performance and, even more important in today’s business world, better security of IP communications.
In Part I of the series we dealt with the installation of the IIS service whilst Part II covered issues related to configuring an IIS Server to handle encrypted connections. Until now, we used Internet Services Manager, a standard administration tool, to introduce changes in the IIS configuration settings. Part III is concerned with some new administration methods allowing one to modify IIS configuration settings that were previously unavailable.
The previous article showed you how to install, configure and, finally, how to connect your new Web Server to the Internet. Now you may be sure that the server runs securely. You have subscribed to Microsoft security bulletins not to omit any important patches. All you have to do now is to rest on your laurels. Are you sure about that?
IIS, an acronym for Internet Information Services is a web application server program that handles HTTP requests, ranking second in popularity (after Apache). Its popularity is mainly due to the fact that IIS sites are so easy to implement – just a few mouse-clicks away – from a total disaster.
In part 1 of this three part series on SMTP relays we talked about the definition and functions of an SMTP relay and how they’re used to protect Exchange Servers protected by an ISA Server firewall. In part 2 we went into more detail and described the features and functions of the various types of SMTP relays used in production networks. Make sure to check out these articles if you haven’t had a chance to do so yet. In this article you get the step by steps to create a secure non-authenticating inbound SMTP relay.
Microsoft has made a number of changes to the default settings in Windows 2003 to make it more secure “out of the box.” In Part 2, we’ll examine the changes that have been made to the default settings for common services and changes in the authentication process, and we’ll discuss some areas in which some believe that Server 2003’s defaults are still too open.
In this article I will focus more on the global settings of password policies and where to change them to incorporate the 20 Golden rules of good password management in Part 1. This article will describe the possibilities of these policies and will run though real world reasons where these global settings should be applied. Different ways of generating passwords will also be described to make it easier for your users to come up with new passwords in a quick trouble free way.
