26-Apr-2024 04:34 GMT.		 UNDER CONSTRUCTION
[Rant] Secure WebsitesANN.lu
Posted on 21-Oct-2001 11:50 GMT by Christian Kemp6 comments
View flat
View list
Jack Meihauf wrote: Is there such a thing these days? With the word that amiga.org was hacked, maybe we should be securing our web sites? Well, theres always one thing that comes first. And that is Backups. It also pays to not keep back ups on the same server.
The administrooskis should pay more attention to security, and also the security of the backups.

An example. Don't named backups yoursite2, yoursite3 etc.., if you're going to leave them on the server. I truely hope Amiga.Org didn't name their backups ao2, ao3 etc. That would be truely silly.

Anyway, best of luck in getting the site up and running, you'll need it with these types pf people around,. Hmm. Maybe you should offer them a job securing the site?

List of all comments to this article
Sorted by date, most recent at bottom
Comment 1Anonymous21-Oct-2001 15:52 GMT
Comment 2mbpark22-Oct-2001 00:32 GMT
Comment 3Solar (BAUD)22-Oct-2001 05:11 GMT
Secure Websites : Comment 4 of 6ANN.lu
Posted by Anon User on 22-Oct-2001 08:29 GMT
What it comes down to is having a group of admins that really know what they are doing.
mbpark
fggh on #c-64 (efnet)
**********************
Though the blame the admin statement is something that many companies would like to believe I've rarely seen that the case. When companies have website outages there's specific reasons for this. Yes, at times having an admin w/o knowledge or not doing their job is an issue. However, as an admin myself I've gone to management with various projects to improve the security and stability of a website. However, management has to cut or minimize IT budgets and spending. Thus, many of the purposals we've done to improve things do not get approved.
Examples:
Clustering and/or local load balancing multiple servers together. This will create a failover server that will take over when the first one dies. Unfortuantely, this doubles and a bit more the cost of the original website. Turned down due to capital restrictions.
Geographic load balancing. This will create a failover server on the west coast to help handle more traffic and take activity when our server on the east coast dies. Once again this doubles cost (2 server) plus there's the additional cost of the geographic load balancers (double cost again.) Turned down due to capital restrictions.
Firewalling - Important to increase network security and create a DMZ. Turned down due to capital restrictions. Management just desires ACL lists on the switch to prevent traffic other then port 80 (http) to be allowed into the server. Turned down due to capital restrictions.
I take offense at people believing that the only reason web servers/services do not function or have been hacked is due the admin's inadequate ability. Many of these are admins that have the ability have made purposal's to tighten security, create failover services, and want to make the Web Service better for the company. Instead we're sited reasons why the company cannot make that move.
If you've worked on Web Services for a company you'll know what I mean. Nothing is better then having a server crash due to hardware issues. Work on auditing procedures and processes by an internal company task force because the company claims they lost over $1,500,000 for the two day period the server was down. To turn around and hand them a project you created over a year ago that had the company spent $10-15,000 would have helped to eliminate the outage of the service. It's amazing how that $15,000 opens up. However, when you bring up the other possible problems and solutions you've created you get push back again because of costs.
So, I agree there are those admin's that mess up. (Hey, there's doctors, lawyers, and pilots that mess up.) But, that's not the only reason for an issue on the web. Other reasons are things that companies cite they didn't do because of X,Y, or Z.
Jump...
#5 mbpark
TopPrevious commentNext commentbottom
List of all comments to this article (continued)
Comment 5mbpark23-Oct-2001 00:58 GMT
Comment 6alan24-Oct-2001 21:18 GMT
Back to Top