IPFW Question about how ipfw rule for HTTP 80 works

[wisdown]

Hey everybody,

Currently I already have my server runing as desired.

Looking for optimizations and how to keep it hardening, I have found the reference on /etc/rc.ipfw about the book Building Internet Firewalls.

So, try following some examples, I did not got how ipfw works when trying limit it, for example, my old rule works "pretty well":

ipfw add 10 -q allow tcp from 10.1.1.100 80 to any 80 out via vmx0 setup keep-state

The book gives the advice about only accept answers using the ACK on TCP and use high ports for navigation (usually only download updates), then I have changed to:

ipfw add 10 -q allow tcp from 10.1.1.100 1024-65535 to any 80 out via vmx0 setup keep-state
ipfw add 20 -q allow tcp from any 80 to 10.1.1.100 1024-65535 in via vmx0 tcpflags ack setup keep-state

The question is how "OUT" works in details?

From my old way my guess it's bidirecional, so when I use something with OUT on firewall, automaticaly I'm accepting similar rule for IN complete the connection it is? (In another words, I cannot control the TCP handshake is it?)

Because on old way I don't have setup an IN rule and works fine.
And adding the second rule (20) seems that never get touched using ipfw show.

What should be the best approach on this example? (Following the book recomendation to only accept answers with ACK set)

PS.: I am asking about generic rule to download updates, not for webserver like apache or others (on webserver the IN works as desired).

 

[PMc]

The question is how "OUT" works in details?

Let me try to explain:

ipfw usually checks the packets twice, when they enter the system through some interface, and when they leave the system through some (other) interface. (This requires net.inet.ip.fw.one_pass=0 - if this is set to 1, it should check them only once, but that behaves weird and I didn't figure how that would be useful.)
Packets that originate from the local system appear only once as outgoing; packets that are destined to the local system appear only once as incoming; packets gatewayed through the system appear twice, packets via lo0 also appear twice, but first out then in - i.e. quite obvious.
The in and out keywords selectively apply to these packets: they handle gatewayed packets only when they are incoming or only when outgoing, and accordingly either packets to or from the local system.

To get some logic into this, I found it best to think of a flow having an originator (client) and a responder (server), and an individual packet being incoming or outgoing (at some point in time on some interface). Then for each packet we can say that it travels either in originate direction (e.g. setup) or in response direction (only when established), while it also can be either incoming or outgoing thru some interface (e.g. on a router), i.e. this is two different bits of information!

So, the in and out options only apply to the direction of this packet in relation to this system; they do not explicitely differenciate between the originate or response part of a flow.

Then, for TCP only, there are two other options, setup and established, and these apply to the state of the connection. They are shorthand terms for the tcpflags option (so this is where Your ACK stuff applies).

Back to in and out: you can also specify the interface that is concerned, with the via, xmit and recv options. But beware: while in and out concern this packet at this moment, these other options concern the history of the packet!
A statement like out recv em0 is legal, and translates to: <a packet that was incoming on em0 interface and is now outgoing on whatever interface>. via is specifically dangerous, as it means either incoming or outgoing: out via em0 applies to packets outgoing thru the em0 interface, but also to packets that were received thru em0 and are now outgoing on whatever other interface. Rune-of-thumb: via should never be used.

From my old way my guess it's bidirecional, so when I use something with OUT on firewall, automaticaly I'm accepting similar rule for IN complete the connection it is? (In another words, I cannot control the TCP handshake is it?)

No. in and out is much more basic and straightforward.

Because on old way I don't have setup an IN rule and works fine.
And adding the second rule (20) seems that never get touched using ipfw show.

That is probably because your rule (10) contains keep-state, and keepstate implicitely does checkstate also, so at this point the incoming packets get recoginzed as belonging to the same flow, and get allowed.

What should be the best approach on this example? (Following the book recomendation to only accept answers with ACK set)

PS.: I am asking about generic rule to download updates, not for webserver like apache or others (on webserver the IN works as desired).

Well, traditionally we used setup (for creating the connection) and established (for everything else). That means, You would allow everything appropriate out xmit vmx0, and only established in recv vmx0.
If your book gives more detailled restrictions on the tcpflags, then pronounce an appropriate tcpflags option instead.

This would be the stateless approach. If you instead do a stateful approach (with keep-state), then that is your rule(10). I would give the flow a distinct name for differenciation (in case the config will grow in the future), so that is allow tcp <from/to whatever> out xmit vmx0 setup keep-state :mydownld.

Then you can allow the packets of this specific flow with check-state :mydownld (no rule body with this). But in Your simple case You don't even need a check-state, because it is already implicitely done at the keep-state.

 

[SirDice]

from 10.1.1.100 80 to any 80 out

Outgoing connections always come from a random source port. This rule is limited to only accepting outgoing connections from port 80 to port 80, which almost never happens.

This is more appropriate because you cannot know what the source port is going to be.

from 10.1.1.100 to any 80 out