Ongoing web server security?

I am currently building a webserver for a project which consists of 3 computers, 1 which has windows 2003 with IIS installed, another with windows 2003 installed with active directory and DNS and another installed with windows 2003 and ISA server. We have secured all systems by blocking unessecary ports and applying SSL and all that mumbo jumbo. Now we have to document the ongoing security monitoring of these servers and I was just wondering if any of you had any suggestions on what ways i could monitor the security on these systems.

might be miss understanding you but either a host intrusion detection system or a network intrusion system comes to mind depending on how much you whant to log and what.

Although you are using 2003, I recommend to read all documents about hardening IIS.
Also, I wouldnt recommend that DNS server runs AD services. Im assuming that both (DNS and IIS) are behind ISA, but still... if it is possible, segregate them (DNS from AD) - but dont put DNS on IIS server.

DNS isnt on the IIS server, it is on the AD server. And di0strb, what are some free IDS software out there? I have looked around for some but they are generally useless.

Go get you a cheap box and put a couple of nics in it. Then just load up snort listening on each nic and hook them up before and after your main router or firewall.

You could then load Ntop on it so you could see all your bandwidth percentages (very nice program check it out).

Then if you want you could run etherape so you could see a visual blueprint of your network and all its connections (not that handy, but looks really good on a noc.)

Finally, you could have ethereal running on the back nic and it would examine all your activity at a packet level.

Heck, if you don't have a firewall up then you could set up iptables as well and add some rules to it.

This box could be a 100 mhz POS. Just put slackware on it and load just the programs you need and disable all the servers on it. Just a cheap idea that would run independent of your other servers and wouldn't take a stab at your wallet (most schools and businessess throw theses away).

I don't mean to be picky but:

Quote:

---

and all that mumbo jumbo

---

just doesn't sound good..... Securing the server by blocking uneccesary ports is one thing but if you aren't patching the available services the firewall might as well not be there. I am also concerned about an AD controller in the mix.

Can you give some more detail about what you are trying to acheive, how your architecture will look etc. so I better understand your aim and approach. There might be a much simpler, (which is therefore more secure), approach.

Quote:

---

Originally posted here by balls_okeeffe
Now we have to document the ongoing security monitoring of these servers and I was just wondering if any of you had any suggestions on what ways i could monitor the security on these systems.

---

IMO the two simplest and best things you can do are to subscribe to [email protected] and READ IT, and make the servers' event logs your morning paper. Nothing beats staying in touch with the servers on a frequent basis. If you are not restricted to just the stuff that comes with the operating system, an intrusion detection system is certainly an idea to consider.

Are you doing this as a school project, or is it work-related?

Either way, some questions to consider:
Are you only in charge of handling the webserver, or are you working on all aspects of this?
How much time per week are you able to spend monitoring the systems?
How much of a budget is there for software like intrusion detection systems, etc.?
How many other boxes will be residing on the same physical network as these servers?
What is the relative threat/risk of an in-person attempt to break the security of the box?
What is the likelihood you will be specifically targeted and attacked (ie: Industrial espionage)?
How many hours per day will there be staff present and capable of reacting to one form of attack or other, or conversely, how many hours per day are the boxes going to be left on their own?
How many "local" untrusted networks (sitting behind your border firewall, but may be open for use by unknown users, like wireless networks, or demonstration networks) are there?
How often are you able to schedule downtime for maintenance?
How easygoing are your superiors when it comes to unscheduled downtime (such as the quick release of Sasser may have required)?

Obviously the answers you give to those questions will be answers to yourself about your needs. Once you answer the questions, you will have a clear idea of what additional steps you will want to take on an ongoing basis.

Once you've correctly setup ISA, enabled SSL, hardened your IIS, setup IDS etc.
There's one thing a lot of people seem to overlook: Audit the webcode!

You won't be the first that got 0wn3d because some dipshit developer created a great looking website that had more holes then swiss cheese.

I also recommened placing the IIS server on it's own segment (create a DMZ; which means you'll need at least 3 nic's in the ISA server). That way if the bad guys somehow got into your webserver they still need to bypass ISA to get onto your internal network.

And one more note, I suggest investing in a hardware firewall. I know MS is pushing ISA as a proxy and firewall combination but I'll never ever use it as a firewall. The reason I'm not using it is because ISA doesn't do anything to harden the tcp/ip stack of windows.

Quote:

---

Can you give some more detail about what you are trying to acheive, how your architecture will look etc. so I better understand your aim and approach. There might be a much simpler, (which is therefore more secure), approach.

---

The network consists of several servers, each with a specific role within the sites local network.
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.
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
The Internet Security and Acceleration Server (ISA) is the sites firewall and only link to the outside world. The operating system consists of Microsoft Windows 2003 Server running ISA 2003.
All current updates/patches/hot fixes for all software including IIS, ISA, Active Directory and all Windows 2003 versions have been installed.
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).

What i'm trying to achieve here is once all the security is in place, I need to document a way to monitor the ongoing security of the site. I dont actually have to perform anything I just need to document it in a report. Any suggestions?

Pick a vulnerability scanner, Retina by eEye is my favorite.
Define and document why you selected it.
Define and document how and when to scan.
Define and document how and when to update the scanner.
Define and document how to verify that it was used correctly and that it is up to date, both that it is the most current library and that the vendor is up to date.
Define and document how vulnerability reports should be formatted and what they should contain.
Define and document what is to be done in the event a scan discovers whatever type of errors it may discover.


Define and document what is audited and why.
Define and document how and when the logs are to be reviewed.
Define and document specific actions to be taken in the event that the logs reveal any number of entry types.

Define and document how all this documentation is to be developed.
Define and document all relevant asset values and the annual costs of existing counter measures, this will help in selecting new counter measures as issues arise.
Define and document all relevant business roles so that the disaster recovery/business continuity people will have a document to refer to
Define and document all relevant key roles and or personal.
Define and document what level this documentation is, who can override, alter, etc.

Hope this helps.

catch

PS. Adding Linux systems as someone else said is a horrible idea, whatever costs you may think you are saving quickly vanish as the operating costs for supporting a whole new platform are calculated in.

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

Quote:

---

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.

---

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).

Quote:

---

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

---

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.

Quote:

---

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).

---

How do you monitor/administer those systems? Physically sitting behind those machines?

Catch,
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......
Thanks again

P.S there are no costs involved with the project as the teacher provides us with everything

Quote:

---

if it is possible, segregate them (DNS from AD) - but dont put DNS on IIS server.

---

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.

Glad I could help. :)

Quote:

---

there are no costs involved with the project as the teacher provides us with everything

---

Time and level/breadth of skill required are costs.

catch

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?

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.

Slarty

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?

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.