Re: use of loopback interface
Yes, probably that's what I saw rather than any more complex rules. Good tip about using tcpdump to learn what if anything the loopback is doing over time. Since it's so easy for an inexperienced user to inadvertently block lo0 with the default rules, it might be worthwhile to add a sentence or two about this the next time the pf section of the networking FAQ is updated. Thanks. //Leigh Engelhart - The only case where I explicitely use lo0 in rules is to excempt it from a previous default block rule, as in # block everything (on _all_ interfaces) by default block in all block out all # don't filter the loopback interface pass in quick on lo0 all pass out quick on lo0 all Run tcpdump on lo0 for a week to see what kind of traffic occurs on there. I never felt the need to restrict it, and blocking it completely does break things in subtle ways (local dns, mail). Or did you find an example rule set that actually blocks/allows specific traffic (certain ports, etc.) on the loopback interface? Daniel
Re: Keepstate ?
On 30/08/2002, Amir Seyavash Mesry <[EMAIL PROTECTED]> wrote To [EMAIL PROTECTED]: > That was exactly the answer I was looking for. And could you please delete all this bullshit below your mails? First off its formatting is completly dead and second it's completly irrelevant. I guess that it may be auto-added, then get some other account for your list-traffic. Thx.
RE: Keepstate ?
That was exactly the answer I was looking for. Amir Seyavash Mesry [EMAIL PROTECTED] LSI Logic Corporation http://www.lsilogic.com/ Raid Support Test Technician 6145-D Northbelt Parkway Norcross, GA 30071 678-728-1211 NOTICE: This communication may contain privileged or other confidential information. If you are not the intended recipient, or believe that you have received this communication in error, please do not print, copy, retransmit, disseminate, or otherwise use the information. Also, please indicate to the sender that you have received this communication in error, and delete the copy you received. Thank you. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Philipp Buehler Sent: Friday, August 30, 2002 9:43 AM To: [EMAIL PROTECTED] Subject: Re: Keepstate ? On 30/08/2002, Daniel Hartmeier <[EMAIL PROTECTED]> wrote To [EMAIL PROTECTED]: > I'm not familiar with Cisco rule sets, so please explain what the > latter rule does, exactly. cisco's 'established' lets anything 'in' where it thinks (!) that it belongs to answering packets. such as fin/rst/syn-ack/ack packets. More or less, anything except a pure 'syn'. so consider this 'established' a subset of 'keep state' where the later provides way more filtering security. BEGIN:VCARD VERSION:2.1 N:Mesry;Amir;Seyavash FN:Amir Seyavash Mesry ORG:LSI Logic Inc.;Raid TITLE:Raid Support Test Technician TEL;WORK;VOICE:(678) 728-1211 ADR;WORK:;;6145-D Northbelt Parkway;Norcross;GA;30071;United States of America LABEL;WORK;ENCODING=QUOTED-PRINTABLE:6145-D Northbelt Parkway=0D=0ANorcross, GA 30071=0D=0AUnited States of Ameri= ca ADR;POSTAL:;;6145-D Northbelt Parkway;Norcross;GA;30071;United States of America LABEL;POSTAL;ENCODING=QUOTED-PRINTABLE:6145-D Northbelt Parkway=0D=0ANorcross, GA 30071=0D=0AUnited States of Ameri= ca EMAIL;PREF;INTERNET:[EMAIL PROTECTED] REV:20020510T175919Z END:VCARD
Re: set_ttl for normalization of the packet
On Fri, 30 Aug 2002, Daniel Hartmeier wrote: > On Thu, Aug 29, 2002 at 09:56:17PM +0200, Alexandre Dulaunoy wrote: > > > As the scrub directive can be set with a specified min/max ttl. This could > > be also useful to add set_ttl directive into scrub to make a > > normalization of the ttl in the packet. > > It's certainly possible, but wouldn't it royally break traceroute and > other applications that _use_ ttl? Yes like any other packet filtering or traffic normalizer with this type of feature. This is not a standard feature. > > Is this an attempt to hide the fact that connections from behind the > firewall originate from different hosts? How does min-ttl 255 not > achieve the same result? The packets might still take different paths > with varying number of hops and arrive with varying ttls at the > destination. Yes, but the set-ttl could be applied to input packet for a specified interface (the like ext_int à la FW1). Just an idea, I need to check the -current to see the inner architecture of pf. You are right, there are multiple implication of doing that. > > Or what's the purpose of resetting all ttls that pass through the > filter? To have a traffic normalizer in front of an architecture to limit the ttl forged packet and so other stuff like that and have a correct overview after for the NIDS and he could concentrate on some other task. I know this is not a standard feature (means exploding some RFCs ;-) but this could be useful in some case. For example, we have the need with a honeynet... Thanks a lot for your time. adulau -- Alexandre Dulaunoy -- http://www.foo.be/ 3B12 DCC2 82FA 2931 2F5B 709A 09E2 CD49 44E6 CBCD --- AD993-6BONE "People who fight may lose. People who not fight have already lost." Bertolt Brecht
Re: Keepstate ?
On 30/08/2002, Daniel Hartmeier <[EMAIL PROTECTED]> wrote To [EMAIL PROTECTED]: > I'm not familiar with Cisco rule sets, so please explain what the latter > rule does, exactly. cisco's 'established' lets anything 'in' where it thinks (!) that it belongs to answering packets. such as fin/rst/syn-ack/ack packets. More or less, anything except a pure 'syn'. so consider this 'established' a subset of 'keep state' where the later provides way more filtering security.
Re: use of loopback interface
On Tue, Aug 27, 2002 at 12:36:33PM -0400, Leigh Engelhart wrote: > In the pf scripts submitted here for review or help, I've noticed a few > times rules that involved the loopback interface (i.e. lo0). In the pf FAQ > and How-To I've read, this isn't mentioned. What sorts of setup or uses > would call for such rules? The only case where I explicitely use lo0 in rules is to excempt it from a previous default block rule, as in # block everything (on _all_ interfaces) by default block in all block out all # don't filter the loopback interface pass in quick on lo0 all pass out quick on lo0 all Run tcpdump on lo0 for a week to see what kind of traffic occurs on there. I never felt the need to restrict it, and blocking it completely does break things in subtle ways (local dns, mail). Or did you find an example rule set that actually blocks/allows specific traffic (certain ports, etc.) on the loopback interface? Daniel
Re: set_ttl for normalization of the packet
On Thu, Aug 29, 2002 at 09:56:17PM +0200, Alexandre Dulaunoy wrote: > As the scrub directive can be set with a specified min/max ttl. This could > be also useful to add set_ttl directive into scrub to make a > normalization of the ttl in the packet. It's certainly possible, but wouldn't it royally break traceroute and other applications that _use_ ttl? Is this an attempt to hide the fact that connections from behind the firewall originate from different hosts? How does min-ttl 255 not achieve the same result? The packets might still take different paths with varying number of hops and arrive with varying ttls at the destination. Or what's the purpose of resetting all ttls that pass through the filter? Daniel
Re: Keepstate ?
On Fri, Aug 30, 2002 at 08:55:41AM -0400, Amir Seyavash Mesry wrote: > Ok so a keep state statement such as > "Pass out all keep state" > would be the same as > "Permit any, any established" > on a cisco router? > Anyone??? I'm not familiar with Cisco rule sets, so please explain what the latter rule does, exactly. The rule 'pass out all keep state' in pf will let all outgoing packets pass and keeps track of the connections, so incoming packets (replies) of the those connections are passed automatically as well. Together with a rule that blocks all incoming packets by default, this rule set would allow only outgoing connections (but pass replies related to them back in) and block incoming connections. Daniel
Re: Is it possible to apply 'route-to' rules to redirected packets?
I guess what you want would be a 'route-replies-to' option, similar to 'route-to', but applying to packets that flow in the reverse direction as the initial packet of the connection that created state. Then you could just say rdr on de0 inet proto tcp from any to 195.200.200.201 port http \ -> 192.168.0.100 port http pass in quick on de0 route-replies-to de0 inet proto tcp \ from any to 192.168.0.100 port http The replies from the web server to the client would go to the interface with the default gateway (tun0, when it's active), but pf would then find the state and the rule that created it, and re-route the packet out through de0. I'm not sure this is a common enough case to warrant the extention, but it kind of makes sense to me. Any opinions? :) Daniel
Re: Is it possible to apply 'route-to' rules to redirected packets?
On Fri, Aug 30, 2002 at 02:08:41PM +0200, Clemens Dumat wrote:
> I tried to apply a route-to on tun0 to get this packet to de0, but i can't get
> it to work. Are 'route-to' pf-rules really treated differently than 'normal'
> rules (as show in http://mniam.net/pf/pf.png), or are they treated just like any
> other filter-rule and skipped when a state is applicable?
Ok, this is a little tricky, so let me first explain how rules, states
and route-to works in pf, then let's see how this affects your specific
situation.
When a packet goes through pf, pf first does a state table lookup. If
the packet matches a state, it's passed. Otherwise, the rule set is
evaluated, and the last matching rule either blocks or passes the
packet, and in the latter case optionally creates state.
The first packet of a connection never matches a state. If the last
matching rule contains a 'route-to' option, the packet is routed to that
interface. If the rule also creates state, the rule that creates it is
stored in the state entry. Further packets of this connection in the
same direction will also honor the route-to interface, if that
information is still available through the state -> rule that created
the state -> route-to option chain (which is broken, for instance, when
you reload the rule set, which clears all rule pointers in all active
states). So, in general, all (outgoing) packets of that connection will
be routed through the specified interface.
Another point is that translated packets (rdr, nat, binat) will
automatically create state when they're passed, even if the last
matching rule does not have the 'keep state' option.
So, let's look at your case.
The initial packet comes in on de0 and gets its destination address
translated to 192.168.0.100. A state lookup happens, but there is no
matching state. So the rule set is evaluated. The last matching rule is
> pass in quick on de0 inet proto tcp from any to any port { http }
So the packet gets passed, and since it was translated, implicitely
creates state. A pointer to the last matching rule is stored in the
state entry.
Now the web server 192.168.0.100 replies with a SYN+ACK to the external
browser. The firewall will try to route this packet out to its default
gateway, so pf gets to filter it on tun0. The state lookup finds the
existing state, so the packet gets passed. The rule that created the
state does not have a route-to option, so the packet is not routed to
another interface, and goes out through tun0. There's no rule set
evaluation at all, and the rule
> pass out quick on tun0 route-to de0:$WLANGate inet proto tcp \
> from any port { http } to any
never matches.
That explains what you see.
So, basically, route-to was made to route _outgoing_ connections through
different interfaces. What you want is a kind of 'route-from', that
affects where replies to _incoming_ connections are routed through. That
doesn't exist yet, I'm afraid. Maybe someone else has an idea how to
achieve the same with the existing options, I can't think of an simple
solution yet.
> A point that could confirm, that packets are treated the same, whether or not
> they have a routing section like 'route-to' in them, is that incoming
> connections aimed for the router (e.g. ssh) work with these rules (that is, when
> there is no state), but only as long as i don't keep state on these incoming
> connections!
Yes, that's because there is no translation creating state implicitely
in this case.
Daniel
RE: Keepstate ?
Anyone??? Amir Seyavash Mesry [EMAIL PROTECTED] LSI Logic Corporation http://www.lsilogic.com/ Raid Support Test Technician 6145-D Northbelt Parkway Norcross, GA 30071 678-728-1211 NOTICE: This communication may contain privileged or other confidential information. If you are not the intended recipient, or believe that you have received this communication in error, please do not print, copy, retransmit, disseminate, or otherwise use the information. Also, please indicate to the sender that you have received this communication in error, and delete the copy you received. Thank you. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Amir Seyavash Mesry Sent: Thursday, August 29, 2002 3:33 PM To: [EMAIL PROTECTED] Subject: Keepstate ? Ok so a keep state statement such as "Pass out all keep state" would be the same as "Permit any, any established" on a cisco router? Amir Seyavash Mesry [EMAIL PROTECTED] LSI Logic Corporation http://www.lsilogic.com/ Raid Support Test Technician 6145-D Northbelt Parkway Norcross, GA 30071 678-728-1211 NOTICE: This communication may contain privileged or other confidential information. If you are not the intended recipient, or believe that you have received this communication in error, please do not print, copy, retransmit, disseminate, or otherwise use the information. Also, please indicate to the sender that you have received this communication in error, and delete the copy you received. Thank you. BEGIN:VCARD VERSION:2.1 N:Mesry;Amir;Seyavash FN:Amir Seyavash Mesry ORG:LSI Logic Inc.;Raid TITLE:Raid Support Test Technician TEL;WORK;VOICE:(678) 728-1211 ADR;WORK:;;6145-D Northbelt Parkway;Norcross;GA;30071;United States of America LABEL;WORK;ENCODING=QUOTED-PRINTABLE:6145-D Northbelt Parkway=0D=0ANorcross, GA 30071=0D=0AUnited States of Ameri= ca ADR;POSTAL:;;6145-D Northbelt Parkway;Norcross;GA;30071;United States of America LABEL;POSTAL;ENCODING=QUOTED-PRINTABLE:6145-D Northbelt Parkway=0D=0ANorcross, GA 30071=0D=0AUnited States of Ameri= ca EMAIL;PREF;INTERNET:[EMAIL PROTECTED] REV:20020510T175919Z END:VCARD
Is it possible to apply 'route-to' rules to redirected packets?
Hi all,
i'm trying to apply route-to rules to packets that have a state (because they
were redirected or came in by a 'keep|modulate state'-rule), but to no avail.
I'm using 3.1-stable.
The situation is as follows: I have a router with 3 interfaces:
de0: external, static IP (e.g. 195.200.200.201)
de1: internal, 192.168.0.1
tun0 (via de2): external, ADSL, IP via DHCP
When tun0 is up (almost always) the default gateway is reachable via tun0, else
via de0.
I want to provide services (smtp, http, more in the future) on static IPs of de0
(the standard or preferably aliased ones).
If i try to do a rdr or a binat on de0 to some private machines, the translation
works correct, but the packets gets routed back to tun0!
Example (Connection attempt from 1.2.3.4:2003 to 195.200.200.201:80):
1) on de0: 1.2.3.4:2003-> 195.200.200.201:80
2) on de1: 1.2.3.4:2003-> 192.168.0.100:80
3) on de1: 192.168.0.100:80-> 1.2.3.4:2003
4) on tun0:195.200.200.201:80 -> 1.2.3.4:2003
As you can see, the problem lies in the 4th step: The packet gets routed to the
default interface and not the one stated in the route-to rule.
I tried to apply a route-to on tun0 to get this packet to de0, but i can't get
it to work. Are 'route-to' pf-rules really treated differently than 'normal'
rules (as show in http://mniam.net/pf/pf.png), or are they treated just like any
other filter-rule and skipped when a state is applicable?
The important rules are:
pass in quick on de0 inet proto tcp from any to any port { http }
pass out quick on tun0 route-to de0:$WLANGate inet proto tcp \
from any port { http } to any
rdr on de0 proto tcp from any to 195.200.200.201 port 80 \
-> 192.168.0.100 port 80
A point that could confirm, that packets are treated the same, whether or not
they have a routing section like 'route-to' in them, is that incoming
connections aimed for the router (e.g. ssh) work with these rules (that is, when
there is no state), but only as long as i don't keep state on these incoming
connections!
Thanks in advance,
Clemens
Re: set_ttl for normalization of the packet
On Fri, Aug 30, 2002 at 08:39:47AM +0200, Ed White wrote: > For example, nmap -sS could be stopped with the right block rule, but if > I'll use -current "scrub in all" what will PF do ? > I believe that packet will pass "scrub" untouched. > Right ? ;-) A scrub rule like this will certainly affect incoming packets. Fragments get reassembled (if they're properly fragmented) and invalid packets get dropped. The purpose of 'scrub', however, is not to defeat an OS detection, in fact it might give a scanner certain clues that scrubbing is going on (as anything the packet filter does). And it doesn't affect nmap -sS scans, since they are not made of fragmented or invalid packets, but basically valid TCP handshakes that never complete. Daniel
RE: set_ttl for normalization of the packet
> As the scrub directive can be set with a specified min/max ttl. > This could > be also useful to add set_ttl directive into scrub to make a > normalization of the ttl in the packet. > > What do you think ? I think that the scrub directive could be used to set more settings. For example, nmap -sS could be stopped with the right block rule, but if I'll use -current "scrub in all" what will PF do ? I believe that packet will pass "scrub" untouched. Right ? ;-) Ed
