It seems like every time someone tests airport security, airport security fails. In tests between November 2001 and February 2002, screeners missed 70 percent of knives, 30 percent of guns and 60 percent of (fake) bombs. And recently, testers were able to smuggle bomb-making parts through airport security in 21 of 21 attempts. It makes you wonder why we're all putting our laptops in a separate bin and taking off our shoes. (Although we should all be glad that Richard Reid wasn't the "underwear bomber.")
The failure to detect bomb-making parts is easier to understand. Break up something into small enough parts, and it's going to slip past the screeners pretty easily. The explosive material won't show up on the metal detector, and the associated electronics can look benign when disassembled. This isn't even a new problem. It's widely believed that the Chechen women who blew up the two Russian planes in August 2004 probably smuggled their bombs aboard the planes in pieces.
But guns and knives? That surprises most people.
Airport screeners have a difficult job, primarily because the human brain isn't naturally adapted to the task. We're wired for visual pattern matching, and are great at picking out something we know to look for -- for example, a lion in a sea of tall grass.
But we're much less adept at detecting random exceptions in uniform data. Faced with an endless stream of identical objects, the brain quickly concludes that everything is identical and there's no point in paying attention. By the time the exception comes around, the brain simply doesn't notice it. This psychological phenomenon isn't just a problem in airport screening: It's been identified in inspections of all kinds, and is why casinos move their dealers around so often. The tasks are simply mind-numbing.
To make matters worse, the smuggler can try to exploit the system. He can position the weapons in his baggage just so. He can try to disguise them by adding other metal items to distract the screeners. He can disassemble bomb parts so they look nothing like bombs. Against a bored screener, he has the upper hand.
And, as has been pointed out again and again in essays on the ludicrousness of post-9/11 airport security, improvised weapons are a huge problem. A rock, a battery for a laptop, a belt, the extension handle off a wheeled suitcase, fishing line, the bare hands of someone who knows karate ... the list goes on and on.
Technology can help. X-ray machines already randomly insert "test" bags into the stream -- keeping screeners more alert. Computer-enhanced displays are making it easier for screeners to find contraband items in luggage, and eventually the computers will be able to do most of the work. It makes sense: Computers excel at boring repetitive tasks. They should do the quick sort, and let the screeners deal with the exceptions.
Sure, there'll be a lot of false alarms, and some bad things will still get through. But it's better than the alternative.
And it's likely good enough. Remember the point of passenger screening. We're not trying to catch the clever, organized, well-funded terrorists. We're trying to catch the amateurs and the incompetent. We're trying to catch the unstable. We're trying to catch the copycats. These are all legitimate threats, and we're smart to defend against them. Against the professionals, we're just trying to add enough uncertainty into the system that they'll choose other targets instead.
Remember that the terrorists' goals have nothing to do with airplanes; their goals are to cause terror. Blowing up an airplane is just a particular attack designed to achieve that goal. Airplanes deserve some additional security because they have catastrophic failure properties: If there's even a small explosion, everyone on the plane dies. But there's a diminishing return on investments in airplane security. If the terrorists switch targets from airplanes to shopping malls, we haven't really solved the problem.
What that means is that a basic cursory screening is good enough. If I were investing in security, I would fund significant research into computer-assisted screening equipment for both checked and carry-on bags, but wouldn't spend a lot of money on invasive screening procedures and secondary screening. I would much rather have well-trained security personnel wandering around the airport, both in and out of uniform, looking for suspicious actions.
When I travel in Europe, I never have to take my laptop out of its case or my shoes off my feet. Those governments have had far more experience with terrorism than the U.S. government, and they know when passenger screening has reached the point of diminishing returns. (They also implemented checked-baggage security measures decades before the United States did -- again recognizing the real threat.)
And if I were investing in security, I would invest in intelligence and investigation. The best time to combat terrorism is before the terrorist tries to get on an airplane. The best countermeasures have value regardless of the nature of the terrorist plot or the particular terrorist target.
In some ways, if we're relying on airport screeners to prevent terrorism, it's already too late. After all, we can't keep weapons out of prisons. How can we ever hope to keep them out of airports?
- - -
Bruce Schneier is the CTO of Counterpane Internet Security and the author of Beyond Fear: Thinking Sensibly About Security in an Uncertain World. You can contact him through his website.
Tuesday, March 28, 2006
Snort on OpenWrt: Guarding the SOHO perimeter
Snort on OpenWrt: Guarding the SOHO perimeter
Monday March 27, 2006 (03:01 PM GMT)
By: Joe Barr
If you're edgy about security for your SOHO LAN, you might want to consider moving your first line of defense out past your firewall. How about on your router, for example? If your router runs OpenWrt, you can do exactly that, by running Snort, the open source intrusion detection system (IDS) project that has become the most widely deployed IDS in the world. Throw in the firewall that comes out of the box with OpenWrt White Russian, and suddenly the perimeter seems a lot more secure.
Nicholas Thill -- known as Nico in the OpenWrt community -- maintains three separate packages for Snort in his repository of packages. They include a plain Jane version, without any support for logging to a database, and two database-specific packages: one for MySQL and one for PostgreSQL. All are based on the Snort release 2.3.3-1 and are considered to be in a testing state and not yet included in the official release.
For the sake of simplicity, I'll discuss the plain Jane installation in this article. Regardless of which version you select, you need to be aware of the fact that you can overload and/or potentially crash your OpenWrt router by running Snort wide-open with all its rule sets and preprocessors (rule sets look for specific signatures, while preprocessors are plugin modules that extend Snort's capabilities), or simply by logging Snort's output to the local system and filling up all available space.
OpenWrt is a wonderful distribution, but it often runs on systems with serious memory and/or storage constraints, which you can easily overload by running Snort with all the trimmings.
Syslog remotely
Snort reports its findings in log records, so running Snort without saving them for later analysis is like typing a book without putting paper in the typewriter: you go through a lot of motions but don't get much of a return for your efforts. Given the typical router's constraints both in processing power and storage space, it makes sense to log Snort's findings remotely.
In order to start syslog logging remotely, you'll need to make changes to your configuration both on the router and on the system where the logging will be done. It's a snap to set up remote logging on OpenWrt, as explained in this Mini-HOWTO on the OpenWrt wiki.
From the OpenWrt command line, enter the following:
nvram set log_ipaddr=<192.168.1.101>
nvram commit
Change the IP address to match the address of the system running syslogd. Then edit /etc/initab and add these two lines:
::respawn:/sbin/syslogd -n
::respawn:/sbin/klogd -n
And finally, edit /etc/init.d/rcS to add:
mkdir /var/log
To handle the logging on the remote side of the connection, add the -r option to the command line that starts syslogd and you're good to go. If you're using Ubuntu, for example, edit /etc/init.d/sysklogd and change the line that reads:
SYSLOGD="-u syslog"
to read:
SYSLOGD="-r -u syslog"
Of course, if you're like me and think that syslogd is so last generation, you can install syslog-ng instead, which accepts remote logging by default.
Installing and Configuring Snort
The easiest way to install the version of Snort is with the OpenWrt Admin Console. But before you do that, check /etc/ikpg.conf on the router and make sure the repository mentioned above is included as a source. If it's not, add this line to the file:
src nico-t http://nthill.free.fr/openwrt/ipkg/testing
Then click on System and Installed Software in the OpenWrt Admin Console and refresh the list of available packages by clicking on Update package lists. All that's left to do then is scroll down the list of packages, find the version of Snort you want, and click on Install next to it.
Before you configure Snort, you'll need to get some rules from the Snort site. Snort rules define the packets that Snort should identify and take action on, and the actions that should be taken.
Rather than downloading only the rules included in the default OpenWrt snort.conf file, I downloaded a full set and put them in /etc/snort/rules. That way, I don't have to get new rule sets each time I tweak snort.conf.
You'll need to define the HOME_NET variable near the top of /etc/snort/snort.conf, and also define an output method near the bottom. Once you've done those two things, Snort should be ready to run, except for whatever tweaking you need to do for preprocessors and rules.
The pre-configured version of snort.conf, for example, comes with almost all the preprocessors commented out. To activate them, simply remove the # signs from the beginning of each line of the section for the preprocessor you want. The same thing is true for the rules. Note: Remember to keep an eye on memory usage as you activate preprocessors and rule sets.
My HOME_NET in snort.conf already looked like this, so I kept it:
var HOME_NET 192.168.1.0/24
For the output option, I removed the # from this line:
# output alert_syslog: LOG_AUTH LOG_ALERT
Those two changes made, I started snort running by entering snort -i vlan1 & and it blasted off, producing the following on my OpenWrt console:
root@OpenWrt:~# Running in IDS mode with inferred config file: /etc/snort/snort.conf
Initializing Network Interface vlan1
--== Initializing Snort ==--
Initializing Output Plugins!
Decoding Ethernet on interface vlan1
Initializing Preprocessors!
Initializing Plug-ins!
Parsing Rules file /etc/snort/snort.conf
+++++++++++++++++++++++++++++++++++++++++++++++++++
Initializing rule chains...
,-----------[Flow Config]----------------------
| Stats Interval: 0
| Hash Method: 2
| Memcap: 10485760
| Rows : 4099
| Overhead Bytes: 16400(%0.16)
`----------------------------------------------
No arguments to frag2 directive, setting defaults to:
Fragment timeout: 60 seconds
Fragment memory cap: 4194304 bytes
Fragment min_ttl: 0
Fragment ttl_limit: 5
Fragment Problems: 0
Self preservation threshold: 500
Self preservation period: 90
Suspend threshold: 1000
Suspend period: 30
Stream4 config:
Stateful inspection: ACTIVE
Session statistics: INACTIVE
Session timeout: 30 seconds
Session memory cap: 8388608 bytes
State alerts: INACTIVE
Evasion alerts: INACTIVE
Scan alerts: INACTIVE
Log Flushed Streams: INACTIVE
MinTTL: 1
TTL Limit: 5
Async Link: 0
State Protection: 0
Self preservation threshold: 50
Self preservation period: 90
Suspend threshold: 200
Suspend period: 30
Enforce TCP State: INACTIVE
Midstream Drop Alerts: INACTIVE
Stream4_reassemble config:
Server reassembly: INACTIVE
Client reassembly: ACTIVE
Reassembler alerts: ACTIVE
Zero out flushed packets: INACTIVE
flush_data_diff_size: 500
Ports: 21 23 25 53 80 110 111 143 513 1433
Emergency Ports: 21 23 25 53 80 110 111 143 513 1433
X-Link2State Config:
Ports: 25 691
112 Snort rules read...
112 Option Chains linked into 57 Chain Headers
0 Dynamic rules
+++++++++++++++++++++++++++++++++++++++++++++++++++
Warning: flowbits key 'tls1.client_hello.request' is checked but not ever set.
Warning: flowbits key 'sslv3.client_hello.request' is checked but not ever set.
+-----------------------[thresholding-config]----------------------------------
| memory-cap : 1048576 bytes
+-----------------------[thresholding-global]----------------------------------
| none
+-----------------------[thresholding-local]-----------------------------------
| none
+-----------------------[suppression]------------------------------------------
| none
+------------------------------------------------------------------------------
Rule application order: ->activation->dynamic->alert->pass->log
Log directory = /var/log/snort
--== Initialization Complete ==--
,,_ -*> Snort! <*-
o" )~ Version 2.3.3 (Build 14)
'''' By Martin Roesch & The Snort Team: http://www.snort.org/team.html
(C) Copyright 1998-2004 Sourcefire Inc., et al.
To make sure Snort was logging to the remote machine, I checked the syslog there and found these two new entries in /var/log/syslog:
Mar 2 15:40:44 192.168.1.1 kernel: vlan1: dev_set_promiscuity(master, 1)
Mar 2 15:40:44 192.168.1.1 kernel: device vlan1 entered promiscuous mode
Before making any big changes to the rules or preprocessors, I wanted to have baseline measurement of how much system resources Snort was eating in terms of memory and CPU, so I asked top. Top said:
Mem: 18420K used, 12164K free, 0K shrd, 896K buff, 4664K cached
Load average: 1.00, 1.01, 0.76 (State: S=sleeping R=running, W=waiting)
PID USER STATUS RSS PPID %CPU %MEM COMMAND
571 root R 436 1 98.4 1.4 vi
899 root R 412 561 0.7 1.3 top
898 root S 7916 561 0.3 25.8 snort
560 root S 640 537 0.3 2.0 dropbear
890 root S 640 537 0.0 2.0 dropbear
561 root S 464 560 0.0 1.5 ash
891 root S 460 890 0.0 1.5 ash
530 nobody S 436 1 0.0 1.4 dnsmasq
49 root S 428 1 0.0 1.3 syslogd
537 root S 420 1 0.0 1.3 dropbear
379 root S 400 1 0.0 1.3 udhcpc
1 root S 392 0 0.0 1.2 init
55 root S 392 1 0.0 1.2 init
541 root S 388 1 0.0 1.2 httpd
50 root S 340 1 0.0 1.1 klogd
542 root S 300 1 0.0 0.9 telnetd
3 root SWN 0 1 0.0 0.0 ksoftirqd_CPU0
7 root SW 0 1 0.0 0.0 mtdblockd
6 root SW 0 1 0.0 0.0 kupdated
4 root SW 0 1 0.0 0.0 kswapd
32 root SWN 0 1 0.0 0.0 jffs2_gcd_mtd4
5 root SW 0 1 0.0 0.0 bdflush
2 root SW 0 1 0.0 0.0 keventd
Right out of the box, and with only minimal rules in place, Snort was eating 25% of system memory. I added rules and preprocessors, primarily for the detection of scans, but I've tried to avoid taking more than 50% of memory or to have less than 1000K free memory. So far, so good, and with no impact on performance of the router. But remember, you can overload the router if you're not careful, so keep a watchful eye on available resources as you tweak the config.
After I enabled the scan detection preprocessors and added a couple of additional rule sets, Snort's memory consumption climbed to 49.3% and the amount of free memory had shrunk to just over 5000K. I decided to stop there.
You might consider installing the plain Jane version first, then moving to one of the database-specific versions if you like. But if you do, remember that changing versions requires more than simply changing your snort.conf to indicate the database: you have to remove the plain Jane version of Snort and then install the database version. That process will replace your snort.conf, so if you want to keep your old one, make a copy before you install the new version of Snort.
For further information about Snort on OpenWrt, see this report by David Schwartzburg.
Monday March 27, 2006 (03:01 PM GMT)
By: Joe Barr
If you're edgy about security for your SOHO LAN, you might want to consider moving your first line of defense out past your firewall. How about on your router, for example? If your router runs OpenWrt, you can do exactly that, by running Snort, the open source intrusion detection system (IDS) project that has become the most widely deployed IDS in the world. Throw in the firewall that comes out of the box with OpenWrt White Russian, and suddenly the perimeter seems a lot more secure.
Nicholas Thill -- known as Nico in the OpenWrt community -- maintains three separate packages for Snort in his repository of packages. They include a plain Jane version, without any support for logging to a database, and two database-specific packages: one for MySQL and one for PostgreSQL. All are based on the Snort release 2.3.3-1 and are considered to be in a testing state and not yet included in the official release.
For the sake of simplicity, I'll discuss the plain Jane installation in this article. Regardless of which version you select, you need to be aware of the fact that you can overload and/or potentially crash your OpenWrt router by running Snort wide-open with all its rule sets and preprocessors (rule sets look for specific signatures, while preprocessors are plugin modules that extend Snort's capabilities), or simply by logging Snort's output to the local system and filling up all available space.
OpenWrt is a wonderful distribution, but it often runs on systems with serious memory and/or storage constraints, which you can easily overload by running Snort with all the trimmings.
Syslog remotely
Snort reports its findings in log records, so running Snort without saving them for later analysis is like typing a book without putting paper in the typewriter: you go through a lot of motions but don't get much of a return for your efforts. Given the typical router's constraints both in processing power and storage space, it makes sense to log Snort's findings remotely.
In order to start syslog logging remotely, you'll need to make changes to your configuration both on the router and on the system where the logging will be done. It's a snap to set up remote logging on OpenWrt, as explained in this Mini-HOWTO on the OpenWrt wiki.
From the OpenWrt command line, enter the following:
nvram set log_ipaddr=<192.168.1.101>
nvram commit
Change the IP address to match the address of the system running syslogd. Then edit /etc/initab and add these two lines:
::respawn:/sbin/syslogd -n
::respawn:/sbin/klogd -n
And finally, edit /etc/init.d/rcS to add:
mkdir /var/log
To handle the logging on the remote side of the connection, add the -r option to the command line that starts syslogd and you're good to go. If you're using Ubuntu, for example, edit /etc/init.d/sysklogd and change the line that reads:
SYSLOGD="-u syslog"
to read:
SYSLOGD="-r -u syslog"
Of course, if you're like me and think that syslogd is so last generation, you can install syslog-ng instead, which accepts remote logging by default.
Installing and Configuring Snort
The easiest way to install the version of Snort is with the OpenWrt Admin Console. But before you do that, check /etc/ikpg.conf on the router and make sure the repository mentioned above is included as a source. If it's not, add this line to the file:
src nico-t http://nthill.free.fr/openwrt/ipkg/testing
Then click on System and Installed Software in the OpenWrt Admin Console and refresh the list of available packages by clicking on Update package lists. All that's left to do then is scroll down the list of packages, find the version of Snort you want, and click on Install next to it.
Before you configure Snort, you'll need to get some rules from the Snort site. Snort rules define the packets that Snort should identify and take action on, and the actions that should be taken.
Rather than downloading only the rules included in the default OpenWrt snort.conf file, I downloaded a full set and put them in /etc/snort/rules. That way, I don't have to get new rule sets each time I tweak snort.conf.
You'll need to define the HOME_NET variable near the top of /etc/snort/snort.conf, and also define an output method near the bottom. Once you've done those two things, Snort should be ready to run, except for whatever tweaking you need to do for preprocessors and rules.
The pre-configured version of snort.conf, for example, comes with almost all the preprocessors commented out. To activate them, simply remove the # signs from the beginning of each line of the section for the preprocessor you want. The same thing is true for the rules. Note: Remember to keep an eye on memory usage as you activate preprocessors and rule sets.
My HOME_NET in snort.conf already looked like this, so I kept it:
var HOME_NET 192.168.1.0/24
For the output option, I removed the # from this line:
# output alert_syslog: LOG_AUTH LOG_ALERT
Those two changes made, I started snort running by entering snort -i vlan1 & and it blasted off, producing the following on my OpenWrt console:
root@OpenWrt:~# Running in IDS mode with inferred config file: /etc/snort/snort.conf
Initializing Network Interface vlan1
--== Initializing Snort ==--
Initializing Output Plugins!
Decoding Ethernet on interface vlan1
Initializing Preprocessors!
Initializing Plug-ins!
Parsing Rules file /etc/snort/snort.conf
+++++++++++++++++++++++++++++++++++++++++++++++++++
Initializing rule chains...
,-----------[Flow Config]----------------------
| Stats Interval: 0
| Hash Method: 2
| Memcap: 10485760
| Rows : 4099
| Overhead Bytes: 16400(%0.16)
`----------------------------------------------
No arguments to frag2 directive, setting defaults to:
Fragment timeout: 60 seconds
Fragment memory cap: 4194304 bytes
Fragment min_ttl: 0
Fragment ttl_limit: 5
Fragment Problems: 0
Self preservation threshold: 500
Self preservation period: 90
Suspend threshold: 1000
Suspend period: 30
Stream4 config:
Stateful inspection: ACTIVE
Session statistics: INACTIVE
Session timeout: 30 seconds
Session memory cap: 8388608 bytes
State alerts: INACTIVE
Evasion alerts: INACTIVE
Scan alerts: INACTIVE
Log Flushed Streams: INACTIVE
MinTTL: 1
TTL Limit: 5
Async Link: 0
State Protection: 0
Self preservation threshold: 50
Self preservation period: 90
Suspend threshold: 200
Suspend period: 30
Enforce TCP State: INACTIVE
Midstream Drop Alerts: INACTIVE
Stream4_reassemble config:
Server reassembly: INACTIVE
Client reassembly: ACTIVE
Reassembler alerts: ACTIVE
Zero out flushed packets: INACTIVE
flush_data_diff_size: 500
Ports: 21 23 25 53 80 110 111 143 513 1433
Emergency Ports: 21 23 25 53 80 110 111 143 513 1433
X-Link2State Config:
Ports: 25 691
112 Snort rules read...
112 Option Chains linked into 57 Chain Headers
0 Dynamic rules
+++++++++++++++++++++++++++++++++++++++++++++++++++
Warning: flowbits key 'tls1.client_hello.request' is checked but not ever set.
Warning: flowbits key 'sslv3.client_hello.request' is checked but not ever set.
+-----------------------[thresholding-config]----------------------------------
| memory-cap : 1048576 bytes
+-----------------------[thresholding-global]----------------------------------
| none
+-----------------------[thresholding-local]-----------------------------------
| none
+-----------------------[suppression]------------------------------------------
| none
+------------------------------------------------------------------------------
Rule application order: ->activation->dynamic->alert->pass->log
Log directory = /var/log/snort
--== Initialization Complete ==--
,,_ -*> Snort! <*-
o" )~ Version 2.3.3 (Build 14)
'''' By Martin Roesch & The Snort Team: http://www.snort.org/team.html
(C) Copyright 1998-2004 Sourcefire Inc., et al.
To make sure Snort was logging to the remote machine, I checked the syslog there and found these two new entries in /var/log/syslog:
Mar 2 15:40:44 192.168.1.1 kernel: vlan1: dev_set_promiscuity(master, 1)
Mar 2 15:40:44 192.168.1.1 kernel: device vlan1 entered promiscuous mode
Before making any big changes to the rules or preprocessors, I wanted to have baseline measurement of how much system resources Snort was eating in terms of memory and CPU, so I asked top. Top said:
Mem: 18420K used, 12164K free, 0K shrd, 896K buff, 4664K cached
Load average: 1.00, 1.01, 0.76 (State: S=sleeping R=running, W=waiting)
PID USER STATUS RSS PPID %CPU %MEM COMMAND
571 root R 436 1 98.4 1.4 vi
899 root R 412 561 0.7 1.3 top
898 root S 7916 561 0.3 25.8 snort
560 root S 640 537 0.3 2.0 dropbear
890 root S 640 537 0.0 2.0 dropbear
561 root S 464 560 0.0 1.5 ash
891 root S 460 890 0.0 1.5 ash
530 nobody S 436 1 0.0 1.4 dnsmasq
49 root S 428 1 0.0 1.3 syslogd
537 root S 420 1 0.0 1.3 dropbear
379 root S 400 1 0.0 1.3 udhcpc
1 root S 392 0 0.0 1.2 init
55 root S 392 1 0.0 1.2 init
541 root S 388 1 0.0 1.2 httpd
50 root S 340 1 0.0 1.1 klogd
542 root S 300 1 0.0 0.9 telnetd
3 root SWN 0 1 0.0 0.0 ksoftirqd_CPU0
7 root SW 0 1 0.0 0.0 mtdblockd
6 root SW 0 1 0.0 0.0 kupdated
4 root SW 0 1 0.0 0.0 kswapd
32 root SWN 0 1 0.0 0.0 jffs2_gcd_mtd4
5 root SW 0 1 0.0 0.0 bdflush
2 root SW 0 1 0.0 0.0 keventd
Right out of the box, and with only minimal rules in place, Snort was eating 25% of system memory. I added rules and preprocessors, primarily for the detection of scans, but I've tried to avoid taking more than 50% of memory or to have less than 1000K free memory. So far, so good, and with no impact on performance of the router. But remember, you can overload the router if you're not careful, so keep a watchful eye on available resources as you tweak the config.
After I enabled the scan detection preprocessors and added a couple of additional rule sets, Snort's memory consumption climbed to 49.3% and the amount of free memory had shrunk to just over 5000K. I decided to stop there.
You might consider installing the plain Jane version first, then moving to one of the database-specific versions if you like. But if you do, remember that changing versions requires more than simply changing your snort.conf to indicate the database: you have to remove the plain Jane version of Snort and then install the database version. That process will replace your snort.conf, so if you want to keep your old one, make a copy before you install the new version of Snort.
For further information about Snort on OpenWrt, see this report by David Schwartzburg.
Monday, March 27, 2006
The World's Most Maintainable Programming Language: Part 1
The World's Most Maintainable Programming Language: Part 1: "
Have modern programming languages failed? From the point of view of learnability and maintainability, yes! What would a truly maintainable and learnable programming language look like? This is the first of a five-part series exploring the future of programming languages. I'll publish the rest throughout the week. (I'll enable comments when I publish the final part, this Friday -- so you can read my entire thesis in context.)
"(Via BSD DevCenter.)
Friday, March 17, 2006
The Open Source Business Model
The Open Source Business Model: "How do open source projects sustain themselves? In the financial sense, I mean. Sometimes, a large corporation will offer a project funding. Or perhaps they will hire the primary developer and allow him to continue working on the project, as Microsoft has done with IronPython. But what about projects who aren't fortunate enough to gain that class of corporate funding? Or who aren't actively seeking it?
Most open source authors that I know of aren't writing their software for the money they hope to make with it. They work on it because they love it and would do it even if there is no hope of gaining funding of any sort. They work on their projects in their spare moments before and after the job that pays the bills and when they aren't enjoying time spent with their families.
Sometimes, a project gains a large enough of a user base that the project's author is able to offer his services around the project on a paid basis. Recently, Kevin Dangoor, the creator of TurboGears, announced that he would be offering consulting services around TurboGears, primarily development of TurboGears features, coaching, and training.
I love seeing open source authors take the initiative to help fund their project by finding a way to charge for their time on it. This is a win-win-win situation. It's an obvious win for the project author since they get paid for doing something they love. It's a win for the person or company who is paying for the author's time since the author is an expert on the subject. And it's a win for the community because the primary author is able to devote more time to the project. Kevin, I'm sure you'll get plenty of business. I wish you much success in this endeavor.
ONLamp.com 3/9/06 7:03 PM webmaster@oreillynet.com (Jeremy Jones)"
(Via ONLamp.com.)
Thursday, March 16, 2006
Network Filtering by Operating System
Network Filtering by Operating System
by Avleen Vig
02/16/2006
You manage a heterogeneous network and want to provide different Quality of Service agreements and network restrictions based on the client operating system. With pf and altq, you can now limit the amount of bandwidth available to users of different operating systems, or force outbound web traffic through a transparent filtering proxy. This article describes how to install pf, altq, and Squid on your FreeBSD router and web proxy to achieve these goals.
Mission Objective
In an ideal environment, there would be no need for bandwidth shaping, OS fingerprint-based filtering, or even Quality of Service (QoS). Several factors in the real world require a change of game plan. Bandwidth is not free, and many ISPs charge customers based on bandwidth usage. Worms, viruses, and compromised systems can all lead to higher bandwidth costs. In the wake of the W32.Slammer worm, which saturated the connections of infected networks, many companies saw their monthly connectivity bills skyrocket due to the worm's traffic.
Filtering your connections based on operating system can go partway to helping keep such situations from running away. While I will focus on filtering traffic from Windows systems, this process can equally apply to BSD, Linux, Mac OS, or a host of other operating systems listed in the pf.os file on your system. This may be especially useful to people running older versions of OSes that have not or cannot be patched but still require some network connectivity.
As an extension of transparent filtering, content filtering is also possible, with tools such as squidGuard allowing children and corporate desktops alike to browse in relative safety.
Tools of the Trade
During my research for this article, several people asked me why I chose to use BSD, pf, altq, and Squid for this task. Other tools come close to providing the required functionality, but none offers to fill the requirements as readily as these. Linux and iptables can work with Squid to provide a transparent proxy but cannot filter connections by operating system. Though other proxy servers exist, Squid is one of the best available today.
It is important to note that OS fingerprinting works only on TCP SYN packets, which initiate TCP sessions, and not on currently established connections or UDP sessions. While this will not be a problem for most systems and network administrators, you may want to pay more attention to your UDP filtering rules.
Installing pf and altq
pf and altq provide packet filtering and bandwidth shaping, respectively. Their relationship is not unlike that between IPFIREWALL and DUMMYNET, where the same rules file configures both pf and altq.
While pf is universally usable, altq requires a supported network card. The good news is that most network cards in common use are supported. Look at the Supported Devices section of man 4 altq to find a list of supported network cards.
Once you've confirmed you have a supported device, add pf and altq to your kernel. You will need to recompile your kernel as described in the FreeBSD Handbook. First, add a few options to the end of your kernel configuration file:
device pf
options ALTQ
options ALTQ_CBQ
options ALTQ_RED
options ALTQ_RIO
options ALTQ_HFSC
options ALTQ_CDNR
options ALTQ_PRIQ
Note: If you are installing altq on a multiprocessor system, add options ALTQ_NOPPC to your configuration before you recompile your kernel.
After you have recompiled your kernel and rebooted, test pf to make sure it installed correctly with the command pfctl -s rules. If you see the error pfctl: /dev/pf: No such file or directory, pf did not install correctly. If you see the error No ALTQ support in kernel ALTQ related functions disabled, pf is working but altq is not. In the latter case, you will still be able to force users through a transparent proxy, but you won't be able to limit bandwidth using altq.
Installing Squid with Transparent Filtering Support
Install Squid with the command:
% cd /usr/ports/www/squid && make config install clean
This will present you with a list of options for compiling Squid. To enable transparent proxy support, select SQUID_PF. You can also select or deselect any other option. I often find SQUID_SNMP useful for gathering and graphing statistics using RRDTool. Once Squid is installed, edit /usr/local/etc/squid/squid.conf. Set at least the options:
http_port YOUR_PROXY_IP:3128
http_access deny to_localhost
acl our_networks src YOUR_NETWORK/24
http_access allow our_networks
visible_hostname YOUR_HOSTNAME
httpd_accel_host virtual
httpd_accel_port 80
httpd_accel_with_proxy on
httpd_accel_uses_host_header on
Replace YOUR_PROXY_IP with the IP address your proxy server will listen on, YOUR_NETWORK/24 with your internal network address range (for example, 192.168.0.0/24), and YOUR_HOSTNAME with the hostname you want to show to users in error messages. YOUR_HOSTNAME is not required but extremely useful if you have a cluster of proxy servers sharing a common front end such as a load balancer.
While you can get by with changing only these options, you should spend some time going through the remainder of your squid.conf file and tuning it to your needs. Over time, you may need to tune various other options such as cache sizes or connection timeouts. The Squid configuration file is a behemoth; spending an hour now getting familiar with various options may save you time and trouble in the future.
by Avleen Vig
02/16/2006
You manage a heterogeneous network and want to provide different Quality of Service agreements and network restrictions based on the client operating system. With pf and altq, you can now limit the amount of bandwidth available to users of different operating systems, or force outbound web traffic through a transparent filtering proxy. This article describes how to install pf, altq, and Squid on your FreeBSD router and web proxy to achieve these goals.
Mission Objective
In an ideal environment, there would be no need for bandwidth shaping, OS fingerprint-based filtering, or even Quality of Service (QoS). Several factors in the real world require a change of game plan. Bandwidth is not free, and many ISPs charge customers based on bandwidth usage. Worms, viruses, and compromised systems can all lead to higher bandwidth costs. In the wake of the W32.Slammer worm, which saturated the connections of infected networks, many companies saw their monthly connectivity bills skyrocket due to the worm's traffic.
Filtering your connections based on operating system can go partway to helping keep such situations from running away. While I will focus on filtering traffic from Windows systems, this process can equally apply to BSD, Linux, Mac OS, or a host of other operating systems listed in the pf.os file on your system. This may be especially useful to people running older versions of OSes that have not or cannot be patched but still require some network connectivity.
As an extension of transparent filtering, content filtering is also possible, with tools such as squidGuard allowing children and corporate desktops alike to browse in relative safety.
Tools of the Trade
During my research for this article, several people asked me why I chose to use BSD, pf, altq, and Squid for this task. Other tools come close to providing the required functionality, but none offers to fill the requirements as readily as these. Linux and iptables can work with Squid to provide a transparent proxy but cannot filter connections by operating system. Though other proxy servers exist, Squid is one of the best available today.
It is important to note that OS fingerprinting works only on TCP SYN packets, which initiate TCP sessions, and not on currently established connections or UDP sessions. While this will not be a problem for most systems and network administrators, you may want to pay more attention to your UDP filtering rules.
Installing pf and altq
pf and altq provide packet filtering and bandwidth shaping, respectively. Their relationship is not unlike that between IPFIREWALL and DUMMYNET, where the same rules file configures both pf and altq.
While pf is universally usable, altq requires a supported network card. The good news is that most network cards in common use are supported. Look at the Supported Devices section of man 4 altq to find a list of supported network cards.
Once you've confirmed you have a supported device, add pf and altq to your kernel. You will need to recompile your kernel as described in the FreeBSD Handbook. First, add a few options to the end of your kernel configuration file:
device pf
options ALTQ
options ALTQ_CBQ
options ALTQ_RED
options ALTQ_RIO
options ALTQ_HFSC
options ALTQ_CDNR
options ALTQ_PRIQ
Note: If you are installing altq on a multiprocessor system, add options ALTQ_NOPPC to your configuration before you recompile your kernel.
After you have recompiled your kernel and rebooted, test pf to make sure it installed correctly with the command pfctl -s rules. If you see the error pfctl: /dev/pf: No such file or directory, pf did not install correctly. If you see the error No ALTQ support in kernel ALTQ related functions disabled, pf is working but altq is not. In the latter case, you will still be able to force users through a transparent proxy, but you won't be able to limit bandwidth using altq.
Installing Squid with Transparent Filtering Support
Install Squid with the command:
% cd /usr/ports/www/squid && make config install clean
This will present you with a list of options for compiling Squid. To enable transparent proxy support, select SQUID_PF. You can also select or deselect any other option. I often find SQUID_SNMP useful for gathering and graphing statistics using RRDTool. Once Squid is installed, edit /usr/local/etc/squid/squid.conf. Set at least the options:
http_port YOUR_PROXY_IP:3128
http_access deny to_localhost
acl our_networks src YOUR_NETWORK/24
http_access allow our_networks
visible_hostname YOUR_HOSTNAME
httpd_accel_host virtual
httpd_accel_port 80
httpd_accel_with_proxy on
httpd_accel_uses_host_header on
Replace YOUR_PROXY_IP with the IP address your proxy server will listen on, YOUR_NETWORK/24 with your internal network address range (for example, 192.168.0.0/24), and YOUR_HOSTNAME with the hostname you want to show to users in error messages. YOUR_HOSTNAME is not required but extremely useful if you have a cluster of proxy servers sharing a common front end such as a load balancer.
While you can get by with changing only these options, you should spend some time going through the remainder of your squid.conf file and tuning it to your needs. Over time, you may need to tune various other options such as cache sizes or connection timeouts. The Squid configuration file is a behemoth; spending an hour now getting familiar with various options may save you time and trouble in the future.
Wednesday, March 15, 2006
10 Best Security Live CD Distros (Pen-Test, Forensics & Recovery) »
10 Best Security Live CD Distros (Pen-Test, Forensics & Recovery) »: "10 Best Security Live CD Distros (Pen-Test, Forensics & Recovery)
Darknet spilled these bits on March 14th 2006 @ 9:17 am
1. BackTrack
The newest contender on the block of course is BackTrack, which we have spoken about previously. An innovative merge between WHax and Auditor (WHax formely WHoppix).
BackTrack is the result of the merging of two Innovative Penetration Testing live Linux distributions Whax and Auditor, combining the best features from both distributions, and paying special attention to small details, this is probably the best version of either distributions to ever come out.
Based on SLAX (Slackware), BackTrack provides user modularity. This means the distribution can be easily customised by the user to include personal scripts, additional tools, customised kernels, etc.
Get BackTrack Here.
2. Operator
Operator is a very fully featured LiveCD totally oriented around network security (with open source tools of course).
Operator is a complete Linux (Debian) distribution that runs from a single bootable CD and runs entirely in RAM. The Operator contains an extensive set of Open Source network security tools that can be used for monitoring and discovering networks. This virtually can turn any PC into a network security pen-testing device without having to install any software. Operator also contains a set of computer forensic and data recovery tools that can be used to assist you in data retrieval on the local system.
Get Operator Here
3. PHLAK
PHLAK or [P]rofessional [H]acker’s [L]inux [A]ssault [K]it is a modular live security Linux distribution (a.k.a LiveCD). PHLAK comes with two light gui’s (fluxbox and XFCE4), many security tools, and a spiral notebook full of security documentation. PHLAK is a derivative of Morphix, created by Alex de Landgraaf.
Mainly based around Penetration Testing, PHLAK is a must have for any pro hacker/pen-tester.
Get PHLAK Here (You can find a PHLAK Mirror Here as the page often seems be down).
4. Auditor
Auditor although now underway merging with WHax is still an excellent choice.
The Auditor security collection is a Live-System based on KNOPPIX. With no installation whatsoever, the analysis platform is started directly from the CD-Rom and is fully accessible within minutes. Independent of the hardware in use, the Auditor security collection offers a standardised working environment, so that the build-up of know-how and remote support is made easier.
Get Auditor Here
5. L.A.S Linux
L.A.S Linux or Local Area Security has been around quite some time aswell, although development has been a bit slow lately it’s still a useful CD to have. It has always aimed to fit on a MiniCD (180MB).
Local Area Security Linux is a ‘Live CD’ distribution with a strong emphasis on security tools and small footprint. We currently have 2 different versions of L.A.S. to fit two specific needs - MAIN and SECSERV. This project is released under the terms of GPL.
Get L.A.S Linux Here
6. Knoppix-STD
Horrible name I know! But it’s not a sexually trasmitted disease, trust me.
STD is a Linux-based Security Tool. Actually, it is a collection of hundreds if not thousands of open source security tools. It’s a Live Linux Distro, which means it runs from a bootable CD in memory without changing the native operating system of the host computer. Its sole purpose in life is to put as many security tools at your disposal with as slick an interface as it can.
Get Knoppix-STD Here
7. Helix
Helix is more on the forensics and incident response side than the networking or pen-testing side. Still a very useful tool to carry.
Helix is a customized distribution of the Knoppix Live Linux CD. Helix is more than just a bootable live CD. You can still boot into a customized Linux environment that includes customized linux kernels, excellent hardware detection and many applications dedicated to Incident Response and Forensics.
Get Helix Here
8. F.I.R.E
A little out of date, but still considered the strongest bootable forensics solution (of the open-source kind). Also has a few pen-testing tools on it.
FIRE is a portable bootable cdrom based distribution with the goal of providing an immediate environment to perform forensic analysis, incident response, data recovery, virus scanning and vulnerability assessment.
Get F.I.R.E Here
9. nUbuntu
nUbuntu or Network Ubuntu is fairly much a newcomer in the LiveCD arena as Ubuntu, on which it is based, is pretty new itself.
The main goal of nUbuntu is to create a distribution which is derived from the Ubuntu distribution, and add packages related to security testing, and remove unneeded packages, such as Gnome, Openoffice.org, and Evolution. nUbuntu is the result of an idea two people had to create a new distribution for the learning experience.
Get nUbuntu Here
10. INSERT Rescue Security Toolkit
A strong all around contender with no particular focus on any area (has network analysis, disaster recovery, antivirus, forensics and so-on).
INSERT is a complete, bootable linux system. It comes with a graphical user interface running the fluxbox window manager while still being sufficiently small to fit on a credit card-sized CD-ROM.
The current version is based on Linux kernel 2.6.12.5 and Knoppix 4.0.2
Get INSERT Here
Extra - Knoppix
Remember this is the innovator and pretty much the basis of all these other distros, so check it out and keep a copy on you at all times!
Not strictly a security distro, but definately the most streamlined and smooth LiveCD distribution. The new version (soon to be released - Knoppix 5) has seamless NTFS writing enabled with libntfs+fuse.
KNOPPIX is a bootable CD or DVD with a collection of GNU/Linux software, automatic hardware detection, and support for many graphics cards, sound cards, SCSI and USB devices and other peripherals. KNOPPIX can be used as a productive Linux desktop, educational CD, rescue system, or adapted and used as a platform for commercial software product demos. It is not necessary to install anything on a hard disk.
Get Knoppix Here
Other Useful Resources:
SecurityDistros
FrozenTech LiveCD List
DistroWatch
Others to consider (Out of date or very new):
SlackPen
ThePacketMaster
Trinux
WarLinux
Network Security Toolkit
BrutalWare
KCPentrix
Plan-B
PENToo"
Tuesday, March 14, 2006
IP COP
"The IPCop project is a GNU/GPL project that offers an exceptional feature packed stand alone firewall to the internet community. Its comprehensive web interface, well documented administration guides, and its involved and helpful user/administrative mailing lists make users of any technical capacity feel at home. It goes far beyond a simple ipchains / netfilter implementation available in most Linux distributions and even the firewall feature sets of commercial competitors.
"Firewalls have had to undergo a tremendous metamorphosis as a result of evolving threats. IPCop is exemplary in offering such a range of default features and even further a large set of optional plug-ins which can provide further functionality..."
"Firewalls have had to undergo a tremendous metamorphosis as a result of evolving threats. IPCop is exemplary in offering such a range of default features and even further a large set of optional plug-ins which can provide further functionality..."
Friday, March 10, 2006
Virtualization with FreeBSD Jails
Virtualization with FreeBSD Jails
by Dan Langille
03/09/2006
This article shows how I created a jail under FreeBSD 5. Though FreeBSD 6.0 has come out since I wrote this article, the strategy should remain the same. I'll update the article with any changes should anything be different.
I have written previously about jails on FreeBSD 4. The goal of this jail is the creation of a test environment for a project I've been working on. Until recently, I've been providing a dedicated machine for exclusive use by the Bacula network backup project. That system ran regression tests on FreeBSD. In a recent consolidation of hardware, I replaced several older machines with one newer machine. I wanted to dispose of the computer used by the Bacula project and move them to a more powerful computer. However, I didn't want them to have exclusive use of this system. I wanted to use the same computer and not have us interfere with each other.
Lift and Separate
Jails can separate different processes and keep them apart so they cannot interfere with each other. For example, you could run Apache in a jail and keep it away from everything else on the machine. Should someone find an exploit in Apache and use it to compromise your system, the intruders can only do what the jail allows them to do. A jail can consist of a full operating system, or a single executable.
The solution I used was to create a virtual machine for use by the Bacula project. I had recently acquired a Pentium 4 2.4GHz machine. It was pretty fast, so I decided to use this for system for my own development purposes. It will also be sitting idle for long periods of time, so I might as well let some else use it, as well. I don't want them to have access to the things I'm working on, so I decided to put them in a jail.
From within a jail, they are chrooted and cannot see anything outside of the jail. At the same time, it appears to them as if they are running on their own machine with their own operating system. As far as they know, they have their own computer and nobody else is on the system.
Running a virtual system within a jail is a good solution if you want to provide someone with resources, but don't want them to have complete control over your system. A jail can help you deal with issues of security and access, and improve the usage of existing resources, all at the same time.
Jail Documentation
The main document for creating a jail is man jail. I followed the instructions listed under "Setting up a Jail Directory Tree." I used those instructions to create the jail. You will need the full source tree for the system you going to create. I used the /usr/src/ directory I had from my most recent build world.
There's one step from man jail that I did not follow. I left Sendmail (actually, Postfix) running. I just changed it so that it did not listen on all IP addresses. I added this setting to /usr/local/etc/postfix/main.cf:
inet_interfaces = $myhostname
That allows the jail to run its own mail server.
I put my jail at /home/jail/192.168.0.155.bacula. This is the value I assigned to D in the instructions. After you have installed the jail, if you peek inside that directory, you'll see it looks just like the root directory of a typical FreeBSD system:
[dan@dfc:/home/jail/192.168.0.155.bacula] $ ls
COPYRIGHT etc libexec root usr
bin home mnt sbin var
boot kernel proc sys
dev lib rescue tmp
[dan@dfc:/home/jail/192.168.0.155.bacula] $
Terminology: Host Versus Jail
The host environment is the main system and is where you first install FreeBSD on the computer. It is in the host environment that you create a jail. The Bacula project will do their testing in the jail. They have access to the jail and only the jail. They will not have access to the host environment at all.
This concept of host environment and jail environment will come up again in this article. It is important that you understand what each one is.
In this example, the host environment is at IP address 192.168.0.100 and the jail is at 192.168.0.155.
Modifying Other Daemons
Most daemons will listen to whatever IP addresses are available to them. After starting your jail, if you try to ssh to it, you will not get into it. You'll be in the host environment instead. To get into the jail environment via ssh, you need to:
Tell the host environment sshd not to listen to the jail's IP address.
Run sshd in the jail.
Host Environment syslogd
This entry in /etc/rc.conf tells syslogd to not listen on any IP address.
syslogd_flags="-ss"
That allows syslogd to run in both the host and the jail environments.
Host Environment inetd
This entry in /etc/rc.conf tells inetd to listen on a specific IP address. This address is that of the host environment:
inetd_flags="-wW -C 60 -a 192.168.0.100"
Note that the first part of the flags in that line is from /etc/defaults/rc.conf:
inetd_flags="-wW -C 60" # Optional flags to inetd
Host Environment sshd
To alter the host environment sshd so it listens only to host environment IP addresses, modify /etc/ssh/sshd_config and set the IP address for the Listen directive:
ListenAddress 192.168.0.100
Then restart the main sshd process:
kill -HUP `cat /var/run/sshd.pid`
Use telnet to verify that the host environment is not listening on the jail address:
$ telnet 192.168.0.155 22
Trying 192.168.0.155...
telnet: connect to address 192.168.0.155: Connection refused
telnet: Unable to connect to remote host
If you don't get a connection, the host environment is not listening. This assumes that you have not yet started sshd in the jail environment.
Jail Environment sshd
To start sshd in the jail environment, add the following line to /etc/rc.conf:
sshd_enable="YES"
Jail Environment syslogd
In addition, I also swapped console output to /var/log/messages, as shown in this snippet from /etc/syslogd.conf:
#*.err;kern.warning;auth.notice;mail.crit /dev/console
*.err;kern.warning;auth.notice;mail.crit /var/log/messages
by Dan Langille
03/09/2006
This article shows how I created a jail under FreeBSD 5. Though FreeBSD 6.0 has come out since I wrote this article, the strategy should remain the same. I'll update the article with any changes should anything be different.
I have written previously about jails on FreeBSD 4. The goal of this jail is the creation of a test environment for a project I've been working on. Until recently, I've been providing a dedicated machine for exclusive use by the Bacula network backup project. That system ran regression tests on FreeBSD. In a recent consolidation of hardware, I replaced several older machines with one newer machine. I wanted to dispose of the computer used by the Bacula project and move them to a more powerful computer. However, I didn't want them to have exclusive use of this system. I wanted to use the same computer and not have us interfere with each other.
Lift and Separate
Jails can separate different processes and keep them apart so they cannot interfere with each other. For example, you could run Apache in a jail and keep it away from everything else on the machine. Should someone find an exploit in Apache and use it to compromise your system, the intruders can only do what the jail allows them to do. A jail can consist of a full operating system, or a single executable.
The solution I used was to create a virtual machine for use by the Bacula project. I had recently acquired a Pentium 4 2.4GHz machine. It was pretty fast, so I decided to use this for system for my own development purposes. It will also be sitting idle for long periods of time, so I might as well let some else use it, as well. I don't want them to have access to the things I'm working on, so I decided to put them in a jail.
From within a jail, they are chrooted and cannot see anything outside of the jail. At the same time, it appears to them as if they are running on their own machine with their own operating system. As far as they know, they have their own computer and nobody else is on the system.
Running a virtual system within a jail is a good solution if you want to provide someone with resources, but don't want them to have complete control over your system. A jail can help you deal with issues of security and access, and improve the usage of existing resources, all at the same time.
Jail Documentation
The main document for creating a jail is man jail. I followed the instructions listed under "Setting up a Jail Directory Tree." I used those instructions to create the jail. You will need the full source tree for the system you going to create. I used the /usr/src/ directory I had from my most recent build world.
There's one step from man jail that I did not follow. I left Sendmail (actually, Postfix) running. I just changed it so that it did not listen on all IP addresses. I added this setting to /usr/local/etc/postfix/main.cf:
inet_interfaces = $myhostname
That allows the jail to run its own mail server.
I put my jail at /home/jail/192.168.0.155.bacula. This is the value I assigned to D in the instructions. After you have installed the jail, if you peek inside that directory, you'll see it looks just like the root directory of a typical FreeBSD system:
[dan@dfc:/home/jail/192.168.0.155.bacula] $ ls
COPYRIGHT etc libexec root usr
bin home mnt sbin var
boot kernel proc sys
dev lib rescue tmp
[dan@dfc:/home/jail/192.168.0.155.bacula] $
Terminology: Host Versus Jail
The host environment is the main system and is where you first install FreeBSD on the computer. It is in the host environment that you create a jail. The Bacula project will do their testing in the jail. They have access to the jail and only the jail. They will not have access to the host environment at all.
This concept of host environment and jail environment will come up again in this article. It is important that you understand what each one is.
In this example, the host environment is at IP address 192.168.0.100 and the jail is at 192.168.0.155.
Modifying Other Daemons
Most daemons will listen to whatever IP addresses are available to them. After starting your jail, if you try to ssh to it, you will not get into it. You'll be in the host environment instead. To get into the jail environment via ssh, you need to:
Tell the host environment sshd not to listen to the jail's IP address.
Run sshd in the jail.
Host Environment syslogd
This entry in /etc/rc.conf tells syslogd to not listen on any IP address.
syslogd_flags="-ss"
That allows syslogd to run in both the host and the jail environments.
Host Environment inetd
This entry in /etc/rc.conf tells inetd to listen on a specific IP address. This address is that of the host environment:
inetd_flags="-wW -C 60 -a 192.168.0.100"
Note that the first part of the flags in that line is from /etc/defaults/rc.conf:
inetd_flags="-wW -C 60" # Optional flags to inetd
Host Environment sshd
To alter the host environment sshd so it listens only to host environment IP addresses, modify /etc/ssh/sshd_config and set the IP address for the Listen directive:
ListenAddress 192.168.0.100
Then restart the main sshd process:
kill -HUP `cat /var/run/sshd.pid`
Use telnet to verify that the host environment is not listening on the jail address:
$ telnet 192.168.0.155 22
Trying 192.168.0.155...
telnet: connect to address 192.168.0.155: Connection refused
telnet: Unable to connect to remote host
If you don't get a connection, the host environment is not listening. This assumes that you have not yet started sshd in the jail environment.
Jail Environment sshd
To start sshd in the jail environment, add the following line to /etc/rc.conf:
sshd_enable="YES"
Jail Environment syslogd
In addition, I also swapped console output to /var/log/messages, as shown in this snippet from /etc/syslogd.conf:
#*.err;kern.warning;auth.notice;mail.crit /dev/console
*.err;kern.warning;auth.notice;mail.crit /var/log/messages
Wednesday, March 08, 2006
OS X security contest ends without incident
Published: 2006-03-08
A new Mac OS X security contest reported on yesterday has ended early, but without incident.
The contest was started on March 6th in response to an article published by CNET News.com and ZDNet of a previous OS X hacking contest. The article initially failed to indicate that contest participants were given local user-level access to the system via SSH - highly unlikely in a real-world setting.
Dave Schroeder at the University of Wisconsin wrote that the test machine, which had traffic spiking to 30 Mbps, received over half a million web requests, 4000 attempted logins via SSH, and had six million events logged in less than 38 hours. Brian Rust, handling media relations for the contest, indicated that the contest was, "not an activity authorized by the UW-Madison," and the university's CIO requested it be ended prematurely. The contest ended without any compromise of the host's security.
Thursday, March 02, 2006
Zero to IPSec in 4 minutes
Zero to IPSec in 4 minutes
Dragos Ruiu 2006-02-28
This short article looks at how to get a fully functional IPSec VPN up and running between two fresh OpenBSD installations in about four minutes flat.
Until recently, setting up an open-source IPSec solution has been woefully complex and involved wading through an alphabet soup of committee-designed protocols. Many people give up on IPSec after their first peek at the horrible and complex software documentation, opting instead to install some sort of commercial SSL VPN which seems much simpler. For those who have been through this exercise, a jumble of SAs, ESPs, AHs, SPIs, CAs, certs, FIFOs, IKEs and policy jargon inside RFCs is enough to give anyone a headache. However, there is good new on the IPSec front: it has all finally been covered up with a nice, simple way to set it up under OpenBSD.
In this short article we'll look at how to get a fully functional IPSec VPN up and running between two fresh OpenBSD machines in about four minutes flat. The goal here certainly isn't to give an exhaustive overview of all the option available in IPSec or OpenBSD, but rather just how quickly and easily we can be up and running when others take days or weeks to do the same thing.
Introducing ipsecctl in OpenBSD
You might not have noticed it, but a new command has sneaked into OpenBSD, starting with version 3.8: ipsecctl. And it's truly wonderful. It provides a much needed layer of abstraction to all the highly flexible, but horribly intricate details of IPSec. In reality, most people don't need half the configuration and protocol options that IPSec provides, so this abstraction layer is sorely needed.
If all one wants to do is set up a simple encrypted Virtual Private Network (VPN) between two sites, the configuration steps one would have to go through otherwise were always truly ugly, and a bottle of aspirin was a mandatory accessory. No more! Now with ipsecctl, a simple VPN can be setup by editing one simple configuration file on OpenBSD: /etc/ipsec.conf.
As a test, my colleague Sean Comeau and I took two freshly installed OpenBSD firewalls, in their default configurations, and edited three files. We changed a total of seven lines of configuration on each system - and had an IPSec VPN exchanging packets between our two sites within four minutes of the first boot.
Those who haven't installed OpenBSD before will find the installation process surprisingly easy. The two most popular ways of installing are via CD-ROM (an inexpensive option, but it must be purchased from the OpenBSD team), or via a simple FTP install using a floppy or CD-ROM boot media. With a broadband connection, a complete FTP install of a default system can easily be completed in under ten minutes. For the purpose of this article, we'll assume you have two fresh installs of OpenBSD ready to go. Note that if you follow the CVS builds of either OpenBSD 3.8-stable or OpenBSD 3.8-current, both machines in your VPN should be running the same snapshot.
An IPSec example
To illustrate just how simple IPSec is to setup in OpenBSD, let's start with an example. First, let's quickly review our goals. We want to network two remote subnets via a fully encrypted, standard IPSec Virtual Private Network (VPN). Both our subnets will have OpenBSD Network Address Translation (NAT) firewalls.
Network A:
External IP address: 1.2.3.4 Internal IP address block: 10.1.1.0/24
Network B:
External IP address: 5.6.7.8 Internal IP address block: 10.2.2.0/24
The configuration of pf, which is our firewall and provides NAT, is found /etc/pf.conf. On both systems in this example, pf.conf should look as follows:
ext_if="fxp0"
int_if="fxp1"
set skip on { lo $int_if }
nat on $ext_if from !($ext_if) -> ($ext_if:0)
block in
pass out keep state
Both systems have had IP forwarding turned on by uncommenting the "net.inet.ip.forwarding=1" line in the /etc/sysctl.conf file. IP forwarding is turned off by default, but is required for NAT. Now that we understand our objectives and have two fully functional base systems, what do we have to do to link our two internal subnets together with a VPN? As you will see, the configuration is surprisingly simple.
Step 1. Configure IPSec
First, add the following lines to Firewall A in /etc/ipsec.conf:
ike esp from 10.1.1.0/24 to 10.2.2.0/24 peer 5.6.7.8
ike esp from 1.2.3.4 to 10.2.2.0/24 peer 5.6.7.8
ike esp from 1.2.3.4 to 5.6.7.8
Next, add the following lines to Firewall B's /etc/ipsec.conf:
ike passive esp from 10.2.2.0/24 to 10.1.1.0/24 peer 1.2.3.4
ike passive esp from 5.6.7.8 to 10.1.1.0/24 peer 1.2.3.4
ike passive esp from 5.6.7.8 to 1.2.3.4
The passive modifier in the configuration denotes that Firewall A will initiate the connection and Firewall B will listen for it.
Step 2. Allow IPSec through the firewall
Now, add the following line to /etc/pf.conf to configure the firewall on Firewall A:
pass quick on $ext_if from 5.6.7.8
and change the "set skip" line from:
set skip on { lo $int_if }
to:
set skip on { lo $int_if enc0 }
This adds the encapsulated enc0 interface to the list.
Now let's move on to Firewall B. In this /etc/pf.conf, add the following lines:
pass quick on $ext_if from 1.2.3.4
set skip on { lo $int_if enc0 }
We're done with both the firewall/NAT and IPSec configiguration, so let's move on to the next step - copying the keys.
Step 3. Copy the isakmpd keys to each system
On Firewall A (1.2.3.4), copy /etc/isakmpd/private/local.pub from Firewall B into /etc/isakmpd/pubkeys//ipv4/5.6.7.8.
Similarly, on Firewall B (5.6.7.8) copy /etc/isakmpd/private/local.pub from Firewall A into /etc/isakmpd/pubkeys/ipv4/1.2.3.4.
The reader should note that while this configuration uses numeric IP addresses, the configuration can also be done with fully qualified domain names. To use domain names, simply copy the keys into the /etc/isakmpd/pubkeys/fqdn directory, and use srcid and dstid keywords in you /etc/ipsec.conf flow specifications.
Step 4. Start the VPN
To start the VPN, use the following commands on both systems:
isakmpd -K
ipsecctl -f /etc/ipsec.conf
Congratualtions! You've just set up an IPSec VPN. You should be pleased to know that the ipsecctl command has automatically configured isakmpd and all its horrible config files, and it has chosen nice, sensible, and secure defaults for you.
The -K option tells isakmpd to skip the intricate and rarely needed policy configurations that would otherwise be required.
Now let's test the VPN. You should be able to ping nodes on 10.2.2.* from nodes on 10.1.1.* and vice versa. If this doesn't work, try starting up isakmpd with the debug option "isakmpd -K -d" to get more diagnostics.
Step 5. Set this up to start automatically at reboot
The default startup daemons on OpenBSD are found in the standard rc.conf file. Edit /etc/rc.conf and change the isakmpd line to:
isakmpd="-K"
Also ensure that 'PF=YES' in rc.conf as well, so that your pf firewall/NAT is started at the next boot. Now we also want to ensure that ipsecctl is started automatically. To the /etc/rc.local file, add the following line:
ipsecctl -f /etc/ipsec.conf
Finally, you may wish to edit your /etc/changelist on both Firewall A and B to ensure that your new /etc/ipsec.conf configuration file is listed. While this step is entirely optional, it ensures that any changes to your IPSec configuration be tracked and emailed to the administrator on a daily basis, as part of the daily mail script. For this to work, you must have configured /etc/mail/aliases and have given the root alias your own email address, and then run 'newaliases' to commit the changes.
And there you have it. Isn't that nice and simple? If you are familiar with pf and pfctl, ipsecctl will seem very easy and provides a very similar interface. In other words, you can get the status of the ipsec flows and associations with:
ipsecctl -sa
And so on. Amazingly, it took more than a decade for someone to finally provide a simple, straightforward configuration interface to IPSec. It's now simple enough that we are finally able to recommend IPSec to novice people so they can easily setup an IPSec VPN.
Conclusion
In this short article we looked at how easy it is to setup an IPSec VPN between two fresh OpenBSD installations. We started with two default installations and changed a total of seven configuration lines. Instead of taking days or weeks to get an IPSec VPN up and running, ours was running in about four minutes.
Thanks Theo and the OpenBSD team for this, as we believe this is truly a huge step forward for users everywhere who want to use IPSec. Ipsecctl is what we have long needed.
As a personal note, I'd like to see other *BSD committers port this to many other systems. Ipsecctl was specified by Matt Sauve-Frankel, and coded by Hans-Joerg Hoexer. While ipsecctl doesn't appear to work fully with IPv6 yet, support for this should be on the way. Also note that there may be differences with how ipsecctl works on the CVS versions of 3.8-current and 3.8-stable, and therefore it is recommended that both firewalls in your IPSec configuration run the same version of OpenBSD.
Dragos Ruiu 2006-02-28
This short article looks at how to get a fully functional IPSec VPN up and running between two fresh OpenBSD installations in about four minutes flat.
Until recently, setting up an open-source IPSec solution has been woefully complex and involved wading through an alphabet soup of committee-designed protocols. Many people give up on IPSec after their first peek at the horrible and complex software documentation, opting instead to install some sort of commercial SSL VPN which seems much simpler. For those who have been through this exercise, a jumble of SAs, ESPs, AHs, SPIs, CAs, certs, FIFOs, IKEs and policy jargon inside RFCs is enough to give anyone a headache. However, there is good new on the IPSec front: it has all finally been covered up with a nice, simple way to set it up under OpenBSD.
In this short article we'll look at how to get a fully functional IPSec VPN up and running between two fresh OpenBSD machines in about four minutes flat. The goal here certainly isn't to give an exhaustive overview of all the option available in IPSec or OpenBSD, but rather just how quickly and easily we can be up and running when others take days or weeks to do the same thing.
Introducing ipsecctl in OpenBSD
You might not have noticed it, but a new command has sneaked into OpenBSD, starting with version 3.8: ipsecctl. And it's truly wonderful. It provides a much needed layer of abstraction to all the highly flexible, but horribly intricate details of IPSec. In reality, most people don't need half the configuration and protocol options that IPSec provides, so this abstraction layer is sorely needed.
If all one wants to do is set up a simple encrypted Virtual Private Network (VPN) between two sites, the configuration steps one would have to go through otherwise were always truly ugly, and a bottle of aspirin was a mandatory accessory. No more! Now with ipsecctl, a simple VPN can be setup by editing one simple configuration file on OpenBSD: /etc/ipsec.conf.
As a test, my colleague Sean Comeau and I took two freshly installed OpenBSD firewalls, in their default configurations, and edited three files. We changed a total of seven lines of configuration on each system - and had an IPSec VPN exchanging packets between our two sites within four minutes of the first boot.
Those who haven't installed OpenBSD before will find the installation process surprisingly easy. The two most popular ways of installing are via CD-ROM (an inexpensive option, but it must be purchased from the OpenBSD team), or via a simple FTP install using a floppy or CD-ROM boot media. With a broadband connection, a complete FTP install of a default system can easily be completed in under ten minutes. For the purpose of this article, we'll assume you have two fresh installs of OpenBSD ready to go. Note that if you follow the CVS builds of either OpenBSD 3.8-stable or OpenBSD 3.8-current, both machines in your VPN should be running the same snapshot.
An IPSec example
To illustrate just how simple IPSec is to setup in OpenBSD, let's start with an example. First, let's quickly review our goals. We want to network two remote subnets via a fully encrypted, standard IPSec Virtual Private Network (VPN). Both our subnets will have OpenBSD Network Address Translation (NAT) firewalls.
Network A:
External IP address: 1.2.3.4 Internal IP address block: 10.1.1.0/24
Network B:
External IP address: 5.6.7.8 Internal IP address block: 10.2.2.0/24
The configuration of pf, which is our firewall and provides NAT, is found /etc/pf.conf. On both systems in this example, pf.conf should look as follows:
ext_if="fxp0"
int_if="fxp1"
set skip on { lo $int_if }
nat on $ext_if from !($ext_if) -> ($ext_if:0)
block in
pass out keep state
Both systems have had IP forwarding turned on by uncommenting the "net.inet.ip.forwarding=1" line in the /etc/sysctl.conf file. IP forwarding is turned off by default, but is required for NAT. Now that we understand our objectives and have two fully functional base systems, what do we have to do to link our two internal subnets together with a VPN? As you will see, the configuration is surprisingly simple.
Step 1. Configure IPSec
First, add the following lines to Firewall A in /etc/ipsec.conf:
ike esp from 10.1.1.0/24 to 10.2.2.0/24 peer 5.6.7.8
ike esp from 1.2.3.4 to 10.2.2.0/24 peer 5.6.7.8
ike esp from 1.2.3.4 to 5.6.7.8
Next, add the following lines to Firewall B's /etc/ipsec.conf:
ike passive esp from 10.2.2.0/24 to 10.1.1.0/24 peer 1.2.3.4
ike passive esp from 5.6.7.8 to 10.1.1.0/24 peer 1.2.3.4
ike passive esp from 5.6.7.8 to 1.2.3.4
The passive modifier in the configuration denotes that Firewall A will initiate the connection and Firewall B will listen for it.
Step 2. Allow IPSec through the firewall
Now, add the following line to /etc/pf.conf to configure the firewall on Firewall A:
pass quick on $ext_if from 5.6.7.8
and change the "set skip" line from:
set skip on { lo $int_if }
to:
set skip on { lo $int_if enc0 }
This adds the encapsulated enc0 interface to the list.
Now let's move on to Firewall B. In this /etc/pf.conf, add the following lines:
pass quick on $ext_if from 1.2.3.4
set skip on { lo $int_if enc0 }
We're done with both the firewall/NAT and IPSec configiguration, so let's move on to the next step - copying the keys.
Step 3. Copy the isakmpd keys to each system
On Firewall A (1.2.3.4), copy /etc/isakmpd/private/local.pub from Firewall B into /etc/isakmpd/pubkeys//ipv4/5.6.7.8.
Similarly, on Firewall B (5.6.7.8) copy /etc/isakmpd/private/local.pub from Firewall A into /etc/isakmpd/pubkeys/ipv4/1.2.3.4.
The reader should note that while this configuration uses numeric IP addresses, the configuration can also be done with fully qualified domain names. To use domain names, simply copy the keys into the /etc/isakmpd/pubkeys/fqdn directory, and use srcid and dstid keywords in you /etc/ipsec.conf flow specifications.
Step 4. Start the VPN
To start the VPN, use the following commands on both systems:
isakmpd -K
ipsecctl -f /etc/ipsec.conf
Congratualtions! You've just set up an IPSec VPN. You should be pleased to know that the ipsecctl command has automatically configured isakmpd and all its horrible config files, and it has chosen nice, sensible, and secure defaults for you.
The -K option tells isakmpd to skip the intricate and rarely needed policy configurations that would otherwise be required.
Now let's test the VPN. You should be able to ping nodes on 10.2.2.* from nodes on 10.1.1.* and vice versa. If this doesn't work, try starting up isakmpd with the debug option "isakmpd -K -d" to get more diagnostics.
Step 5. Set this up to start automatically at reboot
The default startup daemons on OpenBSD are found in the standard rc.conf file. Edit /etc/rc.conf and change the isakmpd line to:
isakmpd="-K"
Also ensure that 'PF=YES' in rc.conf as well, so that your pf firewall/NAT is started at the next boot. Now we also want to ensure that ipsecctl is started automatically. To the /etc/rc.local file, add the following line:
ipsecctl -f /etc/ipsec.conf
Finally, you may wish to edit your /etc/changelist on both Firewall A and B to ensure that your new /etc/ipsec.conf configuration file is listed. While this step is entirely optional, it ensures that any changes to your IPSec configuration be tracked and emailed to the administrator on a daily basis, as part of the daily mail script. For this to work, you must have configured /etc/mail/aliases and have given the root alias your own email address, and then run 'newaliases' to commit the changes.
And there you have it. Isn't that nice and simple? If you are familiar with pf and pfctl, ipsecctl will seem very easy and provides a very similar interface. In other words, you can get the status of the ipsec flows and associations with:
ipsecctl -sa
And so on. Amazingly, it took more than a decade for someone to finally provide a simple, straightforward configuration interface to IPSec. It's now simple enough that we are finally able to recommend IPSec to novice people so they can easily setup an IPSec VPN.
Conclusion
In this short article we looked at how easy it is to setup an IPSec VPN between two fresh OpenBSD installations. We started with two default installations and changed a total of seven configuration lines. Instead of taking days or weeks to get an IPSec VPN up and running, ours was running in about four minutes.
Thanks Theo and the OpenBSD team for this, as we believe this is truly a huge step forward for users everywhere who want to use IPSec. Ipsecctl is what we have long needed.
As a personal note, I'd like to see other *BSD committers port this to many other systems. Ipsecctl was specified by Matt Sauve-Frankel, and coded by Hans-Joerg Hoexer. While ipsecctl doesn't appear to work fully with IPv6 yet, support for this should be on the way. Also note that there may be differences with how ipsecctl works on the CVS versions of 3.8-current and 3.8-stable, and therefore it is recommended that both firewalls in your IPSec configuration run the same version of OpenBSD.
Subscribe to:
Comments (Atom)