Re: Openbsd firewall

[victor calzado <vcalzado () gmail com>]

Hi Joe,

On Thu, 29 Jul 2004 15:55:17 -0500, joe smith <joe () joesmith homeip net> wrote:
> I currently testing an openbsd gateway/firewall for my honeypot setup.
> I'm limiting the amount of bandwidth for each honey pot.  Does anyone
> know why I can not set it below 5.6 kilobits?

Are you using rules that try to shape incoming traffic directly over
the incoming interface of the firewall?

As far as I know traffic-shaper can't deal with incoming traffic doing
bandwidth allocation just because the shaper does not control this
traffic that is generated at the other side of the connection.
You can act over the incoming traffic using outgoing rules attached to
the outgoing interface of the connection, the gateway of the honeypots
VLAN, but you only succeeded if the other host plays fair (anyway you
can define outgoing state rules that match incoming connections and
traffic-shape the outgoing traffic, this should give you a little much
control while doing bandwidth allocation).

To be honest you must be the one that not play fair when trying
"shaping incoming traffic".
I mean, bandwidth allocation is possible acting in a mixed way over
the traffic, you define queues, that control incoming packets and send
them following defined policies that could be host related policies,
so when you are shaping traffic you read packets from the queues and
them you apply the policy that match that traffic if a host sends a
lot of packets, much more packets that policy allow it to send looking
at the bandwidth this host can allocate,  this host is doing something
that may well be called oversuscription that causes congestion of the
physical link. Oversuscription, like in ATM lines, could result in a
saturated queue (at the Ethernet interface, just before reaching you
traffic shaper queue)  that mostly have packets of the offending host,
so traffic from other host that *do* play fair have to wait its turn
in the ethernet queue before reaching the QoS queue (image you have a
friend in a rock'n'roll band and he gives you a VIP pass for a
concert, it there is a very long queue atthe entry of the concert you
should wait like others even when you are a VIP).

This situations usually happen when protocols with different
requirements from latency, speed, bandwidth,etc. live together in the
same shaper so you could find a lot of QoS related information that
could help.

There are some QoS algorithms that works better than other in this
situations but they all do the job at your firewall and they will do
it honestly, so maybe the approach should be other than QoS.

The first thing you have to deal with, even when using QoS, is the
ethernet queue, when you reduce the txquee of an interface you should
be careful, you may think that a short queue will help but it's not
that simple, anyway this queue is designed for fast connection at the
ethernet level to deal with 10/100 traffic and should be reduced when
an ethernet interface that is attached to a slower link. With a
shorted queue the good host packets *should* reach the QoS queue even
when ethernet "oversuscription" is present. (but you must be careful
shorter queues did not work because you'll lost a lot o traffic at the
ethernet level) at this point you still are play fair.

Once you have a ethernet quee that fits your network (this is mostly a
empirical value) you can slow down the incoming connection, this is
the nasty part of the game, doing so involves decrease the window size
(TCP Receive Window ) and delaying ACK responses in the TCP handshake 
so no window size scaling could happen (or even disable dynamic window
size in the gateway). You don't have control of the incoming traffic
but you can give sender a little window size to send ACK with
acknowledge (so knowing the packet size you could make and estimation
of the bandwidth used by a host). Doing so you have increased latency
of the link and have disabled the protocol defined method to avoid
high latency slowdown the connection.
This is not real a traffic shape solution but TCP window shape but
solution you can force the other side to slow down the connection
without packet lost. You don't do QoS at all but have a link with a
very very high latency (you can QoS outgoing traffic to slowdown
connection at your side) and there's little that the other side could
do to escape.

You could be even more nasty and force packet lost to happen even when
the different queues are not full, so the other side of the connection
slow down the packet send rate following congestion avoidance protocol
defined methods. There are some QoS implementations that will do it,
they do it setting a congestion bit in their packets and drop incoming
packets if the other host ignores the "congestion message" but maybe
if you decrease some TCP buffers or queues in the honeypot host you
will get congestion too.

This tweaks could help your outgoing QoS system to get a slower link.

I'll hope this help,
Kind Regards,
Victor



> Thanks
> J