Here are a few less-obvious things to watch out for:
1. InterNIC
Do you have password protection on your InterNIC accounts? If they are only
e-mail authentication, it's "possible" for someone to do mail spoofing and
trick the InterNIC into thinking the request came from the e-mail account
that has rights to it. What can happen? Well in "theory" you could change
the administrative DNS servers to point to someone else's DNS and thereby
re-route traffic anywhere. It's also possible to modify the account and
prevent the original user from changing it. Sure, you could tell the
InterNIC to fix it, but for 12+ hrs you're still screwed.
I've never heard of this being done, but it is "theoretically possible" ...
2. SQL password
Make sure you put security on your SQL server. The SA password should not
be blank or easily guessable. Let's face it, someone can create DSNs via CF
scripts, so if the hacker can create a .cfm page on your server, they can
get in. If they run SQL administrative sp's, they can see all the databases
and start doing things you don't want them to. Even if they can create a
DSN, if you've secured your database server, it won't do them any good
because it won't validate.
3. Bandwidth Attacks
How fast is your pipeline? If the hacker has access to a T1, T3, fast DSL,
cable modem, etc. and you're on a small DSL circuit, have a poor ISP or a
slow box, hackers can use tools like load testing tools, to push a lot of
traffic at your server.
4. Bandwidth and Data Overload
See #3 above, but consider that the hacker has found pages on your site that
are very data intensive and do not use caching. You have also set your
simultaneous requests to a low number (let's say five). If they could
generate enough requests for these high load pages and swamp the server,
they could make it temporarily appear "unavailable" to real users. Make
sure you have enough capacity for big spurts of traffic and set your
firewalls and other devices to compensate. Also consider putting caching in
pages that require a lot of data work and don't change frequently. Remember
that you might not be able to catch this type of attack by using session
variables as the hacker has probably picked a tool that doesn't support
cookies.
5. Remote Access Tools
If you're using remote access tools like VNC, PC Anywhere, Reach Out, make
sure that you properly create and rotate your passwords. Make them a mix of
case and alphanumeric symbols (always include one or two numbers) and make
sure it's long. The only person inconvenienced by a 12 character password
is you. URLs are longer than 12 characters, so it's not that bad. But
let's face it. These tools use standard ports and people guess them to see
if you have it. Once they get it, all they have to do is guess.
6. Backups
Let's face it. If someone does hack in and screws up your site, how will
you restore it? Make sure each time you deploy a new site version, that you
keep a copy of the site on a disk somewhere. CD-ROM burners are cheap.
7. NT / OS Security
What do your NT guest accounts have access to? Do you co-locate your
servers? If others can see your server information, there is a risk. Lock
your server(s) down. There is no reason for everyone in the company or in
the co-location facility to see your server farm. Create a production
domain for your web farm and deny your office domain access to it except for
authorized IT personnel. Everyone else will get there via HTTP, so this
won't hurt them. Free access to the system... that hurts.
8. Past Employees
Anytime someone leaves the company, it's time to change passwords. Most
companies think this is a good policy, but I've seen too many people ignore
this.
Not all of these are easy ideas, but they're worth considering. Proper
security management can help prevent disasters or at least make them easier
to recover from.
--Doug
------------------------------------------------------------------------------
Archives: http://www.eGroups.com/list/cf-talk
To Unsubscribe visit
http://www.houseoffusion.com/index.cfm?sidebar=lists&body=lists/cf_talk or send a
message to [EMAIL PROTECTED] with 'unsubscribe' in the body.
