2004-05-31 unix servers

[newmem]

I am now concerned about the overall security of not only hsphere passwords but passwords stored in MSSQL db's. Each db has an Admin password that controls the entire db or site. Clients will ask me what I do to ensure the security of their website's passwords and their mailing list etc. and I have no idea about it! Are MSSQL db's also hackable and nothing is safe on the net?

"I'm also saying that it shouldn't be cause for paranoia and panic either."

that's where I am headed......can someone please reassure me about the security that we have ourselves and that we offer to our hosting clients?

If passwords are sent in plain text, then who's gonna read them except my ISP, assuming I have no trojans, keyloggers or spyware on my computer? Unless someone has access to my computer, how can they know what password I typed in?

[tkraffty]

Oops - I didn't mean to scare NEWMEM when I mentioned my own client's problems with hackers... So here's some more details, and what I generally tell all my clients about security on the internet --

Our systems (Vortech's servers and data-center) employ all the latest Microsoft and server security patches and updates, and firewall hardware, software and other means are used secure our servers to the highest degree possible. Our server ports and network traffic are secured and constantly monitored, and we also have several mechanisms in place to detect and prevent most "denial-of-service" (DoS) types of attacks.

Due to the nature of the internet however, there are a few issues related to security which are simply beyond our control. Most hackers typically gain access to a web site by means which have nothing to do with the actual security of the web servers or network -- but most possible issues can be avoided by following a few simple rules:

(1.) Most hackers do most of their damage by simply figuring out people's passwords. Most people use passwords which are too simple, and/or they use the same password for all their various accounts. Also, most people use un-secured pages to login to critical systems.

Because of this, it is possible for hackers to use various software to try and "guess" passwords or intercept non-encrypted internet traffic and "sniff" data that may contain passwords. So you want to be sure to (a.) use a complex password that includes UPPER/lower-case letters, numbers and special characters if possible, (b.) use different passwords for different accounts, (c.) regularly change your passwords every several weeks or few months, and (d.) if you use or provide your clients with password-protected access to critical systems, you should secure that online page or area using SSL/HTTPS security encryption.

(2.) Dynamic site components and applications which use file-based databases (like Access) and/or web-based software obtained from third-party developers (which are available to the general public) generally have known paths to database files and administrative features, as well as generic logins provided by the software manufacturers for use when first setting-up the application.

For this reason, be sure to (a.) change the default login accounts provided with any third-party application, (b.) if possible, change the database filename and folder location of any Access database provided with the application, and (c.) if the application provides some critical function, protect the administrative features and/or login pages behind SSL/HTTPS encrypted areas.

(3.) Be sure you have the latest updates for your online applications provided by the manufacturers and developers. For example, older e-mail contact forms can be exploited by spammers as relays to send their messages, and older versions of bulletin board or forum applications may contain known exploits which can be resolved by simply upgrading to the latest versions.

Addendum: Also wanted to point out two more things:

(4.) Like most theft, most security violations are "inside jobs" where employees simply take advantage of someone else's unattended computer and/or an open browser's "remember password" features to simply gain access to another employee's (or the owner's) accounts. Be sure to (a.) logoff from all online sessions, (b.) don't use the "remember me" features on any web sites if your computer is accessible to others, and (c.) be sure to logoff your computer and/or don't leave any critical account information on a computer that may be shared by other employees

(5.) Even with all the above, even the most security conscious individuals sometimes need to login to e-mail or some other account through a non-secured channel, and it's basically a calculated gamble at that point. Your e-mail, for example, sends passwords in the open. Having your own local firewall (like ZoneAlarm) can help keep prying eyes on the internet from associating your IP with a particular account, but in the end, you need to decide the level of risk you're willing to take based on your particular business and the general odds against you. If you work for the DOD or Amazon, chances are good that someone is trying to "sniff" your activities... If you run a basic commerce or small business site, chances are considerably less that anyone would be interested in your activities...

...And that's pretty much it. Again, our servers appear to be as secure as they possibly can be, but most hackers use means to access sites that have nothing to do with the actual servers themselves, but rather the poor password management of the sites' administrators. In the case of my client, he used the same basic password for everything, and he never used the secure login I provided him to access his administrative features... As a result, someone managed to "sniff" out his login and used that to basically gain control of his accounts. We solved the problem by basically changing his primary password, and using different passwords for each separate system on his site. Also upgraded phpBB to version 2.0.8 (which includes better session security), and haven't had a problem with hackers or malicious activity since!

TK

[dpyers]

A note on access DB's. Put them in a directory outside of your root web space and use DSN-less connections with explicit paths to get to them in scripts.

A note on using passwords. Did an exerecise with Bell Labs a few years ago where we took the 10 most common names for women out of a Baby Names book in lower case, added a 0 through 9 on the end of them and then used them for passwords against root, su, and oper on 1000 unix systems. Got into 63% of the systems.

[newmem]

thanks for all the detailed info.......