Archive for August, 2005

Using slapconfig in Mac OS X Server

Sunday, August 28th, 2005

The following command forces an immediate replication event:
slapconfig -replicatenow

The following command will promote a replica to a master:
slapconfig -promotereplica diradmin

The following command will remove a replica from the OD environment (for the purpose of this test the OD REplica will have IP of 192.168.0.88
slapconfig -removereplica 192.168.0.88

The following command command will disable Open Directory on a server that is a replica or master. If you use this then everything in the database on that system will be lost. If it is the only reliable OD system then the OD Database will be lost.
slapconfig -destroyldapserver diradmin

The following command will setup an OD Master as a Kerberos KDC:
slapconfig -kerberize

If replication is broken the following will create a Launchd event to run replication:
slapconfig -startreplicator

The following command will be used to backup the OD database (for this example we’ll back it up to /LDAP_Database_Backup):
slapconfig -backupdb /LDAP_Database_Backup

Assuming the same path the following could be used to restore the database:
slapconfig -restoredb /LDAP_Database_Backup

The following command will return with what role the server has (if any):
slapconfig -getstyle

The following command will report the replicas and replication interval when run from a master:
slapconfig -getmasterconfig

The following command will report the address of the master and the last time the replica was updated from the master when run from a Replica:
slapconfig -getreplicaconfig

The following will setup an OD Master and setup diradmin with the same password as the root account:
slapconfig -createldapmaster

The following command will setup an OD Master and setup diradmin with the provided password (in this case the word newpassword):
slapconfig -createldapmaster diradmin

The following command will change the IP of the OD listener from 192.168.0.2 to 10.0.0.2:
slapconfig -changeip 192.168.0.2 10.0.0.2

The following command will allow you to customize many of the OpenLDAP parameters for Open Directory (read the Man page before using):
slapconfig -setldapconfig

The following command will allow you to customize many of the policies for Open Directory (read the Man page before using):
slapconfig -setmacosxodpolicy

Mac Forensics in Los Angeles

Sunday, August 28th, 2005

Ever been hacked? Had information stolen? Who do you turn to? What do you do? No matter what the level, a security breech has occurred and action must be taken to ensure a repeat offense doesn’t happen. The first reaction to a security breech is to isolate it and fix it as soon as possible. However, writing to the systems in any way can cause clues to be overwritten. Therefore it is important to discover the identity of the attacker.

The more quickly that forensic analysis is performed the more likely that the attacker, vandal or thief will be apprehended. One of the best places to start in analysis is making a copy of the system that hasn’t been written to. For Windows this is done using a program like Ghost. On the Mac platform using Carbon Copy Cloner or the Disk Utility to create an image is a good move. It is best to get a copy of your system as soon after a security incident as possible.

On local systems, there are some valuable pieces of information that can be obtained about the identity of the person stealing data. This can be anything from the IP address of the attacker to the name of the drive they’re transferring data to. On many Operating Systems valuable logs or cached files are overwritten on a routine basis. If a clone is made, it is often best to create a clone, or a replica of the system in its current state, as soon as possible.

If it’s a server, then the logs of the server provide good clues as to where to look for the perpetrator. Once again it is helpful to create a clone of the system. However, this is not always possible on production servers. Copying the log files is the next best thing.

Firewalls can provide good clues as well. The logging cycles on firewalls typically store data for a shorter period of time than on workstations or servers. Creating a screen shot in PDF format of the firewalls logs or exporting the logs into a text file is a good starting point. Firewalls typically provide good information on what addresses are communicating with a network. This makes them good at specifically determining the identity of the attacker and according to logging levels, the attacks used.

No matter what the issue, time is of the essence. Contacting a professional to help is a good idea. Getting the FBI or the LA County District Attorneys office involved can take time and this can cause clues to be damaged, lost or destroyed. IT professionals can also assist in creating a chain of custody on the equipment that can later be used in court when and if the person who’s invaded your privacy is apprehended and put to trial.

Shutting Down Servers and RAID Arrays

Monday, August 22nd, 2005

Introduction

In emergency or critical situations it is sometime necessary to quickly power down an entire network of servers. This could be due to a natural disaster, planned maintenance, or a variety of unforeseen circumstances. This document attempts to scope a quick yet safe method of powering down all servers and network devices, then walking through powering everything back up.

Part I – Shutting Down

Methodology and Theory

This section will explain the general principles of an emergency shutdown. The general procedure is as follows:

1) Notify everyone of the shutdown. Have everyone (ideally) turn off his or her computer.
2) Have all server logins and passwords handy.
3) The shutdown sequence is: Servers, then RAID arrays and attached storage,
then network devices.
4) Make sure every device is completely powered off, and not in stand-by mode.

The most essential part of this is making sure you turn off the servers BEFORE you turn off any storage devices. Most operating systems store often-used files and settings in memory, so shutting servers down first allows the OS to write/update any files beforehand. Once the servers are shutdown and off, generally speaking, it is fine to power down storage.

Shutting Down a Windows-Based Server

1) If you are on a locked screen, and at the desktop, press CTRL-ALT-DEL
at the same time.
2) Enter the administrator login and password. This should put you on a desktop screen.
3) Click on the Start button, then click on “Shut Down”
4) Make sure the option for “Shut down” is selected. On some Windows servers,
you may have to enter a reason before you’re able to press ok.
Type “emergency shutdown” if there is a box asking for a reason. Press OK.
5) Depending on your sever setup, there might be several applications that need
to be shut down. Once Windows tells every application that the machine is turning off,
the applications may ask for permission to quit. Just click “Yes” or “Ok” if any
boxes appear.
6) WATCH AND MAKE SURE THE SERVER SHUTS DOWN. Servers can take
a long time to shutdown/start up due to all the programs and services they need to
keep track of, so this may take up to 3-5 minutes.
7) The server should power down completely. Look at the server and make sure there are
no lights on (which would indicate that the server is in stand-by mode). The surest way
to verify power-off is to check the fan in the back of the box. If the fans are off,
the server is off.
8) If the system has been shut down, but there are still lights on it, you can force
the machine to turn off by pressing the power button, and holding it down
for 10 seconds. This will force the system to lose power. Every PC created after 1997
has this ability.
9) Repeat this procedure for every Windows Server you have.

Shutting down a Mac OS X Server

1) If you are seeing a locked screen, or a screen saver, press a key on the keyboard.
This will wake the system.
2) In the login box, enter the administrator login and password. It should take you to
the desktop.
3) Click on the Apple symbol in the top left corner of the screen.
4) Click on Shut Down.
5) The server will ask if you are sure you want to do this. Click “yes”
6) Depending on your sever setup, there might be several applications that need to
be shut down. Once OSX tells every application that the machine is turning off,
the applications may ask for permission to quit. Just click “Yes” or “Ok” if
any boxes appear.
7) WATCH AND MAKE SURE THE SERVER SHUTS DOWN. Servers can take
a long time to shutdown/start up due to all the programs and services they need
to keep track of, so this may take up to 3-5 minutes.
8) If the system has been shut down, but there are still lights on it, you can force
the machine to turn off by pressing the power button, and holding it down for 10 seconds.
This will force the system to lose power. Every computer created after 1997 has
this ability.
9) Repeat this procedure for every Apple OSX Server you have.

Shutting Down a Linux Server

Note: In order to do this, you will need both the administrator login/password, AND an additional password known as the “root” password. The root password is the King-Of-All-Kings password. It allows you to do ANYTHING to the server, without restriction. Be VERY careful what you type when you are using “root” mode.

1) If you are not at a command line prompt, you are probably looking at a “login:” prompt.
Enter the admin login and password.
2) You will be looking at command line prompt now. Type “su” and press enter.
This means “I want to be a SuperUser”
3) It will ask you for the root password. Enter it here. NOTE: When you type this
password, it will not display it on the screen. This is for security reasons (so nobody
can peek over your shoulder)
4) If you typed it correctly, the prompt should change to a # at the end of it.
5) Type “shutdown now” and press enter.
6) The screen should automatically fill with information about the server shutting down,
and the various services that are being turned off.
7) The machine should shut down completely.

Shutting Down Arrays and Storage

Once the servers are down, most of the hard work is done. Look at the arrays, or network storage. There should be no disk activity on them (ie: no lights should be blinking) If there are posted procedures for a specific method of shutdown, please follow them. If not, once the servers are shut down, as a general rule, it is ok to find the power switch and turn them off.

Shutting Down Routers and Network Devices

Most routers, firewalls, and network devices have no moving parts, and are designed to handle a power outage gracefully. In an emergency, it would be ok to just quickly unplug them after the servers, storage, and workstations are shut down. This is not the best policy, nor is it inclusive for every network device out there. But it is acceptable in a critical situation, where time is of the essence.

Part II – Starting up the network.

Methodology and Principles.

The only concern when starting everything up is the sequence. When shutting down, the order was workstations, servers, storage, then network devices. When starting everything back up, the process is REVERSED.

Plug all routers, firewalls and switches back in. Wait at last 2 minutes for everything to come back online, and for all the lights to start blinking again.

Now power the RAID arrays and storage on. Let the drives spin up and let the systems prepare themselves for use. Wait at least 3-5 minutes for this, even if it looks like everything is done.

One the storage is up and running, it time to power up each server…ONE BY ONE. It is critical to not only turn each server on, but to WATCH each one boot up and get to the login screen. Each machine may take as long as 5 minutes to do this, due to the programs and services being loaded. If any messages appear, write them down and call Three18 (310-581-9500) immediately.

After everything in the server room is up and running, have the users turn on their workstations and attempt to use their usual programs (ie: email, web, filemaker, etc) Make note of any errors or unusual messages. Be sure to write them all down, and call Three18. For the most part, essential services should be good to go (email, internet)

And, as always, call Three18 if you have any questions or concerns. We are available 24 hours a day for emergency situations. 310-581-9500.

Troubleshooting DNS From The Mac OS X Command Line

Sunday, August 21st, 2005

Being able to troubleshoot DNS is very important in a modern network. Without DNS the Internet and email seems broken for end users. Ping is not always the most accurate tool because it can be blocked at routers and firewalls, so using dig or nslookup to find an IP address is an important step in troubleshooting. Once you have found your IP address it is possible to try to telnet into many services by telneting into their ports, which is a far more realstic view of whether a host is up or down than whether it can be pinged.

Here’s a listing of utilities that you can use to test DNS resolution. However, by far the single easiest way to troubleshoot DNS is to always keep the IP address of an alternative DNS server in your head. If are ever in doubt, just put that server into the Network Preference pane and see if things get better. If they do you know what your problem is. If they don’t it’s most likely a physical networking issue that plagues you. Network Utility

This neat little GUI app in the Utilities folder of every OS X machine provides an easy way to nslookup and dig, as well as port scan. But you should also know how to do it from the command line, as you end up with far greater control over your commands.

Dig, or Domain Internetworking Groper, is a useful troubleshooting and informational tool. It will allow you to do DNS queries from the command line on any DNS server. For example to find out what IP a site has do:

dig www.318.com

But what if you get good records in-house and bad records out of house (outside your network) or vise-versa? That’s where using the dig command to look up information from a different DNS server comes in handy. To do this same command, but query a different DNS server (204.69.234.1) instead of what is set in your network preference pane:

dig @4.2.2.2 www.318.com

To find out what server takes mail for 318.com do:

dig 318.com mx

To reverse an IP address:

dig -x 205.178.145.65

Occasionally you might find when you dig a site that you turn up with something that resembles the following:
www.google.com. 36380 IN CNAME www.l.google.com.
www.l.google.com. 66 IN A 64.233.169.103
www.l.google.com. 66 IN A 64.233.169.104
www.l.google.com. 66 IN A 64.233.169.147
www.l.google.com. 66 IN A 64.233.169.99

This is called round robin DNS, and means that when a users runs a ping against a site they could receive a reply from any of the following servers.

So what would you do if you ran a dig and no records came up for anything? Well, that’s where the whois command comes into play. Try running whois 318.com and you will see what DNS servers we are using as well as when our name expires. About once every few months I run into situations where a name has expired.

Installing MediaWiki on Mac OS X

Wednesday, August 17th, 2005

Installing MediaWiki

1. Create a database in MySQL called wikidb.
2. Create a new user called wikiserver that has full priviledges to this database (the user does not need to be called wikiserver, but that is the username we will be using for this walkthrough).
3. Download the latest stable release of MediaWiki from http://mediawiki.sourceforge.net.
4. Extract the tar files into a new folder (for this example we are going to call it wiki to keep things easy). This can be done using the tar -xvzf mediawiki.tar.gz (or subsititute your file name for mediawiki.tar.gz
5. Make the configuration files writeable using the command chmod a+w config while in the new wiki folder
6. Move the wiki folder onto a web server
7. From your web server, visit the site 127.0.0.1/wiki or the subfolder that you placed the wiki files into
8. At the MediaWiki Installation page, you will either see a notice that you can install MediaWiki or a notice that your system does not meet the minimum requirements for installion. If your system does not meet the requirements, install the modules that are listed. If it does, move on to the next steps
9. At the MediaWiki Installation page, scroll down to the Site Config section. Here, fill in the fields for:
a. Wiki name: The name assigned to your wiki.
b. Conact e-mail: Displayed when error notices are encountered.
c. Language: The language to be used for your Wiki
d. Copyright: The copyright type, typically leave this as the default setting
e. Admin Username: The username to use for administering the Wiki
f. Admin Password: The password to use for administering the Wiki
g. Shared Memory caching: Decide whether to use memcached
10. Fill in the appropriate values for the Email and authentication setup section:
a. Email (General): Enable or disable the global use of email for your Wiki
b. User-to-User email: Allow users to email one another
c. Email Notification: Allows users to be notified if there is a change in a folder or page
d. Email Authentication: Enable email authentication for the wiki. Sends request for users to click a link to authenticate into the wiki.
11. Database Configuration options:
a. Database Type: Most users use MySQL, but Oracle is an option as well, although experimental.
b. SQLServerHost: The address of the MySQL Server. If MySQL is on the system you are currently using then leave this field as localhost.
c. Database Name: The name of the database you will be using in MySQL to store your wiki’s data.
d. DB Username: If you used wikiserver in step 2 then use wikiserver here; otherwise use the username you chose in step 2.
e. DB Password: The password you assigned for your wikidb user.
f. Database Table Prefix: Use this option if you would like to share you will be using other tables within the wiki database for other applications.
g. Database Character set: leave this as defualt unless you will be using
h. Superuser account: The MySQL SuperUser account – typically root
i. Superuser Password: The MySQL SuperUser or root account password
12. Click on Install MediaWiki!
13. Move the LocalSettings.php file from the /config directory of the wiki installation into the root directory of the wiki installation
14. Go to the http://127.0.0.1/wiki folder and the default Main MediaWiki page will open
15. Customize the wiki to work for your organization