Random ramblings from the depths of my mind…
Well, it’s happened yet again. Ubisoft came up with a grand new copy protection scheme that was going to stop pirates in their tracks. It would be the holy grail that would make it so only paying customers could use the game. If they had an internet connection. Every time they wanted to play the game. Huh. That sounds… annoying. But if it works, maybe it’ll help. Right? Read the rest of this entry »
CakePHP is great, but the default installation has a performance issue that is very easy to resolve, and should be fixed in any production installation of a CakePHP application. The solution is very simple.
In the default install, there is a file in the webroot called .htaccess. It contains mod_rewrite rules, and you have to set you vhost up to allow overrides. This introduces a significant overhead to each request, as apache has to search for applicable htaccess files and merge their settings into the core apache config every request. On a production application this can become significant, especially if you get a significant amount of traffic.
I’ve tried the Hacker’s Diet once before in the past, and did fairly well, but eventually lost motivation and just stopped. But this year, my employer has offered us what amounts to a free gym membership, and I took the extra step of paying for a trainer. So I’m taking the opportunity to start the Hacker’s Diet back up, and to get deadly serious about getting in better health.
I’m going to the gym 3 times a week, for at least 30 minutes each time. I’m also participating in a bowling league weekly (more exercise than you might think… it makes me break a sweat in a hurry), and once the weather improves, I’ll be golfing at least 9 holes a week (walking and carrying clubs). That plus the great weight tracking provided by the Hacker’s Diet tools has already started to make a big difference in my health. I’m feeling more energetic, and I’ve lost several pounds in the last month.
I’ve added a little weight tracking badge to the sidebar here, and I’ll be posting update regularly to my twitter feed. I want all my friends to hold me accountable on this. Ask me how I’m doing. Chew me out if I start to slip and climb back up in weight. My eventual goal is ~210 pounds, which will take a little more than a year to achieve at 1.5 pounds per week, so by the end of this year, I should be around 225 or so. Which would be amazing. I haven’t weighed 225 since around the time I got married, over 10 years ago.
Due to repeated problems with hackers on servers at my day job, I’ve developed a new security plan that I’m going to share in a second. First, a little background, and then I’ll list my requirements that I used to develop the plan.
First, we have no official system administrator, and we have 15 or more servers right now, all running CentOS 5. No one really has time to do everything that should be done to keep them up to date and secured. I’ve made loud noises about this for some time, but for various reasons, nothing much has been done about this.
So, my requirements for the new security setup are: 1. Extremely low maintenance once it is in place. I understand that updates are important, but we don’t have someone to do that full time. 2. Because of that lack of personel, it should reduce exposure of possibly vulnerable services as much as possible. 3. Simple to work with and update as needed.
I did some research, and settled upon the following security ‘layers’ if you will.
First layer: Cracklib configured to require much more secure passwords. Most if not all of our compromised servers have been caused by weak passwords on key accounts.
Second layer: SSH daemon configured to not allow remote root login. There is no reason this should be necessary.
Third layer: IP Tables to lock down system so that only ports that are required for the purpose of the server are available publiclly, and all other ports are only open to the systems that need them. This includes locking the SSH and cPanel ports to only be available by default from the main office network, and any static home IPs of workers.
Fourth layer: Port Knocking daemon set up to give the ability to open the SSH port as needed from other locations. I’ve set it up with a 10 port sequence randomly generated from the 10,000 – 49,151 range, and randomly selected as TCP or UDP. Even at only 10 ports long, there’s 8.66 × 1048 possible sequences, which is plenty secure, when in combination with all the other layers. When the knock sequence is detected, it opens port 22 to the origin IP for 15 seconds, and then closes it again.
Fifth layer: DenyHosts daemon set up using global pool of blocked hosts to keep anyone who somehow happens to get through the port knocking from being able to bruteforce the SSH passwords.
I’ve already implemented the five layers above on several servers, and tested them for a while. It seems to be working flawlessly so far, and it should make the servers much more secure. As part of the implimentation process, I have mandated that we re-install the OS on the servers, to make sure they have a clean system with no backdoors built in. I don’t think there’s much chance of someone having a back door in place that could compromise this, but I’m not taking the chance.
If you have any further suggestions, enhancements, or questions, please let me know. I’m always willing to look at improving this plan further.
As part of the same project that resulted in my last posting, I needed to write several processes that would be managed by cron. In the past, at the Yahoo contract, we had come up with a way to do this involving a customized version of the basic CakePHP index.php file. However, his required us to place the cron code on the main controllers, and extra protections to ensure that the code was inaccessible from the main web interface. I was never thrilled with the solution, but it was the best we had at the time.
So for this project, I looked into the concept of ‘Shells’, which are basically command-line interfaces to a CakePHP application. It quickly became obvious that this was the best way to go about handling the cron jobs for a CakePHP application. It allows you to place all your sensitive cron code completely out of reach of the web facing part of the application, increasing security and decreasing complexity. It’s really quite simple as well.
The process is basically outlined in this section of the CakePHP manual, and should be simple enough to follow. The end result is code like this:
class BillingShell extends Shell { var $uses = array('OrderLineItem', 'Division'); function main() { echo "Please specify which billing task to run. Currently, the only choice is 'daily'.\n\n"; } function daily() { date_default_timezone_set('America/Denver'); App::Import('Component','Cbg'); $this->Cbg = new CbgComponent(); $this->create_invoices(); $this->process_invoices(); } // Other functions not shown }
And you can run it as a cron like this:
# m h dom mon dow command */5 * * * * /full/path/to/cakeshell billing daily -app /full/path/to/app