May 14, 2007

IBM DevWorks on Linux System Auditing

Linux system auditing by example

This is a great article that covers some of the methods used to perform regular security audits of your Linux system. Pay especial attention to the first section, on identifying suid binaries. The principles of 'defense-in-depth' suggest that not only do we limit the software installed on a system to strictly those necessary to provide the services desired, but that even within that installation, we minimize the access of the bits of software that aren't strictly necessary to the functioning of our server.

Blogged with Flock

Posted by ssc_upenn at 9:32 AM | Comments (0) | TrackBack

November 30, 2006

Secure Encryption on the Mac -- a nifty How-TO

This is a pretty good tutorial for creating encrypted space on your Mac, without going the whole-hog route of using FileVault to encrypt your entire Home directory.

Macworld: Secrets: Encrypt files for safety

technorati tags:, , ,

Blogged with Flock

Posted by ssc_upenn at 1:19 PM | Comments (0) | TrackBack

October 30, 2006

Zotero -- Citation Management for Firefox

Well, for Firefox 2.0, to be more specific.

Linux.com | Zotero: A seriously useful research tool

This looks really cool, so you should check it out... I'm sure the Boss will be blogging this, so I'll let him write the more in-depth review.


technorati tags:, ,

Blogged with Flock

Posted by ssc_upenn at 8:56 AM | Comments (0) | TrackBack

June 16, 2006

Setting up a Linux system to use software RAID

This is a really great link on how to do this 'by hand.' I recommend that you do every task at least once 'by hand,' so that you can have a sense for what actually happens when you use a gui or script to accomplish it. In this case, the task is migrating a single hard drive system to use RAID 1 (mirroring) through the in-kernel software RAID system.

http://http://www.debian-administration.org/articles/238

Posted by ssc_upenn at 1:13 PM | Comments (0) | TrackBack

February 22, 2006

Denying access if SSH is dictionary attacked

If you're running your own UNIX box (Solaris, Linux, OS X), you may notice (if you ever peruse your SSH logs, often /var/log/secure) sections of your logfile where the same host attempts to connect to your server via SSH with an assortment of common usernames and common passwords. This is what is known as a dictionary attack.

Fortunately, there's a program called DenyHosts which is designed to deal with this very problem.

Here's an article on DenyHosts from Linux Today (original article at How-To Forge).

Posted by ssc_upenn at 12:03 PM | Comments (0) | TrackBack

August 12, 2005

How to change your UNIX password

Ok, Ok. You've convinced me. I have to change my password. I'm a Windows user, and I don't want to have to fool around with logging into a terminal session, or finding an SSH client, or any of that foolishness. What do I do? Huh? I can't hear you, Mr. Smugly-Superior-UNIX-Guy...

Changing your password on the SSC UNIX systems is actually very easy, and is one of the few things that we recommend that you do on a Windows box (if you happen to have one handy, as Mr. S-S-UNIX-Guy never seems to...).

Type Ctl+Alt+Del (we refer to this as 'giving Windows the three-finger salute')

Click "Change Password"

In the window that appears you'll see the field Log in to: and next to it, you'll see some text. Clear that field, and type:

lambic.ssc.upenn.edu

Then, type your old password in the Old Password: field, and then a new password in the New Password: and Confirm New Password: fields, respectively.

If you typed everything properly, you'll see a dialog box that says "Password changed."

Posted by ssc_upenn at 10:32 AM | TrackBack

April 1, 2005

Password-protected Web directories

How do I make a directory on my website password protected? I have some data I want people to download, but I want only certain people to have access to it...

There are a number of reasons why you might want to limit access to some data in your website -- your data may be proprietary, and you need to limit access in order to comply with licensing requirements; your data may contain personal identifiers, and you need to limit access to meet institutional privacy requirements; or, it may simply be that the data are for an in-progress research project, and thus need to have access to them restricted.

In any case, password protecting a directory on your SSC website is easy.

In the following example, we'll pretend that:

Step 1
Log into the appropriate server via an SSH client. If you want to create a directory within your personal website (ie: inside of $yourusername/public_html), you should log in to lambic.ssc.upenn.edu. If you want to password-protect a directory within an organizational website (a project or departmental website, for example), you should log into porter.ssc.upenn.edu. So, for this example: 
$ ssh sarahf@lambic.ssc.upenn.edu
Step 2
Create the directory which will contain your sensitive data. 
[sarahf@lambic ~]$ cd public_html
[sarahf@lambic ~]$ mkdir sensitive_data
Step 3
Once you've created the directory wherein you're going to place your sensitive data, you need to create a userlist file and a password file to set up password access. Given the directory we created in Step 2, do the following. 
[sarahf@lambic ~]$ cd sensitive_data
[sarahf@lambic ~]$ vi .htaccess

What I've just done is opened a file called .htaccess for editing, using the vi editor. If you're not comfortable using the vi editor, you may use emacs, or pico, or jed, or any other editor we have available on the webserver. In the .htaccess file, I would need the following information:

AuthType Basic
AuthName "Authorized Users Only"
AuthUserFile /home/sarahf/.htpasswd

<Limit GET>

require user allieg

</Limit>

Once you've got the required info in this file, save it (in vi, that's :wq).

Step 4

You will have noted, of course, that we were asked to provide a path to a file called '.htpasswd'. I'll need to create this file, as follows:

[sarahf@lambic ~]$ htpasswd -cm /home/sarahf/.htpasswd allieg
New password: dashow
Re-type new password: dashow
Adding password for user allieg

In the above example, you can see that we gave the htpasswd command the username we're adding the password for ("allieg"), as well as typing the password we want our user to use to access our data ("dashow"). The -cm tells the htpasswd command to create a new passwd file and to encrypt it using md5 encryption.

This brings up an interesting question: Is it better to have one username and password for everyone with whom I wish to share my data, or should I issue each user their own username and password?

It's certainly more convenient for your users to share a password, but it doesn't allow you to keep track of who's accessing your data. My recommendation is to use individual users and passwords, but it really is up to you.

Posted by ssc_upenn at 3:21 PM | Comments (0) | TrackBack

Help with Statistics Software

Who do we talk to if we need help with the statistical software running on SSC computers?

This entry isn't just about UNIX, although we often get these questions, so it's worth answering here. On our staff we have Ed Horn, who will be more than happy to answer questions regarding the statistical packages we have installed in SSC (in addition to the applications installed on the UNIX servers, we also have statistical applications installed in the Graduate Data Analysis Lab (GDAL, 3rd floor McNeil), and in the Undergraduate Data Analysis Lab (UDAL, 1st floor McNeil).

Ed can normally be found in GDAL, but spends quality time in UDAL, as well.

Posted by ssc_upenn at 3:03 PM | Comments (0)

Cluster Backups

Does SSC back up the information in my home directory on the Bewoulf clusters? If not, how can I do it myself?

SSC does not backup up the home directories on the Beowulf clusters. It is certainly advisable that cluster users take steps to make sure that their data are backed up to another machine in the event of a cluster failure.

One way to do this is by using a UNIX utility called 'rsync' in concert with SSH to automatically copy your home directory to another UNIX location (your home directory on lambic, say...) and then to synchronize the changes nightly. Below are instructions on how to set this up. Substitute your userid for $username, and lines beginning with # are shell commands you type.

Step 1

Log into lambic.ssc.upenn.edu (or another UNIX server, if you have access to one) using SecureCRT or another SSH client. This is the server you will be backing your cluster files to.

# cd /home/$username

Step 2

Check to see if you already have a public/private key pair on this server 
# cd .ssh
# ls *.pub

Look for a file called id_rsa.pub or id_dsa.pub -- these are public keyfiles If you find a public key, skip to step 3, below. If not, follow step 2a.

Step 2a
Generate a public key on the UNIX server 
# ssh-keygen -t dsa -N "" -b 1024
This generates a public/private keypair for your userid, and places it in the expected location, above.

Step 3

Move your public key to the cluster you wish to backup ($cluster). 
# scp ~/.ssh/id_dsa.pub $username@$cluster.upenn.edu:/home/$username/.ssh/authorized_keys2

(this copies your pubkey from athena, and places it on max. This allows you to ssh in to max without having to type a password. This will prove useful in the next step)

Step 4

Backup your home directory on the cluster to the UNIX server you logged into in Step 1, above. 
# mkdir /home//$cluster_backup

This step creates a directory on the local UNIX server where your backup files will be stored.

# rsync -avze ssh $username@$cluster.upenn.edu:/home/$username/$cluster_backup

Once you run the second command, you should see the message 'generating file list...' and then the names of the files that are being backed up whiz by. Because you've made your public key from the local UNIX server one of the cluster's authorized keys for your username, you should not have to provide your password.

Once you're satisfied that this has worked properly, you can add an entry to cron along these lines (using the command 'crontab -e'):

18 3 * * * /path/to/rsync -avze ssh $username@$cluster.upenn.edu:/home/$username/$cluster_backup

which would run the backup at 3:18am every morning.

(Remember to subsititue your username and the name of the cluster you wish to backup in the above examples).

If there are problems or questions, please don't hesitate to contact SSC-help.

Posted by ssc_upenn at 10:47 AM | Comments (0)