Developer blog: reyk: hoststated(8) preinspection

Contributed by
dlg
on 2007-02-22
from the schnell-schnell-schnell dept.

Some month ago I was looking for a solution to run OpenBSD as a fully-featured loadbalancer. It was bothering me for a long time that I had to run some systems coupled to the Alteons, F5s, Linux virtual servers, or even Cizzz-coeees of the world. So I was very happy when I found pyr's work. I helped to improve his daemon, imported it into OpenBSD as hoststated(8) and convinced Theo to get him into the project as a new developer. hoststated is amazing and I'm already using it in production, but one major thing was missing: Layer 7 Loadbalancing.

Loadbalancing in OpenBSD is not very new; you can do it for a long
time now using the pf(4) redirection features, typically using layer 3
round-robin distribution to a table of internal hosts. Besides pf, it
is also possible to handle a bigger load by using the layer 2
loadbalancing functionality which I implemented in the trunk(4)
driver. You can also use the ARP balancing functionality of carp(4)
but this requires to run OpenBSD on all the backend servers (this is
nice but unfortunately not the typical case).

hoststated implements one missing link, the ability to do keep alive
checks of the internal servers. If you run a simple pf redirection in
front of a webserver pool, you would never know if all of the internal
hosts are really available and the users would worry about failed
connections. But the daemon will dynamically alter the redirection
table of active hosts and is even able to check various protocols,
like HTTP, for an expected reply.

So what about Layer 7 Loadbalancing? I was very happy that I could
offer OpenBSD-based loadbalancers now, when I suddenly got asked: "Do
you support SSL Acceleration?". Sure, we do, but there are many ways
to achieve this functionality. And I did not really like the existing
solutions. These "reverse-proxies" were either very complex, bloated,
or non-free. And the preferred solutions like pound, squid or even
OpenBSD's version of the Apache mod_proxy fall into the categories of
beeing bloated and complex. And I did not like the licenses...

First of all, I was concerned about the security of the existing
solutions. Security's worst enemy is complexity (thanks Bruce). I
looked at pound, the most promising candidate, but stumbled over
things like pthreads, regular expressions, and weird string functions
like strcpy with dynamic input buffers. This doesn't necessarily mean
that pound is insecure but it doesn't match our idea about software
and the principle of proactive security. I don't like pthreads in
networking daemons, because of potential risks in wrong use and the
complexity of the API itself. You can implement high performance
networking daemons using a single-threaded and non-forking event model
with non-blocking I/O (this is how most of our networking daemons like
bgpd(8), ospfd(8), or even hoststated work). Furthermore, the regular
expressions are a powerful way to match input strings and to split the
result into smaller pieces. Even though the regex(3) and regexp(3)
APIs are very popular and probably the key feature of scripting
languages like Perl, the implementation is very complex and a big
enigma to us developers; it is a potential risk. And hence, I replaced
the initial use of regex in the hoststated send/expect code with the
very simple fnmatch(3) interface (fnmatch is also used for shell
globbing, the advanced directory "wildcards").

So I decided to implement something on my own, something simple but
powerful. I already had some code as part of my company's
preinspection functionality to do generic TCP relaying with some
additional protocol inspection. In fact, preinspection is meant to be
an answer to the general UTM (Unified Threat Management) and deep
inspection/intrusion prevention hype. I hate the idea of parsing the
contents of every single packet payload, it is normally very slow, you
have an incredible amount of false positives/negatives, and the
protocol parsers are typically very buggy and a security nightmare on
the firewall itself. So preinspection is more like behavior based
blocking as we do in OpenBSD with pf overload tables, connection
rates, max source connections, greylisting and greytrapping with
spamd(8), and many other smart features.

Prevent an instrusion before looking into the packet details, leave
the fancy UTM work to other systems behind the firewall. Who cares
about the name of every single virus in the networks, as long as it's
kept out of it!

The relay code was a good starting point for my planned SSL
accelerator. In theory, such an SSL accelerator is nothing more than a
TCP relay which listens for SSL connections on the one side and opens
"plain" connections to the target system on the other side. In
contrast to a protocol proxy, a basic TCP relay or SSL accelerator
doesn't need to know any details about the transmitted layer 7
protocol, it just forwards any traffic between both sides. But you end
up in one major problem if you use a relay as a SSL accelerator or
reverse proxy: the target system doesn't know about the real client's
IP address, it just sees incoming connections from the relay itself.

I needed to extend the relay to do a little bit of HTTP processing.
The trick was to add an additional HTTP header to forwarded requests,
the "X-Forwarded-For" header as used by some other HTTP proxies and
non-free loadbalancers. But instead of hardcoding the X-Forwarded-For
header, I implemented a generic way to add, remove, change, expect or
filter HTTP headers. It is also possible to append values to existing
headers, because it's very common to append the client's IP address to
a comma-separated list in the existing header (a HTTP request may pass
several proxies on its way to the target host).

A perfect place to add the relay code was the existing hoststated. The
existing framework of the daemon and the multi-process privsep model
allowed to add independent processes handling the relay functionality
while using the state information provided by the existing host check
engine. And while I was already working with pyr on improving the
hoststated for the upcoming 4.1 OpenBSD release, I was able to extend
my TCP relay and SSL accelerator to become a real layer 7
loadbalancer. I simply had to implement some loadbalancing protocols
like roundrobin, loadbalance, and hash (indeed, roundrobin and
loadbalance got inspired from my existing work in trunk(4)) to be used
independently from the pf redirection. The loadbalance protocol uses a
hash over the source and destination IP addresses to select the target
host and hash allows to feed specified HTTP header values into the
hash instead.

And I went further than I expected... Some web applications use
session IDs in the URL to track the users. For example, you may have a
session ID like http://www.myhost.com/shop.php?page=foo&sessid=387874683268264826482&shop=bar
I extended my relay code to be able to parse the variables in an URL,
the GET-Vars, and to feed specified values into the hash. It allows to
grab the sessid variable and to feed it into the computed hash for the
loadbalance and hash protocols. This allows to do session-aware
loadbalancing to a pool of HTTP servers, if your web application
doesn't support any kind of internal clustering. And of course, you
can also use the filter or expect rules on the GET-Vars.

The relay has been tested to be very efficient and I initially
installed it as a SSL accelerator in front of a high volume web shop.
Our systems are running on dual core Opteron servers with PCI express
em(4) gigabit NICs, high end crypto accelerators, and using OpenBSD's
amd64 multiprocessor kernel. We tested the SSL accelerator with up to
110.000 pf states, about 5.000 new SSL connections per minute using
layer 7 loadbalancing and HTTP header rewriting, and nearly the same
volume of concurrent HTTP connections using layer 3 pf redirection.
After about six hours of testing we decided that the implementation is
good enough for production use ;-)... We had to stop the test when we
reached the limits of the backend webservers (pf's state and source
connection limits will protected the servers in production).
Amazingly, the loadbalancer was only up to 20% to 40% busy with a peak
load of 4.0 and below 40MB user memory usage (SSL session cache
disabled). While the relay code is designed to be non-blocking and
single-process based as mentioned before, I use a configurable count
of preforked relay processes to prevent any delays that can happen in
the SSL handshake.

A drawback of layer 7 TCP relays is that you cannot provide stateful
failover like we do with carp and pfsync(4). To improve the situation,
I implemented support for the carp demotion counters as used by bgpd
to force a quicker failover on error conditions. You can enable carp
demotion of a specified interface group, typically the group called
carp, to increase the demotion counter if all hosts in a table are
down. An increased carp demotion counter will force the local system
into BACKUP state to allow a graceful failover to a backup
loadbalancer. Furthermore, a global carp demotion option allows to
force the system into BACKUP state if hoststated exits or is beeing
killed to reload the configuration. It will clear the specified
group's demotion counter on startup and set it to 128 on exit.

A different thing, but a very good addition to the high performance
loadbalancers, is mpf's
implementation of IP-based loadsharing for CARP. Instead of
running in the typical BACKUP/MASTER configuration, the redundant
OpenBSD systems will compute a source/destination hash on the IP
addresses to decide if they accept the incoming connections. Both
systems will run in BACKUP and MASTER state at the same time and the
load will be equally shared. I considered it as an option for the SSL
accelerators, and tested
the functionality with positive results, but the good performance
of the primary relay didn't require to run a CARP "cluster" (But I
hope that this new carp mode will be available after the 4.1 release).

Anyway, relay is more than just a loadbalancer! It also supports
transparent proxying using NAT lookups, generic TCP redirection, and
we're thinking about many other smart features in the future. A very
simple patch to add URL white/blacklisting is on the way and you can
do some nice tricks with TCP-based connections. And here we end up in
a new trap - hoststated is a host state monitoring daemon, partially a
loadbalancer but now it's getting a general-purpose preinspection
thing? Should we change the name again? Probably not.

Nevertheless, the relay functionality and hoststated will be available
in OpenBSD 4.1. It is still considered to be experimental, and I have
some work on my TODO list, including additional cleanup, code review
and improvement. The latest discussions on our mailing lists about
possible reverse proxy solutions showed me that it was the right time
to release something new, to carefully enter layer 7 in OpenBSD.

More to follow...

(Comments are closed)

By
marklar () marklar_@hotmail.com
on 2007-02-22 05:03

This is insane, you're about to put F5 out of business if you keep this up... good job!!
Nice to see the solid platform that OpenBSD has built makes this kind of development possible, I look forward to a HowTo because I'm itching to try it.

By
Nate (Nate)
on 2007-02-22 05:17

> Nice to see the solid platform that OpenBSD has built makes this kind of development possible, I look forward to a HowTo because I'm itching to try it.

Welcome to OpenBSD, home of the no How-tos. This looks like a job for Manpage!

By
Anonymous Coward ()
on 2007-02-22 05:40

> Welcome to OpenBSD, home of the no How-tos. This looks like a job for Manpage!

I've always found the FAQ to be more howto-ish than FAQ-ish. Meh.
As long as there's something to tell me what man page I need to look at in order to work with feature X (and the FAQ generally does this), I'm happy.

> > Nice to see the solid platform that OpenBSD has built makes this kind of development possible, I look forward to a HowTo because I'm itching to try it.
>
> Welcome to OpenBSD, home of the no How-tos. This looks like a job for Manpage!

> This is insane, you're about to put F5 out of business if you keep this up... good job!!

Who wouldn't want to get rid of their F5's ;)

By
Jeremy Huiskamp (kamper)
on 2007-02-22 07:09

Sounds like cool stuff. While some apps do use session ids in the url, is it not more common to put them in cookies? That's been my experience anyways.

By
christian () llx@swissonline.ch
on 2007-02-23 00:01

> Sounds like cool stuff. While some apps do use session ids in the url, is it not more common to put them in cookies? That's been my experience anyways.

the prefered way to track a user session in an SSO environment is
ssl-based. it is far more complex to steal ssl-credentials then cookies. to protect you from insane configurations it is even
better to combine ssl-traking with one or more other session
tracking mechanism. but this is somewhat off-topic here.

may containers use poor random values for there sessionID thus a
nice openbsd-like feature would be to replace the sessionID with a strong randomized value.

By
Anonymous Coward ()
on 2007-02-24 18:53

> Sounds like cool stuff. While some apps do use session ids in the url, is it not more common to put them in cookies? That's been my experience anyways.

Yes, and its not any harder to parse the cookies than it is to parse the query string, so it shouldn't be hard to add. You should never have session IDs in the url, as then they get passed in referrer headers and other malicious sites can steal your users valid session IDs without even needing to get in between them and your server to sniff.

By
Henrik Kramshøj () hlk@kramse.dk
on 2007-02-22 07:55
www.kramse.dk

Nice article!

I just want to point your attention to Varnish high-performance HTTP accelerator which also help a couple of big sites with accellerating.

The project is not very old, and some of the readers that needs
these technologies might not know about it.
http://varnish.projects.linpro.no/

Actually I haven't tried it on OpenBSD yet, but it is on the ToDo list

By
Anonymous Coward ()
on 2007-02-22 08:31

> Nice article!
>
> I just want to point your attention to Varnish high-performance HTTP accelerator which also help a couple of big sites with accellerating.
>
> The project is not very old, and some of the readers that needs
> these technologies might not know about it.
> http://varnish.projects.linpro.no/
>
> Actually I haven't tried it on OpenBSD yet, but it is on the ToDo list

Really? Poul-Henning Kamp (the developer) is a well known OpenBSD hater -- he went as far as heckling Reyk and calling him a terrorist IIRC

By
Henrik Kramshøj ()
on 2007-02-22 11:40

> > Nice article!
> >
> > I just want to point your attention to Varnish high-performance HTTP accelerator which also help a couple of big sites with accellerating.
> >
> > The project is not very old, and some of the readers that needs
> > these technologies might not know about it.
> > http://varnish.projects.linpro.no/
> >
> > Actually I haven't tried it on OpenBSD yet, but it is on the ToDo list
>
> Really? Poul-Henning Kamp (the developer) is a well known OpenBSD hater -- he went as far as heckling Reyk and calling him a terrorist IIRC

Yes, he is your run of the mill old grumpy UNIX guy ...
I regularly run into him at various places in DK, and he is nice and knowledgeable. Varnish is way cool and being deployed at quite big sites with great success. Would be sad if we couldn't make it work on OpenBSD someday.

I guess that terrorist, FUDDING etc is something about wireless and especially Atheros drivers/blobs?

If so I think a lot of people get the whole point wrong.

The way I see it FreeBSD wanted the cards supported and decided to "take on for the team" by bending over - their choice.
While OpenBSD opted for the harder way, make a free driver - which is GREAT - I love the ath driver and even replaced an unsupported Cisco 802.11b in my Thinkpad X31 with an atheros 802.11g. Thanks Reyk!

The goals were different and both succeeded with their goals
- the real problem is how it affects the whole driver, vendor system vs
open source, and here I can only say that I agree fully with the OpenBSD way!

Enough of that, I need to show these cool OpenBSD things on Linuxforum 2007!

By
Anonymous Coward ()
on 2007-02-22 19:32

> Really? Poul-Henning Kamp (the developer) is a well known OpenBSD hater -- he went as far as heckling Reyk and calling him a terrorist IIRC

What the ..

By
sthen ()
on 2007-02-22 10:21

> Actually I haven't tried it on OpenBSD yet, but it is on the ToDo list

OpenBSD doesn't have EVFILT_TIMER in kqueue(2) which Varnish needs.

By
Anonymous Coward ()
on 2007-02-22 18:21

> > Actually I haven't tried it on OpenBSD yet, but it is on the ToDo list
>
> OpenBSD doesn't have EVFILT_TIMER in kqueue(2) which Varnish needs.

Also Varnish does not support load balancing to back-end servers.

By
uspoerlein ()
on 2007-02-22 18:58

> > > Actually I haven't tried it on OpenBSD yet, but it is on the ToDo list
> >
> > OpenBSD doesn't have EVFILT_TIMER in kqueue(2) which Varnish needs.
>
> Also Varnish does not support load balancing to back-end servers.

Yes it does, with their own "programming language" you can decide to fire off requests to different backend servers. You can also do this session-based, if the session is transmitted via &sid=foo-URL. I don't know if you can inspect the Cookies of the HTTP request, but I would be surprised if you couldn't.

Please check out the interview with phk on bsdtalk, he give's a really nice overview of Varnish.

By
Anonymous Coward ()
on 2007-02-22 19:31

> > > > Actually I haven't tried it on OpenBSD yet, but it is on the ToDo list
> > >
> > > OpenBSD doesn't have EVFILT_TIMER in kqueue(2) which Varnish needs.
> >
> > Also Varnish does not support load balancing to back-end servers.
>
> Yes it does, with their own "programming language" you can decide to fire off requests to different backend servers. You can also do this session-based, if the session is transmitted via &sid=foo-URL. I don't know if you can inspect the Cookies of the HTTP request, but I would be surprised if you couldn't.

Thats not the same as load balancing, at all.

>
> Please check out the interview with phk on bsdtalk, he give's a really nice overview of Varnish.

I've read the source, thanks very much.

>
>

By
Pete ()
on 2007-02-22 10:09

hi reyk,

nice work :-) I'm a long time pound user, but this new stuff looks very promising

is it possible to make sessions sticky based on cookie contents ? e.g. a pretty common cookie is JSESSIONID, based upon which I'd love to be able to tie to a particular backend.

also, what is the behaviour when a client is tied to a backend which is suddenly determined as unavailable ? is the session reset or is it transparently remapped to an alternative avaiable backend ?

> hi reyk,
>
> nice work :-) I'm a long time pound user, but this new stuff looks very promising
>
> is it possible to make sessions sticky based on cookie contents ? e.g. a pretty common cookie is JSESSIONID, based upon which I'd love to be able to tie to a particular backend.
>

I do support hashing of the complete Cookie header, splitting the Cookie into values is on my TODO list. This will allow to use the cookie value like any other HTTP header or GET-Var.

> also, what is the behaviour when a client is tied to a backend which is suddenly determined as unavailable ? is the session reset or is it transparently remapped to an alternative avaiable backend ?
>

The relay will use the host states from the hoststated check engine to determine if a target host is up or down. If the determined host is down, the relay will try the next available host for this connection, if using the table loadbalance, roundrobin, or hash protocols.

I'm thinking about adding an additional fallback if the inbound connection to a host that was marked as up failed.

If all hosts in the table are down, hoststated can use the carp demotion option to enter carp BACKUP state.

> thanks
>
> /pete

By
sthen ()
on 2007-02-22 11:42

Nice work...

> I'm thinking about adding an additional fallback if the inbound connection to a host that was marked as up failed.

That may be worth doing, at least for the obviously broken "SYN -> no response" or "SYN -> RST", you could mark the backend as being down straight away rather than waiting for the next scheduled check, and ideally cut the client's connection across to another backend.

"request sent but no response from backend within timeout" and "request sent but error response from backend" probably need more consideration, the unwary user may get bitten with duplicate form submissions etc.

By
David Gwynne (dlg)
on 2007-02-22 12:00

> also, what is the behaviour when a client is tied to a backend which is suddenly determined as unavailable ? is the session reset or is it transparently remapped to an alternative avaiable backend ?

it depends on how the group of servers store their information about a clients session.

for example, the default session store for php driven stuff is a file in /tmp. obviously if that server with the session info dies then the session dies too, and the client will have to create a new session on another server in the pool.

however, you can modify it so the session store is something like a database. if all servers in the pool are using the one database to store session info then a server can die without the client noticing. another server in the pool can get the session info and pick up where the other left off just fine.

By
Anonymous Coward ()
on 2007-02-22 14:51

Alternativly, some web languages allows to store session in a memcached pool shared among servers.

On a side note, did you looked at HA Proxy ?
It's a similar (event driven, w/ servers health checks, http layer7 facilities, ... but lacks SSL support) load balancer, written by a Linux kernel dev. Run fine on OpenBSD.

There's bright ideas to poke here, related to high performance and even security (eg. connection tarpitting is nice !).

By
Matt Van Mater ()
on 2007-02-22 13:28

This is great, I have been looking for a non-Apache, non-Pound, non-squid way of doing this natively on openbsd for some time now. Keep up the good work, i appreciate it.

By
Anonymous Coward ()
on 2007-02-22 19:29

"Should we change the name again? Probably not."

oh go on ...

By
Anonymous Coward ()
on 2007-02-22 23:45

> "Should we change the name again? Probably not."

Please do this before it gets put into an official release if it's going to happen. I preferred the idea of eating hosts with the previous name anyway.

By
Anonymous Coward ()
on 2007-02-23 20:03

> Please do this before it gets put into an official release if it's going to happen.

seems doubtful, but my vote is for Anemone ;)

> I preferred the idea of eating hosts with the previous name anyway.

eating hosts ?

By
Anonymous Coward ()
on 2007-02-24 04:50

> > I preferred the idea of eating hosts with the previous name anyway.
>
> eating hosts ?

Well the first iteration was actually called slbd.
I didn't see there was an eponym at the time.

By
Curis ()
on 2007-02-22 20:06

This is a great feature but looking into the hoststated.conf(5), hoststated(8) and hoststatedctl(8) man pages I didn't see a way to test multiple ports on one host.

I'm thinking of my Rails project where I run a Mongrel cluster on ports 8000-8005 and would like to be able to check that they are still alive and also loadbalance between those 5 (as well as another machine that also runs the same setup).

Is this capable, or on the TODO list? Either way this is looking great and I can always just keep the two front facing Apache servers on port 80 I have now with proxy balancing between the Mongrel clusters.

By
Frank DENIS ()
on 2007-02-26 12:42

> This is a great feature but looking into the hoststated.conf(5), hoststated(8) and hoststatedctl(8) man pages I didn't see a way to test multiple ports on one host.
>
> I'm thinking of my Rails project where I run a Mongrel cluster on ports 8000-8005 and would like to be able to check that they are still alive and also loadbalance between those 5 (as well as another machine that also runs the same setup).

Sorry, but I don't see the point of using hostated in that case, in place of Apache2, Lighttpd-current or Nginx.
Mongrel is great, but for static content, it sucks. So let a front-end web server handle the static content, and have mongrel only handle the Rails part.

By
Anonymous Coward ()
on 2007-02-23 04:18

Brilliant! What a development. Frankly I've been impressed with the load balancing capabilities of a simple rdr server pool but this L7 stuff is cool, especially at the performance level. Another ++ for the solid OpenBSD architecture and adherence to doing things the best way possible.

I hadn't realized that this was the case:

> You can also use the ARP balancing functionality of carp(4) but this requires to run OpenBSD on all the backend servers (this is nice but unfortunately not the typical case).

What's with the dependency on the arpbalance on the backend OS?

And what is the required way of enabling the hardware load balancer for use in the SSL acceleration? I have a "Hifn 7955/7954" and haven't been clear on how to use it for acceleration.

By
Lennie ()
on 2007-02-24 10:29

> Brilliant! What a development. Frankly I've been impressed with the load balancing capabilities of a simple rdr server pool but this L7 stuff is cool, especially at the performance level. Another ++ for the solid OpenBSD architecture and adherence to doing things the best way possible.
>
> I hadn't realized that this was the case:
>
> > You can also use the ARP balancing functionality of carp(4) but this requires to run OpenBSD on all the backend servers (this is nice but unfortunately not the typical case).
>
> What's with the dependency on the arpbalance on the backend OS?
>
> And what is the required way of enabling the hardware load balancer for use in the SSL acceleration? I have a "Hifn 7955/7954" and haven't been clear on how to use it for acceleration.
>

I can only answer your first question.

( in case you do not know what arp is, arp is the methode of finding out which network-card 'houses' an IP-address. So if you want to send some packets to an other host on your local network, an ARP-request will be send out to ask what network-card these packets need to be send to, for them to arrive (the 'owner' then responds with it's MAC- or Ethernet-address) )

arpbalance an advanced feature of CARP in OpenBSD (maybe even other BSD's), it allows you to devide a network into equal parts per server (or firewall ofcourse). One host will respond to ARP-requests for certain machines on the network, an other machine in the 'cluster' responds to others. Thus creating a loadbalancing system.

About the hardware take a look here:
http://www.openbsd.org/cgi-bin/man.cgi?query=hifn&arch=i386&sektion=4

If I've understood it right, supported hardware should automagically get used by OpenBSD for the encryption-methodes supported by the hardware.

As I've never seen such a card up close, I'm guessing it should show up in dmesg and tell you what is supported.

By
Ed White ()
on 2007-02-23 19:02

I would prefer to have 2 separated software to handle "host state monitoring" and "stuff".

By
Anonymous Coward ()
on 2007-02-23 21:38

> I would prefer to have 2 separated software to handle "host state monitoring" and "stuff".
>
>

stuffd(8), then hostated(8) would have ate too many d's. Good thing it was renamed... ;-)

By
sthen ()
on 2007-02-23 23:24

> I would prefer to have 2 separated software to handle "host state monitoring" and "stuff".

a load-balancer needs to know the state of the hosts; combining them reduces overhead (machine resources, mostly-duplicated configuration) ... it does make sense.

Update: The hoststated relay SSL mode was tested by a PCI DSS (Payment Card Industry Data Security Standard) audit with the result that I had to add two options to disable the old SSLv2 protocol and to reject any medium or low grade cipher suites. Good thing; now it seems to comply, you can run it as a SSL accelerator for e-commerce applications, and put you mind at rest...

ssl { no sslv2, ciphers "HIGH" }

I also tweaked some other options, added the log action to track header/url values, and implemented a configurable listen backlog option for an improved performance with many concurrent connections.

By
David Gwynne (dlg)
on 2007-02-24 10:58

> Update: The hoststated relay SSL mode was tested by a PCI DSS (Payment Card Industry Data Security Standard) audit with the result that I had to add two options to disable the old SSLv2 protocol and to reject any medium or low grade cipher suites. Good thing; now it seems to comply, you can run it as a SSL accelerator for e-commerce applications, and put you mind at rest...

does complying mean anything, or is this just a gold sticker for good behaviour?

if it is better with the compliant behaviour, perhaps it would make sense to make that the default?

> > Update: The hoststated relay SSL mode was tested by a PCI DSS (Payment Card Industry Data Security Standard) audit with the result that I had to add two options to disable the old SSLv2 protocol and to reject any medium or low grade cipher suites. Good thing; now it seems to comply, you can run it as a SSL accelerator for e-commerce applications, and put you mind at rest...
>
> does complying mean anything, or is this just a gold sticker for good behaviour?
>

it is a requirement to connect your e-commerce platform to various payment gateways for things like VISA.

> if it is better with the compliant behaviour, perhaps it would make sense to make that the default?

yes, i changed it to disable SSLv2 and to use the "HIGH" crypto ciphers by default. you have to enable it now if you need any kind of MEDIUM or LOW
crypto or if you need to use SSLv2.

Awesome work!
I was curious if there was any feature planned to enable actions to be conditional based on certain headers? Specifically with Pound I often do special backend routing based on the Host header - for instance with the following (rough) pound.conf snippit:

The first chunk would pick up a request for http://railstest/ and the latter would serve everything else. I use this on a single IP, which lets me avoid DNS changes for backend handling changes. I didn't see anything in the man page about this, so please do apply the clue stick if I'm missed it.
Again, great work, I'd dump pound in a moment if I could use hoststated (not that pound is bad, just OpenBSD rules)!

Do you have any thoughts towards manipulating HTML on the fly? I have a video streaming server I'd like to provide controlled access to the outside world. It's web server only talks http. I initially setup squid reverse proxy to get to it, unfortunately the embedded server hard codes the server IP address using hidden values, so the ActiveX control can access the video stream. Rewriting HTML content on the fly could replace the internal IP address with the OpenBSD system running hoststated.

g.day

By
Anonymous Coward ()
on 2007-03-01 19:21

So guys, assuming we have 2 or more firewalls that are load balanced using CARP+pfsync, do we also need to setup hostated on all firewalls?