This user hasn't shared any biographical information
Posts by Nick Gasper
A while a go, I wrote down some personal rules to what I should do as an admin. First and foremost, and underlined about six times was this: Test Everything. It seems so simple, but you have to consider, if it’s not tested, and verified, it’s not working. Simple. Oh, it may be working, but it may not be. “May” is not good enough. So when I roll out a new server, I test and test and test. When I make a change, I test it. If I do reboot a server, I watch logs to make sure that the services are working. If the logs don’t show that everything is working, I manually test things.
So, I got a little tired of FTP and SSH brute force attempts. I know that if you have strong passwords on your system, you can safely ignore them, and on customer systems behind real firewalls, I do so. However, on my personal systems, I have 0 problem blocking people who annoy me. So I installed pfBlocker on my virtual firewall to see what I could do.
pfBlocker is a package that has blacklist functions that supersede a couple older packages. I initially installed it a replacement for CountryBlock. The first thing I did was go through my logs and see which countries were the most obnoxious. China was the first to go, followed by Southeast Asia, and Venezuela. Sorry, I don’t want you accessing my network.
That allow took care of 70% of my attempted exploits. There are, however, plenty of compromised machines in the United States of America, so I had to think of something else.
Recently I had a bit of a conundrum – I wanted to offer web-based FTP access to my friends who host on my personal cluster but I didn’t want to run a web server on that centralized machine. (disclosure: I have a vmForge VDC from ipHouse so I can rapidly prototype as needed)
Long story short, I decided to use relayd to answer on the outside interface for port 80 on the IP assigned to the file-server, and use phpWebFTP (looks ugly, works well) on my webcluster. I, however, wanted to use SSL for this server, which brought up its own challenge. How do I tell my Apache front-ends to serve up a different cert for this IP address. After some experimentation, I discovered the right process.
A long, long time ago (Internet years), our webmaster (and Mike) changed the ipHouse web-cluster to run PHP via FastCGI. They did this with the thought that FCGId would offer greater performance and stability while offering the same security as running PHP via the CGI interface.
Around the same time I also tried implementing FCGId in Ubuntu on one of my virtual servers. It worked well, but I thought it was a bit verbose. Recently, I took on the project to set up FCGId for a managed customer. I decided to ask our webmaster how he implemented FGCI via the FCGIwrapper primitive and still get suEXEC to work.
Caching is a key component to any system design. Caching allows programs to be lazy, by referring to data that’s already been access. Looking up data takes a lot of work. Think of it this way: Someone asks you want the Capital of Indonesia is, and you don’t have Google handy. You have to figure out the best reference to look in, probably an encyclopedia, find the proper page, search on that page for the data that corresponds to “Capital”, in this case, Jakarta, and relay that information back to the person that asked you. However, five minutes later someone else asks you “what is the capital of Indonesia” and you simply say “Jakarta.” You’ve cached that data, and are now returning it. More >