Lori MacVittie comes up with another one worthy of a response post. This time, she asks if admins are starting to become developers. In a nutshell: I don't think so, but we are definitely programmers.
Ah, there are those damned semantics again!
My opinion here comes from more than the simple fact that my employer has placed a "Systems Programmer" stamp on me despite the fact that my primary job duties do not include programming anything. Programmers make specialized procedural tools, while I feel that developers are a different breed entirely. Developers architect entire solutions and tie together lots of programs: usually functions and routines they've written or borrowed. Developers often collaborate with other developers on a project and usually put together something that will get used by someone other than themselves, from a single client or an internal organization all the way up to public-facing web applications available to anyone on the Internet!
Through the course of my sysadmin and infosec career, I've written literally thousands of tools in varying states of complexity and user-friendliness from object-oriented PHP behemoths to generate large reports from a database down to simple loops that copy shell scripts out to the enterprise before executing them on each system. At any given time, I have scores and scores of these little home-grown scripts and programs laying around.
Administration usually involves repetitive, mundane tasks. Analytical types will usually find a way to automate the things that can be predicted. I wouldn't confuse this process with being a developer, though. I'm not saying developers always create solutions that are more elegant, elaborate or stable. I am saying that developers have a different mind-set than admins, who usually (as Lori points out) create quick tools for themselves or their peers.
Lori MacVittie comes up with another one worthy of a response post. This time, she asks if admins are starting to become developers. In a nutshell: I don't think so, but we are definitely programmers.
Sorry for the lack of content lately. Work has been crazy, and I had a lazy five-day weekend that I decided to use for vegging out more than geeking out. Whilst camping over the Memorial Day weekend, I did come to appreciate the redundancy built in to Mag Instrument's AA Mini-Mag (and most other lights of theirs), a spare bulb hiding in the tail cap right below the battery spring:
I got this flashlight almost a decade ago as schwag (and seriously nice schwag at that) from Check Point while working at a Check Point Value-Added Reseller as a support technician and penetration tester. The bulb that burned out over this last weekend was the original. I can't even imagine how many hours of burn-time it had, how many drops to the pavement it's taken, or how many times it saved my ass.
I only wish that this kind of redundancy was more common in everyday life from household appliances to consumer-grade electronics. Parts that are most prone to failure should be included. Some old vacuum cleaners even came with a spare drive belt and a nice place to store it.
Now, it seems you only see redundancy addressed when you're dealing with large-scale Enterprise IT and industrial- or military-grade machinery. Otherwise, it's:
Somewhere in history, we've lost our way...
[phreakmonkey] got his hands on a great piece of old tech. It’s a 1964 Livermore Data Systems Model A Acoustic Coupler Modem. He recieved it in 1989 and recently decided to see if it would actually work. It took some digging to find a proper D25 adapter and even then the original serial adapter wasn’t working because the oscillator depends on the serial voltage. He dials in and connects at 300baud. Then logs into a remote system and fires up lynx to load Wikipedia.The HiR team loves Old School tech, but where do I even begin with this? The guy found a serial modem (and had to SCROUNGE for an industry-standard serial cable?) and used it exactly as it was designed to be used without any modifications. Where's the hackery here? Why is this even newsworthy?
In the 1980s, I cut my teeth on a similar modem albeit quite a bit newer than 1964. When dial-up Internet became accessible here in Kansas City, I would fire up a GRAPHICAL DOS-Based web-browser (Minuet, if you care) and connect via SLIP or PPP.
I suppose since I'm getting older, it's only going to get worse from here. I'll recall old tech with a certain fondness, and I'll get curmudgeonly whenever it becomes 'news' that someone found out how to use the old hardware as it was designed. Stored properly, well-built electronics don't rot or rust. These relics should simply "just work" and the fact that some standards from the 1960s still exist today should surprise no one. The world has built a vast technology canon of these standards. Some of the very standards we take for granted now are a result of engineering that happened hundreds and hundreds of years ago.
Now get off my lawn, you darn kids!
/me shakes his fist at whippersnappers!
I ran across PHP Anywhere over the weekend. At first glance, it looks as feature-rich as the free version of PHP Designer, a Windows-only tool I use at work when I have to mess with PHP (which isn't too often)
There's just one question I have: who in their right mind would store the FTP password to their web site "in the cloud" like this? In fact, I don't even have FTP access ENABLED on my primary web server. I set up a test instance somewhere else to play with PHP Anywhere. I usually scp my files to their destination. Sadly, that's not an option for PHP Anywhere yet, but if it did, you'd still be storing credentials to modify your website...
I suppose if you are really in a crunch somewhere and lack your usual desktop IDE of choice (and for some reason can't get on the system to edit it locally), it makes for a neat toy.
That's all for today. I'm going to change my password on that FTP account now...
I'm assuming that you have a working OpenBSD/Apache/MySQL/PHP environment working prior to this, or at least have all the packages installed. We will be slightly modifying the MySQL startup process, and changing some stuff on the filesystem to allow the chroot to function properly.
Introduction to chroot
Chroot means "change root", and it's a way to spawn a process so that it has a different apparent root directory. Try as it might, this process cannot get to the "real" root. This has many advantages, especially with web servers.
While an operating system itself might be locked down like Fork Knox, the system's overall security is only as good as the applications that get installed on it. Just take a look at Milw0rm and you'll see that web application vulnerabilities are a dime a dozen. Local file inclusion and other vulnerabilities can sometimes allow an attacker to get to the very heart of the host operating system. With chroot, the attacker is unable to see the real operating system's environment -- in this case, only things within /var/www are visible to Apache and its sub-processes.
Path names that do not have a leading / will automatically use the "ServerRoot" directive (/var/www in OpenBSD) This is why you see lines such as "ErrorLog logs/error_log" in the configuration.
Basically, chroot is awesome. It's also a pain in the ass if you aren't used to dealing with it. Don't worry; I'm here to help.
Why isn't Apache always chrooted then?
There are things in the real operating system environment that the web server relies on. For AMP web applications, PHP needs access to the MySQL Socket (in /var/run/mysql). If you have Sessions enabled and using the filesystem, then /tmp needs to be accessible. Anything else in the "real root" that needs to be accessed must be re-created or hard-linked within /var/www as if it's the root directory.
Anything else in Apache's configuration that calls for path names with a leading / (VirtualHost, UserDir, etc) will be forced to use /var/www as its root as well. I do not recommend creating hard links from inside ServerRoot to external directories for web content. Instead, create subdirectories under /var/www for content (ex: /var/www/virtuals/HiRtest/ ) and grant write permissions for users who need it.
Fixing the broken stuff!
Most AMP packages only need somewhere to store Session information and a way to get to the MySQL socket. Since the real /tmp contains information that is not needed for Apache, we'll just create a new tmp directory specifically for Apache within /var/www and make it world-writable with the "sticky bit" set (exactly like the real /tmp)
sudo mkdir /var/www/tmp
sudo chmod 1777 /var/www/tmp
Next up is the MySQL socket. First, reproduce the directory structure for the MySQL socket under /var/www.
sudo mkdir -p /var/www/var/run/mysql # -p creates subdirs as needed
Then, make sure the real mysql.sock file gets hard linked into the new directory. If you added the "mysql.server start" line to the end of /etc/rc.local, you can accomplish this pretty easily by adding a hard link command after the mysql server starts. I also added a line to remove the old hard link before starting MySQL. The end of my /etc/rc.local looks like this:
ln /var/run/mysql/mysql.sock /var/www/var/run/mysql/mysql.sock
Finally, make sure that you set the httpd line in /etc/rc.conf to look like the line below, unless you really need more options. Just make sure "-u" isn't one of them!
httpd_flags="" # for normal use: "" (or "-DSSL" after reading ssl(8))
At this point, I would advise rebooting the system. While you can start and stop Apache and MySQL, it's best to make sure that everything will come back up and that the chroot hard link to the MySQL socket will be re-created properly upon reboot. Otherwise, you might find yourself with a problem later on.
After rebooting, Apache web server should have all its components working properly again within its chroot environment. In my case, I installed WordPress 2.7.1 before setting Apache to chroot mode. After simply restarting Apache in chroot mode, WordPress gave only an error message about being unable to connect to the database. After making the other changes above and rebooting, WordPress is back to life. The same should hold true for most other packages.
Snort is a software package which monitors a network for suspicious traffic and provides advanced warning of an attack. Snort can also be useful in security failure mode analysis, where it can provide a log of network wide events over a pririod of time. Snort is open source software under the GPL License which means it is free to distribute provided the source is made available.
This article is intended for network administrators and requires an intermediate functional knowledge of server administration and networking skills in a Linux environment.
5. Informative Resources
The trouble with managing a network of any size is that we only know about a breach of security after it happens. Most servers have logging but so much is being logged that its impractical to keep up with it. Yet there are many vulnerabilities which manipulate the logs or the signs of the intrusion are so cryptic it blends in with the every day noise of doing business.
Firewalls and Anti-virus only detect a small portion of network security issues. Enter the next piece of the puzzle: The Intrusion Detection System. An IDS sits at the top level network and checks the network traffic for patterns of known attacks then logs them and it can be configured to provide advanced warning of an attack in progress.
SNORT is an IDS and is free open source software (free as in beer) which can be configured to fit almost any IDS role. SNORT is not the end-all be-all security technology, it is just another security tool to be used in conjunction with other tools and practices to keep your network safer.
Like all pattern recognition based security, it must be updated regularly to be able to detect new threats.
Most security vendors are moving towards a Unified Threat Management System, which pulls firewall, vpn, IDS, Antivirus/mal-ware into one centrally maintained appliance available by subscription.
For this example we will be using Ubuntu Linux Server Edition on a computer with 2 or more network adapters. Since snort will be performing a great deal of logging, the more space you make available, the better off it will be.
$sudo apt-get install snort
The package manager will download all of the dependencies and install them for you.
It will then ask you for the network range you will be monitoring. (ex. 192.168.1.0/24 )
Snort will begin logging traffic it sees in /var/log/snort/alert .
Syslog is the system log daemon which manages the various reports and logs which are produced by the services currently running on your machine. Should you need to report the information to a central server or log management database (like Cisco MARS) you can create a cusom local log by:
1. Edit snort.conf and add in output "alert_syslog: LOG_LOCAL4 LOG_ALERT"
2. Edit syslog.conf "local4.alert ww.xx.yy.zz" (Where ww.xx.yy.zz is the ip address or DNS name of your logging server.)
3. Restart Snort and syslogd
Most networks use a switched network which means traffic not destined for your port on the switch doesn't go there. An intelligent switch can be configured to copy all traffic to your port in addition to its intended destination. This is the ideal solution in that if we are using Gigabyte Ethernet the only other option to sniff traffic is an active bridge or hardware Ethernet tap between the top level switch and the rest of the network. Gigabyte Ethernet uses all of the pairs of a cable for receiving and transmitting so creating a passive tap between it and another host would significantly change the electrical properties of the cable and cause significant degradation of signal. 10/100 Ethernet however only uses two pairs to transmit and receive so its possible to create a passive Ethernet tap where the sending and receiving pairs would be read by a nic on your sniffing machine. This is where the specification for two or more nic's comes in because you have to use one nic to read the transmit pair and one nic to read the receive pair.
The information from the Snort sensor is normally captured in a logfile on that sensor. We configured it to send the log information to a central syslog server. Snort also has plug-ins for MySql and Postgres SQL so the information can be accessed from a database, and also allows for the use of a web-front end. SnortCenter ,SAM and ACID are examples of a web based snort data viewer.
There are also stand-alone applications such as Razorback which can display Snort logs. Snort also has a iptables firewall plugin called Snortsam which can modify the firewall settings on the fly if prevention functionality is needed.
5. Informative Resources
Cisco Systems, Inc. "Device Configuration Guide for Cisco Security MARS, Release 6.x ." (Accessed May 2009)
http://www.cisco.com/en/US/docs/security/security_management/cs-mars/6.0/device/configuration/guide/chSnort.html (September 2008)
Danyliw, Roman "Analysis Console for Intrusion Databases." (Accessed May 2009)
http://www.andrew.cmu.edu/user/rdanyliw/snort/snortacid.html (Last Update 3/9/2003)
Freiberg, Sam "Snort Alert Monitor." (Accessed May 2009)
InterSect Alliance. "RazorBack: The SNORT GUI for displaying events." (Accessed May, 2009)
Knobbe, Frank "SnortSam." (Accessed May 2009)
The SNORT Team. "Snort - the de facto standard for intrusion detection/prevention." (Accessed May 2009)
Oprah Winfrey. She mentions something, it turns to gold. Seemingly, any book, service or gadget she endorses immediately spreads like wildfire. Yesterday, it was KFC's new "Kentucky Grilled Chicken"
Today, I get all kinds of email from 'friends' (brainwashed sheeple) that "Oprah is giving away free chicken!" (Beware, I wouldn't click any links on that page without some security plugins like NoScript installed)
Oprah isn't giving away squat. Oprah's site links to unthinkfc.com (not linked), a site telling you to "unthink what you thought about KFC" (unsurprisingly owned by KFC), which links to Coupons.com. Coupons.com doesn't give you graphic representations of coupons. They install software that is supposed to keep ne'er do wells such as ourselves from printing off thousands of copies of these coupons. Obviously with the advent of cheap color copy/fax/print machines, this really doesn't stop us. But that's not the point.
Does this raise any red flags for you? It does for me!
Coupons.com installs its "coupon printer" application with classic spyware-like traits such as failing to actually uninstall itself when asked, tracking you and even printing information onto these coupons to correlate not only which coupons you print, but which ones get used and where. [Reference: Wired]
So congratulations, Oprah. Regardless your knowledge of the situation and likely without any ill will, you just pwnt almost all of your computer-owning sheeple. 9,000 Internets to you!
Update: unkinkfc.com now links to a PDF coupon download. Kudos to them!
Digging through the pile of history that time forgot, I ran into my old Tandy Armatron. The grease in its gears has deteriorated, as to be expected when something goes un-used for close to two decades. So, it was time to take it apart.
Let me tell you, this machine is considerably more complicated than you'd think, but it's back together and working better. Miraculously, this is the first time I've ever taken this thing apart. I would often take my toys apart for no good reason, and had varying degrees of failure and success in reassembly. I can guarantee that my younger self would not have had the degree of mechanical wherewithal required to get this thing put back together. It's easier than rebuilding a car engine, though!
While the Armatron seemed like a fairly useless device to many, the way it worked fascinated me quite a bit, and fostered my interest in mechanical things, robots, and remote control. My dad asked me if I can program it. I told him I could make it programmable. I wonder how hard it would be to make this work with a microcontroller?
I'll keep this quick and easy. You can just reference my OAMP walk-through from 4.4 if you want to see some more output, but otherwise you can simply run these commands:
# sets up the path for pkg_add (I usually add these lines to my .profile)
PKG_PATH=ftp://ftp.openbsd.org/pub/OpenBSD/4.5/packages/i386/# Installing these two packages will fetch all the dependencies
sudo pkg_add php5-mysql mysql-server# Copy the sample files into place
sudo cp /var/www/conf/modules.sample/php5.conf \# Get MySQL started and the default database installed/var/www/conf/modules/
sudo cp /var/www/conf/php5.sample/mysql.ini \/var/www/conf/php5/
# Set apache to start on boot by editing /etc/rc.confsudo /usr/local/bin/mysql_install_dbsudo /usr/local/share/mysql/mysql.server startsudo /usr/local/bin/mysqladmin \-u root password 'your-password'
# Launch apache (unless you plan on rebooting when this is done)sudo vi /etc/rc.conf#(find httpd_flags once editing the file)# use -u to disable chroot, see httpd(8)
sudo httpd -u# Set MySQL to start at boot
That's really all there is to it!sudo vi /etc/rc.local(add the following line to the end)/usr/local/share/mysql/mysql.server start
If you run httpd in its default chroot mode, it can be difficult to get some AMP packages running properly due to the location of the MySQL socket and the php configuration. If you run httpd -u, most PHP5-compatible packages should just work with minimal effort.
I have never actually installed Wordpress before, and I got it up and running on OAMP (without chroot) in about 3 minutes by following the Wordpress instructions.
Next Sysadmin Sunday, I'll hopefully cover the things you should be prepared to do in order to run AMP packages in OpenBSD's default chroot environment. I've done it before (whilst working at a startup in 2006) but I'm a bit rusty.
Ah, holy wars. vi vs. emacs. Mac vs. Windows. Marmite vs. starving to death. Who doesn't love a good, old-fashioned battle royale? Today, we're pitting BSD vs. Linux.
Whilst in college, I was living in a bachelor pad with two other hackers. I'd been running Red Hat Linux 5.2 on my new PC for a few months when one of my roomies introduced me to FreeBSD 2.2.8. This single event sparked my love for BSD in general. Later, I'd come to really settle on OpenBSD. Over the last 15 years, I've written quite a bit about various operating systems including the BSDs. I by no means hate Linux. I still have to use it for some things. I simply have my gripes about it.
Leading up to the release of OpenBSD 4.5, I got in a few debates -- holy wars, kind of.
Wednesday, I got into a Linux/BSD debate with Mubix.
Then Ben, the instigator that he is, brought up a decent point in the public info-sec fora that is Twitter:
"... Why should I try [OpenBSD]? What advantages does it have over Linux?"
I, always ready to inject semantics to prove a point, started with the obvious: Linux is a kernel, not an operating system. I also quickly pointed out that Holy Wars are hard to do on Twitter. So here I am. Ben really wanted a comparison of OpenBSD vs. his current solution of Debian Linux.
Really, though, semantics have a lot to do with it. Linux is not a complete operating system.
Lineage of Linux
The Linux kernel itself is maintained by a core of kernel developers. Almost all Linux distributions come with the GNU system -- the so-called "userland environment" -- which was itself designed to replace the proprietary UNIX userland in the 1980s. The GNU system and the Linux kernel are developed independently of one another. In fact, Linus Torvalds was completing work on the Linux Kernel around the same time as The Free Software Foundation was putting the finishing touches on GNU. With these two free software components combined, a truly free operating system could be rolled out. This is, of course, why The Free Software Foundation prefers that people use "GNU/Linux" when talking about Linux as an operating system, rather than simply Linux as a kernel. Debian led the charge in adopting the GNU/Linux name.
This was all unfolding in the early 1990s, with the first distributions accessible to the masses around 1992 and 1993 with the popularity of dial-up Internet in the home and CD-ROM drives and media becoming less expensive and widely used.
While GNU and Linux combined make a bare-bones operating system with just enough tools to log in and compile software, it's not enough to be useful to the average person. To that end, groups package the GNU system, the Linux kernel and sometimes up to thousands of third-party packages into distributions. These distributions are complete operating systems: many of them are somewhat secure, stable, and usable for their given purpose.
Ubuntu, one of the more popular distributions, gathers praise for being one of the easiest for non-technical people to use. It also gets criticized by many technical folks who prefer something more svelte and minimalist. Those technical folks often choose Linux distributions that fit their needs: Arch Linux, Debian, or Gentoo. Likewise, corporations often spring for enterprise-supported distributions like SUSE Linux Enterprise Server or Red Hat Enterprise Linux. There are literally hundreds of active distributions, all of which loosely fall under the Linux umbrella. I do not have time to list them all, however I've touched on some of the more popular ones.
Configuration and package management
Package management systems, configuration tools, and other details vary widely between them. A sysadmin that uses SLES at work, for example, will probably have to spend some time figuring out how things with on Arch Linux or Debian GNU/Linux. Most Linux distros use a System V-style init based on runlevels. Configuring services and daemons usually involves messing with files and subdirectories in /etc/init.d/. The automated tools to do this, however, differ between families of Linux distributions.
Popular Linux package-management systems
RedHat Package Manager (Red Hat, SUSE, Fedora)
Debian Package (Debian, Ubuntu)
PacMan (Arch, Frugalware)
BSD-Derived Ports-like systems (Arch Build System, Gentoo)
Lineage of the BSDs
Berkeley Software Distribution (BSD) started as an additional package to go with Bell Labs' Unix Version 6. By the end of 1979, 3BSD was a complete operating system (kernel and userland) designed to run on DEC VAX systems. By late 1983, BSD had implemented TCP/IP. Legal troubles surrounding copyright of the source code held back BSD's development in the early 1990s, but by 1994, a portable, free operating system (4.4BSD-Lite) existed: a kernel and userland wrought from a very mature code-base written by a comparatively small group of developers. Development of BSD at Berkeley win 1995.
A more mature and unified kernel / userland code-base, and smaller development community are two major things that separate BSD-derived operating systems from Linux distributions. All BSD operating systems still package many other open-source tools such as X.org, Apache Web Server and perl. Many of the BSDs come with some or all of the above included by default. To that end, even BSD flavors are similar to Linux Distributions in that the release team can pick and choose what gets rolled in with the base operating system.
During the legal battle encumbering official development on BSD, a team of developers ran with some existing free software from the official 4.3BSD release, 386BSD and some GNU code as well. The result was FreeBSD. FreeBSD now focuses on cutting-edge hardware support, performance and scalability. More "liberal" than the other BSDs, FreeBSD isn't vehemently against closed-source binary drivers and allowing developers to sign Non-Disclosure Agreements with hardware vendors in the name of functionality -- practices that Linux developers regularly partake in.
Around the same time, NetBSD was also underway. Today, NetBSD focuses on clean kernel code that is extremely portable and easy to compile across almost every 32-bit computing platform. If your kitchen sink had a CPU, it could probably run NetBSD.
OpenBSD forked from NetBSD shortly after NetBSD's 1.0 release, mostly due to a falling out between Theo DeRaadt and the rest of the NetBSD developers. OpenBSD's primary focus has always been on security and freedom of code. Strict code audits, re-writing open-source replacements for proprietary services, and refusal to use closed-source binary "blob" drivers or sign NDAs are some key factors.
FreeBSD and NetBSD have a somewhat "hybrid" init for services and daemons. For the most part, "easy" system configuration tools are only found in the installation tools and scripts. Configuration is typically done by modifying human-readable files and scripts in /etc that are well-documented with comment lines. The syntax of the system tools often varies slightly from the GNU equivalents found in Linux distributions.
Binary packages are handled nearly identically across all three major BSD platforms, which borrowed the functionality from FreeBSD.
The Ports Tree is a staple in BSD derivatives. It is a skeletal directory of patches that can automatically fetch, build, and install source code including all dependencies. NetBSD refers to this functionality as "Source packages" because it uses the term "Ports" to describe porting the entire operating system to different architectures.
In praise of Linux
No one had really heard of GNU until the Linux kernel came along. It was the last piece of a huge puzzle. That puzzle was a free operating system that beat BSD to the target market by almost 3 years. It took the Internet by storm, engaging a new wave of passionate coders. As a catalyst, Linux has probably done more for the Free and Open Source Software movement than anything else to date. It also happens to be that Linux's threading is quite efficient, and the kernel scales fabulously from old 386 computers up to bleeding-edge supercomputers. For things where symmetric multi-processing and threading matters, such as databases, Linux can be a very hard competitor to beat.
My Linux gripes
I feel like there are too many cooks in the kitchen sometimes. Updates to the kernel and GNU sources happen fast and frequently from a very, very diverse and loose pool of developers. It's both good and bad. It also seems like every budding techno-junkie has thought that it would be a good idea to learn how to craft their own Linux distribution. There are too many to be useful. Fortunately, there's a relatively small group of distributions that really matter out here in the real world. Still, one has to experience many of them in order to be what I'd consider a Linux expert. When hiring a sysadmin with 3 years of Linux experience you really don't know if they will have any idea what to do with the flavor you've got deployed, without asking. I also dislike the ominous verbiage and forced-open source of the GNU Public License under which most of Linux and all of GNU is licensed. The GPL forces you to share the source code to anything you derive from GPL-licensed work. While it sounds noble, it's actually a restriction on what you can and cannot do. The license itself is incompatable with some other popular licenses, so you may not be able to use code from two different projects if you plan on releasing the end result to the masses.
In praise of BSD
I'm an OpenBSD fanboy, but I like NetBSD and FreeBSD as well. If you've used one, you will probably be comfortable using the others. They are fast and come installed with a fairly minimal set of tools, but it's very east to install the things you want and need in order to build your system up the way you want it. I don't know anyone who's tried BSD coming from another UNIX-like operating system background and not at least liked it. The BSD license has less restrictions on what you can do with the code. While a smaller core of developers generally means the BSDs have less support than Linux for bleeding-edge hardware, I like the fact that the BSD flavors are more mindful of what is allowed into the base operating system. In the case of NetBSD and OpenBSD, I see a lot of benefits that come from a strict code auditing framework. Recently, FreeBSD has been working on scaling CPU performance, but it's taken them a long time to catch up to Linux on enterprise server class hardware.
My BSD gripes
With few exceptions, BSD is usually slow to the game for adding exciting new features and hardware support. Because of this, there are still places where the BSD kernel lacks the performance of Linux. BSD is therefore often playing catch-up with Linux on performance, while Linux is busy adding new features. The BSDs are often a pain in the ass to patch, too. And just like Linux, OpenBSD releases patches as soon as they fix a problem. They don't release binary patches, though, so you have to have a kernel and userland source tree available, manually patch and re-compile components, and move them into place. This is an arduous procedure that's arisen because of the portability of the source code. Still, I wish that official binary patches were released for popular architectures, such as x86. See: OpenBSD FAQ on Patching.
To answer Ben's original questions:
Why should I use OpenBSD?
If you are the kind of person who likes a lean environment for your desktop or servers, you will probably like any of the BSDs. I'd recommend starting with FreeBSD, or if you're a die-hard command-line commando, OpenBSD. If you're serious about security and stability, OpenBSD is a good choice. BSD isn't for everyone, and there are some things that it's simply harder to to on BSD than it is to do on Linux. Running Mozilla with Flashplayer, for example. I honestly don't miss having flash. It's an annoyance to me, most of the time. Exception: When someone sends me a really funny video on YouTube.
What advantages does it have over Linux?
I think I've made plenty of points and counterpoints regarding the technical advantages of Linux and BSD. It's difficult to compare Linux (in general) and all the BSD flavors side-by-side. So my initial comment stands: "Seriously, more geeks should give this operating system a try!" You might just like it!
OpenBSD's philosophy and ease of use are what keep me coming back. Are those advantages over Linux? No. It's about personal preference.
PHP is a popular server side scripting language, it's as simple or as complex as you want to make it. It is typically used along with Linux, Apache Web server and MySQL RDBMS. In most web applications the script acts on user provided information and returns processed data. To this end there are a number of simple steps you can take to help make your web application less vulnerable to exploitation by an unfriendly party.
This article is intended for beginning to intermediate web application programmers.
2. Methods of input
3. Input data validation
4. Trusted processing
5. Database queries
6. Raising the bar
7. Informative resources
PHP is a HTML pre-processor, meaning that it reads a file before it is sent to the user and if it contains PHP script, it processes it and returns the document and the processed results to the user. There are many other technologies which do the same thing each with their benefits and flaws. The importance here is not to proclaim the benefits of PHP over the others but to show some good ideas of how to protect your applications from un-friendlies.
2. Methods of input
In PHP we can get information externally from the webserver itself ($_SERVER), Cookies ($_COOKIE), Get variables ($_GET), Post Variables ($_POST) . In addition PHP can internally connect to just about anything.
So when Joe, our end user goes to your website to check this weeks Fantasy Football scores on your website, he will login (sending login information using POST variables) to a script which then reads the login information and decides whether he can login. Then it returns a page with the result of his attempt and then either takes him to the next page or back to the login prompt. Once he is logged in, PHP sets a Cookie with a unique random session id. Every time a browser returns that cookie to a page, it knows that this session is good and belongs to Joe. Then Joe sorts his results page sending some criteria via a Get variable which is used to control a query to the sports database.
The important thing to know is that Joe can control everything he sends to the server. He can see the cookie contents, post data and get variables. Lets say that Joe wants to check a friends team score. The site allows Joe to sort his scores using GET variables. Joe just places in an escape character and appends some SQL to view his friends score.
3. Input data validation
Think of a web application like a game of D&D, if you are out on the desert plains with a 12th level Barbarian named Ogar, whats keeping the player from making Ogar go left when the DM expects the player to go right? There is no reason Ogar the barbarian can't sit down and whittle a set of dice, mark up a parchment with character stats and then play Cube farms & Bosses.
You have a nice HTML page which provides for the intended actions of the user but everything in the browser or on the computer is out of your control. Java script, plug ins, input, cookies and URLs are not controllable and therefore cannot be fully trusted.
The quality of the data you take in is important, the other part of this is abstraction of the users decisions. If a persons available choices are A,B and C, and internally you identify A, B and C as actions and everything else as false input then that is more effective than allowing user input directly control your data.
4. Trusted processing
5. Database queries
Filtering valid data is just one step, the other step is on your data sources such as MySQL, Postgres, Oracle ... most modern Databases allow you to do a prepared statement which auto-magically binds input into a SQL string. Because its binding data directly to a variable the chances that a user's escape string can hijack the SQL query is greatly diminished. By limiting the users input to only data and not to the program execution process you greatly reduce the possibility of your script becoming compromised.
"http://example.com/mypage.php?display=select * from mydatabase.mytable where user=Joe order by date;"
Including SQL in a user accessible variable is a really really bad idea. Even if it is on a link that Joe wont see and Java script is used to obscure the URL. Joe controls the machine so any obfuscation used will never be effective. What is stopping Joe from substituting "select 'joe' as user password as score, currdate() as date from mysql.users where username=root;"?
6. Raising the bar
There are alot of "Magic Bullet" solutions to web application security. Application firewalls monitor information going both to and the web application. SQL application firewalls filter out suspicious SQL commands going to your RDBMS server. For most developers, these solutions are
either too expensive or too complex to implement for individual web applications. Here are some PHP security plug ins and tools to help raise the bar on the cheap.
When you use this or any other security plug-in, it is vital that you evaluate your applications baseline performance to know what is normal behavior. For instance PHPBB2, a popular PHP bulletin board application display a large list of forums. And mysteriously the settings would not save. I was using Suhosin and this was caused because the number of variables being posted was above Suhosin's default limit and the script was aborting before it could save the changes.
On the server side there is Green SQL, which is a MySQL sanitizer/proxy. Then there is mod_security which hardens Apache and turns it into an application firewall. mod_chroot is similar in the basic functionality of mod-security except it just chroots Apache transparently to the user. Then there are web application security scanners such as the ones included in Nesssus.
Wapiti checks for cross-site scripting (XSS), injection and other common issues. OWASP's WebScarab is a good utility for testing user access to http variables on the client side and intercepting the raw http conversation between the client and the server.
7. Informative resources
Breach Security "Mod Security home page". (Accessed April 2009)
Dawes, Rogan "OWASP WebScarab Project" (Accessed April 2009)
Esser, Stefan "Hardened PHP Project" (Accessed April 2009)
Freitag, Pete "20 ways to Secure your Apache Configuration" (Accessed April 2009)
http://www.petefreitag.com/item/505.cfm (Posted Dec 5, 2005)
Green SQLProject "Green SQL home page". (Accessed April 2009)
Hobbit "mod_chroot" (Accessed April 2009)
OWASP Foundation. "Main Page" (Accessed April 2009)
Tenable network security inc. "Nessus Product Page" (Accessed April 2009)
The Apache Foundation. "Apache HTTP Server Project". (Accessed April 2009)
The PHP Group. "PHP: Hypertext Preprocessor". (Accessed April 2009)
Surribas, Nicolas "Wapiti Web application vulnerability scanner / security auditor" (Accessed April 2009)
Ax0n's OAMP (Apache, Mysql, PHP on OpenBSD) Article:
Asmodian X's Name based hosting mini-howto:
Asmodian X's Workbench - Suhosin :