Brian Keefer wrote:
There ARE a number of vendors selling OBSD solutions, actually. One I
remember running across is LOK Technologies.
Drivers should NOT be an issue - you're building an appliance, it should
be pretty simple to picl compatible s/w.
Lee
It's not to say there aren't vendors out there using non-Linux platforms
for their appliances. I mentioned CipherTrust, but they also ran into
some OS-specific issues when dealing with their DB vendor... IronPort
is also based on FreeBSD, but their choice of AV engines is apparently
pretty restricted. Why else would they still only have Sophos after all
these years, while every other e-mail appliance vendor has multiple AV
choices? My guess is they can't use Linux binary compatibility because
of the extent they've hacked their kernel and FS. Maybe that's not
true, but you have to wonder why they don't have McAfee or Kaspersky or
Panda, etc. Borderware also uses a FreeBSD based platform, but they're
a little different because they started with that for their firewall
product (a reasonable choice) and extended it to e-mail later when they
built a product for that. I might also point out that it took over 4
major revisions of their e-mail software to get it anywhere near stable
on top of their OS.
As for the drivers... like I said, it restricts options. Our
entry-level box at one point had a built-in RAID controller that was one
of those pseudo-hardware controllers that was really run by a binary
blob. That wouldn't have worked on OpenBSD. The motherboards we
currently use have built-in nForce ethernet chips, which only became
supported in 3.9. We use them for secondary/tertiary interfaces (it's
basically a "free" feature that customers get). Our other options would
be to select a motherboard that didn't use "blob-dependent" chipsets, or
put riser cards and separate PCI cards in, or just simply ship with less
features. That would either be more expense, or less value for our
customers. It would also add time to our release cycle by having to
test more hardware before we settle on a final design.
It might seem like a small amount of time, but a few extra combinations
means a few extra weeks of QA time, and possibly engineering would have
to delay coding while waiting on the final hardware config, etc... QA
is actually a lengthy process in appliance design, so any added
complexity in the test matrix has a negative impact on projects very
quickly. It's not to say it couldn't be done: It absolutely could be.
It's just that it wouldn't be zero cost, and why would we do that unless
we had to?
There are lots of ways to do anything. In the end it depends what goal
you're trying to achieve. If your goal is to use your favorite
operating system for the project, that's certainly doable. If your goal
is, hypothetically say, minimizing time to market while keeping a lid on
engineering and QA costs, your OS selection might look a little different.
It's just simply a matter of using the right tool for the right job. If
you're trying to do heavy-duty packet filtering VPN end-points, or
routing (where most of the code is leveraging built-in tools), a *BSD is
probably a good choice. If you just need a platform to load a bunch of
software on top of, some of which is third-party commercial stuff, *BSD
is not going to be your best choice.
Good points Brian. As a fellow appliance builder, I can really
appreciate and identify with what you said. For me though, the "right
tool for the right job" is OpenBSD.
Warning.. shameless plug ahead.
When I was still a grad student, my professor Dr. Yuliang Zheng
(inventor of HAVAL and signcryption) and I decided to start a business
to get some of our research out into the market. Our first product, the
AccessEnforcer, began as a simple email filtering appliance based on
OpenBSD.
Many years (and bowls of ramen noodles) later, the box has since evolved
into a full-fledged Unified Threat Management (UTM) appliance that does
firewall, intrusion detection/prevention, VPN, anti-spam, anti-spyware,
web filtering, email filtering, IM blocking, etc. -- and it is still
based on OpenBSD.
From Day 1, we began building the box on OpenBSD for a very simple
reason -- we will never let our customers use something that we do not
trust and use ourselves. OpenBSD is the only platform I trust to build
firewalls and other critical Internet-facing machines, so it was a
natural choice to use it for our product. So yes like you said, it was
"certainly doable." :)
Our target market is small to medium-sized businesses, who rarely have
enough resources for IT security so it also makes sense to use a solid
platform like OpenBSD for them.
As for AV engines, we're a bit different from the other vendors since we
use DyVax, our own signature-less AV engine which is the technology we
were trying to bring to market in the first place. :)
Of course OpenBSD is not perfect.. as you have pointed out, there is a
lack of drivers. So yes we had to be careful when choosing hardware
vendors. It wasn't too difficult, but it also certainly wasn't "pretty
simple" like another misc@ poster suggested.
But what I found was, the drivers that _are_ there in OpenBSD are
complete and Just Work -- there is no need to hunt down half-working
third-party source code patches (or *shudder* binary blobs) or play the
chase-the-kernel-version game to get something to work. I'd take a
high-quality OpenBSD blob-free driver over a non-free driver any day.
Another bonus of using OpenBSD: sensible API like strlcpy(3)/strlcat(3),
the sys/queue.h and RB-tree convenience macros, and extra
security-focused gcc warnings actually make development fun. There's
also plenty of high-quality source code to learn from.. as I dig deep
into both the userland and kernel, it is evident how well thought out
the entire system is. In a world of bad code and vulnerabilities, it is
such a joy to be able to read and learn from OpenBSD code to develop
better software every day.
Bottom line.. OpenBSD is a very viable and solid platform for commercial
security appliances. It does require some investment in choosing
hardware upfront, but in return you get a clean, secure, and robust
foundation to develop on, which I believe will pay off in the long term,
especially for security appliances.
As an aside, it seems like there are a fair number of us OpenBSD users
here in Silicon Valley. Lots of us have been individually lobbying
various hardware manufactures, most of which are headquartered in this
area, to release documentation for their products. I think it might be
more effective if we combine efforts and started pressing to get
in-person meetings with folks in product marketing at some of these
companies. If we could get 2 or 3 of us who are pretty well versed in
the business side of technology to present well-reasoned arguments for
why it would benefit these companies to have their hardware more widely
supported, we might begin to see some cracks in the blob armor.
Is anyone else local here interested in starting an unofficial lobbying
group to put together some position points as to why hardware vendors
should release documentation and start trying to schedule some meetings
with vendors?
I applaud your efforts in doing this. I'm based all the way over here on
the east coast in Charlotte, North Carolina, so I probably won't be of
much help for in-person lobbying efforts in Silicon Valley.. however
please email me privately if you would like to discuss any way I can
help lob some ammunition your way. :)
My 2 cents,
Lawrence
Lawrence Teo
Calyptix Security
8701 Mallard Creek Rd
Charlotte, NC 28262
Phone: 704-971-8989
[EMAIL PROTECTED]
http://www.calyptix.com/
