After you create your PassCard, you can test your new passwords out here: https://www.microsoft.com/protect/fraud/passwords/checker.aspx?WT.mc_id=Site_Link
20100426
20100425
Go ahead, write your password(s) down, with PasswordCard.
PasswordCard allows you to create a card with randomly generated strings of characters on an 8 X 29 grid with colors denoting the row and symbols denoting the column; Gmail: Diamond Green, Facebook: Spade Pink. It's up to you to set the passwords on your accounts, so you can use as many characters as you need. Make sure to check the box for "special characters" for use on sites that require it (like AKO.) Just don't write your coordinates on the back of your card ;-) (Users will always find a way.)
https://passwordcard.org
https://passwordcard.org
20090908
Lazy Workers May Be Deemed Hackers
In this article, Mark Rasch cites examples of how a few courts have expanded the definition of hacking to include previously innocuous forms of misuse. This gives system administrators and CIOs some real legal teeth to go after Acceptable Use Policy violators. (Facebooking at work)
http://www.securityfocus.com/columnists/504?ref=rss
http://www.securityfocus.com/columnists/504?ref=rss
20090803
Simple, Remote *nix Backups
This adapted from an essay I wrote for an English class assignment on "process analysis:"
The intended audience would be more towards university students with shell accounts and limited resources than Unix sysadmins.
...There are many complicated methods of backing up important system data on Unix systems, and entire software applications have been written to handle this task. What I will show you is the simple and secure way a regular, non-privileged user can accomplish this task with the standard utilities available, and only a moderate amount of technical knowledge.
First, you must have shell accounts on two servers. The Unix shell is the command environment. Most universities provide students with shell access to one or more servers.
...You need to have a remote place to store your backed up data in the case of a system failure on the server you are working on.
...It is important that you establish a secure mode of transfer between the two servers. Older protocols, such as Telnet and File Transfer Protocol, transmit data in clear-text (unencrypted) format. An attacker can intercept and reassemble these packets to steal your information. To facilitate the secure transfer of data, the Secure Shell protocol, known as SSH, was developed. Normally to establish an SSH connection to a server, you must enter your username and password, but since you want this process to be automated, and you do not want your password sitting around in a text file, you must use shared key authentication. This will enable you to establish a secure, encrypted tunnel for your data to traverse from server to server.
The following steps will allow you to enable shared key authentication between two servers:
1. Enter the following command at the prompt ($):
ssh-keygen -t rsa
2. The following dialog will ensue:
Generating public/private rsa key pair. Enter file in which to save the key (/home/user/.ssh/id_rsa): /home/user/.ssh/identity /home/user/.ssh/identity already exists. Overwrite (y/n)? y Enter passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved in /home/user/.ssh/identity. Your public key has been saved in /home/user/.ssh/identity.pub. The key fingerprint is: d0:43:31:b9:6d:6c:0f:b2:25:73:d4:58:2c:e3:8f:d0 user@local
3. Copy the public key over to the remote server:
user@local$ scp /home/user/.ssh/iddentity.pub user@remote:local.ssh user@remote's password: identity.pub 0% 0 0.0KB/s --:-- ETA^Midentity.pub 100% 233 0.2KB/s 00:00
4. SSH to the remote server and add the key to the list of authorized keys.
user@local$ ssh user@remote
"user@remote's password"
user@remote$ cat local.ssh >> .ssh/authorized_keys
user@remote$ exit
logout
Connection to remote closed
5. Verify that the account can now log in without a password.
user@local$ ssh user@remote (notice that no password is required this time) user@remote$ exit
logout Connection to remote closed
(Note: having recently set this up on an HP-UX system, the process for adding the generating and adding the keys to the keychain is a bit different. The above method worked on FreeBSD, Linux and MacOSX at the time I originally did the essay.)
Next, you need to decide what data you want to save, and make the backup file. Space may be limited, so it is critical that you weigh the importance of your data. Financial records, business correspondence and academic work are prime candidates for archival. Once you have chosen your data you can use Unix’s native backup utility, tar, to backup your data. The syntax for this is:
$ tar –cf file.tar directoryA/ directoryB/ somefiles.
This will create a single file that when extracted will exactly duplicate the existing directory structure. After this data is backed up, move this data over to the remote server for storage:
$ scp file.tar user@remoteserver:file.tar
Now that you have completed your first backup, and verified that everything has gone according to plan, you are ready for the final step, automation. The first step in automation is the authoring of a shell script. Though it sounds intimidating, a shell script is merely a text file that contains a list of commands to be executed in chronological order. As you can imagine, the script you will be writing will contain the three commands previously discussed. It will also contain an additional line at the beginning that must read “#/bin/sh”. This tells your system that this file is a shell script. You can use any text editor to write the script. After you save your file, make it executable and unreadable to anyone else on the system:
$ chmod 700 script.sh
Here is a sample backup script:
#bin/sh
tar -cf /backup/stuff.tar /home/user/stuffiwanttosave #creates the backup
scp /backup/stuff.tar user@remote:stuff.tar - transfers the backup to the remote server
rm /backup/stuff.tar – deletes the backup file
exit
Next, use the crontab utility to schedule your back up. You can invoke the crontab editor by typing:
$ crontab –e.
This will open a vi session to edit the config file, $man vi to see more details on using vi. Crontab entries are formatted:
* * * * * command to be executed
Minutes, Hours, Day of month, Month of the year, Day of the week(0-6)
To schedule your backup for 1:55 AM every Sunday, your entry would read:
55 1 * * 0 /home/user/script.sh
This will automate the process of your backups so that you can set it and forget it.
The intended audience would be more towards university students with shell accounts and limited resources than Unix sysadmins.
...There are many complicated methods of backing up important system data on Unix systems, and entire software applications have been written to handle this task. What I will show you is the simple and secure way a regular, non-privileged user can accomplish this task with the standard utilities available, and only a moderate amount of technical knowledge.
First, you must have shell accounts on two servers. The Unix shell is the command environment. Most universities provide students with shell access to one or more servers.
...You need to have a remote place to store your backed up data in the case of a system failure on the server you are working on.
...It is important that you establish a secure mode of transfer between the two servers. Older protocols, such as Telnet and File Transfer Protocol, transmit data in clear-text (unencrypted) format. An attacker can intercept and reassemble these packets to steal your information. To facilitate the secure transfer of data, the Secure Shell protocol, known as SSH, was developed. Normally to establish an SSH connection to a server, you must enter your username and password, but since you want this process to be automated, and you do not want your password sitting around in a text file, you must use shared key authentication. This will enable you to establish a secure, encrypted tunnel for your data to traverse from server to server.
The following steps will allow you to enable shared key authentication between two servers:
1. Enter the following command at the prompt ($):
ssh-keygen -t rsa
2. The following dialog will ensue:
Generating public/private rsa key pair. Enter file in which to save the key (/home/user/.ssh/id_rsa): /home/user/.ssh/identity /home/user/.ssh/identity already exists. Overwrite (y/n)? y Enter passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved in /home/user/.ssh/identity. Your public key has been saved in /home/user/.ssh/identity.pub. The key fingerprint is: d0:43:31:b9:6d:6c:0f:b2:25:73:d4:58:2c:e3:8f:d0 user@local
3. Copy the public key over to the remote server:
user@local$ scp /home/user/.ssh/iddentity.pub user@remote:local.ssh user@remote's password: identity.pub 0% 0 0.0KB/s --:-- ETA^Midentity.pub 100% 233 0.2KB/s 00:00
4. SSH to the remote server and add the key to the list of authorized keys.
user@local$ ssh user@remote
"user@remote's password"
user@remote$ cat local.ssh >> .ssh/authorized_keys
user@remote$ exit
logout
Connection to remote closed
5. Verify that the account can now log in without a password.
user@local$ ssh user@remote (notice that no password is required this time) user@remote$ exit
logout Connection to remote closed
(Note: having recently set this up on an HP-UX system, the process for adding the generating and adding the keys to the keychain is a bit different. The above method worked on FreeBSD, Linux and MacOSX at the time I originally did the essay.)
Next, you need to decide what data you want to save, and make the backup file. Space may be limited, so it is critical that you weigh the importance of your data. Financial records, business correspondence and academic work are prime candidates for archival. Once you have chosen your data you can use Unix’s native backup utility, tar, to backup your data. The syntax for this is:
$ tar –cf file.tar directoryA/ directoryB/ somefiles.
This will create a single file that when extracted will exactly duplicate the existing directory structure. After this data is backed up, move this data over to the remote server for storage:
$ scp file.tar user@remoteserver:file.tar
Now that you have completed your first backup, and verified that everything has gone according to plan, you are ready for the final step, automation. The first step in automation is the authoring of a shell script. Though it sounds intimidating, a shell script is merely a text file that contains a list of commands to be executed in chronological order. As you can imagine, the script you will be writing will contain the three commands previously discussed. It will also contain an additional line at the beginning that must read “#/bin/sh”. This tells your system that this file is a shell script. You can use any text editor to write the script. After you save your file, make it executable and unreadable to anyone else on the system:
$ chmod 700 script.sh
Here is a sample backup script:
#bin/sh
tar -cf /backup/stuff.tar /home/user/stuffiwanttosave #creates the backup
scp /backup/stuff.tar user@remote:stuff.tar - transfers the backup to the remote server
rm /backup/stuff.tar – deletes the backup file
exit
Next, use the crontab utility to schedule your back up. You can invoke the crontab editor by typing:
$ crontab –e.
This will open a vi session to edit the config file, $man vi to see more details on using vi. Crontab entries are formatted:
* * * * * command to be executed
Minutes, Hours, Day of month, Month of the year, Day of the week(0-6)
To schedule your backup for 1:55 AM every Sunday, your entry would read:
55 1 * * 0 /home/user/script.sh
This will automate the process of your backups so that you can set it and forget it.
20090712
Mac Forensics
The first configuration change required, is to disable auto-mounting of drives. When the Macintosh uses the automount feature to mount a drive, it mounts it in read-write mode. Mounting in this mode will change the access times of certain files, rendering the evidence tainted (Hawkins 2002.) Disabling automount will allow the investigator to later mount the device in read only mode, or make an image of the device without mounting it, a technique that is useful in recovering data from a corrupt file system. To disable the auto mount feature, the investigator must edit the hostconfig file in the /etc directory (/etc/hostconfig), changing the automount flag to –NO-. Once this setting is changed, the user must reboot. They are now ready to connect the suspect device to the system.
There are a number of attachments for connecting IDE, SCSI, and SATA drives to a MacBook through the firewire port. Once the device is connected to the computer, the investigator can issue the ‘mount’ command without any options to see what the address of the device is. Unix-based operating systems assign all drives a filename in the /dev directory. From here, the investigator has the option of mounting the device in read only mode by executing the mount command with the –r flag: $ mount –t ext2 –r /dev/disk1s1 (where disk1s1 is the suspect device.) It is preferable, however; to create a forensic copy of the device.
To create this copy, the investigator can use Mac’s built in ‘dd’ or ‘datadump’ utility. This utility will create a bit by bit copy of the device without mounting it and/or changing any files on the device. To use dd to make a forensic copy pass the location of the device you wish to copy along with a destination for the new image. (# dd if="/dev/disk3s1" of="/Users/donny/badguysstuff.dmg") The .dmg extension is the Macintosh disk image format. These images can be mounted as disks and even booted to if the image is a copy of a complete Mac filesystem. Once the original device is removed and stored in an evidence container, the user can begin the investigation.
At this point, there are a number of tools the investigator can install to aide in discovery. Most of these are commercial products that require nominal to hefty fees to use. One of the more useful commercial utilities is Norton DiskEdit, which can recover deleted files. There is also an entire suite of forensic tools for Macintosh from a company called “BlackBag.” This tool is priced at roughly $500, but gives the user everything he or she needs to get started. While more expensive tools will perform better in most instances, there are freely available forensic tools that can be used on the Mac.
To start, there are a number of command line utilities built into the operating system that can give the investigator useful information regarding the device’s partition structure and access times. Data can be retrieved using the hexdump command. The hexdump command can print to the screen or a file the bit-by-bit information contained on the drive, allowing for analysis at the lowest level (Donnelly 2004.) There is an additional utility, ‘OD’, that can also dump data in ASCII, Octal, and Decimal format.
In addition to these utilities, there is also an open source tool available called ‘Sleuthkit.’ Sluethkit, along with its graphical front-end, ‘Autopsy’, can be downloaded for free at http://www.sluethkit.org. The install is reasonably easy by Unix standards. It is important to remember to install sluethkit before installing autopsy. Once installed, run the autopsy server and login with a browser to http://127.0.0.1:9999. The interface is easy to use and allows for data inspection at the bit level as well as case tracking and note taking.
With a few easy configuration changes, the Macintosh platform can be a very powerful computer forensic tool at a reasonably affordable cost.
Sources
Donnelly, Derrick (2004) O’reily Mac OSX Conference notes Retrieved November 25, 2006 from website http://conferences.oreillynet.com/cs/macosx2004/derrick_donnelly.pdf
Hawkins, Peter (2002) Macintosh forensic analysis using os x Retrieved November 25, 2006 from website http://www.sans.org/reading_room/whitepapers/apple/269.php
Subscribe to:
Posts (Atom)
