Thanks to everyone that responded. It's nice to know that my security concerns weren't completely out to lunch, but at the same time I have heard a few things that I have never heard of (SecureIIS), or really considered in this case (insurance).
With regards to SecureIIS, I'll be doing some research over the next few days to see how it applies in this case. Thanks for the tip. With regards to insurance, I'm not 100% convinced it would be needed here. The only reason I say this is because my customer and I have an informal arrangement, and it is understood that they are only paying for my time. However, with the type of money at issue with this server, I think we should probably formalize our arrangement, and state in a contract exactly what I am responsible for (and/or not responsible for). Don't get me wrong, we discussed a formal contract early on, and felt a simple handshake deal was sufficient for the time being - with the understanding that this could change in the future. I think the future has arrived... <grins> As for who will access the application, at this time I am only aware of a need for employees to have access. There may be a need in the (near) future for clients to have access to some of the reports, but these can be dumped to PDF and emailed to them, or setup in a shared folder on a different server. Cade, with regards to the types of attacks, my thinking was something like this... Based on my own server logs, I can see a lot of common attempts to get at an IIS server. It would be simple enough to write some redirection rules (or similar - I'd have to look up the specific commands again) to handle these requests and feed them a 404. You raise a good point about the "unknown" types of attacks and how to handle them. I was hoping that by feeding the requests through Apache, there would be a simple way to filter out IIS specific requests (like the "../../../../winnt/system32/cmd.exe" type of hack). As far as the app is concerned, it will never use a URL like that, but rather a plain jane type of URL (http://my.server.com/some/path), and all form data (via GET or POST) is validated, and handles SQL injection. But, I suppose it'd be easy enough to create an attack using a plain jane type of URL as well. So, off I go to research SecureIIS... :) (BTW, can you tell I no longer trust IIS?? LOL) In addition to the mission critical application, they are looking to host a web mail interface internally - also on an IIS server. My thoughts were that we could protect that server as well with a simple virtual host on the apache server. They only have one static IP, and may need port 80 directed to multiple web servers - so virtual hosts. And because I don't trust IIS anymore, I would use Apache for them (if they agree of course). Kin, it's been a bit, but I believe PPTP is an older method used for VPN's, and most VPN solutions have moved away from it for security reasons (can someone correct me if needed??). I think the older Microsoft VPN servers use a flavor of PPTP, while newer servers (MS and OSS) use something else... (I REALLY need to investigate/do VPNs again). Also, I'll be in touch regarding that insurance contact - it can't hurt to get the details. :) Thanks again for all the input, and my appollogies for the lengthy reply. Shawn On Wednesday 16 February 2005 17:47, Kevin Anderson wrote: > I'd pay a disproportionate amount of attention to Cade on this. Security > truly is his area of expertise. He is top notch at it. > > Just my thoughts, in case you were curious about his answer being different > from everyone else's. > > Kev. > _______________________________________________ clug-talk mailing list [email protected] http://clug.ca/mailman/listinfo/clug-talk_clug.ca Mailing List Guidelines (http://clug.ca/ml_guidelines.php) **Please remove these lines when replying
