RE: PF related crash? (fwd)
-- Forwarded message --
Date: Sat, 22 Feb 2003 16:29:06 -0500
From: Glen MacAfee [EMAIL PROTECTED]
To: 'Wouter Clarie' [EMAIL PROTECTED]
Subject: RE: PF related crash?
Here are the results of dmesg and the ruleset; being a newbie, though, I'm
not sure exactly what you mean by crash trace and ps. What specifically
should I do?
BTW, I have tried this with the scrub and states/fragments uncommented but
to no avail.
Thanks,
Glen
OpenBSD 3.2 (GENERIC) #25: Thu Oct 3 19:51:53 MDT 2002
[EMAIL PROTECTED]:/usr/src/sys/arch/i386/compile/GENERIC
cpu0: F00F bug workaround installed
cpu0: Intel Pentium (P54C) (GenuineIntel 586-class) 166 MHz
cpu0: FPU,V86,DE,PSE,TSC,MSR,MCE,CX8
real mem = 49917952 (48748K)
avail mem = 40730624 (39776K)
using 634 buffers containing 2596864 bytes (2536K) of memory
mainbus0 (root)
bios0 at mainbus0: AT/286+(9b) BIOS, date 12/12/96, BIOS32 rev. 0 0xf7722
apm0 at bios0: Power Management spec V1.1
apm0: AC on, battery charge unknown
pcibios0 at bios0: rev. 2.1 0xf76e0/0x910
pcibios0: PCI BIOS has 4 Interrupt Routing table entries
pcibios0: PCI Exclusive IRQs: 10 11
pcibios0: PCI Interrupt Router at 000:01:0 (SIS 85C503 ISA rev 0x00)
pcibios0: PCI bus #0 is the last bus
bios0: ROM list: 0xc/0x8000 0xca000/0x1800
pci0 at mainbus0 bus 0: configuration mode 1 (bios)
pchb0 at pci0 dev 0 function 0 SIS 5511 rev 0x00
pcib0 at pci0 dev 1 function 0 SIS 85C503 ISA rev 0x01
pciide0 at pci0 dev 1 function 1 SIS 5513 EIDE rev 0x08: DMA, channel 0
configured to compatibility, channel 1 configured to compatibility
wd0 at pciide0 channel 0 drive 0: ST31720A
wd0: 16-sector PIO, LBA, 1626MB, 3305 cyl, 16 head, 63 sec, 3331852 sectors
wd0(pciide0:0:0): using PIO mode 4, DMA mode 2
pciide0: channel 1 ignored (disabled)
vga1 at pci0 dev 11 function 0 SIS 86C205 rev 0x44: aperture at
0xfdc0, size 0x40
wsdisplay0 at vga1: console (80x25, vt100 emulation)
wsdisplay0: screen 1-5 added (80x25, vt100 emulation)
fxp0 at pci0 dev 17 function 0 Intel 82557 rev 0x08: irq 11, address
00:d0:b7:27:db:69
inphy0 at fxp0 phy 1: i82555 10/100 media interface, rev. 4
fxp1 at pci0 dev 19 function 0 Intel 82557 rev 0x0c: irq 10, address
00:02:b3:32:1b:11
inphy1 at fxp1 phy 1: i82555 10/100 media interface, rev. 4
isa0 at pcib0
isadma0 at isa0
pckbc0 at isa0 port 0x60/5
pckbd0 at pckbc0 (kbd slot)
pckbc0: using irq 1 for kbd slot
wskbd0 at pckbd0: console keyboard, using wsdisplay0
pmsi0 at pckbc0 (aux slot)
pckbc0: using irq 12 for aux slot
wsmouse0 at pmsi0 mux 0
pcppi0 at isa0 port 0x61
midi0 at pcppi0: PC speaker
sysbeep0 at pcppi0
lpt0 at isa0 port 0x378/4 irq 7
npx0 at isa0 port 0xf0/16: using exception 16
pccom0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo
pccom1 at isa0 port 0x2f8/8 irq 3: ns16550a, 16 byte fifo
fdc0 at isa0 port 0x3f0/6 irq 6 drq 2
fd0 at fdc0 drive 0: 1.44MB 80 cyl, 2 head, 18 sec
biomask 4040 netmask 4c40 ttymask 5cc2
pctr: 586-class performance counters and user-level cycle counter enabled
dkcsum: wd0 matched BIOS disk 80
root on wd0a
rootdev=0x0 rrootdev=0x300 rawdev=0x302
WARNING: / was not properly unmounted
fd0: timeout (st0 0 cyl 0)
fd0c: soft error reading fsbn 0
# $OpenBSD: pf.conf,v 1.6 2002/06/27 07:00:43 fgsch Exp $
#
# See pf.conf(5) for syntax and examples
#
# replace ext0 with external interface name, 10.0.0.0/8 with internal
network
# and 192.168.1.1 with external address
# Part 1 -- Macros and definitions
IfExt = fxp0
IfInt = fxp1
IPsExt = 64.36.88.0/24
# Part 2 -- Options
#set limit { states 2000, frags 2000 }
#set loginterface $IfExt
# Will changing the line below from aggressive to normal help?
set optimization aggressive
#set timeout { tcp.opening 6, tcp.closing 6 }
#set timeout tcp.closing 300, other.first 100
# Normalize: reassemble fragments and resolve or reduce traffic ambiguities
# Problems with scrub causing kernel panic? Let's try turning it off...
#scrub in all
# Part 3 -- NAT
# Since this is a bridging FW, there will be no nat or rdr rules
# Part 4 -- Packet Filter Rules
#External bridge interface rules -- allow all in, filter on internal
# In bridge mode, we only filter on one interface.
pass in quick on $IfExt all
pass out quick on $IfExt all
# Internal bridge interface rules (main ruleset)
# Rule order does not matter.
# Most likely all of the packets we want dropped will use a rule of the
form:
# block out log quick on $IfInt ...
pass in quick on $IfInt inet proto { tcp, udp } from 64.36.88.146 to $IPsExt
port 1024
block out log quick on $IfInt inet proto { tcp, udp } from any to $IPsExt
port 1024
# This next rule blocks out attempts to connect to the MS UnPnP port; thanx
to grc
block out log quick on $IfInt inet proto tcp from any to $IPsExt port = 5000
# In rules
pass in quick on $IfInt proto { tcp, udp } from any to any keep state
# pass out/in certain ICMP queries and keep state (ping)
pass in quick on $IfInt inet proto icmp all icmp-type 8 code 0 keep state
# Allow certain UDP services in (DNS,
RE: PF related crash? (fwd)
On Fri, 21 Feb 2003, Glen MacAfee wrote:
IPsExt = xx.xx.xx.0/24
First, please always filter out real address information on public
lists. While we're all here to help, that doesn't stop folks who have
bad motives from getting this off the archives.
# Part 2 -- Options
#set limit { states 2000, frags 2000 }
#set loginterface $IfExt
# Will changing the line below from aggressive to normal help?
set optimization aggressive
#set timeout { tcp.opening 6, tcp.closing 6 }
#set timeout tcp.closing 300, other.first 100
Ok, you've set aggressive timeouts with the aggressive option, but you
aren't limiting your states or frags. Knowing you're only running 48MB
of RAM, it's not unreasonable to assume you're running out of memory.
You need to determine how much free RAM you have (excluding PF states),
then limit states based on that amount. The calculation is roughly 1k
states == 1MB RAM.
# Part 4 -- Packet Filter Rules
#External bridge interface rules -- allow all in, filter on internal
# In bridge mode, we only filter on one interface.
pass in quick on $IfExt all
pass out quick on $IfExt all
Ok, you need to study the PF documentation (FAQ, manpages, howto, etc).
PF is a last rule matches firewall. HOWEVER, you've already put in
the quick option on your first 2 rules... pass in and pass out.
You're letting EVERYTHING through your firewall. You're effectively
running nothing but a bridge... all the rules that follow are ignored by
the match engine, thanks to those 2 quick rules.
block in log on $IfInt all
And this is the last rule in your set. Provided you had NO quick
options in all the preceding rules, you would have just blocked
EVERYTHING inbound from your internal network. But even that's
irrelevant at this point... you're only supposed to filter in ONE
direction on a bridge. *sigh*
Try the following ruleset. Note that the $IPsExt needs to be defined,
and you'll probably want to redefine $fw_services (stuff allowed into
your firewall/bridge host), $udp_allowed (udp traffic allowed into your
internal hosts), and $tcp_allowed (tcp traffic allowed into your
internal hosts). ALSO NOTE that $udp_allowed and $tcp_allowed are only
defined to allow incoming traffic initiated from the outside... stuff
you are running internal servers for, IOW. You do NOT need to allow
UDP/DNS traffic explicitly just for your internal hosts' resolution...
that is allowed and tracked by the outgoing UDP state rule.
The modulate state option in the TCP section is only necessary if you
need to protect hosts with weak TCP implementations. If you're running
primarily Linux 2.4 and OpenBSD hosts, you only need to keep state.
Otherwise, and particularly if you're running Windows hosts, go ahead
and use modulate state.
Please take some time to study this ruleset and learn what and why it
does what it does. Reference the manpages to clarify what an option
means. And for the LOVE OF GOD, please unplug this box from the
internet ASAP until you get the ruleset fixed... you're running a
wide-open bridge. :)
-J.
# Macros
IfExt=fxp0
# Change the following network address to suit your needs
IPsExt=xxx.xxx.xxx.0/24
# Define the following sample services
fw_services={ ssh }
udp_allowed={ }
tcp_allowed={ http, smtp, https, ssh }
# Stuff that shouldn't cross our network
bad_blocks={ 0.0.0.0/8, 10.0.0.0/8, 127.0.0.0/8, 169.254.0.0/16,
172.16.0.0/12, 192.0.2.0/24, 192.168.0.0/16, 204.152.64.0/23,
224.0.0.0/3 }
# Options
set limit { states 16000, frags 8000 }
set loginterface $IfExt
set optimization aggressive
# Packet Normalization
scrub in all
# Default block
block out log on $IfExt all
block in log on $IfExt all
block return-rst out log on $IfExt proto tcp all
block return-rst in log on $IfExt proto tcp all
block return-icmp out log on $IfExt proto udp all
block return-icmp in log on $IfExt proto udp all
# Block unwanted
block in quick on $IfExt from 255.255.255.255/32 to any
block in quick on $IfExt from any to 255.255.255.255/32
block in quick on $IfExt from $bad_blocks to any
block in quick on $IfExt from any to $bad_blocks
# Allow certain icmp connections
pass out on $IfExt inet proto icmp all keep state
pass in on $IfExt inet proto icmp all icmp-type 8 code 0 keep state
# Allow certain udp connections
pass out on $IfExt proto udp all keep state
pass in on $IfExt proto udp from any to any port $udp_allowed keep state
# Allow certain tcp connections
pass out on $IfExt proto tcp all modulate state
pass in on $IfExt inet proto tcp from any to ($IfExt) port $fw_services
flags S/SA keep state
pass in on $IfExt proto tcp from any to any port $tcp_allowed flags S/SA
modulate state
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of
Wouter Clarie
Sent: Saturday, February 22, 2003 04:21
To: [EMAIL PROTECTED]
Subject: Re: PF related crash?
On Fri, 21 Feb 2003, Glen MacAfee wrote:
I'm getting crashes whenever I put a heavy load on the fw/bridge that I
have
Re: PF related crash? (fwd)
On Sun, Feb 23, 2003 at 10:20:05AM -0500, Jason Dixon wrote: On Fri, 21 Feb 2003, Glen MacAfee wrote: IPsExt = xx.xx.xx.0/24 First, please always filter out real address information on public lists. this is the worst advice I've seen in the last few hours. -- 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: PF related crash? (fwd)
Jason Dixon wrote: On Sun, 2003-02-23 at 11:14, Henning Brauer wrote: On Sun, Feb 23, 2003 at 10:20:05AM -0500, Jason Dixon wrote: On Fri, 21 Feb 2003, Glen MacAfee wrote: IPsExt = xx.xx.xx.0/24 First, please always filter out real address information on public lists. this is the worst advice I've seen in the last few hours. At the risk of publicly embarrassing myself, WHY? Why in the hell would you want people knowing your IP information... particularly on such a poorly configured (effectively NO) firewall? Henning, I really respect you, so I'm really confused as to your terse and enigmatic response. What Henning is probably getting at is the sheer effectiveness of obfuscating information on a support list. Chances are you could determine IP information anyways, if from nothing else than looking at the header for the IP of the sending mail relay. Obfuscating data makes it difficult to see into the problem. Giving the pertinent information saves the list members from having to send more mail asking for details. If you are in the habit of obfuscating data on other lists (see also security through obscurity), you're going to waste a lot of peoples' time. Reasons to do so are in such cases where (as in a firewall issue) you are asking ppl to critique your config or tell you why something doesn't work. If we can see the real address info, and understand the subnet design and what interface is on what network and what the rules apply to, its much easier. I understand your point about the misconfigured firewall and not wanting ppl to know how to reach you, but the majority of the time, do everyone a favor and give the unfettered, full, needed info in your help request. My $0.02. DS
Re: PF related crash? (fwd)
On Sun, 2003-02-23 at 16:41, Sancho2k.net Lists wrote: What Henning is probably getting at is the sheer effectiveness of obfuscating information on a support list. Chances are you could determine IP information anyways, if from nothing else than looking at the header for the IP of the sending mail relay. Obfuscating data makes it difficult to see into the problem. Giving the pertinent information DS, please understand that what I'm about to say is in no way directed to you... you're simply the messenger/interpreter. But GODDAMMIT, I'm tired of people suggesting that nothing get obfuscated because hackers could get it anyways. It's ridiculous to suggest that because a very small minority set of bad people might be able to dig up the relevant information (in this case, a netblock of incredibly vulnerable hosts), that it's a bad idea to hide it in a posted firewall ruleset to a public mailing list from the other hordes of minimally qualified script kiddies. Gimme a fucking break. We're talking about the external netblock, people. Not the internal routing table, not a handful of relevant macros, not a trace. Just a NETWORK ADDRESS. How could obfuscating this possibly rate as the worst advice of the day on anyone's radar? Please keep in mind that I am a critic of security through obscurity as well. But, as my momma used to say, pick your battles wisely. -J.
Re: PF related crash? (fwd)
pfft. nothing is scret on an IP address. if you have problems making your IP public... stop sending mails, stop surfing, stop doing dns. this is ridiculous. keeping your IP secret buys you NOTHING. -- 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: PF related crash? (fwd)
On Sun, 23 Feb 2003, Jason Dixon wrote: Just a NETWORK ADDRESS. How could obfuscating this possibly rate as the worst advice of the day on anyone's radar? There's been no useful advice today on misc@, so your words get the honour? Sam -- A few .Xr's short of a man page.
Re: PF related crash? (fwd)
On Sun, 2003-02-23 at 17:06, Henning Brauer wrote: pfft. nothing is scret on an IP address. if you have problems making your IP public... stop sending mails, stop surfing, stop doing dns. this is ridiculous. keeping your IP secret buys you NOTHING. Gosh, you're so right. It's impossible someone might submit their real ruleset from a hotmail/yahoo/myrealbox email account. What was I ever thinking. Let's make it a requisite that all folks with broken rulesets post their firewall's external IP information to the list. /sarcasm Henning, it's unfortunate that you probably think I'm on the other side of the fence. That's not at all the case... you're just being unreasonable. So be it, we'll agree to disagree. -J.
Re: PF related crash? (fwd)
Gosh, you're so right. It's impossible someone might submit their real ruleset from a hotmail/yahoo/myrealbox email account. What was I ever thinking. Let's make it a requisite that all folks with broken rulesets post their firewall's external IP information to the list. /sarcasm There is nothing more frustrating than trying to help someone with a problem, and then realizing you spent your time debugging a typo made when obfuscating IP addresses. Also, when these addresses are obfuscated, often they are NOT done in a consistent manner. This makes the config files impossible to read. it is ALWAYS easiest to track down a problem from the actual ruleset used. Unless you have a good reason to change something, DON'T. -kj
Re: PF related crash? (fwd)
On Sun, 2003-02-23 at 19:49, [EMAIL PROTECTED] wrote: There is nothing more frustrating than trying to help someone with a problem, and then realizing you spent your time debugging a typo made when obfuscating IP addresses. Also, when these addresses are obfuscated, often they are NOT done in a consistent manner. This makes the config files impossible to read. it is ALWAYS easiest to track down a problem from the actual ruleset used. Unless you have a good reason to change something, DON'T. I'm still aghast that you neglect to recognize this fellow's instance as a situation that falls into this scenario. Did you even bother to review his ruleset? He was allowing EVERYTHING... with quick, without state. What, for gosh sake, WOULD you consider an ok situation to obfuscate his external address? Not to mention it was only submitted in ONE place... a macro! Are you suggesting that, more often than not, folks post their ruleset with macros so obfuscated as to render them illegible? Or perhaps you're simply fabricating an impractical happenstance to validate your zealotry? 14.230.99.0 #imaginary xx.xx.xx.0#obfuscated Was that really so confusing? -J.
Re: PF related crash? (fwd)
There is nothing more frustrating than trying to help someone with a problem, and then realizing you spent your time debugging a typo made when obfuscating IP addresses. Are you suggesting that, more often than not, folks post their ruleset with macros so obfuscated as to render them illegible? Or perhaps you're simply fabricating an impractical happenstance to validate your zealotry? right. I made up that impractical happenstance. I frequently make up hypothetical situations and act like they really happened, because I want people to think I'm important. no, Jason. I'm saying when people mangle their rulefiles before posting them, THEY OFTEN MANGLE THEIR RULEFILES. This is why I don't bother reading obviously mangled rulefiles any more. out -kj
