[OT] Firewall reference information
I hope my request is not inappropriate for the technical nature of the list. I'm hoping to find some references to use for a research paper I'm doing for a university class entitled "Comparative Benefits of Open Source Packet Filter Firewalls in Production Use." Part of my paper will cover comparitive acceptance of a couple of the big names in firewalls, compared to usage of alternatives such as netfilter, ipf, and of course pf. Anyway. Does anyone have some information suitable for this convoluted undertaking? In particular I'd like to find: -Any (pref. updated)suitable technical reference (whitepaper, abstract, etc.) about pf's functionality and features. -Comparitive market share of PIX, FW-1, Sonicwall, etc. -Benefits of pf in featureset compared to commercial products. -Studies on open source solution usage in the firewall arena. -Daniel, Henning, other pf contributors - anything you guys could find time to mention would be of particular value due to its authoritative nature.. ;) If anyone has conducted any kind of study like this for thier company and wouldn't mind sharing thier findings, please do so. If you feel like sharing some related input (your experience is welcome), send some my way too. If you do have something to contribute, don't bother polluting the list. You can hit me privately. TIA, Darren Spruell
Re: how stupid is this?
Alejandro G. Belluscio wrote: Hello David, Wednesday, February 19, 2003, 11:29:47 AM, you wrote: David> DNS sometimes also uses TCP on port 53 for large packets, so you David> probably want to allow that as well. I don't think so. DNS uses TCP only for zone transfers. But since he'll use dbjdns, which specifically DOESN'T supports either zone transfers or TCP, there's no point in opening that point of failure. Don't forget about axfrdns for TCP queries and zone x-fers. He'll be fine. DS Besides, the problem of hsoting your own DNS is that: 1) You get a listed server so you're fair game for script kiddies. 2) No software has the security track record of BIND (ok, may be MS, but let's not get to a MS bashing fest). So it's the number one port for script kiddies to try. Specifically, because they can't know the difference with dbjdns. I have contracted my dns. So I forget about that security problem, and since it's so cheap, and given that the increase in reading logs that causes hosting a DNS, I think it's actually cheaper. I pay like $4 per year for domain. Being cheap let's say that I make than in an hour. Do I save myself more than an hour of dns maintenance plus security aduting plus the eventuality of the time and expenses of having your machine owned? Yeah! Big time! Think about it. In fact it might be cheaper than buing a new sofa :-)
RE: Strange problem with pf, nat, and ftp
Hi Daniel, > Since you have the routable addresses, you could NAT the servers to > their respective addresses: > > nat on $ExtIf from 192.168.2.85 to any -> 14.244.112.5 > nat on $ExtIf from 192.168.2.0/24 to any -> 14.244.112.10 Argh, I should have thought of that! As soon as I saw your post, I knew it would work, and it does. Thanks for the tip. Darren.
Re: Syntax error in Snapshot pf.conf
On Wed, Feb 19, 2003 at 06:49:43PM -0500, Jason Dixon wrote:
> On Wed, 2003-02-19 at 18:38, Henning Brauer wrote:
> > > $int_if:network expands properly, but dynamic () does not work (again,
> > > passes test mode ok, but fails with a reload).
> > WHAT does not work?
> > ($interface:network) is not supposed to work.
> Sorry, my mistake. I expected parse mode to catch it. :(
yeah, it should.
Index: parse.y
===
RCS file: /cvs/src/sbin/pfctl/parse.y,v
retrieving revision 1.325
diff -u -r1.325 parse.y
--- parse.y 19 Feb 2003 22:00:20 - 1.325
+++ parse.y 20 Feb 2003 00:07:00 -
@@ -1588,6 +1588,10 @@
;
address: '(' STRING ')'{
+ if (ifa_exists($2) == NULL) {
+ yyerror("interface %s does not exist", $2);
+ YYERROR;
+ }
$$ = calloc(1, sizeof(struct node_host));
if ($$ == NULL)
err(1, "address: calloc");
--
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: Strange problem with pf, nat, and ftp
On Wed, Feb 19, 2003 at 03:51:17PM -0800, Darren Gibbons wrote: > In my quest to hunt down the problem, I noticed something else interesting. > This problem does not occur (i.e. forwarding ftp works for both Windows and > Unix clients) *if* the external address I use to forward internally is the > same address that the internal network is nat'd on! Seems very strange to > me. One possible explanation is that the windows clients expect the active data connections to come from the same IP address as they opened the control connection to, and drop data connections from other sources. Since you have the routable addresses, you could NAT the servers to their respective addresses: nat on $ExtIf from 192.168.2.85 to any -> 14.244.112.5 nat on $ExtIf from 192.168.2.0/24 to any -> 14.244.112.10 Or you could even use binat to map the addresses one to one, so even passive mode would work. Or you could run ftp-proxy with the reverse mode patch, with separate instances for port 21 on the different aliases. If you only need to support outgoing connections, NATing to the respective address is probably the easiest and most secure solution. Daniel
Re: Syntax error in Snapshot pf.conf
On Wed, 2003-02-19 at 18:38, Henning Brauer wrote: > > $int_if:network expands properly, but dynamic () does not work (again, > > passes test mode ok, but fails with a reload). > > WHAT does not work?? > > ($interface:network) is not supposed to work. Sorry, my mistake. I expected parse mode to catch it. :( -J.
Strange problem with pf, nat, and ftp
Hi all, I (like many before me) am having difficulties setting up ftp through an OBSD 3.2 FW to a server on our internal network. Here is the background: - OBSD 3.2 firewall with two nics - Multiple IP addresses aliased to external interface - Internal FTP (passive and active) works fine via ftp-proxy The firewall is a very vanilla setup, following Hoang's excellent tutorial (http://www.muine.org/~hoang/openpf.html). We've got three different FTP/web servers set up internally that I would like to allow access to for external clients. I've got three additional addresses aliased to the external interface, and I redirect traffic on port 80 to the aliased addresses to the internal servers. So far so good. The strange part is occurring when I try to redirect ftp traffic to the internal ftp servers. I recognize that without some kind of reverse proxy on the firewall that passive FTP is never going to work -- that's fine, they can use a client that does active ftp. Here's the summary: If an external Windows client tries to ftp to an address that I'm forwarding to the internal server, they can log in and authenticate, but can't do directory listings or transfer files. OK -- I know what you're thinking -- it's a problem inherent with the FTP protocol (i.e. data transfer on random high-port, etc.) Here's the strange thing: I only get this problem if I try to ftp from a Windows ftp client. Doesn't matter which one -- if I ftp from the windows command line ftp, or CuteFTP, or WSFTP -- all will log in properly, but hang on the directory listing. However, if I connect using a Unix based FTP client (I've tried 'ftp' and 'ncftp' on Linux and FreeBSD) it works no problem! In my quest to hunt down the problem, I noticed something else interesting. This problem does not occur (i.e. forwarding ftp works for both Windows and Unix clients) *if* the external address I use to forward internally is the same address that the internal network is nat'd on! Seems very strange to me. Here's some snippets of config files to see if you can shed some light on this: /etc/hostname.xl1 [external interface] inet 14.244.112.10 255.255.255.0 NONE inet alias 14.244.112.18 255.255.255.255 14.244.112.255 inet alias 14.244.112.5 255.255.255.255 14.244.112.255 inet alias 14.244.112.6 255.255.255.255 14.244.112.255 inet alias 14.244.112.7 255.255.255.255 14.244.112.255 /etc/pf.conf nat on $ExtIf from 192.168.2.0/24 to any -> 14.244.112.10 # this works rdr on $ExtIf proto tcp from any to 14.244.112.18/32 port 8080 -> 192.168.2.56 port http # this works rdr on $ExtIf proto tcp from any to 14.244.112.5/32 port http -> 192.168.2.85 port http # Windows ftp clients will be able to log in, but no directory listings # Unix clients will work fine with this setting. rdr on $ExtIf proto tcp from any to 14.244.112.5/32 port ftp -> 192.168.2.85 port ftp # this works for both windows and unix ftp clients, because it is the # same address that the internal network is nat'd on. # rdr on $ExtIf proto tcp from any to 14.244.112.10/32 port ftp -> 192.168.2.85 port ftp Any ideas? Thanks, Darren.
Re: Syntax error in Snapshot pf.conf
On Wed, Feb 19, 2003 at 06:17:17PM -0500, Jason Dixon wrote: > On Wed, 2003-02-19 at 18:00, Henning Brauer wrote: > > On Wed, Feb 19, 2003 at 05:40:30PM -0500, Jason Dixon wrote: > > > Are you saying that interface macros now support dynamic > > > updates by default? > > > > no, of course not. > > > > ($interface)/24 works again now though. > > Cool. And sorry for the confusion, I was assuming "network" was akin to > "cidr". I didn't realize "network" was NETWORK. ;-) > > $int_if:network expands properly, but dynamic () does not work (again, > passes test mode ok, but fails with a reload). WHAT does not work?? ($interface:network) is not supposed to work. -- 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: Syntax error in Snapshot pf.conf
On Wed, 2003-02-19 at 18:01, Jason Dixon wrote: > Sorry to self-post, but I did find that the syntax ($int_if:24) does > indeed work. The manpage mentions... Dammit, minor glitch. Test mode (-n) reports no errors, but loading the new ruleset gives me this: -bash-2.05b# pfctl -F rules && pfctl -R -f /etc/pf.conf rules cleared pfctl: DIOCADDRULE: Invalid argument If memory serves, doesn't this suggest some sort of kernel/userland incompatibility? I don't think this is the case, since the ruleset loads fine without that rule. Grrr. -J.
Re: Syntax error in Snapshot pf.conf
On Wed, 2003-02-19 at 18:00, Henning Brauer wrote: > On Wed, Feb 19, 2003 at 05:40:30PM -0500, Jason Dixon wrote: > > Are you saying that interface macros now support dynamic > > updates by default? > > no, of course not. > > ($interface)/24 works again now though. Cool. And sorry for the confusion, I was assuming "network" was akin to "cidr". I didn't realize "network" was NETWORK. ;-) $int_if:network expands properly, but dynamic () does not work (again, passes test mode ok, but fails with a reload). -J.
Re: Syntax error in Snapshot pf.conf
On Wed, Feb 19, 2003 at 05:40:30PM -0500, Jason Dixon wrote: > Are you saying that interface macros now support dynamic > updates by default? no, of course not. ($interface)/24 works again now though.
Re: Syntax error in Snapshot pf.conf
On Wed, 2003-02-19 at 17:40, Jason Dixon wrote:
> On Wed, 2003-02-19 at 15:06, Henning Brauer wrote:
> > > >I assumed it was due to the expansion "($int_if)/24", so I tried with a
> > > >single IP, and that fixed it. What is the new syntax like for cidr
> > > >expansion on an interface? I can't find any examples in the manpage.
> > > >
> > > $int_if:network probably
> >
> > well, of course that works fine, and of course $int_if/24 does too, but
> > ($int_if)/24 does _not_.
> > did that EVER work correctly?
> > off to check pf.c ...
>
> As mentioned previously, yes, this worked with 3.2 -release and
> -stable. Now that I think about it, the dynamic syntax () isn't even
> necessary on THAT interface, but I can see other instances where it
> might be. Are you saying that interface macros now support dynamic
> updates by default? If not, which syntax does? Forgive me if it's in
> the manpage, I can't find it.
Sorry to self-post, but I did find that the syntax ($int_if:24) does
indeed work. The manpage mentions...
"When the interface name is surrounded by parentheses, the rule is
automatically updated whenever the interface changes its address. The
ruleset does not need to be reloaded."
I'm probably splitting hairs, but this sounds a little ambiguous with
respect to interface modifiers. Nothing a little testing can't solve,
but...
If I knew how to correctly create a diff, I'd be happy to submit doc
patches. {wink}
-J.
Re: Syntax error in Snapshot pf.conf
On Wed, 2003-02-19 at 15:06, Henning Brauer wrote: > > >I assumed it was due to the expansion "($int_if)/24", so I tried with a > > >single IP, and that fixed it. What is the new syntax like for cidr > > >expansion on an interface? I can't find any examples in the manpage. > > > > > $int_if:network probably > > well, of course that works fine, and of course $int_if/24 does too, but > ($int_if)/24 does _not_. > did that EVER work correctly? > off to check pf.c ... As mentioned previously, yes, this worked with 3.2 -release and -stable. Now that I think about it, the dynamic syntax () isn't even necessary on THAT interface, but I can see other instances where it might be. Are you saying that interface macros now support dynamic updates by default? If not, which syntax does? Forgive me if it's in the manpage, I can't find it. -J.
Re: Syntax error in Snapshot pf.conf
On Wed, Feb 19, 2003 at 11:21:52PM +0100, Srebrenko Sehic wrote: > On Wed, Feb 19, 2003 at 03:08:11PM -0700, [EMAIL PROTECTED] wrote: > > > if you think about it for a minute, > > > $interface/24 > > > and > > > $interface:network > > > are not the same. > > > they CAN expand to teh same thing. one possibility. just one. > > Well true, but in most cases where this is used, the intent is > > the latter (the network $interface sits on). I would expect > > :network and :broadcast syntax to satisfy just about everyone. > Agree. Flexibility is great, but it just might get too flexible. > KISS. you you'd look at host() in pfctl_parser.c, you'd see we get $interface/24 for free. and I even have diffs to simplify that further.
Re: Syntax error in Snapshot pf.conf
On Wed, Feb 19, 2003 at 03:08:11PM -0700, [EMAIL PROTECTED] wrote: > > if you think about it for a minute, > > $interface/24 > > and > > $interface:network > > are not the same. > > they CAN expand to teh same thing. one possibility. just one. > > > Well true, but in most cases where this is used, the intent is > the latter (the network $interface sits on). I would expect > :network and :broadcast syntax to satisfy just about everyone. Agree. Flexibility is great, but it just might get too flexible. KISS. // haver
Re: Syntax error in Snapshot pf.conf
> if you think about it for a minute, > $interface/24 > and > $interface:network > are not the same. > they CAN expand to teh same thing. one possibility. just one. Well true, but in most cases where this is used, the intent is the latter (the network $interface sits on). I would expect :network and :broadcast syntax to satisfy just about everyone. -kj
Re: Syntax error in Snapshot pf.conf
On Wed, Feb 19, 2003 at 09:51:14PM +0100, Srebrenko Sehic wrote: > Is there any reason to have 10 ways of writing the same thing? Shouldn't > we choose a syntax and stick with that? if you think about it for a minute, $interface/24 and $interface:network are not the same. they CAN expand to teh same thing. one possibility. just one. $ echo "block inet from lo0/24" | pfctl -nvf - block drop inet from 127.0.0.0/24 to any $ echo "block inet from lo0:network" | pfctl -nvf - block drop inet from 127.0.0.0/8 to any -- 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: syntax error - pf parser's bug?
On Wed, Feb 19, 2003 at 09:47:31PM +0100, Henning Brauer wrote: > > I could be kind and tell you that you just want to add the address family to > your rule, but that'd probably be to much handholding ;-) oh ipv6... never tought of that.. and actually i removed it from most of my kernels, except this one.. shame on me. anyway, if parser said: stdin:3: icmp version does not match inet6 address family it would be a lot more clear, because, I guess, 'any' includes also my ipv6 address for that nic (no matther that icmp should be 'icmp6' for it to actually match). btw Wouter Clarie: no, I don't expect to flags S match udp/icmp but I preffer to have one rule for the three protocols; PF takes care of applying propper rules to propper protocols. about flags S, wheren't we be supposed to change flags S/SA for for flags S for future changes on PF? I may very well misunderstood that; if you confirm, I'm going to scan archives for propper info. thank you
Re: syntax error - pf parser's bug?
On Wed, 19 Feb 2003, Henning Brauer wrote:
> On Wed, Feb 19, 2003 at 09:42:23PM +0100, Wouter Clarie wrote:
> > On Wed, 19 Feb 2003, Juan Vera wrote:
> > > # pfctl -n -f -
> > > pass out quick on xl0 proto { tcp, udp, icmp } from any to any flags S keep state
> > > pass out quick on xl0 proto { tcp, udp, icmp } from xl0 to any flags S keep state
> > > stdin:3: icmp version does not match address family
> > > stdin:3: skipping filter rule due to errors
> > > pfctl: Syntax error in file: pf rules not loaded
> > The error message is indeed incorrect.
>
> no, it is not. it is entorely correct. he has an IPv6 address on xl0,
> and of course, one of the expanded rules is address family inet6 with
> protocol icmp. and "icmp version does not match address family" is
> entirely correct.
Must be because i've never used IPv6... I always forget that thing is
around, too ;-) Your explanation would indeed make a lot more sense than
mine.
> > I don't understand how you think icmp packets could have a SYN flag
> > set though
>
> flags is ignored for non-tcp packets anyway. on rules which can match
> tcp packets, but aren't necessarily tcp only, we alloe flags for quite
> some time.
Hrmm alright...
Re: syntax error - pf parser's bug?
On Wed, Feb 19, 2003 at 09:42:23PM +0100, Wouter Clarie wrote: > I don't understand how you think icmp packets could have a SYN flag set or UDP for that matter. In -current, the rule parses okay as the flags keyword is ignored for UDP/ICMP. beware, flags S won't work come 3.3. - jolan
Re: syntax error - pf parser's bug?
On Wed, Feb 19, 2003 at 09:42:23PM +0100, Wouter Clarie wrote:
> On Wed, 19 Feb 2003, Juan Vera wrote:
> > # pfctl -n -f -
> > pass out quick on xl0 proto { tcp, udp, icmp } from any to any flags S keep state
> > pass out quick on xl0 proto { tcp, udp, icmp } from xl0 to any flags S keep state
> > stdin:3: icmp version does not match address family
> > stdin:3: skipping filter rule due to errors
> > pfctl: Syntax error in file: pf rules not loaded
> The error message is indeed incorrect.
no, it is not.
it is entorely correct.
he has an IPv6 address on xl0, and of course, one of the expanded rules is
address family inet6 with protocol icmp.
and
"icmp version does not match address family"
is entirely correct.
> I don't understand how you think icmp packets could have a SYN flag set
> though
flags is ignored for non-tcp packets anyway.
on rules which can match tcp packets, but aren't necessarily tcp only, we
alloe flags for quite some time.
Re: Syntax error in Snapshot pf.conf
On Wed, Feb 19, 2003 at 09:26:16PM +0100, Cedric Berger wrote: > Hmm, you're right. > And reading from pfvar.h, I believe this should work. > That's a weird setting, though. > We really need to reimplement ($int_if:network) someday. > I wrote a patch for that looong ago. > Cedric Is there any reason to have 10 ways of writing the same thing? Shouldn't we choose a syntax and stick with that? // haver
Re: syntax error - pf parser's bug?
On Wed, 19 Feb 2003, Juan Vera wrote:
> # pfctl -n -f -
> pass out quick on xl0 proto { tcp, udp, icmp } from any to any flags S keep state
> pass out quick on xl0 proto { tcp, udp, icmp } from xl0 to any flags S keep state
> stdin:3: icmp version does not match address family
> stdin:3: skipping filter rule due to errors
> pfctl: Syntax error in file: pf rules not loaded
The error message is indeed incorrect.
I don't understand how you think icmp packets could have a SYN flag set
though, so there's human error in your ruleset too. The "temporary fix"
you suggested is not temporary: that's the way it's supposed to be.
//Wouter
> temporary fix:
>
> # pfctl -n -f -
> pass out quick on xl0 proto { tcp, udp } from xl0 to any flags S keep state
> pass out quick on xl0 proto icmp from any to any keep state
Re: Syntax error in Snapshot pf.conf
I used to use ($int_if)/24 all the time with no problems. With my latest ruleset, I've moved over to $int_if:network because my internal ip isn't likely to change, however I'm another one waiting for ($int_if:network) :) -- Alistair Kerr On Wed, 19 Feb 2003, Henning Brauer wrote: > On Wed, Feb 19, 2003 at 08:41:43PM +0100, Cedric Berger wrote: > > Jason Dixon wrote: > > > > >I just finished upgrading a 3.2 -stable box to yesterday's snapshot to > > >try out the new IP ID feature (where is that documented?). Anyhoo, > > >there was one rule in the pf.conf that was fine in 3.2, but the snapshot > > >is choking on: > > > > > >pass in on $ext_if proto tcp from $other_net to ($int_if)/24 flags S/SA > > >modulate state > > > > > >I assumed it was due to the expansion "($int_if)/24", so I tried with a > > >single IP, and that fixed it. What is the new syntax like for cidr > > >expansion on an interface? I can't find any examples in the manpage. > > > > > $int_if:network probably > > well, of course that works fine, and of course $int_if/24 does too, but > ($int_if)/24 does _not_. > did that EVER work correctly? > off to check pf.c ... > > -- > 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) > > >
syntax error - pf parser's bug?
on 3.2-stable
# pfctl -n -f -
pass out quick on xl0 proto { tcp, udp, icmp } from any to any flags S keep state
pass out quick on xl0 proto { tcp, udp, icmp } from xl0 to any flags S keep state
stdin:3: icmp version does not match address family
stdin:3: skipping filter rule due to errors
pfctl: Syntax error in file: pf rules not loaded
#
temporary fix:
# pfctl -n -f -
pass out quick on xl0 proto { tcp, udp } from xl0 to any flags S keep state
pass out quick on xl0 proto icmp from any to any keep state
#
Re: Syntax error in Snapshot pf.conf
Henning Brauer wrote: $int_if:network probably well, of course that works fine, and of course $int_if/24 does too, but ($int_if)/24 does _not_. did that EVER work correctly? off to check pf.c ... Hmm, you're right. And reading from pfvar.h, I believe this should work. That's a weird setting, though. We really need to reimplement ($int_if:network) someday. I wrote a patch for that looong ago. Cedric
Re: Syntax error in Snapshot pf.conf
On Wed, Feb 19, 2003 at 08:41:43PM +0100, Cedric Berger wrote: > Jason Dixon wrote: > > >I just finished upgrading a 3.2 -stable box to yesterday's snapshot to > >try out the new IP ID feature (where is that documented?). Anyhoo, > >there was one rule in the pf.conf that was fine in 3.2, but the snapshot > >is choking on: > > > >pass in on $ext_if proto tcp from $other_net to ($int_if)/24 flags S/SA > >modulate state > > > >I assumed it was due to the expansion "($int_if)/24", so I tried with a > >single IP, and that fixed it. What is the new syntax like for cidr > >expansion on an interface? I can't find any examples in the manpage. > > > $int_if:network probably well, of course that works fine, and of course $int_if/24 does too, but ($int_if)/24 does _not_. did that EVER work correctly? off to check pf.c ... -- 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: Syntax error in Snapshot pf.conf
Jason Dixon wrote: I just finished upgrading a 3.2 -stable box to yesterday's snapshot to try out the new IP ID feature (where is that documented?). Anyhoo, there was one rule in the pf.conf that was fine in 3.2, but the snapshot is choking on: pass in on $ext_if proto tcp from $other_net to ($int_if)/24 flags S/SA modulate state I assumed it was due to the expansion "($int_if)/24", so I tried with a single IP, and that fixed it. What is the new syntax like for cidr expansion on an interface? I can't find any examples in the manpage. $int_if:network probably Cedric
Syntax error in Snapshot pf.conf
I just finished upgrading a 3.2 -stable box to yesterday's snapshot to try out the new IP ID feature (where is that documented?). Anyhoo, there was one rule in the pf.conf that was fine in 3.2, but the snapshot is choking on: pass in on $ext_if proto tcp from $other_net to ($int_if)/24 flags S/SA modulate state I assumed it was due to the expansion "($int_if)/24", so I tried with a single IP, and that fixed it. What is the new syntax like for cidr expansion on an interface? I can't find any examples in the manpage. TIA, J.
Re: PF gateway performance
Hi All: With some not *too* crappy nic cards i have gotten nearly 90Mb Xfer rates with OpenBSD3.2 WITH pf blocking some traffic. Another thing you might look at is whether your connection is 100BaseTX Full-Duplec. You should be able to do better than 3mb even with RL cards. Marina Brown On Wed, 19 Feb 2003, Daniel Hartmeier wrote: > On Mon, Feb 17, 2003 at 12:20:51PM +0100, Ed White wrote: > > > It was a FTP transfer between .1.10 and .2.10 and got 3 Mbyte/s as max > > transfer rate and the console was not responsive. > > Using a switch (instead of the box) I jumped to 6.5 Mbyte/s. > > Repeat the same test with pf disabled (pfctl -d). I'm almost sure it > won't make any difference, so the bottleneck isn't pf but the nics. > > Daniel > > >
Re: how stupid is this?
Hallo Alejandro G. Belluscio <[EMAIL PROTECTED]> schrieb: > Hello David, > Wednesday, February 19, 2003, 11:29:47 AM, you wrote: > David> DNS sometimes also uses TCP on port 53 for large packets, so you > David> probably want to allow that as well. > I don't think so. DNS uses TCP only for zone transfers. Are you sure about that? In RFC 1035 you can read: -8<- The Internet supports name server access using TCP [RFC-793] on server port 53 (decimal) as well as datagram access using UDP [RFC-768] on UDP port 53 (decimal). ->8- Packets longer then 512 Byte can be truncated or the client ask over TCP, is well explained in: "W. Richard Stevens - TCP/IP Illustrated, Volume 1: The Protocols" I know, that the most of "normal" tcp-trafic ist transported by UDP, and TCP is left for the zone transfers. I also have block 53/tcp on my packetfilter, but just to be exact, DNS also works over TCP. > 2) No software has the security track record of BIND (ok, may be MS, The 2 versions of bind that I have seen in OpenBSD aren't that bad. But for the version we have nerver seen in OpenBSD thats true. best regards Maik
Re: how stupid is this?
On Wed, Feb 19, 2003 at 03:42:52PM +0100, Stefan Sonnenberg-Carstens wrote: > How stupid are YOU !??!?!? > DNS uses tcp/53 for zone transfers regarding slave servers, not big packets WRONG. should a DNS packet exceed 512 bytes, it is cut and sent incomplete with a flag telling the client to requery over tcp. of course this is dog slow, and a good reason to avoid giving out RRsets > 512 bytes. -- 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: how stupid is this?
A DNS query will use UDP by default since it has less overhead. However, the standard limits the size of a UDP query to 512 bytes. If the query is more than 512 bytes, the TC (TrunCation) bit is set in the return query. Typically the resolver will then retry the query using a TCP connection. The firewall wizards list has been discussing this and showing examples. See RFC 1035/Standard 13 and O'reilly's DNS & BIND book. How does humble pie taste? ;-) <> Jim -Original Message- How stupid are YOU !??!?!? DNS uses tcp/53 for zone transfers regarding slave servers, not big packets ! - Original Message - > > matter that I run dns & mail on my firewall. My pf rules are pretty > > standard, a default deny + allow in UDP on port 53 & TCP on 25. > > I also allow in SSH, WWW but only from my work IP address, so that > > shouldn't affect things & POP but only from internal hosts. > > DNS sometimes also uses TCP on port 53 for large packets, so you > probably want to allow that as well. >
Re: how stupid is this?
On Wed, Feb 19, 2003 at 04:02:30PM +0100, Stefan Sonnenberg-Carstens wrote: > >From the RFC : > > 4.2.1. UDP usage > > Messages sent using UDP user server port 53 (decimal). > > Messages carried by UDP are restricted to 512 bytes (not counting the IP > or UDP headers). Longer messages are truncated and the TC bit is set in > the header. > > I'm confused. About what? Nowhere in the quoted text (nor in the RFC) does it say that DNS messages are limited to UDP, even though it is recommended as the primary means of communication. -- Nils Nordman <[EMAIL PROTECTED]>
Re[2]: how stupid is this?
Hello Daniel, Wednesday, February 19, 2003, 11:50:00 AM, you wrote: Daniel> On Wed, Feb 19, 2003 at 03:42:52PM +0100, Stefan Sonnenberg-Carstens wrote: >> How stupid are YOU !??!?!? >> DNS uses tcp/53 for zone transfers regarding slave servers, not big packets >> ! Daniel> Relax, he's right (see RFC1035). DNS uses TCP when the packet size Daniel> exceeds the UDP limit (512 bytes payload). I guess he didn't read the original post's subject ;-) But realistically TCP is used when having huge round robins, huge DNS servers lists, answering with all the zone or, the almost equivalent, doing zone transfers. That's why TinyDNS doesn't use TCP. So it's besides the point to allow it. -- Best regards, Alejandro Belluscio
Re[2]: how stupid is this?
Hello David, Wednesday, February 19, 2003, 11:29:47 AM, you wrote: David> DNS sometimes also uses TCP on port 53 for large packets, so you David> probably want to allow that as well. I don't think so. DNS uses TCP only for zone transfers. But since he'll use dbjdns, which specifically DOESN'T supports either zone transfers or TCP, there's no point in opening that point of failure. Besides, the problem of hsoting your own DNS is that: 1) You get a listed server so you're fair game for script kiddies. 2) No software has the security track record of BIND (ok, may be MS, but let's not get to a MS bashing fest). So it's the number one port for script kiddies to try. Specifically, because they can't know the difference with dbjdns. I have contracted my dns. So I forget about that security problem, and since it's so cheap, and given that the increase in reading logs that causes hosting a DNS, I think it's actually cheaper. I pay like $4 per year for domain. Being cheap let's say that I make than in an hour. Do I save myself more than an hour of dns maintenance plus security aduting plus the eventuality of the time and expenses of having your machine owned? Yeah! Big time! Think about it. In fact it might be cheaper than buing a new sofa :-) -- Best regards, Alejandro Belluscio
Re: how stupid is this?
Hello Dave, Wednesday, February 19, 2003, 6:58:31 AM, you wrote: Dave> Hello, Dave> I run a 3.2-stable server under my sofa at home. It's under there so my Dave> daughter can't pull the wires out! Dave> anyway... Dave> My question is how stupid is it to run DNS(tinydns),Mail(qmail) + my home Dave> firewall/router ( NAT + pf ) on the same machine?? The choice of software is excellent. You can use vpopmail to really ease thet account maintenance problem. I don't like to run DNS off my machine for the reasons I've already posted (it's a hassle and it's more expensive than subcontracting) Dave> I also allow in SSH, WWW but only from my work IP address, so that shouldn't Dave> affect things & POP but only from internal hosts. Do you know how easy is to spoof IPs? I've never used IPs for accepting some connection. For SSH a good password of an RSA signature should be enough. For HTTP, if you use Apache, you can allow only HTTPS and add a clause that needs client autentication through eiter password, x509 certificate or both. Dave> I'm going to be going wireless on my LAN side soon with the same BSD box Dave> being my wireless access point (gonna use IPSEC), as long as my pf rules as Dave> tight should I be o.k? Or am I being dumb & I need to do something like Dave> stick a DMZ machine in for my dns/mail? I don't really like the wireless LAN if you already have the cable. But if you use IPSec you shouldn't have a problem. I've never done it, though. -- Best regards, Alejandro Belluscio
Re: how stupid is this?
>From the RFC : 4.2.1. UDP usage Messages sent using UDP user server port 53 (decimal). Messages carried by UDP are restricted to 512 bytes (not counting the IP or UDP headers). Longer messages are truncated and the TC bit is set in the header. I'm confused. - Original Message - From: "Daniel Hartmeier" <[EMAIL PROTECTED]> To: "Stefan Sonnenberg-Carstens" <[EMAIL PROTECTED]> Cc: "David Krause" <[EMAIL PROTECTED]>; "Dave Rocks" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Wednesday, February 19, 2003 3:50 PM Subject: Re: how stupid is this? > On Wed, Feb 19, 2003 at 03:42:52PM +0100, Stefan Sonnenberg-Carstens wrote: > > > How stupid are YOU !??!?!? > > DNS uses tcp/53 for zone transfers regarding slave servers, not big packets > > ! > > Relax, he's right (see RFC1035). DNS uses TCP when the packet size > exceeds the UDP limit (512 bytes payload). > > Daniel > > >
Re: how stupid is this?
Sorry, folks. some hotshot. This has never happend ... - Original Message - From: "Daniel Hartmeier" <[EMAIL PROTECTED]> To: "Stefan Sonnenberg-Carstens" <[EMAIL PROTECTED]> Cc: "David Krause" <[EMAIL PROTECTED]>; "Dave Rocks" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Wednesday, February 19, 2003 3:50 PM Subject: Re: how stupid is this? > On Wed, Feb 19, 2003 at 03:42:52PM +0100, Stefan Sonnenberg-Carstens wrote: > > > How stupid are YOU !??!?!? > > DNS uses tcp/53 for zone transfers regarding slave servers, not big packets > > ! > > Relax, he's right (see RFC1035). DNS uses TCP when the packet size > exceeds the UDP limit (512 bytes payload). > > Daniel > >
Re: how stupid is this?
On Wed, Feb 19, 2003 at 03:42:52PM +0100, Stefan Sonnenberg-Carstens wrote: > How stupid are YOU !??!?!? you are the stupid here and stop barking like a wild dog. check the facts. david is right. > DNS uses tcp/53 for zone transfers regarding slave servers, not big packets hint: never wondered why there are 13 fscking root servers there and not more? now go get yourself a behavior. I heard eBay are selling some at good prices this year. (sorry henning, blood pressure is jumping to unknown heights.) -- Saad Kadhi -- [[EMAIL PROTECTED]] [[EMAIL PROTECTED]] [pgp keyid: 35592A6D http://pgp.mit.edu] [pgp fingerprint: BF7D D73E 1FCF 4B4F AF63 65EB 34F1 DBBF 3559 2A6D] ---
Re: how stupid is this?
On Wed, 19 Feb 2003, Stefan Sonnenberg-Carstens wrote: > How stupid are YOU !??!?!? No need to insult people. The original poster choice the subject, not David. > DNS uses tcp/53 for zone transfers regarding slave servers, not big packets > ! You don't consider zone transfer large packets? > - Original Message - > From: "David Krause" <[EMAIL PROTECTED]> > To: "Dave Rocks" <[EMAIL PROTECTED]> > Cc: <[EMAIL PROTECTED]> > Sent: Wednesday, February 19, 2003 3:29 PM > Subject: Re: how stupid is this? > > > > * Dave Rocks <[EMAIL PROTECTED]> [030219 04:09]: > > > matter that I run dns & mail on my firewall. My pf rules are pretty > > > standard, a default deny + allow in UDP on port 53 & TCP on 25. > > > I also allow in SSH, WWW but only from my work IP address, so that > > > shouldn't affect things & POP but only from internal hosts. > > > > DNS sometimes also uses TCP on port 53 for large packets, so you > > probably want to allow that as well. > > > > David Cheers, Dries -- Dries Schellekens email: [EMAIL PROTECTED]
RE: PF gateway performance
It's the Nics. We use a transparent bridge and use two 3Com 3C905c nics and get a sustained 70Mbps across the bridge using a P2-350 and 128MB of Ram. 10.0.0.12(some client) --> xl1 [PF] xl0 < 10.0.0.1 (Router) I know people to run OpenBSD as CableModem Routers/Firewalls on as low as 486DX100's and Pentium 100's and have gotten sustained 20Mbps (and sometimes higher if the person they are they are off the same Cable Loop). Spend the extra $$$ and buy yourself two 3Com or Netgear Nics (Used as example since the driver in already present for them in the 3.2 build) --David Chubb -Original Message- From: Stefan Sonnenberg-Carstens [mailto:[EMAIL PROTECTED]] Sent: Wednesday, February 19, 2003 9:13 AM To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: PF gateway performance If you'd like to know, where the limiting factor is, set up a bridge with rl0 and rl1 attached to it. If the performance is better, the CPU is limiting. But it seems obvious to me, that the NICs are the problem, as Daniel states. - Original Message - From: "Ed White" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Monday, February 17, 2003 12:20 PM Subject: PF gateway performance > Hi, > > I would like to know some results from ml readers. > I tested OpenBSD 3.2-stable with with setup: > > CPU Pentium 133 > RAM 96 Mb > 2 x Realtek (rl0 & rl1) [yes, I know there's better hardware...] > > rl0 = 10.0.1.1 > rl1 = 10.0.2.1 > > IP forwarding enabled > > pf.conf > pass in quick all > pass out quick all > - > > The test: > > 10.0.1.10 ---> 10.0.1.1 [PF] 10.0.2.1 ---> 10.0.2.10 > > It was a FTP transfer between .1.10 and .2.10 and got 3 Mbyte/s as max > transfer rate and the console was not responsive. > Using a switch (instead of the box) I jumped to 6.5 Mbyte/s. > > Is there anyone who could try the same test with similar CPUs ? > For example, will PF get a boost from MMX registers ? > > Thanks. > > > Ed > > > > > >
Re: how stupid is this?
On Wed, Feb 19, 2003 at 03:42:52PM +0100, Stefan Sonnenberg-Carstens wrote: > How stupid are YOU !??!?!? > DNS uses tcp/53 for zone transfers regarding slave servers, not big packets > ! Relax, he's right (see RFC1035). DNS uses TCP when the packet size exceeds the UDP limit (512 bytes payload). Daniel
Re: how stupid is this?
How stupid are YOU !??!?!? DNS uses tcp/53 for zone transfers regarding slave servers, not big packets ! - Original Message - From: "David Krause" <[EMAIL PROTECTED]> To: "Dave Rocks" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Wednesday, February 19, 2003 3:29 PM Subject: Re: how stupid is this? > * Dave Rocks <[EMAIL PROTECTED]> [030219 04:09]: > > matter that I run dns & mail on my firewall. My pf rules are pretty > > standard, a default deny + allow in UDP on port 53 & TCP on 25. > > I also allow in SSH, WWW but only from my work IP address, so that > > shouldn't affect things & POP but only from internal hosts. > > DNS sometimes also uses TCP on port 53 for large packets, so you > probably want to allow that as well. > > David > > >
Re: how stupid is this?
* Dave Rocks <[EMAIL PROTECTED]> [030219 04:09]: > matter that I run dns & mail on my firewall. My pf rules are pretty > standard, a default deny + allow in UDP on port 53 & TCP on 25. > I also allow in SSH, WWW but only from my work IP address, so that > shouldn't affect things & POP but only from internal hosts. DNS sometimes also uses TCP on port 53 for large packets, so you probably want to allow that as well. David
Re: PF gateway performance
If you'd like to know, where the limiting factor is, set up a bridge with rl0 and rl1 attached to it. If the performance is better, the CPU is limiting. But it seems obvious to me, that the NICs are the problem, as Daniel states. - Original Message - From: "Ed White" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Monday, February 17, 2003 12:20 PM Subject: PF gateway performance > Hi, > > I would like to know some results from ml readers. > I tested OpenBSD 3.2-stable with with setup: > > CPU Pentium 133 > RAM 96 Mb > 2 x Realtek (rl0 & rl1) [yes, I know there's better hardware...] > > rl0 = 10.0.1.1 > rl1 = 10.0.2.1 > > IP forwarding enabled > > pf.conf > pass in quick all > pass out quick all > - > > The test: > > 10.0.1.10 ---> 10.0.1.1 [PF] 10.0.2.1 ---> 10.0.2.10 > > It was a FTP transfer between .1.10 and .2.10 and got 3 Mbyte/s as max > transfer rate and the console was not responsive. > Using a switch (instead of the box) I jumped to 6.5 Mbyte/s. > > Is there anyone who could try the same test with similar CPUs ? > For example, will PF get a boost from MMX registers ? > > Thanks. > > > Ed > > > > > >
Re: PF gateway performance
On Mon, Feb 17, 2003 at 12:20:51PM +0100, Ed White wrote: > It was a FTP transfer between .1.10 and .2.10 and got 3 Mbyte/s as max > transfer rate and the console was not responsive. > Using a switch (instead of the box) I jumped to 6.5 Mbyte/s. Repeat the same test with pf disabled (pfctl -d). I'm almost sure it won't make any difference, so the bottleneck isn't pf but the nics. Daniel
PF gateway performance
Hi, I would like to know some results from ml readers. I tested OpenBSD 3.2-stable with with setup: CPU Pentium 133 RAM 96 Mb 2 x Realtek (rl0 & rl1) [yes, I know there's better hardware...] rl0 = 10.0.1.1 rl1 = 10.0.2.1 IP forwarding enabled pf.conf pass in quick all pass out quick all - The test: 10.0.1.10 ---> 10.0.1.1 [PF] 10.0.2.1 ---> 10.0.2.10 It was a FTP transfer between .1.10 and .2.10 and got 3 Mbyte/s as max transfer rate and the console was not responsive. Using a switch (instead of the box) I jumped to 6.5 Mbyte/s. Is there anyone who could try the same test with similar CPUs ? For example, will PF get a boost from MMX registers ? Thanks. Ed
Re: how stupid is this?
On Wed, Feb 19, 2003 at 09:58:31AM +, Dave Rocks wrote: > My question is how stupid is it to run DNS(tinydns),Mail(qmail) + my home > firewall/router ( NAT + pf ) on the same machine?? > I always read NEVER run anything extra on your firewall. For my small home > set-up ( i get maybe 20 emails a day & 50 dns requests ) does it really > matter that I run dns & mail on my firewall. My pf rules are pretty > standard, a default deny + allow in UDP on port 53 & TCP on 25. > I also allow in SSH, WWW but only from my work IP address, so that > shouldn't affect things & POP but only from internal hosts. > I'm going to be going wireless on my LAN side soon with the same BSD box > being my wireless access point (gonna use IPSEC), as long as my pf rules as > tight should I be o.k? Or am I being dumb & I need to do something like > stick a DMZ machine in for my dns/mail? if you can afford an extra box and extra space under the sofa to stow it under, then this is the way to go. otherwise, you must answer a question: how sensitive is the information transiting thru your firewall? what are the estimated costs of it being uncovered/leaked? what are the impacts to your image if your firewall got cracked? well, I think you'll have to answer it anyways. rampant paranoia is never very far. but let me tell you this: if the information you have is damn precious, no matter what you do to protect it, it might just rise the skills/money required to get it. if you are like john nobody, get a drink and happily configure your firewall with the above-mentioned software using as secure a configuration as possible and opt for secure options (SSH-tunneled POP instead of clear POP from outside if ever needed, etc. you get the picture). the idea of using IPsec on your wireless lan is good. IMHO, it's the best option today (WEP is...well...you know and 802.1x has already shown some cracks). I even met some french so-called consultants that went to the extent of using SSH-tunneled protocols inside of IPsec using 2048 bits keys etc. hum. and if that helps, I ran my home firewall for ages with dns, email and other services (from the internal network). has it got cracked? none that I know of since I closely monitor my logs on a daily basis and I run integrity checking software (aide. still using it. but I'm in the move to samhain though the docs are overwhelming *cough*). but since last year, I afforded an extra sofa and an extra dmz box 8~). [1]. cheers. -- [1] fips, if you come this way again you will never have to hear humming machines(tm) anymore. -- Saad Kadhi -- [[EMAIL PROTECTED]] [[EMAIL PROTECTED]] [pgp keyid: 35592A6D http://pgp.mit.edu] [pgp fingerprint: BF7D D73E 1FCF 4B4F AF63 65EB 34F1 DBBF 3559 2A6D] ---
Re: how stupid is this?
On Wed, Feb 19, 2003 at 09:58:31AM +, Dave Rocks wrote: > My question is how stupid is it to run DNS(tinydns),Mail(qmail) + my home > firewall/router ( NAT + pf ) on the same machine?? I don't see anything wrong with this for home setups.
how stupid is this?
Hello, I run a 3.2-stable server under my sofa at home. It's under there so my daughter can't pull the wires out! anyway... My question is how stupid is it to run DNS(tinydns),Mail(qmail) + my home firewall/router ( NAT + pf ) on the same machine?? I always read NEVER run anything extra on your firewall. For my small home set-up ( i get maybe 20 emails a day & 50 dns requests ) does it really matter that I run dns & mail on my firewall. My pf rules are pretty standard, a default deny + allow in UDP on port 53 & TCP on 25. I also allow in SSH, WWW but only from my work IP address, so that shouldn't affect things & POP but only from internal hosts. I'm going to be going wireless on my LAN side soon with the same BSD box being my wireless access point (gonna use IPSEC), as long as my pf rules as tight should I be o.k? Or am I being dumb & I need to do something like stick a DMZ machine in for my dns/mail? Cheers for reading. Dave _ Worried what your kids see online? Protect them better with MSN 8 http://join.msn.com/?page=features/parental&pgmarket=en-gb&XAPID=186&DI=1059
