For me it all boils down to risk analysis. I do not believe that any system is Hack proof. Spend enough time and money and you will crack anything. My concern is to assess the degree of additional risk created by opening port 443. I agree that if there is a risk that even one person will gain access then you must keep your patches upto date. However patches only fix known bugs :( , hence my current preference to restrict by ip address (as a first line of defence) as this at least reduces the number of potential attacks.
I accept your point that all it takes is for our "friends" to shift emphasis to 443 and things will be as bad as ever. I think the advice has to be VPN rgds gmcb -----Original Message----- From: Nick Holland [mailto:[EMAIL PROTECTED]] Sent: 06 March 2002 16:52 To: [EMAIL PROTECTED] Subject: Re: [gb-users] Security Issues [EMAIL PROTECTED] wrote: > > I work for a Company that has developed a web based Warehousing system for > Vendor Managed Inventory. This has been very successful for us, however with > the increase in attacks from virus's we made a decision to restrict access > by ip. This has been very successful from the virus point of view (0 attacks > in the last year). However our ever enthusiastic salesforce are pushing for > a relaxing of this. > > If we were to remove the ip restriction, block port 80 and allow only access > via 443 would this in the panels opinion represent a massive increase in > risk? We have considered VPN, however the thought of talking a non > IT-literate person through the installation and setup when he speaks no > English and I speak nothing else and he is umpteen thousand miles away just > doesn't work for me. Scenereo: Let's make the assumption you are running NT,2000, or XP. Let's say you did this a year ago... CodeRed comes along, and you snicker and pat yourself on the back, as your port 80 blocking very effectively prevented your machine from being infected...who needs to worry about patch kits? Ah, but the vulnerability is still there. While your machine may not even see the CodeRed probes (due to firewall filtering), a person who uses the CodeRed technique on you, refocused on port 443, will find your box as much a pushover as any (or even more, if you followed my "who needs to worry..." (il)logic) If your web server and application is vulnerable to attack, it is vulnerable to attack. Period. If you wish to filter it to "known" sites, this helps a lot...but even then, this is not true security. Scenereo: 100% outside your control, your client has a vulnerable system. It is cracked. It is now used as a springboard to attack your system. Now see first scenereo. Unlikely? maybe...maybe not. If someone is going to target you...why? Two reasons I can think of: 1) Because they can (or more accurately, want to show they can). 2) Because you have something they want. Who would find you have something they want? A competitor of one of your customers, or a competitor of yours. Or, perhaps, your customer, looking for information on their competitors (your other customers). Or, anyone looking for priveledged information that might be on your site for any reason. Filtering by user will prevent you from being randomly attacked, but the person attacking *YOU* might just have to be more creative. You can't filter your way out of broken...or breakable...software. The best you can do is isolate to minimize the dammage and maybe make it take longer to hit paydirt...long enough that hopefully you can catch and stop it before something really bad happens. If your application is vulnerable to attack, you have to fix it, not filter your way to "safety". Filtering will help protect you from vulnerabilities in areas OTHER than your app (i.e., if your OS of choice has a vulnerable service you don't need, filtering can eliminate that risk) Nick. -- http://www.holland-consulting.net --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] To subscribe to the digest version first unsubscribe, then e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] To subscribe to the digest version first unsubscribe, then e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
