So, you have a web server. So, you have PHP. So, you want to make it a little quicker? The following are a few ideas to let you do that. First, let me share my experiences.
I have always been wondering "what would a digg do to my site." I mean, I don't run a commenting system, so I'm refering to just some article. Because I prefer to manage my own server, I have decided to use a VPS (Virtual Private Server) from VPSLink. Before purchasing I searched around, read reviews, and finally tested it out. Liking what I tested, I stayed. However, since I just host a few 'play' sites (http/email/ftp), and a few sites for friends, I am not going to spend much money on a high-end plan. That leaves me with a little problem: how can I maximize what I've got?
I've tried quite a few things. I finally ended up using Apache to handle php and Lighttpd to serve all static crap. So, how?

Staticzerize A Page

One of the first things you will need to do is pull down a static copy of your page.

 user@vps:~$ wget http://www.kelvinism.com/howtos/notes/quick-n-dirty-firewall.html 

That was easy enough. Next, let's create a directory for static pages.

user@vps:~$ sudo mkdir /var/www/html/kelvinism/static
user@vps:~$ sudo mv quick-n-dirty-firewall.html /var/www/html/kelvinism/static/ 

Sweet. (This is assuming of course that the site's DirectoryRoot is /var/www/html/kelvinism). Next, Lighttpd.

Lighttpd Configuration

Install Lighttpd however you choose. There are a few key changes to make in the configuration.
First, change the directory for your base DocumentRoot. Next, change what ports the server will listen on.

server.document-root = \"/var/www/html\"
## bind to port (default: 80)
server.port = 81
## bind to localhost (default: all interfaces)
server.bind = \"127.0.0.1\"

Ok, Lighttpd is all done. Now just start her up, and move onto Apache.

 user@vps:/etc/lighttpd$ sudo /etc/init.d/lighttpd start 

Master Configuration

Depending on your distro and what apache you installed, you might need to do this a little different. I will illustrate how to do it with the Apache package from the Debian repository. Let's activate the mod_proxy module.

 user@vps:~$ sudo a2enmod
Password:
 Which module would you like to enable?
 Your choices are: actions alias asis auth_basic auth_digest authn_alias authn_anon authn_dbd authn_dbm authn_default authn_file authnz_ldap authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache cern_meta cgi cgid charset_lite dav dav_fs dav_lock dbd deflate dir disk_cache dump_io env expires ext_filter file_cache filter headers ident imagemap include info ldap log_forensic mem_cache mime mime_magic negotiation php5 proxy proxy_ajp proxy_balancer proxy_connect proxy_ftp proxy_http rewrite setenvif speling ssl status suexec unique_id userdir usertrack version vhost_alias

 Module name? proxy_http

If you are not using a system with a2enmod, you can edit your configuration by hand. Just insert the following into your apache2.conf or httpd.conf files:

LoadModule proxy_module /usr/lib/apache2/modules/mod_proxy.so
LoadModule proxy_http_module /usr/lib/apache2/modules/mod_proxy_http.so 

The actual location of the extension (*.so) will vary depending on where you installed it. If you have tried this out and get forbidden errors, or it just simply isn't working, the reason is because the proxy modules isn't configured right. You will likely get an error like:

 client denied by server configuration: proxy 

To solve this, you need to edit /etc/apache2/mods-enabled/proxy.conf or your httpd.conf file.

<IfModule mod_proxy.c>
   #turning ProxyRequests on and allowing proxying from all may allow
    #spammers to use your proxy to send email.
    ProxyRequests Off
    <Proxy *>
        AddDefaultCharset off
        Order deny,allow
        Deny from all
        Allow from .kelvinism.com
    </Proxy>
    # Enable/disable the handling of HTTP/1.1 \"Via:\" headers.
    # (\"Full\" adds the server version; \"Block\" removes all outgoing Via: headers)
    # Set to one of: Off | On | Full | Block
    ProxyVia On
</IfModule>

Now, open up your httpd-vhosts.conf or httpd.conf or wherever your site configuration is stored, and add the following inside the <virtualhost> directive:

#DocumentRoot is just for reference, I assume you know how to setup virtualhosts.

DocumentRoot /var/www/html/kelvinism/
ProxyRequests Off
ProxyPreserveHost On
ProxyPass /howtos/notes/quick-n-dirty-firewall.html http://127.0.0.1:81/kelvinism/stat ic/quick-n-dirty-firewall.html 
ProxyPass /images/ http://127.0.0.1:81/kelvinism/images/ 
ProxyPassReverse / http://127.0.0.1:81/kelvinism/

As an alternative, you could use a rewrite rule.

#DocumentRoot is just for reference, I assume you know how to setup virtualhosts.
DocumentRoot /var/www/html/kelvinism/
RewriteEngine On
RewriteRule ^/howtos/notes/quick-n-dirty-firewall\.html$
http://127.0.0.1:81/kelvinism/static/quick-n-dirty-firewall.html [P,L]
ProxyPass /images/ http://127.0.0.1:81/kelvinism/images/
ProxyPassReverse / http://127.0.0.1:81/kelvinism/
 

So what this does is pass the page http://www.kelvinism.com/howtos/notes/quick-n-dirty-firewall.html through mod_proxy to Lighttpd. So, test it out, and you are all done!

Let's say one page on your site is getting hit hard. And I mean, it was digg'd or something. If the page resides on some CMS or blog, and each request is being processed by PHP and resulting in requests to your database, crap is gonna hit the fan. Well, at least if you're cheap like me, you'll try to squeeze every penny out of what you've got.
That said, mod_rewrite comes to the rescue.
There are only a few modifications that you need to do. The first is to ensure that mod_rewrite is enabled. If you have apache installed on debian, this might do:

user@vps:~$ sudo a2enmod
Password:
Which module would you like to enable?
Your choices are: actions alias asis auth_basic auth_digest authn_alias authn_anon authn_dbd authn_dbm authn_default authn_file authnz_ldap authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache cern_meta cgi cgid charset_lite dav dav_fs dav_lock dbd deflate dir disk_cache dump_io env expires ext_filter file_cache filter headers ident imagemap include info ldap log_forensic mem_cache mime mime_magic negotiation php5 proxy proxy_ajp proxy_balancer proxy_connect proxy_ftp proxy_http rewrite setenvif speling ssl status suexec unique_id userdir usertrack version vhost_alias
Module name? rewrite 

Otherwise, you'll need to drop the following in your apache2.conf (or httpd.conf).

LoadModule rewrite_module /usr/lib/apache2/modules/mod_rewrite.so

Next, grab the page that is getting hit hard from your site.

user@vps:~$ wget http://www.kelvinism.com/stuff/hit-hard.html

Next, let's create a static directory and move that page into it.

user@vps:~$ sudo mkdir /var/www/html/kelvinism/static
user@vps:~$ sudo mv hit-hard.html /var/www/html/kelvinism/static/

Coolio. Now we'll rewrite the normal URL (the one being hit hard) to the static URL.
If you have full access to the server, just mimic the following to a VirtualHost:

<VirtualHost *>
    DocumentRoot /var/www/html/kelvinism
    ServerName www.kelvinism.com
    ServerAlias kelvinism.com www.kelvinism.com
<Directory \"/var/www/html/kelvinism\">
    Options Indexes -FollowSymLinks +SymLinksIfOwnerMatch
    allow from all
    AllowOverride None
    RewriteEngine On
    RewriteRule ^stuff/hit-hard\\.html$ /static/hit-hard.html [L]
</Directory>
</VirtualHost>

If you don't have access to the server, you can just add the following to a .htaccess file:

RewriteEngine On
RewriteRule ^stuff/hit-hard\.html$ /static/hit-hard.html [L]

Sweet.

I've run into this error quite a few times, might as well toss blog entry about it:
ERROR 1064 at line 17: You have an error in your SQL syntax near 'ENGINE=MyISAM DEFAULT CHARSET=latin1' at line 7
One likely reason this comes about is because the data being imported/exported is not compatible with the database version. For instance, at home you export the information from a mysql5 database. Then you try to import it on a mysql3.23 database somewhere else -- and it craps out on you. Bummer.
The solution is quite simple:

 mysqldump --compatible=mysql323 -u root -p database > exportName.sql

Status:

My buddy Ian and myself have decided to get our MCSEs. However, Ian is a Mac lover, and I can't seem to stay away from Linux (and I'm too cheap right now to buy a MacBook). The irony might be subtle, yet we are still studying and making progress. For the most part, I have decided to take the tests in the following order:

70-290, Security+, 70-270, 70-291, 70-293, 70-294, 70-298, 70-299

Update: So, now I'm MCSE. I'm still debating whether or not to do the final Security test. I really need to get caught up with Exchange, so I might do the Messaging test at some point, but who knows. At this point I'm calling it good.

Core Exams: Networking System

Exam 70-290: Managing and Maintaining a Microsoft Windows Server 2003 Environment

Exam 70-291: Implementing, Managing, and Maintaining a Microsoft Windows Server 2003 Network Infrastructure (notes)

Exam 70-293: Planning and Maintaining a Microsoft Windows Server 2003 Network Infrastructure

Exam 70-294: Planning, Implementing, and Maintaining a Microsoft Windows Server 2003 Active Directory Infrastructure

Core Exams: Client Operating System

Exam 70-270: Installing, Configuring, and Administering Microsoft Windows XP Professional

Security Specialization: Core Design

Exam 70-298: Designing Security for a Microsoft Windows Server 2003 Network

Security Specialization:Core Security

Exam 70-299: Implementing and Administering Security in a Microsoft Windows Server 2003 Network

CompTIA Security+

So, you've got a few Xen images around, and they are starting to fill up. How do you add a few more gigs to 'em?

 root@tpe:/# xm shutdown vm01
 root@tpe:/# cd /xenimages
 root@tpe:/xenimages# dd if=/dev/zero bs=1024 count=1000000 >> vm01.img
 root@tpe:/path/to/images# resize2fs -f vm01.img
 

That's it, you just added a gig to your image called 'vm01.img'.

Ian keeps bugging me at how great Quicksilver is. Knowning that there must be an alternative built for linux, I accidently stumbled across Katapult.

While it still has a little room to grow, Katapult makes a great tool in any KDE toolchest. Press ALT+SPACE, and your widget fires up, ready to take your orders. Since words don't really do this justice, I created a screencast.

Katapult Screencast from Kelvin Nicholson on Vimeo.

Status:

I've played with quite a bit of virtualization, especially VMWare for ages. About eight months ago I started to play around with Xen, and got it to work great, except for the fact that the nvidia driver wouldn't work with the Xen kernel. That said, I'm gonna give another go.

Throughout senior high, and especially my last year, I managed to score a bunch of crappy motherboards and random parts and pieces. Six or so years later, my parents are still finding old motherboards. Considering these computers were mainly P120s with 64-128 megs of RAM, they weren't so hot. What is one to do?

As you could guess, when I started university I had quite a few computers in my room. I had about three or so P120s (one in a hampster cage, don't ask), one AMD600, an AMD1ghz and one iBook (500 whooping mhz). Computers would die, get replaced, but overall they worked quite well. Considering almost all the computers ran Linux (the AMD1ghz also ran Windows -- to play games -- and the iBook sort of ran OSX -- and YDL), every system was quite happy. I had an OpenBSD box as my gateway. Life was good.

But now I don't like having five+ systems. Electricity alone is a strong factor, plus, I don't really want to manage all those systems. Plus noise.

Because of this, I have two systems: my workstation/test lab, and my laptop. I hopefully will never need anything more. But, because of thise, I needed Xen to play nice with my Nvidia closed source driver -- which when I tested it eight months or so ago, it wasn't. Since then I have been using Linux-Vserver, and while it works great, my requirements have started to change.

Luckily Nvidia has released a few new updates, and a few hackers have patched the driver to include support for a xen-based kernel. Maybe I'll write up a tutorial at some point.

Since I've already done the creation of the doms before, and it is somewhat similar to Vserver, everything went smoothly. You can expect some fun screencasts and experiments in the near future.

Yea, you read that right. Three commands and you can run a pen-test on your website/webserver. So, how?

kelvin@home:~$ sudo apt-get install nikto
kelvin@home:~$ sudo nikto -update
kelvin@home:~$ nikto -h www.thoughtdeposit.net

As you can see, Nikto is a web server scanner, apparently for over 3200 dangerous files/vulnerabilities. Additional features can be seen at the Nikto website, yet you will certainly want to add this old gem to your webserver toolbelt as soon as possible.

In the next year I plan to make a little video, nothing fancy likely, but something that will require an editor. However, I don't own a mac (which rules our Final Cut Pro + After Effect and iMovie, which Ian and I both have had too much fun with. Inside joke.) I'm also a die-hard Linux fan, trying to hold out buying a mac for as long as possible.

SF to the rescure. There are four editors listed, and in the next year I'll try them all. Overalll, they look quite promising.

Jahshaka -- Beta. Good reviews from what I've seen.
Kdenlive -- Alpha/Beta. Looks a lot less mature than Jahshaka, especially since I'm going to have to check it out via svn. But, the screenshots look quite impressive.
LiVES -- Beta.

For those of you not needing Apache and the whole kitchen sink, [insert reason here], Lighttpd is a very attractive contender. For me, it has a small memory footprint, which is highly appealing. However, getting SEO urls to work (i.e. utilizing rewrite), isn't too straightforward.
Tada! A little research yields two helpful links: one at lighttpd.net regarding how to use ModRewrite and another showing how to slightly modify the .htaccess file used by OpenSEF and Apache.
So...
1) Flush/clear any caches available
2) Make sure site is listed in OpenSEFs manager inside Joomla
3) Make sure SEO is Enabled insided the Joomla 'Site Configuration'
4) Change your host conditional statement so it matches this:

$HTTP[\"host\"] =~ \"(^|\\.)yourdomainname\\.com$\" {
     server.document-root = \"/var/www/your/domainlocation/\"
     url.rewrite-once = (
          \"^images*\\.(jpg|jpeg|gif|png)\" => \"$0\",
          \"^/administrator.*$\" => \"$0\",
          \"^/mambots.*$\" => \"$0\",
          \"(/|\\.htm|\\.php|\\.html|/[^.]*)$\" => \"/index.php\"
     )
}

Clear your browser cache, and check it out. If it doesn't work, you can try to "Delete All" URLs inside OpenSEF, and then your site will rebuild as necessary. Another note, as you can maybe tell by the above ruleset: you can have rewrite ignore directories. Just include:

\"^/directory.*$\" => \"$0\",

I'll admit, I think one of the thickest barriers to entry regarding Linux is variety. I love variety, but general end users don't adjust well to change (IMHO). Thus enter the stage: Portland. So, what does this mean to the end user? This means that, eventually, the UI throughout linux will all look similar -- regardless if it is designed to utilize GTK, QT or anything else (that is, if it is built off the Portland standard).

Sweeeet.

And as a runner-up, worth mentioning, the user driven Tango Desktop Project

I like most standards, I can't deny it. One thing that I find too humorous is the amount of sites that are not valid, even sites that claim they are. One tool in my box is HTML Validator, an extensioin for Firefox. A nice little icon appears in the lower right, indicating whether a page is valid, not-so-valid, or really-not-so-valid. Makes it easy to check your own sites, and others.

This little process, a total of two lines, took way to long to figure out.

First, we convert the VMware avi (VMnc format) to the Microsoft avi format.

 mencoder -of avi -ovc lavc movie.avi -o movie2.avi 

Next, we convert the Microsoft avi format to FLV format.

 ffmpeg -i movie2.avi -r 12  -b 100 movie.flv 

You can play around with the -r switch (rate per second) and the -b switch (bitrate). But, if those get larger, so does your FLV file.

Status:

After consulting several vendors in Kuala Lumpur, I was able to get the right Cisco with the right IOS. One of their technicians came and installed it, and that night I hooked it up to our VPN. Besides the fact that the internet distribution is still a little shady in Kuala Lumpur, the connection remains somewhat stable, and yet another node is brought on the company intranet.

Information is power, or so many of us think. As an I.T. administrator, no matter what the level, it is of my opinion that knowing what your network is doing is important. This includes regular operation, what it could do in the event of a disaster, or when it is just slightly not functioning.

Jeez, I'm personifying a computer network.

As I wrote in another post, I setup network monitoring for several nodes. But, what happens when an anomaly occurs? This is the story of hunting down a worm/virus, from far, far away.

While I can't go into too many details, for obvious reasons, I'll try and tell the story as-it-The overall process took for cleaning took several weeks to resolve, although minimizing the effect occurred the second the anomaly was discovered. The lengthy time to resolve is mainly due to the time to request computers to be patched/updated/scanned (like I said, this anomaly was with a large branch office in another country).

I've blurred out any relevant information for obvious reasons.

Almost immediately after setting up monitoring I noticed something strange occurring. As you can notice from the below graph (from nfsen), something is obviously wrong. If you can't notice it, that big spike, in what we'll call Network Green, should give you a clue. Now, I can expect a spike during lunch when people watch movies or send their 50mb picture email attachments, but this spike isn't always at noon, and as we'll see, it sure ain't emails.

Find the anomaly:

So, let's try to find out what is going on. Indeed, there are some analyzers of flow traffic that can display the types of traffic, and are useful if the issue isn't apparent, but NFSEN's filtering capabilities haven't failed me yet (although seeing a graph with types of traffic is useful).

We can now take a look at what is going on. Let's next just take a look at the statistics offered:

I've left the dates in there for you to see something interesting: Network Green transferred over 15 GIGS of UDP traffic. If we think back to networking basics, we can remember that UDP is a connectionless protocol. So, what uses UDP? DNS/TFTP, some streaming media, VoIP, and several types of encryption. That said, there isn't any legitimate reason for any of the employees to use that much bandwidth, of this type. Only one thing seemed apparent: somebody was massively downloading from some p2p source, or we had a worm/virus.

Now that we know it is UDP related, let's find out more. I've filtered by UDP in the graph just so you can see how much traffic that really is. Let's select the anomaly. We first select the left side...

Then we select the right side, and we have a pretty green highlighted section.

Now it is time to hunt the person down. Using NFSEN's built-in filtering capabilities, I was able to find which computer was being naughty. I first created the filter rule for the appropriate network (IP obscured for confidentiality):

Then could see the obvious place to look next:

As is highlighted, you can see that one IP is continually transferring UDP traffic over port 14857. Well, it certainly isn't DNS or TFTP! (But we knew that when 15+ gigs was transferred:) When we look at the Top 10 Src IP Addr, ordered by bytes, we can see that one IP transferred a whole lot of traffic.

What now? I pulled out the nmap/nessus combo and tried to see what was running. Telneting to port 14857 didn't return any form of hello message, and nmap didn't return any known services for whatever was on port 14857. At this point I sent out the emails/documentation to managers in the remote office requesting for anti-virus to be checked and loaded onto any computers. Next, I blocked the port, from that computer, from sending outgoing traffic. Occasionally, as you can see in the graph, another computer or two would show the same symptoms, but within two weeks the oddity had disappeared. Thanks you NFSEN and Cisco.

Status:

One of the greatest benefits, in my opinion, of Cisco routers is the ability to generate netflows. In a lot of ways, I would prefer to do this than implement some appliance (say, using ntop). The ability to analyse the amount of traffic becomes extremely valuable. Not only can one measure the amount of traffic, but the type of traffic that is being generated through the network.

Using a similar configuration, I setup all four Ciscos to export netflows that stream back to a server in the States. I decided to use nfdump as a collector. After the dumps are collected, it is simple to setup nfsen to parse and analyse the received flows. It even allows you to generate really pretty graphs.

So, why do this? For starters, collecting netflows allows the basic analysis of data, which can tell you several things. You can know instantly how saturated your connection is, if there are any anomalies, if there is any file sharing going on or when heavy traffic usage is. For instance, if the connection becomes slow during the end of the day, you can analyse what protocol is used the most during that time. Or, as was my case, hunting down virus infected computers that were fully saturating a 10mbit pipe.

A week in the life of NFSEN:

Abstract

The following is a Quick n' Dirty method at implementing a very simple firewall.

Locate IPTables

Depending on your server, first locate iptables:

 [root@vps /]# which iptables 

Create IP Based Accept/Deny

Create a whitelist (ignored by firewall) or blacklist (packet dropped) if you wish:

 [root@vps /]# vi /usr/local/etc/whitelist.txt 

And/Or...

[root@vps /]# vi /usr/local/etc/blacklist.txt 

In each file, add each IP per line, for instance:

 4.2.2.2 66.35.15.20 

firewall.sh Script

Then put the following in /etc/init.d/firewall.sh, and edit to fit your needs:

#!/bin/sh
#
## Quick n Dirty Firewall
#
## List Locations
#

WHITELIST=/usr/local/etc/whitelist.txt
BLACKLIST=/usr/local/etc/blacklist.txt

#
## Specify ports you wish to use.
#

ALLOWED="22 25 53 80 443 465 587 993"

#
## Specify where IP Tables is located
#

IPTABLES=/sbin/iptables

#
## Clear current rules
#

$IPTABLES -F
echo 'Clearing Tables F'
$IPTABLES -X
echo 'Clearing Tables X'
$IPTABLES -Z
echo 'Clearing Tables Z'
echo 'Allowing Localhost'

#Allow localhost.
$IPTABLES -A INPUT -t filter -s 127.0.0.1 -j ACCEPT

#
## Whitelist
#

for x in `grep -v ^# $WHITELIST | awk \'{print $1}\'`; do
        echo "Permitting $x..."
        $IPTABLES -A INPUT -t filter -s $x -j ACCEPT
done

#
## Blacklist
#

for x in `grep -v ^# $BLACKLIST | awk \'{print $1}\'`; do
        echo "Denying $x..."
        $IPTABLES -A INPUT -t filter -s $x -j DROP
done

#
## Permitted Ports
#

for port in $ALLOWED; do
        echo "Accepting port TCP $port..."
        $IPTABLES -A INPUT -t filter -p tcp --dport $port -j ACCEPT
done

for port in $ALLOWED; do
        echo "Accepting port UDP $port..."
        $IPTABLES -A INPUT -t filter -p udp --dport $port -j ACCEPT
done

#
## Drop anything else
#

$IPTABLES -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
$IPTABLES -A INPUT -p udp -j DROP
$IPTABLES -A INPUT -p tcp --syn -j DROP

Start Firewall

 [root@vps /]# chmod 700 /etc/init.d/firewall.sh
  [root@vps /]# /etc/init.d/firewall.sh 

As you may know, I've been taking a few of the MCSE:Security tests when I have time.  This afternoon I passed the 70-291, which is claimed to be the hardest of all the tests (and of the one's I've taken so far, I would concur).

 I'm taking my tests at the Geego Systems center.  If you are in Taipei for some reason, and needing a place to take some tests, this place is a safe bet.  Their staff is pretty darn cool, and they let me drink as much tea as I want.

 Anyways, the test.  I can't talk about any of the questions, 'cause I've "signed" an NDA, and Microsoft will take away my certification(s).  But, I'll tell you what I did to study.

I took three approaches, as I do to all the tests.

1) Get an Exam Cram2 70-291 book, and read it through, cover-to-cover.  This, in my opinion, is a great way to get to know the language used, and some of the concepts.  Exam Cram 2 books do a pretty good job of cutting out the fluff.

2) I have a copy of Mastering Windows Server 2003 that I picked up in Hong Kong last year.  It doesn't do a good job of cutting out the fluff, which makes it a great resource to flip through.  It is seems to have almost every tutorial you could imagine.  The one downside though, as there always is one, is that the book is starting to get a little dated.  Either way, this has to be one of the most complete books on 2003 I have ever flipped through.

3) It is all fine and dandy to read, but it is my belief that everything you read, you should do.  My little lab (see end of post for my cool diagram) seems to suite me quite well.  If you have read this far, and want some things to do in your test lab, this is what I would recommend:

• DNS - Know how to add CNAME's, A records and play with MX records.  Know how to prioritize mail servers.  Know how to create aliases.
• WSUS - Sadly, many of the books I've seen (or the two listed above), don't talk about WSUS.  I believe Microsoft just made the change on their tests, but it is on there.  And they hit this topic pretty hard, so be prepared.
• Security Templates  - Creating baselines and doing audits
• Network Security - Configuring firewalls, configure VPN between two networks (RRAS)
• DHCP - Creating scopes, relay agents and reserving client addresses
• TCP/IP -This test has a pretty big backbone of TCP/IP.  Know how to subnet, and general networking terms/methods.  Picking up a book on the Network+ certification, such as the Exam Cram2 Network+ book (which I read to refresh myself, and pass the Network+ test), could be useful.

Luckily I was able to get a few years of some real life hands-on experience with installing, implementing and managing AD through a previous I.T. position.   Practice always helps though.  Good luck!

 

Status:

Users don't like to remember passwords, heck, I don't like to remember to use passwords. I decided to upgrade all the webapps to authenticate off the domain, welcome a start to SSO. To do this I implemented the adldap php class to control authentication to each webapp. Thus, a simple GPO can control who has access to the app or not. A simple solution to a rather simple problem.

Status:

Backing up across the states has worked decently well, but due to several changes a more dedicated backup solution is in order. Desiring something quick, simple and inexpensive, research revealed a company that would perfectly fit the requirements. iBackup was a perfect substitute - instead of SSH+rsync to another office, iBackup provides rsync over ssl to their data center. A few simple changes to the cron job, and backup location is thus changed.

Status:

Time has come to bring another network on the VPN, and perform some more upgrades. The usual by now, I guess.

-Get China on VPN
-Limit access to other locations
-Update all systems
-Perform security audits
-Upgrade wifi
-Setup video conferencing

Ian and I set off for our China office out of Hong Kong, and the next day started working. Total preparation was around a month, maybe a little large, mainly due to red tape. We first acquired assistance of IBM China, who were of a great help aiding us in finding our desired Cisco. One of the most important factors, which we couldn't resolve by purchasing the Cisco in the States, is support/warranty contracts (if the Cisco totally dies, what then). Through our contact we were also able to find some local vendors that would support Wifi and the Cisco, in case of an emergency.

Before leaving I prepared the necessary configurations for the Cisco, or at least a good guide to start from. The technician who came out tried to get things going through the built in GUI, however wasn't have so much luck. I took over using my pre-built configuration and soon (we swapped out the old router with the Cisco during lunch) everything, including overloaded NAT, was working fine. By the time employees came back from lunch, they couldn't notice any difference.

While the Cisco tech (who I believe is a good guy, even though I did the Cisco install) was waiting for some paper work went through and upgraded the way obsolete wifi point from WEP (which wasn't even turned on anyways) to WPA. The reasons for this, especially connected to the VPN, are very obvious. Technically the AP wasn't supposed to support WPA, but he found the correct Chinese firmware and it worked. This is good, as the new AP wouldn't be coming for a little while.

Next on the list was video conferencing. The solution was the path of least resistance: Skype on a laptop. Ian took this one, setup the laptop, and tested conferencing back to the States.

On the agenda for that night was VPN. The problem with bringing the China office on the VPN is one of security. Virus' were quite prevalent (e.g. my shared drive on my Linux laptop, to use as a sandbox, had a couple .exe files dropped into it. All with rather odd names...) -- so we first ran some security audits. Nessus was a great help, as always, and we tracked down over [an UNFATHOMABLE amount of] critical holes. Picking the biggest culprits we started patching computers, removing spyware and running anti-virus. Slowly (a few days) we got the number knocked down significantly.

Lastly I hooked China up to the VPN. In order to do this safely I created some very strict access lists, to only allow outgoing communication over ports 80 and 443 (since that is all they needed at that point). Previously setup we had a webshare website (auth linked to the PDC), so no need to open any other ports.

Overall we completed what we set out to do. We made a few good contacts, achieved our goals, and once again learned more about doing I.T. overseas.

Status:

Before we grow any further, a new DNS scheme is in order. Following the pattern of: citycode.domain.com - shouldn't be too hard. A slightly stressful rename of the PDC (just one so far, still small) was in order. After that (and client computers re-associated), the routers were updated, the DNS server updated, and everything worked peachie. Not bad for a weekends worth of work.

Logs spiraling crazy, we run out of disk space all the time. A nifty trick to find where the disk went is to issue: du -cks * |sort -rn |head -11

This returns where the disk usage is, and makes finding the bloated log a lot easier.

The following sites might be helpful to configure IPSec again, or on a more complex basis:

http://www.cisco.com/univercd/cc/td/doc/product/iaabu/pix/pix_60/ipsec/conipsec.htm

http://www.cisco.com/warp/public/707/overload_private.shtml

Here's a tip for Firefox. An extension called BugMeNot enables you to right click on "general" forms and say "Login with BugMeNot." Firefox will call the BugMeNot extension which looks up in an external database login information. For instance, www.nytimes.com requires a login, which is a great place to test it out.

http://extensionroom.mozdev.org/more-info/bugmenot

Status:

All is well for some disasters, but what happens if our entire office burns down? SSH+rsync to the rescue, again.

I first setup the PDC and webapp server to backup to the file server on a regular basis (PDC: incremental every day, full on Saturday). Then the file server takes those backups (including the files stored on the file server) every night and syncs them with another server across the States. In case something drastic happens, these off-site backups should be a savior.

I have a feeling we will shortly be deploying many Linux servers to perform certain actions. Maybe we will implement Asterisk to be used as a VoIP interchange between locations, maybe the backup servers will be Linux based, maybe the BDCs.

One thing that could speed up implementation at remote sites is to build live cds for certain purposes. For instance, on the file server in PDX to keep updated live cds for certain projects. Like, a BDC live cd or a backup live cd. Already setup with the most current packages (or scripts to fetch+install them). So when we get to the site we just put the CD in, click or type "load" and poof, the server is installed and configured.

These links (haven't read all of the process) may be helpful:

http://www.linuxjournal.com/article/7233

http://gentoo-wiki.com/HOWTO_build_a_LiveCD_from_scratch

A developer just showed me an interesting framework to produce python-backed sites VERY quickly. This is mainly for you Ian, it natively supports AJAX as well. Here's the link:

http://www.turbogears.org/

I watched the demo, pretty interesting.

We don't want to have a billion servers each doing their own task -- so what can we use as a solution? Server virtualization (or semi-virtualization or para-virtualization). This involves cutting down a server into mini servers that each have full customization. Our VPS at hostmysite is like this. So why would you want to do this? A few reasons actually.

-Localize exploits. Let's say DNS gets exploited -- the access gained would only be for DNS, and not for mail and web and everything else.

-Easy "upgrades," backups and redundancy. Let's say we start to use MySQL more and more, but the server can't handle it. To upgrade (ignoring replication for this example) we could just turn off the virtual server (in essense lock files), move it to other server, drop it into another server that is setup to do virtualization, and turn it it on. Nearly no downtime, and you know it will work.

Anyhow, worth looking at. Here are some of the most mature linux virtualization packages out there:

http://openvz.org/ -- This is the open source version of hostmysites VPS. The main difference is it isn't setup for doing mass hosting (like, 1000 VPSs on a huge mainframe).

http://www.openvps.org/

http://linux-vserver.org/ -- Very plain website, but there is news that the authors are pushing for this code to be included in the Linux kernal natively.

http://www.cl.cam.ac.uk/Research/SRG/netos/xen/ -- I've heard rumors also about this being one of the most advanced.

http://www.vmware.com/ -- The one and only. This is full virtualization so will contain the most overhead (some of the previous packages have almost no overhead, not even 1%). Oh yea, and this "costs" money.

Status:

The webapp server is running fine, but backups are important. Better yet, a hot computer is a great idea. To do this, I setup an older spare rackmount as a 'live' webapp server, just in case. A duplicate LAMP was setup, web apps copied over SSH via rsync on a regular basis, and the icing on the cake: mysql replication.

So, if the dedicated webapp server dies a painful death, a quick change of IP for the webapp server in the internal DNS to the backup rackmount, and nobody will know anything happened.

My friend Ian told me about this originally, but my pen-testing cousin just send me the link as well. p2p VPN, w00t. Hamachi is a VPN alternative that does not have the normal router problems associated with IPSEC and PPTP vpns. That is good because of firewalls and nat and things like that.

http://www.hamachi.cc/

So, you need a TFTP server for something? Cool, you must be doing something fun. I need a TFTP server to copy Cisco IOS images onto the routers; hopefully you are doing something cooler.
1) Enable TFTP in inetd.conf
Open up /etc/inetd.conf and look for the following line:

kelvin@pluto:~$ vi /etc/inetd.conf

#tftp  dgram   udp     wait    root    /usr/sbin/in.tftpd  in.tftpd -s /tftpboot -r blksize

This is on line 72 for me (hint: in vi press ctrl+c, then :set number). Uncomment it. If you don't have this line, bummer. Search for in.tftpd and use that as a substitute.

kelvin@pluto:~$ which in.tftpd
/usr/sbin/in.tftpd
kelvin@pluto:~$

2) Create the TFTP directory
As you can see, we need the directory tftpbood. Create it.

 kelvin@pluto:~$ sudo mkdir /tftpboot 

3) Restart inetd

kelvin@pluto:~$ sudo kill -1 [inetd pid]

You can get the inetd pid by typing:

kelvin@pluto:~$ ps -aux | grep inetd 

Cheers.

Edit: A colleague in New Zealand was searching for something and stumbled upon this page. I gave him the tip that if you need to find the tftp server (or any service), you can do it based on port:

lsof -i :69

Status:

Time has come to upgrade a few servers in the office. An older P4 2.8 was being used as a webapp server, and that needs to go. The resource utilization wasn't too much of an issue, however the computer was aging. Plus, it wasn't strictly built to host critical services, but since we grew so quickly, it is what was available. Additionally, the PDC was hosting user files and with these mounting in size, a dedicated file server is in order.

Oh, and Ian and I are on a strict budget, as usual.

Our trusty CDW shipped over two IBM rackmounts. Plenty of CPU and RAM to grow, the key feature that we were needing was hardware RAID1. With those shipped out, Ian screwed them into the rackmount and we started working on them. Both servers had Debian slapped on, and one then into a true LAMP server. On the LAMP server we also loaded up our ticketing system, and several IMAP based email accounts (good ol' Dovecot).

On the other server was setup as a dedicated file server. For several reasons, including the strict budget, we synced Samba up to the 2003 PDC. Thus, all profiles (through file redirection) are mapped to the Samba box, which does auth via kerberos back to the PDC. Besides user profiles, several shared folders exist, and access is based on GPO. I must admit, Samba+Windows2003 is a very handy combo.