First off, unless you're absolutely certain that your SBS installation is secure; i.e., it's running with SSL and SSH, I'd give serious consideration to replacing it with a Linux server -- there just isn't all that much that SBS can do that cannot be done at least as well (and probably more securely) with Linux, SSL and SSH. If that's not practical, you may want to consider a VPN setup although that may be more expense and trouble than it's worth unless it's done at your router(s) with RSA security tokens or the like for any external; i.e., outside the building, employee or not, authorized users.
One simple thing you can do is make sure your site does not respond to ping
; if the bad actors don't know you're there, they're not going to bother you quite as much. That doesn't mean that you're not going to be probed, however, so make certain that your system logs are scanned at least weekly to identify sshd
and other probes; add any site that has done that to your /etc/hosts.deny
file and/or your IPTABLES data base -- identify the domain the probe is coming from (with whois
and simply deny access to the entire domain. Here's a few that I block because I've had multiple probes and break-in attempts from them:
iptables -A INPUT -s 18.104.22.168/16 -j DROP
iptables -A INPUT -s 200.169.98/24 -j DROP
iptables -A INPUT -s 22.214.171.124/16 -j DROP
iptables -A INPUT -s 126.96.36.199/18 -j DROP
I also completely bock China and Korea based simply on experience with attempts from those countries and I do not do business with either.
You should be running any web-based applications with Apache security; i.e., the web address is https
-something, not -- internal or external -- http
. Your MySQL server(s) should be locked down with individual passwords (not internal or external site-wide passwords); make sure that administration has at least executed mysql-secure-installation
on every one of your MySQL servers (and that the test
data base has been removed from MySQL). There should be zero access to any MySQL data base without a user id and password. Use individual accounts and passwords for all employees, administrators or not (although that is somewhat impractical for those absolutely required root access).
You should already be aware than Microsoft products are to be assumed insecure no matter what -- given a long, long history of intrusion along with extensive and expensive damage, it may be better to be safe than sorry and simply migrate everything to Linux. I'm not being prejudiced here, I've been burned and I didn't much like it. I also got real tired of spending hundreds if not thousands of dollars to protect computers from things that should never have existed in the first place had the vendor done a professional job. Essentially, Microsoft products have never been and I don't expect them ever to be secure -- it's your money and it's your data, you decide.
Never, under any circumstance, allow a vendor or client to plug a computer into your network, particularly a Microsoft computer. Do not allow anyone -- internal or external -- to plug in a flash drive, floppy disk, CD-ROM or DVD unless it has first been scanned by your system administrators. Don't allow people to tote floppies, CD's, DVD's and especially flash drives back and forth. If you're using wi-fi, it must be password-protected; better yet, hard-wired is always more secure than wi-fi.
The combination of SSL and SSH is about as secure as you can practically get if you insist that all access to any computer in your facility is done only with SSH. When you use Apache securely, you're using SSL and SSH and you simply insist that all outside access is done with proper user identification and password. That means that any new user be stopped at the front page and either enters a known user id and password or requests a new account in which case you go through establishing the account with human review
before replying with a validation (one of those "click here to validate your account" e-mails). It's worth setting up account numbers and it's really worth having password expire periodically (monthly is good, quarterly is less annoying but remember that it's your system and act accordingly). You should use PAM or some other utility to insist on "good" password and don't let anybody re-use previous passwords. If an employee is discharged or leaves voluntarily, lock every account they use during the exit interview.
If you insist on permitting Microsoft products internally, make sure they're as secure as you can get them -- every box must be updated when Microsoft issues security patches, every box must be running McAfee, Norton or some other favorite security software (and kept up-to-date, no excuses). No user should have administrative privileges; i.e., no user can install software on the box. In any event, schedule runs of the security software an audit periodically to assure that there isn't "foreign," user- or bad-guy-installed software on your Microsoft systems.
Bottom line is that you can pretty much trust SSH -- but you have to actually use
it; establish standards and stick to them, no exceptions.
Hope this helps some.