View source for HOWTO Mac OS X Server (10.4)

A new page has been cloned from this one:
[[HOWTO Mac OS X Server (10.5)]]

So, I had an afternoon to work on this, and I got a successful install.  I was sad to find there was so little documentation from other people using Mac OS X Server, so I decided to write up what I did.  This worked for me, and it'll probably work for you, but as always, YMMV.

Now, there may have been much simpler ways to accomplish this, and I'm sure it's a little rough around the edges, but it works, and I'm happy.  Hopefully it'll help someone else.

Enjoy!

==Assumptions==

# You are running 10.4.11 Server, stock system
# There are no modifications to Python (still stock)

==Procedure==

===1. Get the software===
<pre>cd ~/source
curl -O http://superb-sea2.dl.sourceforge.net/project/fail2ban/fail2ban-stable/fail2ban-0.8.4/fail2ban-0.8.4.tar.bz2</pre>

===2. Unpack the software===
<pre>tar xvfj fail2ban-0.8.4.tar.bz2</pre>

===3. Install the software===
<pre>cd fail2ban-0.8.4
sudo python setup.py install</pre>

===4. Fix an issue with Python 2.3===

Apparently in OS X 10.4.x, Apple includes Python 2.3 by default.  This causes a problem with the
<code>fail2ban</code> script (specifically something called <code>asyncore</code> 
[http://code.google.com/p/pyftpdlib/issues/detail?id=16]), so we need to make a modification to 
<code>/usr/share/fail2ban/server/asyncserver.py</code> as root. (I use <code>emacs</code>, but feel 
free to use what you like)
<pre>sudo emacs /usr/share/fail2ban/server/asyncserver.py</pre>

Change line 135 from this:
<pre>asyncore.loop(use_poll = True)</pre>
To this:
<pre>asyncore.loop(timeout=1, use_poll=hasattr(asyncore.select, 'poll'))</pre>

===5. Make a spot for the log file===
<pre>sudo touch /var/log/fail2ban.log</pre>

===6. Edit the <code>fail2ban</code> configuration files===

Here's where you need to tell the program what you want to do.  You can read all about this on the <code>fail2ban</code> wiki [http://www.fail2ban.org/wiki/index.php].  I'm only focusing on using <code>ssh</code> & <code>ipfw</code>.

<pre>sudo emacs /etc/fail2ban/jail.conf</pre>

In the section marked <code>[ssh-ipfw]</code>, you'll want to make it look like so:
<pre>
enabled  = true
filter   = sshd
action   = ipfw
logpath  = /var/log/secure.log
</pre>

===7. Make a little change in the <code>ipfw</code> actions===

We need to make a couple of changes in how <code>fail2ban</code> deals with adding rules.

I have two ethernet cards (one public-facing, the other private), and I want to lock down both avenues when needed, so we need to edit the <code>ipfw.conf</code> file:

<pre>sudo emacs /etc/fail2ban/action.d/ipfw.conf</pre>

and change:
<pre>actionban = ipfw add deny tcp from <ip> to <localhost> <port></pre>

to this:
<pre>
actionban = ipfw add 200 deny tcp from <ip> to your-public-addy-here <port>
            ipfw add 201 deny tcp from <ip> to your-private-addy-here <port>
</pre>
Obviously, you'll want to replace your specific IP addresses in the dummy placeholders above.  If you only have one IP address, you could have left the <code><localhost></code> tag in place (just make sure you've got <code><localhost></code> defined in <code>/etc/fail2ban/action.d/ipfw.conf</code>.)

<i>(<b>Note:</b> I also added rule numbers 200 & 201 so that they'd be higher up in the IPFW food chain.)</i>

====Further enhancement====
While the above <code>actionban</code> does block unwanted addresses from specific ports it suffers from defining all the banned address on a single rule number with a specific port. When the unban command is issued for the first blocked address it will remove the entire rule set with that number (in the above case rules 200 and 201) including any addresses that were banned after the first one. This is not desirable since any of the addresses added between the first ban and it's corresponding unban will now be allowed by the firewall and only logged as already banned by fail2ban (until their ban time is up or fail2ban is reloaded).

A solution to this problem is to use the following:
<pre>
actionban = t=150
 while [ `ipfw list |grep -ic 00$t | awk '{print $1;}'` != '0' ] 
 do ((++t)) 
 done 
 ipfw add $t deny tcp from <ip> to any
</pre>

This will search and use the first available rule number starting at 150. When it is time to unban an address, only the one rule is removed thus preserving the other banned addresses.

Some attackers will cycle through the ports while using the same IP address. By changing <code>to your-private-addy-here <port></code> to <code>to any</code> in the <code>ipfw add</code> rule the firewall will block all bad traffic on this server, not just a specific port. If you still need to specify your server's IP address just leave off the <code><port></code> so it blocks all the traffic.

<i>(<b>Note:</b> This method works until the counter reaches 1000 at witch time wanted rules may be deleted. If you have a large number of banned addresses you may want to consider permanently banning some of them.</i>

--[[User:Td|Td]] 18:33, 3 February 2010 (UTC)

===9. Add a startup file===

Someone has provided a nice startup file for Mac OS X, but it needs a little editing.

<pre>
cd ~/source/fail2ban-0.8.4/files
sudo cp macosx-initd /Library/LaunchDaemons/org.fail2ban.plist
sudo emacs /Library/LaunchDeamons/org.fail2ban.plist
</pre>

In the editor, get rid of the first two lines, such that the file begins with ''<?xml ...''

===10. Start it up===

<pre>sudo launchctl load /Library/LaunchDaemons/org.fail2ban.plist</pre>

You should see some informational text appear, then your prompt will return to you.  You can verify that things are running smoothly with a look at the log file (<code>/var/log/fail2ban.log</code>).


==See also==
#http://www.fail2ban.org/wiki/index.php/Main_Page
#http://code.google.com/p/pyftpdlib/issues/detail?id=16
#http://www.infosecwriters.com/text_resources/pdf/securing-mac-os-x-tiger.pdf