Re: Accounting per host status.
Gustavo Chamone wrote: > Folks, > since I couldn't find anything related to this on the archive, I'm hoping > that you guys can help me out. > > Last may, Hartmeier sent an e-mail with the Hackathon Summary[1]. He > mentioned that there was some work in progress on accounting per host, being > made by Ryan McBride. Does anyone know the status of this feature? > > If this feature already went into -current, I'll be glad to test it. You can use pfflowd[1] to get NetFlow statistics. These are per-state, rather than per-host so you would need to summarise them. I have a sample NetFlow collector[2] (written in perl) which you could hack to do this too. I really should make a port of pfflowd... -d [1] http://www.mindrot.org/pfflowd.html [2] http://www.mindrot.org/files/pfflowd/collector.pl
Looks like we've got a live one....
You'd better be blocking MS RPC PDQ! Oh, and expect a flood of downloads from ftp.openbsd.org once people figure Microsoft's definition of "Trusted Computing" :-) Dom - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Dom De Vitto Tel. 07855 805 271 http://www.devitto.com mailto:[EMAIL PROTECTED] - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Implementing a 'scrub tos' option?
Hi! Living on a DSL link is hard when it comes to ALTQ configuration on the upstream side. If you are able to configure both sides of a link policy based routing is no problem (i.e. prioritizing ACKs or icmp/udp/Diablo 2 :)). In my (and prob. this is the most common setup) I cannot (legally) take control of the upstream router and its queueing policies. As a result when my downstream is busy ACKs, icmp errors, nameserver queries et al. are treated like normal bulk data packets and not prioritized. When setting TOS fields on outgoing packets the same bits are set in the answer thus allowing basic priorization for incoming packets on the upstream router: $ nemesis icmp -qE -S 10.10.1.2 -D 195.244.235.251 15:48:25.783347 10.10.1.2 > 195.244.235.251: icmp: echo request (ttl 255, id 42131, len 28) 15:48:25.852952 195.244.235.251 > 10.10.1.2: icmp: echo reply (ttl 245, id 2534, len 28) $ nemesis icmp -qE -S 10.10.1.2 -D 195.244.235.251 -t 0x10 15:48:27.033848 10.10.1.2 > 195.244.235.251: icmp: echo request [tos 0x10] (ttl 255, id 16345, len 28) 15:48:27.168675 195.244.235.251 > 10.10.1.2: icmp: echo reply [tos 0x10] (ttl 245, id 33430, len 28) Since the line is not completly busy as of now there are no noticible round trip time differences in this example beside the set tos fields. I'd like to implement a 'scrub' option which basicly works like this: scrub out on $ext_if proto udp from $internal to $nameservers port 53 keep state tos 0x10 There are many other ways of using this option but the example should give you a brief overview of my intention. I talked to Henning since I didn't know if there were any issues since this has not been implemented as of now but could not remember any reasons. Even now when ECN et al. are coming up this feature looks interesting to me. Looking at the source (I'm somewhat familiar with the pf FreeBSD port) inserting the appropriate option right after the random IP ID setting in pf_norm.c seems to be easy. Before starting setting up an OpenBSD box I'd like to know if there are any caveats/reasons since this has not been done already. Thanks, Hendrik -- Hendrik Scholz - <[EMAIL PROTECTED]> - http://raisdorf.net/ drag me, drop me - treat me like an object
Re: Ruleset Rdr Problem
On Monday, Aug 11, 2003, at 18:35 US/Pacific, Scott Sipe wrote:
OpenBSD pf firewall for small network, adsl in, doing nat. I want to
rdr certain ports on the firewall to an internal server. My rdr and
pass lines work fine for some services (http [80], rsync [873], etc)
but two services DON'T work--MS RDP (Remote Desktop) which runs on
port 3389 on the windows boxes. I'm rdring ports 4001 and 4002 to two
different computers. This works if I take out the line "block all"
and doesn't work when I do "block all"--http and rsync work > regardless.
tcp_in = "{ 22, 80, 873, 4001, 4002 }"
rdr on $ext_if proto tcp from any to any port 4001 -> $comp1 port 3389
rdr on $ext_if proto tcp from any to any port 4002 -> $comp2 port 3389
pass in quick on $ext_if inet proto tcp from any to any port $tcp_in
flags S/SA modulate state
Keep in mind the filter rules are applied _after_ translation, which
affects the port numbers. $tcp_in should include 3389 instead of 4001
and 4002.
Re: Implementing a 'scrub tos' option?
On Mon, Aug 11, 2003 at 04:01:38PM +0200, Hendrik Scholz wrote: > Before starting setting up an OpenBSD box I'd like to know if there > are any caveats/reasons since this has not been done already. I guess the question is: does a significant share of internet routers honour the flag? What effect do IPTOS_LOWDELAY, _THROUGHPUT and _RELIABILITY (you can only set one of them) have, today, over the Internet? I've heard stories that most devices will just plain ignore all flags. Can someone with real-life experience comment on this? I do understand what the purpose of the flags was, from the RFC. But how effective is their use in real life? Daniel
Re: Implementing a 'scrub tos' option?
Ed White wrote: >> > pass in quick inet proto tcp from $My_ISP_class_B to $eth_ext port 22 tos >> > $key keep state >> >> This is the worst kind of security through obscurity. > > That's not security at all. My point exactly. > That's custom setup, like using sshd on port 31337. And equally stupid. > Where's gone power of choice ? pf has never given you freedom of choice. E.g. where is the option to filter by data[offset]? This lack of choice is a good thing, not a bad thing as people seem infatuated by stupid choices. OTOH a "pass set-tos xxx" option (what this discussion was originally about) would be nice... -d
Re: Implementing a 'scrub tos' option?
On Tue, Aug 12, 2003 at 10:09:01PM +1000, Damien Miller wrote: > OTOH a "pass set-tos xxx" option (what this discussion was originally > about) would be nice... there are various people now asking for a possibility to set the tos. I tend to think it makes sense. not sure about the syntax tho. -- 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)
PF logging as in the FAQ not working
Hello. Just got an OpenBSD 3.3 machine running as the firewall for a small network - I've just started using OpenBSD recently so I'm sure it a rookie mistake. I've been trying to get the packet logging set up as in the faq but I can't get the file pflog.txt to be created. I've read this post and checked everything that I can think of:http://www.benzedrine.cx/pf/msg01009.html I've tried running the scripts as root and I get no errors but the file pflog.txt is never created, even when I can see that there is information in the pflog file. I created the pflogger user as in the FAQ but left the password blank to prevent logon. Could that be causing the problem? I've configured syslog.conf as follows and restarted it as in the FAQ # $OpenBSD: syslog.conf,v 1.12 2001/08/23 13:27:52 camield Exp $ # *.err;kern.debug;auth.notice;authpriv.none;mail.crit/dev/console *.notice;auth,authpriv,cron,ftp,kern,lpr,mail,user.none /var/log/messages kern.debug,user.info,syslog.info/var/log/messages auth.info /var/log/authlog authpriv.debug /var/log/secure cron.info /var/cron/log daemon.info /var/log/daemon ftp.info/var/log/xferlog lpr.debug /var/log/lpd-errs mail.info /var/log/maillog #uucp.info /var/log/uucp local0.info /var/log/pflog.txt local0.info @syslogger *.err root *.notice;auth.debug root *.alert root *.emerg * # Uncomment to log to a central host named "loghost". You need to run # syslogd with the -u option on the remote host if you are using this. # (This is also required to log info from things like routers and # ISDN-equipment). If you run -u, you are vulnerable to syslog bombing, # and should consider blocking external syslog packets #*.notice;auth,authpriv,cron,ftp,kern,lpr,mail,user.none@loghost #kern.debug,user.info,syslog.info @loghost #auth.info,authpriv.debug,daemon.info @loghost # Uncomment to log messages from sudo(8) and chat(8) to their own # respective log files. Matches are done based on the program name # Program-specific logs: #!sudo #*.*/var/log/sudo #!chat #*.*/var/log/chat My /etc/pflogrotate is as follows: FILE=/home/pflogger/pflog5min.$(date "+%Y%m%d%H%M") kill -ALRM $(cat /var/run/pflogd.pid) if [ $(ls -l /var/log/pflog | cut -d " " -f 8) -gt 24 ]; then mv /var/log/pflog $FILE chown pflogger $FILE kill -HUP $(cat /var/run/pflogd.pid) fi and the permission are: -rwxr--r-- 1 root wheel 241 Aug 13 09:23 /etc/pflogrotate The /home/pflogger/pfl2sysl is as follows: for logfile in /home/pflogger/pflog5min* ; do tcpdump -n -e -ttt -r $logfile | logger -t pf -p local0.info rm $logfile done and the permission are as follows: -rwxr--r-- 1 pflogger pflogger 128 Aug 13 09:40 /home/pflogger/pfl2sysl Is there something I've missed or done incorrectly? Is there something else to check? Scott Plumlee PGP Public key: http://plumlee.org/pgp/ D64C 47D9 B855 5829 D22A D390 F8E2 9B58 9CBF 1F8D
Re: FTP Chroot not working
This question is really not appropriate for a packet filter mailing list. Please post this to [EMAIL PROTECTED] //Wouter On Wed, 13 Aug 2003, Justin Houchin wrote: > Hi Everyone, > I have been trying for the past couple of days to get FTP chroot > working on my 3.3 machine. I have added the user name to /etc/ftpchroot. > Started the ftp server with ftpd -D. I can log into the ftp server and > get to the root directory. It is not restricting the user in the > /etc/ftpchroot file to there home directory. Any ideas?
pf and bridge question
Hi, I have an OpenBSD 3.3 firewall which acts as a transparent bridge between our network (not NATted) and a router giving access to the rest of the world. The bridging interfaces are configured without IP address and a third (management) NIC is configured with an IP address inside our network's address space. A colleague of mine claims that this can lead to confusion in the routing/bridging code of the firewall and possible corruption of the arp table. He says that the management interface should never be in the same logical or physical network as one of the two sides of the bridge, i.e. it should have an address in rfc1918 space and be physically connected to different networking hardware. I have difficulty in understanding how this could be true and he cannot give me an explanation other than that he has had trouble with this in the past (running older versions of OpenBSD 3.2 with ipf). Can someone here enlighten me as to whether this is really a possible problem and if so how exactly some sort of corruption/glitch could happen? Thanks a lot, Marc P.S. Naturally I am aware of the fact that having the management interface on a separate NATted network with it's own protection is a good thing security-wise, so that's not really my question.
Ruleset Rdr Problem
I apologize in advance if this is a stupid question :)
OpenBSD pf firewall for small network, adsl in, doing nat. I want to
rdr certain ports on the firewall to an internal server. My rdr and
pass lines work fine for some services (http [80], rsync [873], etc) but
two services DON'T work--MS RDP (Remote Desktop) which runs on port 3389
on the windows boxes. I'm rdring ports 4001 and 4002 to two different
computers. This works if I take out the line "block all" and doesn't
work when I do "block all"--http and rsync work regardless.
Hope I'm not doing something TOO newbish.
thanks,
Scott Sipe
p.s. pf is godly, thanks so much for the great piece of software! :)
my pf.conf ###
ext_if="fxp1"
int_if="fxp0"
priv_nets = "{ 127.0.0.0/8, 192.168.0.0/16, 172.16.0.0/12, 10.0.0.0/8 }"
tcp_in = "{ 22, 80, 873, 4001, 4002 }"
icmp_types = "echoreq"
set block-policy return
set loginterface $ext_if
scrub in all
#altq on $ext_if priq bandwidth 360Kb queue { q_pri, q_def }
#queue q_pri priority 7
#queue q_def priority 1 priq(default)
nat on $ext_if from $int_if:network to any -> ($ext_if)
# These are actual IP addresses in the real version
#
rdr on $ext_if proto tcp from any to any port 80 -> $server port 80
rdr on $ext_if proto tcp from any to any port 4001 -> $comp1 port 3389
rdr on $ext_if proto tcp from any to any port 4002 -> $comp2 port 3389
# rdr outgoing FTP requests to the ftp-proxy
rdr on $int_if proto tcp from any to any port ftp -> 127.0.0.1 port 8021
# With the following line commented everything works--with it
# uncommented, ports 80,873 work, but no 4001,4002
#block all
pass quick on lo0 all
block drop in quick on $ext_if from $priv_nets to any
block drop out quick on $ext_if from any to $priv_nets
pass in quick on $ext_if inet proto tcp from any to any port $tcp_in
flags S/SA modulate state
pass out quick on $ext_if inet proto tcp from any to any flags S/SA
modulate state
pass out quick on $ext_if inet proto udp all keep state
pass out quick on $ext_if inet proto icmp from any to any keep state
pass in inet proto icmp all icmp-type $icmp_types keep state
#
# Deal with inside traffic
#
pass in on $int_if from $int_if:network to any keep state
pass out on $int_if from any to $int_if:network keep state
Re: Implementing a 'scrub tos' option?
On Wed, Aug 13, 2003 at 01:43:18PM +0200, Hendrik Scholz wrote: > Hi! > > On Wed, 13 Aug 2003 12:01:16 +0200 > Henning Brauer <[EMAIL PROTECTED]> wrote: > > > there are various people now asking for a possibility to set the tos. > > I tend to think it makes sense. > > not sure about the syntax tho. > > From my point of view it fits into the scrub scheme. > Adding it to each rule (like flags, keep state, ...) would just > pollute the rules. > Same is true for the no-df, min-ttl, random-id, max-mss, ... options. > > From my point of view setting TOS values should be independent of > actual rules. Imagine the following set of rules: > > pass out quick on $ext_if proto icmp from $internal to any keep state > pass in quick on $ext_if proto icmp all keep state > > You'd have to add the tos statement to both rules in case you want > the replies to incoming icmp echo request packets to be passed out > with a tos flag set. > > OTOH > > scrub out on $ext_if proto udp from any to $nameservers tos lowdelay > > would be the way I'd implement it. eh, that needs to be set-tos or the like I think - to confusing with tos-based filtering on rules.
Re: Implementing a 'scrub tos' option?
Hi! On Mon, 11 Aug 2003 17:06:30 +0200 Daniel Hartmeier <[EMAIL PROTECTED]> wrote: > On Mon, Aug 11, 2003 at 04:01:38PM +0200, Hendrik Scholz wrote: > > > Before starting setting up an OpenBSD box I'd like to know if there > > are any caveats/reasons since this has not been done already. > > I guess the question is: does a significant share of internet routers > honour the flag? What effect do IPTOS_LOWDELAY, _THROUGHPUT and > _RELIABILITY (you can only set one of them) have, today, over the > Internet? I've heard stories that most devices will just plain ignore > all flags. Can someone with real-life experience comment on this? I do > understand what the purpose of the flags was, from the RFC. But how > effective is their use in real life? >From my point of view most devices can simply ignore these flags since the only box which has to actually analyse these bits is the upstream router itself. All other systems on the way should have more bandwidth. Routes from/to the nameserver and bulk transfer sources will be different in most applications so the lack of TOS support on these systems and the intermediate routers should not affect the overall performance if the final router (where all packets from all connections are gathered) supports TOS. As you can see I'm quite optimistic about this but will do some tests using the Cisco equipment I can get my hands on. Thanks for the comments, Hendrik -- Hendrik Scholz - <[EMAIL PROTECTED]> - http://raisdorf.net/ drag me, drop me - treat me like an object
Re: relaydb question..
On Tue, Aug 12, 2003 at 01:50:43PM -0700, Meenal C wrote: >I have implemented Daniel's solutions (pf+relaydb on OpenBSD) and it works great! > I have a question though... Why does relaydb ignore addresses inside of round > brackets ? It seems to be adding only addresses within []. > Some emails do not even have a single address within []. > (who adds the addresses in [] anyways, I am using qmail as my MTA, does it matter at > all ? Is there a config setting somewhere ?) sendmail uses []. Andrey Smagin has extended relaydb to recognize (), among other added features, see http://smagin.com/relaydbp/ I didn't find time to merge back his changes, maybe the port will eventually just use his sources instead. Daniel
E1 X.21 Serial Interface
Hi All, I apologise if this is off topic for the list, but I am sure someone here must be doing this. I am running the standard distro of OpenBSD 3.2 on our firewall. We currently have an SDSL connection which has an Ethernet interface. We would like to change ISPs and have been told we need to purchase an expensive CISCO router. Is there any way I can directly connect my OBSD box to an ATM over E1/X.21 service (they tell me it is a DB25 connector, but I presume a PC serial port would not be an appropriate choice :). Thanks, Craig Bennett
RE: pf and bridge question
As long as you separate the rulesets for the bridged config and the management nic, I don't see how it could happen unless the pf code is not meant to handle this, I am running the same config roughly and it works damn good, in fact too good when I first configed it. Also I would like to point out that you stated he had trouble (OpenBSD 3.2 with ipf) with IPF. IPF and PF are 2 totally different animals. IPF may have a bug but unless Daniel or Henning or eh I forget, know of a bug using this configuration, then it should work as I have seen it. 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 Marc Beyer Sent: Wednesday, August 13, 2003 3:18 PM To: [EMAIL PROTECTED] Subject: pf and bridge question Hi, I have an OpenBSD 3.3 firewall which acts as a transparent bridge between our network (not NATted) and a router giving access to the rest of the world. The bridging interfaces are configured without IP address and a third (management) NIC is configured with an IP address inside our network's address space. A colleague of mine claims that this can lead to confusion in the routing/bridging code of the firewall and possible corruption of the arp table. He says that the management interface should never be in the same logical or physical network as one of the two sides of the bridge, i.e. it should have an address in rfc1918 space and be physically connected to different networking hardware. I have difficulty in understanding how this could be true and he cannot give me an explanation other than that he has had trouble with this in the past (running older versions of OpenBSD 3.2 with ipf). Can someone here enlighten me as to whether this is really a possible problem and if so how exactly some sort of corruption/glitch could happen? Thanks a lot, Marc P.S. Naturally I am aware of the fact that having the management interface on a separate NATted network with it's own protection is a good thing security-wise, so that's not really my question.
Re: DIOCCHANGEADDR in 3.3-stable
Ok, here's the fix and the example.
Index: pf_ioctl.c
===
RCS file: /cvs/src/sys/net/pf_ioctl.c,v
retrieving revision 1.78
diff -u -r1.78 pf_ioctl.c
--- pf_ioctl.c 9 Aug 2003 14:56:48 - 1.78
+++ pf_ioctl.c 11 Aug 2003 20:10:55 -
@@ -1750,7 +1750,7 @@
error = EBUSY;
break;
}
- pool = pf_get_pool(pca->anchor, pca->ruleset, 0,
+ pool = pf_get_pool(pca->anchor, pca->ruleset, pca->ticket,
pca->r_action, pca->r_num, pca->r_last, 1, 1);
if (pool == NULL) {
error = EBUSY;
Assuming you have a rule
@3 rdr on gem0 inet proto tcp from 1.2.3.4 to 5.6.7.8 port = 1234 \
-> { 10.1.1.1, 10.2.2.2 } port 2345 round-robin
this example will add a third address to the pool, resulting in
@3 rdr on gem0 inet proto tcp from 1.2.3.4 to 5.6.7.8 port = 1234 \
-> { 10.3.3.3/16, 10.1.1.1, 10.2.2.2 } port 2345 round-robin
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
int
main(int argc, char *argv[])
{
int dev;
struct pfioc_rule pr;
struct pfioc_pooladdr pa;
if ((dev = open("/dev/pf", O_RDWR)) == -1) {
perror("open");
goto error;
}
memset(&pr, 0, sizeof(pr));
pr.action = PF_CHANGE_GET_TICKET;
pr.rule.action = PF_RDR;
if (ioctl(dev, DIOCCHANGERULE, &pr)) {
perror("ioctl DIOCCHANGERULE");
goto error;
}
memset(&pa, 0, sizeof(pa));
pa.action = PF_CHANGE_ADD_HEAD;
pa.ticket = pr.ticket;
pa.r_action = PF_RDR;
pa.r_num = 3;
pa.r_last = 0;
pa.af = AF_INET;
pa.addr.addr.type = PF_ADDR_ADDRMASK;
pa.addr.addr.v.a.addr.v4.s_addr = inet_addr("10.3.3.3");
pa.addr.addr.v.a.mask.v4.s_addr = inet_addr("255.255.0.0");
if (ioctl(dev, DIOCCHANGEADDR, &pa)) {
perror("ioctl DIOCCHANGEADDR");
goto error;
}
close(dev);
return (0);
error:
if (dev != -1)
close(dev);
return (1);
}
Daniel
Re: Ruleset Rdr Problem
On Mon, Aug 11, 2003 at 06:56:23PM -0700, Trevor Talbot wrote: > > Keep in mind the filter rules are applied _after_ translation, which > affects the port numbers. $tcp_in should include 3389 instead of 4001 > and 4002. > also keep in mind that you'll forget that fact about 700 times. you might find it helpful to add logging to your block rules -- at least while you're testing things. here's a helpful script to watch what's being logged on pflog0 : = #!/bin/sh sudo tcpdump -n -e -ttt -r /var/log/pflog $* | tail -80 sudo tcpdump -n -e -ttt -i pflog0 $* = you could, for instance, in light of today's circus of fun, do: ( i've named it pfwatch.sh ) $ pfwatch.sh tcp and dst port 135 to see all the fun ppl who are having a bitch of a time running windows update . jared. -- [ openbsd 3.3 current/GENERIC ( aug 10 ) // i386 ]
Re: Implementing a 'scrub tos' option?
Hi! On Wed, 13 Aug 2003 12:01:16 +0200 Henning Brauer <[EMAIL PROTECTED]> wrote: > there are various people now asking for a possibility to set the tos. > I tend to think it makes sense. > not sure about the syntax tho. >From my point of view it fits into the scrub scheme. Adding it to each rule (like flags, keep state, ...) would just pollute the rules. Same is true for the no-df, min-ttl, random-id, max-mss, ... options. >From my point of view setting TOS values should be independent of actual rules. Imagine the following set of rules: pass out quick on $ext_if proto icmp from $internal to any keep state pass in quick on $ext_if proto icmp all keep state You'd have to add the tos statement to both rules in case you want the replies to incoming icmp echo request packets to be passed out with a tos flag set. OTOH scrub out on $ext_if proto udp from any to $nameservers tos lowdelay would be the way I'd implement it. Hendrik -- Hendrik Scholz - <[EMAIL PROTECTED]> - http://raisdorf.net/ drag me, drop me - treat me like an object
Re: Implementing a 'scrub tos' option?
Hi! On Wed, 13 Aug 2003 14:51:35 +0200 Daniel Hartmeier <[EMAIL PROTECTED]> wrote: > Yes. Basic question is: do you want to set the same tos on all packets > of one connection (state entry) automatically? > > Or is setting tos completely unrelated to connections, and you want to > do it per packet (no matter what connection the packet might be part > of). Having a look at it from the application view (outgoing tcp connection, error generated on the remote side or icmp echo req/reply) we have to set the bit for each connection so the connection oriented/rule based approach makes more sense to me (in contrast to what I though might be useful in the previous mails :)) (perfect world[*]) example: 1) scrub out on $ext_if proto icmp all tos lowdelay vs. 2) pass out quick on $ext_if proto tcp from any to any port 22 \ flags S/SA keep state tos lowdelay pass out quick on $ext_if proto icmp all keep state tos lowdelay The first would allow ping replies to be prioritized and send back fast. But it does not care about icmp unreachables created somewhere on the way to the remote end. 2) When running an ssh session the TOS bit would be set on all packets and hopefully (check Stevens) the TOS bit will be set in an icmp packet generated on the way or the destination itself. I'll set up a box tonight and just start writing some code so I can actually check wether it makes sense to use tos bits at all. Hendrik *) in a world where every router needed honors tos bits -- Hendrik Scholz - <[EMAIL PROTECTED]> - http://raisdorf.net/ drag me, drop me - treat me like an object
Re: PF logging as in the FAQ not working
On Wed, 2003-08-13 at 12:08, [EMAIL PROTECTED] wrote: > Hello. Tried that and still no luck. Even did chown and chgrp to pflogger > and nothing. a) Please stop top-posting. b) Whenever you create a new file for a daemon like syslog to write to, you need to restart that daemon. kill -HUP `cat /var/run/syslog.pid` -J. > At 11:39 AM 8/13/2003 -0400, Jason Dixon wrote: > >On Wed, 2003-08-13 at 10:19, [EMAIL PROTECTED] wrote: > >> Hello. Just got an OpenBSD 3.3 machine running as the firewall for a > small > >> network - I've just started using OpenBSD recently so I'm sure it a rookie > >> mistake. I've been trying to get the packet logging set up as in the faq > >> but I can't get the file pflog.txt to be created. I've read this post and > >> checked everything that I can think > >> of:http://www.benzedrine.cx/pf/msg01009.html > > > >touch /path/to/pflog.txt > > > >-- > >Jason Dixon, RHCE > >DixonGroup Consulting > >http://www.dixongroup.net > -- Jason Dixon, RHCE DixonGroup Consulting http://www.dixongroup.net
Re: E1 X.21 Serial Interface
>My advice is, unless you are planning on BGP which increases the costs, to >buy an E1 capable CPE box (cisco is not the only make) and use it as first >hop :( Must less hassle in the long run. Thanks for the advice Peter. I haven't been able to source an LMC card so a router out front looks like the way we will go. Craig
binat change of behaviour OpenBSD 3.1 to 3.3
I have just upgraded a couple of our firewalls from 3.0 and 3.1 to 3.3. The site that uses binat rules is the one that started on 3.1 The external interface (vlan2) has each useable IP in an /27 range aliased on the interface. I then have a load of rdr, nat and binat rules to map certain IPs and IP:port combinations to internal locations. Before the upgrade all was OK. After the upgrade the binat rules stopped working in the INBOUND direction. Making an outbound connection is OK and the source address is correct. I have band-aided the problem by putting in catch-all rdr rules without a portspec. I did see some 'BAD STATE' errors in debug output while diagnosing, but I did not have the foresight to change syslogd.conf to save them. I had to get the site working again, so I can only test proposed change and get debug at limited times. Anyhow, after all that - any concrete ideas what may have changed to cause this type of thing ? Peter
Re: Implementing a 'scrub tos' option?
Ed White wrote: > BTW filtering on TOS value introduce a good way to filter some ports even if > you get a dynamic IP. > > Example: > > You want to filter port tcp:22 to avoid the whole internet to get the OpenSSH > prompt. Adding a rule like this would make it possible... > > pass in quick inet proto tcp from $My_ISP_class_B to $eth_ext port 22 tos $key > keep state This is the worst kind of security through obscurity. -d
Re: PF logging as in the FAQ not working
On Wed, 2003-08-13 at 10:19, [EMAIL PROTECTED] wrote: > Hello. Just got an OpenBSD 3.3 machine running as the firewall for a small > network - I've just started using OpenBSD recently so I'm sure it a rookie > mistake. I've been trying to get the packet logging set up as in the faq > but I can't get the file pflog.txt to be created. I've read this post and > checked everything that I can think > of:http://www.benzedrine.cx/pf/msg01009.html touch /path/to/pflog.txt -- Jason Dixon, RHCE DixonGroup Consulting http://www.dixongroup.net
Re: pf and altq couple: before and after merge
On Mon, Aug 04, 2003 at 11:35:13PM +0300, Alexey E. Suslikov wrote: > so, what is the point of example? we are unable to match in and out packets > to shape them separately (remember, the state is the matching criteria) and > we are unable to shape same packets on the different interfaces (the state is > the matching criteria). oops, all connection's packets forcedly placed to one > queue and we have no ability to control traffic within this STATEFUL QUEUE. just don't filter statefull if you want to control the directions seperately. or filter statefull on both interfaces. like, d'uh. > Henning, Daniel, please, explain... there is stuff that was theoretically possible with altq before the merge that is not any more. who gives a shit? it wasn't usable at all! nobody used it because the UI was totally fucked up! -- 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: Implementing a 'scrub tos' option?
On Monday 11 August 2003 18:33, Hendrik Scholz wrote: > Where should I install a bridge? LANrouter > I cannot insert anything behind my router but like to modify the > telco routers queueing mechanism. I don't know your situation, but putting a bridge there could be invisible for LAN hosts and for the router. Using an IPless setup will let you use the same network topology/configuration. NOTE: Invisible unless you start playing with hping or other tools. Ed
Basic pfctl question
Hi there. I have a OpenBSD 3.3 running on a Sun Ultra1. I have 4 Interfaces (hme0 - hme3) Right now I only have 2 Interfaces running, hme0 is connected to the internet and hme3 is the internal network (but with official ip's - not nat). My basic question now. When I want certain traffic to be allowed to come in to the internal network, do I have to allow it on both Interfaces (hme0, hme3). Outgoing from hme3 shouldn't be restriced. I'm a bit confused with all those nat examples. Thanks for any help. -- mfg Marc Eggenberger
FTP Chroot not working
Hi Everyone, I have been trying for the past couple of days to get FTP chroot working on my 3.3 machine. I have added the user name to /etc/ftpchroot. Started the ftp server with ftpd -D. I can log into the ftp server and get to the root directory. It is not restricting the user in the /etc/ftpchroot file to there home directory. Any ideas? Justin
Re: pf and bridge question
Hi, thanks for the answers I've received to this. Dom De Vitto wrote: This is because most switches are not security oriented and should be considered dumb hubs on all ports, all vlans. If anyone says this isn't so I'll beat them with enough references to flood a STM64... I think that was kinda what he was talking about, since a switch could leak packets to the wrong interface the machine could get confused. But this still sounds wrong to me (and apparently to everybody else here) because the bridge would never actually see the frame arriving on the wrong interface and the routing code that deals with packets on the management interface wouldn't care about the bridge table (right?). Anyway, since you all agree that this is unlikely/impossible to cause a problem I think I'll take my chances with it. Thanks again, Marc
Re: Basic Operation Issue
Oh no problem. Thanks for clearing that up for me, I feel so much better now that I know I'm not crazy. Also, I agree that Daniel did make a good point that I hadn't thought about previously regarding the internal users using the firewall for DNS, Proxy, etc. I am of the mindset that these services should never be run ON the firewall so I hadn't really thought about other scenarios but I suppose the reality is there are people out there running that type of configuration. Again, thanks Joel (and Daniel) for shedding some light on it. Justin J. Sabino wrote: Been reading a lot about pf recently, extremely nice software and love the easy syntax and great features. Something however has me a bit confused that I've read on this page: http://www.openbsd.org/faq/pf/filter.html#example I'm trying to remember what I had in mind when I wrote that, but I can't. Daniel makes a good point by saying that the ruleset would work with the use of proxies, etc, but I'm sure that wasn't my intention. Also, like Daniel said, that's not mentioned anywhere on the page. I've submitted a patch which should show up soonish to change the rules to: # pass all traffic to and from the local network pass in on $int_if from $lan_net to any pass out on $int_if from any to $lan_net Thanks for pointing that out. :-) .joel
Re[2]: pf and altq couple: before and after merge
Tuesday, August 5, 2003, 11:00:14 AM, Daniel Hartmeier wrote: > Well, not an arbitrary number of states per connection, at most two > (unless translation and/or encapsulation is involved, then you could > possibly create more). > You can easily see how this works by loading the simple ruleset > pass all keep state > and create a connection through the firewall. You'll see two state > entries. They contain directions (the arrows in pfctl -ss output). > Each subsequent packet of the connection will match only one of the > states on the first interface (where it arrives at the firewall) and the > other state on the second interface (where it leaves the firewall), due > to the direction stored in the state. You can see this by observing the > packet/bytes counters in pfctl -vss output. > A more specific example: if you create a connection from 10.1.1.1 to > 10.2.2.2 through the firewall, entering through interface $int and > leaving through $ext of the firewall, the first packet > 10.1.1.1 -> 10.2.2.2 incoming on $int > will create state. The state entry will allow without ruleset evaluation > a) incoming packets (on any interface) from 10.1.1.1 to 10.2.2.2 > b) outgoing packets (on any interface) from 10.2.2.2 to 10.1.1.1 from the man pf.conf: STATEFUL INSPECTION pf(4) is a stateful packet filter, which means it can track the state of a connection. Instead of passing all traffic to port 25, for instance, it is possible to pass only the initial packet, and then begin to keep state. Subsequent traffic will flow because the filter is aware of the connection. If a packet matches a pass ... keep state rule, the filter creates a state for this connection and automatically lets pass all subsequent packets of that connection. Before any rules are evaluated, the filter checks whether the packet matches any state. If it does, the packet is passed without evaluation of any rules. there is no any mention about "direction" property in the state entry: "... If a packet matches a pass ... keep state rule, the filter creates a state for this connection and automatically lets pass all subsequent packets of that connection...". > note that this does not cover the very same packet leaving through $ext > 10.1.1.1 -> 10.2.2.2 outgoing on $ext ALL SUBSEQUENT PACKETS. is "10.1.1.1 -> 10.2.2.2 outgoing on $ext" not a subsequent packet of the already keepstated connection? why this is "neither a) nor b)"? > this is neither a) nor b), it doesn't match the state entry, and the > ruleset is evaluated, and can create a second state entry, which will > match > c) outgoing packets (on any interface) from 10.1.1.1 to 10.2.2.2 > d) incoming packets (on any interface) from 10.2.2.2 to 10.1.1.1 > Now all subsequent packets of this connection (in either direction, on > either interface) will match exactly one of the state entries on each > interface (matching both states, subsequently, in the process), due to > how the state entries restrict the direction with regard to source and > destination addresses in a)-d).
Re: Basic Operation Issue
J. Sabino wrote: Been reading a lot about pf recently, extremely nice software and love the easy syntax and great features. Something however has me a bit confused that I've read on this page: http://www.openbsd.org/faq/pf/filter.html#example I'm trying to remember what I had in mind when I wrote that, but I can't. Daniel makes a good point by saying that the ruleset would work with the use of proxies, etc, but I'm sure that wasn't my intention. Also, like Daniel said, that's not mentioned anywhere on the page. I've submitted a patch which should show up soonish to change the rules to: # pass all traffic to and from the local network pass in on $int_if from $lan_net to any pass out on $int_if from any to $lan_net Thanks for pointing that out. :-) .joel
Re: Implementing a 'scrub tos' option?
On Monday 11 August 2003 16:01, Hendrik Scholz wrote: > Living on a DSL link is hard when it comes to ALTQ configuration on the > upstream side. > In my (and prob. this is the most common setup) I cannot (legally) take > control of the upstream router and its queueing policies. Sorry it's not clear to me the problem. Couldn't you insert a bridge ? BTW filtering on TOS value introduce a good way to filter some ports even if you get a dynamic IP. Example: You want to filter port tcp:22 to avoid the whole internet to get the OpenSSH prompt. Adding a rule like this would make it possible... pass in quick inet proto tcp from $My_ISP_class_B to $eth_ext port 22 tos $key keep state Ed
relaydb question..
Hi, I have implemented Daniel's solutions (pf+relaydb on OpenBSD) and it works great! I have a question though... Why does relaydb ignore addresses inside of round brackets ? It seems to be adding only addresses within []. Some emails do not even have a single address within []. (who adds the addresses in [] anyways, I am using qmail as my MTA, does it matter at all ? Is there a config setting somewhere ?) Thanks! -C _ The Free Redirection Services http://www.now.nu
Re: Implementing a 'scrub tos' option?
On Wednesday, Aug 13, 2003, at 03:01 US/Pacific, Henning Brauer wrote: On Tue, Aug 12, 2003 at 10:09:01PM +1000, Damien Miller wrote: OTOH a "pass set-tos xxx" option (what this discussion was originally about) would be nice... there are various people now asking for a possibility to set the tos. I tend to think it makes sense. Something to take note of: pf's current tos matching for queueing purposes breaks when ECN is in use. Be careful of that when setting the tos, too...
Re: pf and bridge question
On Wed, Aug 13, 2003 at 05:39:56PM -0400, Amir Seyavash Mesry wrote: > Henning or eh I forget, know of a bug using this configuration, then it > should work as I have seen it. I don't know what should prevent that from working indeed. -- 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 and bridge question
Ok, lets go through this... > Hi, > > I have an OpenBSD 3.3 firewall which acts as a transparent bridge > between our network (not NATted) and a router giving access to the rest > of the world. The bridging interfaces are configured without IP address > and a third (management) NIC is configured with an IP address inside our > network's address space. A colleague of mine claims that this can lead > to confusion in the routing/bridging code of the firewall and possible > corruption of the arp table. He says that the management interface He is talking crap. PF (or any other firewall I know of) doesn't know anything about arp tables, or even arp packets. You _can_ get issues if you have two bridge interfaces, as PF only has one kernel table. > should never be in the same logical or physical network as one of the > two sides of the bridge, i.e. it should have an address in rfc1918 space > and be physically connected to different networking hardware. This is because most switches are not security oriented and should be considered dumb hubs on all ports, all vlans. If anyone says this isn't so I'll beat them with enough references to flood a STM64... > I have difficulty in understanding how this could be true and he cannot > give me an explanation other than that he has had trouble with this in > the past (running older versions of OpenBSD 3.2 with ipf). Can someone > here enlighten me as to whether this is really a possible problem and if > so how exactly some sort of corruption/glitch could happen? Magic? bad administration? If Henning or Daniel haven't seen this behaviour, I doubt it exists. > Thanks a lot, > > Marc > > P.S. Naturally I am aware of the fact that having the management > interface on a separate NATted network with it's own protection is a > good thing security-wise, so that's not really my question. Dom - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Dom De Vitto Tel. 07855 805 271 http://www.devitto.com mailto:[EMAIL PROTECTED] - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Basic Operation Issue
Been reading a lot about pf recently, extremely nice software and love the easy syntax and great features. Something however has me a bit confused that I've read on this page: http://www.openbsd.org/faq/pf/filter.html#example First, I've read that pf is configured by default with an implicit allow all policy, I take that to mean that if you simply turn on pf and do not load any pf.conf file (filtering or nat rules, etc), the policy will allow everything, is this correct? If that's the case, then I'm confused by the example on this page. The lines at the top of the policy (block in all, block out all) effectively deny all traffic on any interface in any direction.. Given the rest of the rules, I don't see how a box on the internal LAN would be able to talk to anything on the Internet. There doesn't seem to be anything allowing that traffic IN on the internal interface and OUT on the internal interface for the reply traffic back to the internal host from an Internet host.. I see the rule that allows tcp, udp and icmp out the external interface and with the use of keep state, replies would be let back in to the external interface but the internal interface (I think) would block these connections. Am I missing something? Thanks! JMS
Re: more than one rdr
On Fri, Aug 08, 2003 at 02:57:18PM -0700, Bryan Irvine wrote: > Is there a way to assign more than one ip to the $ext_if and do rdr > based on that? You can add an ip alias and use binat. I had problems w/arp that way. Could have been a problem between the keyboard & chair though. > like (pretend 192.168.0 is a public routable range) > > rdr on $ext_if proto tcp from any to 192.168.0.5 port 80 -> 10.0.0.5 > rdr on $ext_if proto tcp from any to 192.168.0.6 port 80 -> 10.0.0.6 > > My understanding is that pf will only see the port 80 and all traffic > would get matched against the first rule. Hmm? That is not the case at all. > Is this the definition of "1 to 1 NAT"? Within the context of pf, binat is the most like 1 to 1 NAT.
Re: Accounting per host status.
On Wed, Aug 06, 2003 at 05:47:43PM -0300, Gustavo Chamone wrote: > Last may, Hartmeier sent an e-mail with the Hackathon Summary[1]. He > mentioned that there was some work in progress on accounting per host, being > made by Ryan McBride. Does anyone know the status of this feature? I'm flying to calgary in september to ork more on this with theo and ryan in september. -- 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)
Accounting per host status.
Folks, since I couldn't find anything related to this on the archive, I'm hoping that you guys can help me out. Last may, Hartmeier sent an e-mail with the Hackathon Summary[1]. He mentioned that there was some work in progress on accounting per host, being made by Ryan McBride. Does anyone know the status of this feature? If this feature already went into -current, I'll be glad to test it. Thanks a lot! Best regards, Gustavo Chamone * [1]: http://www.benzedrine.cx/pf/msg02201.html
Re: Implementing a 'scrub tos' option?
On Wed, Aug 13, 2003 at 01:43:18PM +0200, Hendrik Scholz wrote: > You'd have to add the tos statement to both rules in case you want > the replies to incoming icmp echo request packets to be passed out > with a tos flag set. Yes. Basic question is: do you want to set the same tos on all packets of one connection (state entry) automatically? Or is setting tos completely unrelated to connections, and you want to do it per packet (no matter what connection the packet might be part of). Doing it in scrub is the second case, scrubbing happens for individual packets before a state lookup is done, hence scrub rules know nothing about state entries (what connection the packet might be part of). Doing it in pass keep state rules could use the state entry association to set tos for all packets of the connection. Daniel
Re: PF logging as in the FAQ not working
Hello. Tried that and still no luck. Even did chown and chgrp to pflogger and nothing. At 11:39 AM 8/13/2003 -0400, Jason Dixon wrote: >On Wed, 2003-08-13 at 10:19, [EMAIL PROTECTED] wrote: >> Hello. Just got an OpenBSD 3.3 machine running as the firewall for a small >> network - I've just started using OpenBSD recently so I'm sure it a rookie >> mistake. I've been trying to get the packet logging set up as in the faq >> but I can't get the file pflog.txt to be created. I've read this post and >> checked everything that I can think >> of:http://www.benzedrine.cx/pf/msg01009.html > >touch /path/to/pflog.txt > >-- >Jason Dixon, RHCE >DixonGroup Consulting >http://www.dixongroup.net
Re: PF logging as in the FAQ not working
At 12:27 PM 8/13/2003 -0400, you wrote: >a) Please stop top-posting. Sorry about that. If you would prefer that I not reply all also, please let me know. >b) Whenever you create a new file for a daemon like syslog to write to, >you need to restart that daemon. > >kill -HUP `cat /var/run/syslog.pid` I had NOT tried that before. Went back and ran the scripts as root again after deleting and recreating pflog.txt and performing the command as above. Still no output in pflog.txt. I did forget to put in the first post that I had changed the root shell to bash versus sh. I haven't seen anything about that in the faq that would indicate a problem but is there something that this might affect? I appreciate the time and the help. Is there a method that I can use to verify that this command : logger -t pf -p local0.info is working? I've been able to verify the other commands are performing the actions that they are supposed to (by running them by themselves, I can see that they process the output and remove the file).
