Just add a firewall rule allowing SSH only from specific IP
addresses, it will stop all of this.
On Jun 13, 2005, at 10:46 AM, Philon Terving wrote:
The user names are random (including root and admin) indicating that
it's someone trying to get into my machine.
If things are still random and your passwords are good enough
(perhaps
you should consider ssh-keys!?) there's nothing to worry about.
There are some steps you can take to help make your server more
secure from these kinds of vulnerability scans. This isn't
exhaustive, of course.
0) Use a really good password, something like "Ludwig45/entomologist"
or even kookier. This might sound crazy, but it's perhaps your
strongest defense. If a crazy, complicated password is daunting --
and you're tempted to use something shorter and simpler -- consider
writing (just) this single password on a sticky note and putting it
in your wallet or pocketbook. Hard core security freaks hate this,
but if you're like me and can't remember things very well (hey, the
90s were rough), it's a acceptable approach. I can deal with the
exceptionally remote risk that someone will mug me outside Borders,
steal my wallet, guesses correctly that I manage servers, figures out
the specific hostname of the specific server at the specific company,
figures out the corresponding account name, and then busts into the
machine. You can use Keychain.app or a thumbdrive or something, but
that may limit which or what type of computer you can use to retrieve
the info. Sticky notes in wallets never crash (except when you wash
your wallet in laundry).
1) One thing that bugs me is that Apple assigns a default shell to
new accounts created via Workgroup Manager.* And in my experience,
99.5% of my users don't need that -- it should be something an admin
should have to deliberately enable, not specifically disable (in my
opinion, anyway). From WGM, select your users and change their shell
to "none". Technically, it sets it to /dev/null.
2) Since I don't always connect to my client's servers from my own
PowerBook, I don't use SSH keys. You can, and it's a good decision if
you're comfortable with those limitations. There are a number of
resources for this -- the first resource I pulled up searching a9.com
for "ssh keys" is <http://www.arches.uga.edu/~pkeck/ssh/>.
3) Modify the sshd_config to include an Allow/Deny directive. You
can get quite crafty with this, and it's really pretty easy to do.
Me, I limit access only to one user account, but I think you can also
specify connections from only certain networks or specific hosts --
again, there are resources on the web for that, too. You can get
quite granular, but be sure you don't lock yourself out if suddenly
you have to shell into your server from your Aunt Margaret's house
one Sunday morning in an emergency.
3.5) On that note, some routers or gateways turn on/off services or
port forwards during specified times. For example, the D-Link
wireless router I have at home can be configured to forward SSH
requests only between 9:00 and 18:00. Again, it's a limitation you
may be able to live with, but servers don't always act funky during
prescribed times.
4) Use TCP wrappers -- I don't have a lot of experience with this,
but it's been mentioned a number of times and resources are out there.
5) Bill's suggestion for a firewall rule is good -- but remember if
you specify *just* a specific IP address, you'll obviously have to
always have that IP. You can use wildcards, I think, for a range of
IPs, though. Again, don't defeat yourself when trying to defeat
others though.
6) When creating new user accounts, don't use shortnames like "bob",
"jane" and "frank". The script that scans your machine for weakly
protected accounts will use common English names. You can thwart the
script by simply making shortnames something like pmartin or paumar01
or the like.
* Personally, I think steps zero, one and six are three of the most
important to take. I mentioned here before that I examined a
compromised Mac server where such a script successfully SSH'ed into
the server with the username "lisa". After many things were rebuilt
and reconfigured, I asked Lisa what her password for her server
account was -- it was "lisa" -- her first name. Once the script gets
an affirmative response that an account exists but the supplied
password is wrong, it will begin to hammer the server with
possibilities. There was no reason for her or any of her colleagues
to have shell accounts, so that was one (of many) changes I
immediately made.
Good luck!
Noah
-----------------------
Noah B F Abrahamson
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Macos-x-server mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/macos-x-server/email@hidden
