Re: Why isn't this port blocked?
On Fri, Mar 07, 2003 at 05:22:23PM -0500, Peter Gorsuch wrote: > Connections to port 12002 occur between net2 and net3, > which should only allow port 42. Show us the state entry (from pfctl -vvss output) that passes the connection, then the corresponding rule (pfctl -vvsr, for the rule number in the state entry). I don't see which rule would allow the connection, make sure you have pf enabled (pfctl -si must say 'Enabled') and you've actually loaded the ruleset (check pfctl -sr output). Daniel
Why isn't this port blocked?
Connections to port 12002 occur between net2 and net3,
which should only allow port 42.
Thanks,
Pete
#pf.conf
#"net_" numbers:
#corp = x.5.55.0/24
#net2 = 2.2.0.0/16
#net3 = 3.3.0.0/16
#net4 = unused
#net5 = unused
#net6 = unused
#VARIABLES:
corp="xl0"
net2="fxp1"
net3="fxp0"
net4="fxp2"
net5="fxp3"
net6="fxp4"
#NAT:
nat on $corp from 2.2.0.0/16 to any -> 12.5.55.230
nat on $corp from 3.3.0.0/16 to any -> 12.5.55.230
#add more nat rules if needed as segments are added...
###
#Filter rules:
###
#block all by default:
block in all
block out all
###
#pass all for services as noted
#DNS
pass out inet proto { tcp, udp } from any to any port 53 keep state
#WWW
pass out inet proto tcp from any to any port 80 keep state
pass out inet proto tcp from any to any port https keep state
#ICMP
pass in proto icmp from any to any keep state
pass out proto icmp from any to any keep state
#Samba
pass in inet proto { tcp, udp } from any to any port { 135, 137, 138, 139 }
pass out inet proto { tcp, udp } from any to any port { 135, 137, 138, 139 }
keep state
pass in proto { tcp, udp } from any to any port 445
pass out proto { tcp, udp } from any to any port 445 keep state
#WINS on net2 and net3:
pass in on $net2 inet proto tcp from 3.3.0.0/16 to 2.2.0.0/16 port 42 keep
state
pass in on $net3 inet proto tcp from 2.2.0.0/16 to 3.3.0.0/16 port 42 keep
state
#Unix printing:
pass out inet proto { tcp, udp } from $corp to any port { 515, 9100 } keep
state
#REMOTE CONTROL (allow VNC on all hosts listening for a connection):
pass in inet proto { tcp, udp } from any to any port 5899 <> 5911 keep state
pass out inet proto { tcp, udp } from any to any port 5899 <> 5911 keep
state
pass in inet proto { tcp, udp } from any to any port 5799 <> 5811 keep state
pass out inet proto { tcp, udp } from any to any port 5799 <> 5811 keep
state
Re: PF/NAT UDP fragment problem
On Fri, 07 Mar 2003, Daniel Hartmeier wrote:
> Your ruleset looks fine, that's exactly how it should work (rdr on
> external, nat on internal, scrub on both).
That's good to know. Would "scrub in all" work just as well as "scrub
in on {$ExtIf, $IntIf} all fragment reassemble"?
> It must be somehow related to the fragmentation. For some reason, the pf
> box is not reassembling the fragments. To determine the reason, can you
>
> a) enable debug logging with pfctl -x m, and check /var/log/messages
> for entries related to pf fragment reassembly? Ideally, quote all
> lines related to one packet's fragments being reassembled.
A few of these lines were repeated in /var/log/messages. Here they are
without the repeats.
pf_normalize_ip: IP_DF
pf_normalize_ip: dropping bad fragment
Mar 7 15:20:02 reflect /bsd: pf_normalize_ip: IP_DF
Mar 7 15:20:02 reflect /bsd: pf_normalize_ip: dropping bad fragment
>
> b) get a tcpdump -nvvvXSpi $IntIF output from the pf box for all
> fragments of a single packet.
>
> One possible explanation would be if the fragments have the DF (don't
> fragment) flag set.
Indeed, it does. I took a look at the tcpdump and the fragments do have
the DF flag set.
> pf, prior to -current as of a few weeks ago, drops
> them unconditionally. If that's the problem, you could try a snapshot
> (which is stable, now that we approach 3.3-release). If not, hopefully
> the additional output from above shows something.
Excellent. Thank you for the help. I'll try -current and see how that
turns out. If it's still a problem, I'll include the dumped packets,
but I think you found the issue.
Thanks again,
pete
Re: PF/NAT UDP fragment problem
On Fri, Mar 07, 2003 at 03:27:06PM -0500, Pete Toscano wrote:
> That's good to know. Would "scrub in all" work just as well as "scrub
> in on {$ExtIf, $IntIf} all fragment reassemble"?
Yes, 'fragment reassemble' is the default, so both do the same thing
(unless you have additional interfaces that you don't want to scrub on,
of course). If you load 'scrub in all' and then display the loaded rules
(with pfctl -sr), you'll see that it gets loaded as 'fragment
reassemble'.
> Mar 7 15:20:02 reflect /bsd: pf_normalize_ip: IP_DF
> Mar 7 15:20:02 reflect /bsd: pf_normalize_ip: dropping bad fragment
Ok, that's it, then.
> Excellent. Thank you for the help. I'll try -current and see how that
> turns out. If it's still a problem, I'll include the dumped packets,
> but I think you found the issue.
With a recent snapshot, add 'no-df' to your scrub rule(s), and pf will
strip the IP_DF flag before reassembly, so the packets can get
reassembled. The snapshots on the ftp mirrors already include that
change.
Daniel
Re: PF/NAT UDP fragment problem
On Fri, Mar 07, 2003 at 11:45:16AM -0500, Pete Toscano wrote: > Anybody have any ideas? Am I using scrub incorrectly? Should I be > using scrub? Is there something else I'm doing wrong? Is there any > other potentially useful information I forgot to give? Your ruleset looks fine, that's exactly how it should work (rdr on external, nat on internal, scrub on both). > = ...and replies to it. This is where the frag begins. > 14:33:26.784417 DD.DD.DD.DD > II.II.II.II: (frag 55914:[EMAIL PROTECTED]) > 14:33:26.784437 DD.DD.DD.DD.5353 > II.II.II.II.56175: udp 1643 (frag 55914:[EMAIL > PROTECTED]) > = Nat receives the two reply fragments > 14:33:26.951181 DD.DD.DD.DD.5353 > II.II.II.II.56175: udp 1643 (frag 55914:[EMAIL > PROTECTED]) > 14:33:26.951195 DD.DD.DD.DD > II.II.II.II: (frag 55914:[EMAIL PROTECTED]) > = Nothing goes out Nat's external interface It must be somehow related to the fragmentation. For some reason, the pf box is not reassembling the fragments. To determine the reason, can you a) enable debug logging with pfctl -x m, and check /var/log/messages for entries related to pf fragment reassembly? Ideally, quote all lines related to one packet's fragments being reassembled. b) get a tcpdump -nvvvXSpi $IntIF output from the pf box for all fragments of a single packet. One possible explanation would be if the fragments have the DF (don't fragment) flag set. pf, prior to -current as of a few weeks ago, drops them unconditionally. If that's the problem, you could try a snapshot (which is stable, now that we approach 3.3-release). If not, hopefully the additional output from above shows something. Daniel
RE: intrusion detection
Just wanted to add a word of appreciation for pftop. Since I have a transparent bridge (which I didn't want to give an interface to), I just loaded Can's pftop package via floppy (14K) and it runs nicely. Not only is it great for looking at what people are doing on your network (well, I have 3000 connections so the order and view features are nice on a strict 80 x 24 screen), but I found the rules and labels views to be extremely helpful for looking through and cleaning up my rules. Again, thanks. I'm looking forward to our campus security symposium where I get to demonstrate the use of pf against all these other high priced vendor products (Cisco PIX, SonicWall, etc). In a meeting, Network operations here at UC Davis told us it would cost $14,000 for a PIX to firewall a subnet; I laughed and explained how I'd already done it with a Pentium 200. They were a bit stunned I've helped about 10 other departments so far use OpenBSD firewalls, and NOC is at a bit of a loss to explain how these firewalls keep sprouting up instead of their high-priced solutions. ;-) I'm looking over Daniel's pfstat for my NAT box, which does have an interface. *** * Adam Getchell [EMAIL PROTECTED] * System Architect/Programmer (530) 752-1584 * Human Resources Information Systems http://www.hr.ucdavis.edu/ *** "Invincibility is in oneself, vulnerability in the opponent." -- Sun Tzu
PF/NAT UDP fragment problem
I hope somebody here can help me with a PF/NAT problem I'm having. I'm
moving a machine of ours from OpenBSD 2.9 to 3.2. This was all working
with IPF running on the 2.9 install.
The machine in question ("nat") is working as a front for a DNS(SEC)
server. It takes UDP or TCP packets to port 53 on its external
interface (xl0) and forwards them out its internal interface (xl1) to
the real server running on a different. The machine the real server is
running on ("dennis") is further back in our network, behind a few
firewalls and in private IP space. Finally, nat is not along the
default path of dennis. Because of this, the source address of the
redirected packets needs to be rewritten to nat's internal IP address.
One side note about this. Normal DNS (UDP) queries do not fragment, but
it's not unusual to see DNSSEC queries fragment. This is the whole
reason we set up nat in the first place. The older BigIP boxes we were
using were dropping the UDP fragments returned by dennis. Non-DNSSEC
queries would work and TCP-based DNSSEC queries would work, but the
UDP-based DNSSEC queries would fail.
With OpenBSD 2.9, I was able to get this set up working without any
problems using the following:
rdr xl0 PP.PP.PP.PP/32 port 53 -> DD.DD.DD.DD port 5353 tcp/udp
map xl1 from 0.0.0.0/0 to DD.DD.DD.DD port = 5353 -> II.II.II.II/32 portmap tcp/udp
1:65000
Where PP.PP.PP.PP == nat's Public IP
II.II.II.II == nat's Internal IP
DD.DD.DD.DD == dennis' IP
With OpenBSD 3.2, I'm back to the same problem I was having with the
BigIPs. It looks like nat's dropping the UDP fragments returned from
dennis. This is the first time I've used pf, so I'm fairly certain that
it's just a problem with configuration of pf. I'm hoping someone can
help me.
This is the entire pf.conf file I'm using:
ExtIf="xl0"
IntIf="xl1"
DNS="PP.PP.PP.PP"
Dennis="DD.DD.DD.DD"
#scrub in all
scrub in on $ExtIf all fragment reassemble
scrub in on $IntIf all fragment reassemble
rdr on $ExtIf proto {udp,tcp} from any to $DNS port 53 -> $Dennis port 5353
nat on $IntIf proto {udp,tcp} from any to $Dennis port 5353 -> $IntIf
pass in all
pass out all
I tried the commented out "scrub in all" vs the other two "scrub"
commands, but that didn't help.
With this configuration loaded, normal UDP queries to PP.PP.PP.PP work
fine. TCP-based DNSSEC queries also work fine. The UDP-based DNSSEC
queris are failing. From tcpdumps on nat's two interfaces and on
dennis' interface, here's the patch I stitched together... (dennis' time
is off slightly.)
= DNSSEC query comes into nat's external interface
14:33:26.917445 XX.XX.XX.XX.43263 > PP.PP.PP.PP.53: 18333+ [1au] A? foo.com. (36)
(DF)
= Nat RDRs it to dennis (DD.DD.DD.DD) and NATs it to its
internal interface (II.II.II.II)
14:33:26.917596 II.II.II.II.56175 > DD.DD.DD.DD.5353: udp 36 (DF)
= Dennis receives the query...
14:33:26.752437 II.II.II.II.56175 > DD.DD.DD.DD.5353: udp 36 (DF)
= ...and replies to it. This is where the frag begins.
14:33:26.784417 DD.DD.DD.DD > II.II.II.II: (frag 55914:[EMAIL PROTECTED])
14:33:26.784437 DD.DD.DD.DD.5353 > II.II.II.II.56175: udp 1643 (frag 55914:[EMAIL
PROTECTED])
= Nat receives the two reply fragments
14:33:26.951181 DD.DD.DD.DD.5353 > II.II.II.II.56175: udp 1643 (frag 55914:[EMAIL
PROTECTED])
14:33:26.951195 DD.DD.DD.DD > II.II.II.II: (frag 55914:[EMAIL PROTECTED])
= Nothing goes out Nat's external interface
Anybody have any ideas? Am I using scrub incorrectly? Should I be
using scrub? Is there something else I'm doing wrong? Is there any
other potentially useful information I forgot to give?
BTW, this machine is running -STABLE, patched up to Wednesday night.
Thanks,
pete
Re: set loginterface
Kenny Gryp wrote: Are there some plans on selecting multiple loginterfaces to produce stats? I'm running -CURRENT now and i can only select one loginterface. If not, are there some reaons why you can only define one loginterface? I had a patch long time ago that achieve that. I could try to resurect it if there is a need for that feature. That will be post-3.3, of course. Cedric
set loginterface
Are there some plans on selecting multiple loginterfaces to produce stats? I'm running -CURRENT now and i can only select one loginterface. If not, are there some reaons why you can only define one loginterface? Thanks. -- Kenny Gryp http://gryp.dakin.be Anti Micro$oft Action Front:http://www.amaf.be Linux.be: http://www.linux.be Linux Usergroup West-Vlaanderen:http://www.lugwv.be College Linux User Group Torhout: http://www.c-lugt.be pgp0.pgp Description: PGP signature
Re: ALTQ ack prioritization
On Fri, Mar 07, 2003 at 01:40:31PM +0100, Henning Brauer wrote: >(pfctl.h ad pfctl_altq.c cheanged too) need more proofs I cannot type? *sigh* -- Henning Brauer, BS Web Services, http://bsws.de [EMAIL PROTECTED] - [EMAIL PROTECTED] Unix is very simple, but it takes a genius to understand the simplicity. (Dennis Ritchie)
Re: ALTQ ack prioritization
On Thu, Mar 06, 2003 at 09:09:14PM -0500, Jason Dixon wrote: > I forgot to mention, I'm running -snapshot from 3/2/03. It doesn't look > like what happened to me was caused by any bugs (that Henning has > mentioned in the meantime), but I'm curious... were any of those bugs > fixed after my snapshot? I keep forgetting WHEN I fixed stuff ;-) ok, cvs log helps. the first really ugly bug prevented the priority from working as it should. I fixed that in revision 1.332 of parse.y, that was 2003/02/26. The second one only affected filter rules which do specify queue(s) but do not specify an interface (pass in from ... vs pass in on $if from ...). That I fixed in rev. 1.335 of parse.y (pfctl.h ad pfctl_altq.c cheanged too) on 2003/03/02. so, your snapshot will have the first fix, as this one was in the snapshots even before I committed it (was it this one? man, I have memory leaks), it will not have the second one. -- Henning Brauer, BS Web Services, http://bsws.de [EMAIL PROTECTED] - [EMAIL PROTECTED] Unix is very simple, but it takes a genius to understand the simplicity. (Dennis Ritchie)
