May 11th, 2004 02:41 PM
And if you want any more details about the project, just ask about what area for me to emphasise and I'll let you know.....The above post was just an overall scope of what is happening with the project
May 11th, 2004 03:04 PM
I suggest storing the database on another server. If someone broke into your webserver your customer database is up for grabs. Seperate the data from the functionality. Create one segment for the webserver(s) and another for your database server(s).
The web server, as the name suggests, is primarily concerned with the sites web service which contains e-commerce components, and also stores client/customer details locally on the server into a database.
And you are going to enable them because you will be running an e-commerce site on it and I've never seen one that used only static html.
The operating system consists of Microsoft Windows 2003 Server Web Edition running IIS 6.0. IIS 6.0 installs in a highly secure state, serving only static HTML content until other features and file types (such as ASP and ISAPI) are enabled
How do you monitor/administer those systems? Physically sitting behind those machines?
All Servers are currently stationed in a secure facility, on there own internal network. There are no other client or servers on the internal network and the only outside link to the internet resides through the ISA Server (firewall).
Experience is something you don't get until just after you need it.
May 11th, 2004 03:16 PM
Thanks a heap for your post it will be very helpful for the documentation of the security monitoring as i was unsure of how to go about documenting it all. The way you've listed those points out will provide a good structure for the document, it was the exact response I was after......
P.S there are no costs involved with the project as the teacher provides us with everything
May 11th, 2004 03:38 PM
A team member was reading through this topic and we dont get why its not good to have AD and DNS on the same box, the only reason we could think of is load concerns.
if it is possible, segregate them (DNS from AD) - but dont put DNS on IIS server.
May 11th, 2004 03:41 PM
Glad I could help.
Time and level/breadth of skill required are costs.
there are no costs involved with the project as the teacher provides us with everything
May 12th, 2004 05:32 AM
After all this has been documented, We have to perform security tests on the servers. Anyone have any suggestions on what areas of security to test and how?
May 12th, 2004 11:04 AM
Ideally, I'd say, put the web server and any dependent servers (e.g. SQL) outside of your windows domain you use for other things, and don't share any logons between those and other (more important boxes). Also keep them in a separate network segment (vlan will do if your switches are capable), and firewall access between them and your main network, as well as between them in the outside world. Ideally allow no access to your internal network from the DMZ.
This approach is known as a "DMZ".
You haven't mentioned what your DNS is for. If your DNS is trivial, holding a few domains with simple records that don't change very often, you don't need to run DNS at all, just get your ISP to run it instead. I realise it's very difficult to move DNSs around without a break in service though.
Seriously, you should not need to be running a (public) DNS unless you're doing something fancy with hostnames or hosting a huge number of domains which you change very often.
In any case, you'll want a secondary somewhere on a different network.
If the DNS is an AD DNS for resolving Windows boxes hostnames, (as per Active Directory setup), place it internally and don't allow any access (also use a domain name which does not exist on the internet, like yourcompany.internal)
Of course you will from time to time require access to your web server / sql server in the DMZ. However, it is a good idea to have any communication initiated from the inside of your firewall, that way anybody who "owns" the web server will have no way in.
May 12th, 2004 02:52 PM
This is the proble, with sites like this... a slew of technical people trying to answer administrative problems. Nearly every single answer has been about configuration... configuration has already been resolved, next is the all important aspect of keeping the system secure and this is not a question that can be answered with Linux IDS systems or AD configuration tricks or DMZs... this question can only be answered by developing a policy to define upkeep and auditing procedures.
To answer your second question balls... so long as you use any industry standard auditing tool (as i said before Retina is my favorite due to it's well formatted report generation, its CHAP technology, and its ease of use) and use it regularly. Also develop a series of auditing rules and filters, taking care to document why and how.
On going security is really about showing due care and the only way to do this is to ensure everyone knows what is expected of them, someone knows why it is expected to be that way, and verification that things are done as expected. Doing more than this will cost you money as you end up spending more than your assets are worth, any less will leave you in a postion of liability in the event of a compromise.
The actual tools don't matter, so long as they well known. Industry standard scanner X may suck compared to this kick ass scanner your friend made... however the lost resources in defending your friend's scanner in the event of a compromise will end up costing you. Those pushing to find you liable will want to know why you didn't just use something standard and maybe not, maybe they'll just fire you under the assumption that you are dumb or took a bribe or something. Make sense?
May 12th, 2004 03:23 PM
Balls: Since this is a learning environment I will address the question regarding DNS and AD being housed together.
AD is entirely dependent upon properly configured DNS in order to be able to function correctly, (it really doesn't work without it). The problem comes when you look at a properly configured AD integrated DNS zone. There is more information there about the nitty-gritty details of your network, it's resources etc. than you can shake a stick at. You really don't want this information exposed to the public network.
This has lead to what is called Double-DNS or Split-DNS. The AD servers should be maintained _entirely_ on the trusted network since they all contain the sensitive information. All the clients should be set to get their DNS resolution from these internal AD servers.
In the DMZ should be your public DNS servers. They should contain _only_ records that pertain to your publicly available resources such as nameservers, web, ftp and mail servers, etc. Zone transfers should be enabled to only the nameservers listed in each zone.
The internal servers should be set to use forwarders. The forwarders are set to the DMZ DNS servers and for extra assurance the firewall should only allow outbound DNS from the internal DNS servers to the DMZ DNS servers, (not onwards to the public network). The DMZ DNS servers should be allowed free access through DNS to anywhere on the net and incoming DNS requests should only be allowed to the DMZ DNS servers. DNS Requests from the DMZ to the trusted network should be blocked, there's no reason for the DMZ servers to have any idea that the trusted network exists.
In this way external devices making DNS requests can only reach the DMZ and can therefore only reach publicly available information about your zone. The AD DNS servers can only make requests of the DMZ servers which keeps their DNS traffic off the public network entirely.
Finally, you can use the same domain name internally as you do publicly. The problem comes when internal users try to access external resources in the same domain. They will fail unless you place fixed records in the AD DNS zones that point to the external resource because the search will cease at the AD DNS server because it is an authoritative server for the zone.
As you can see from that, the DMZ servers contain no information that you do not want to be publicly available and they aren't allowed to even request it from the trusted network. This makes it practically impossible for anyone to enumerate your internal structure using DNS.
Integrating the two on a publicly available server simply elevates your risk significantly.
Don\'t SYN us.... We\'ll SYN you.....
\"A nation that draws too broad a difference between its scholars and its warriors will have its thinking done by cowards, and its fighting done by fools.\" - Thucydides