Hi,
I want to push data from pflog0 device to my graylog server.
Has anyone done something similar or maybe with elastic/GELF ?
There is https://github.com/dennisoelkers/keil but seemd abandoned and I
couldn't make it work.
There is also packetbeat which is also ported to openbsd but it seems
On Thu, Jan 2, 2020 at 12:34 PM Otto Moerbeek wrote:
> > Can't seem to find that specific info anywhere.
>
> see man pf.conf and then search for allow-opts
I see that it says they are blocked, but nothing to indicate they are
also automatically logged.
Chris
On Thu, Jan 02, 2020 at 12:27:40PM -0500, Sonic wrote:
> On Thu, Jan 2, 2020 at 1:00 AM Sebastien Marie wrote:
> > And by default, packets
> > with ip-options are block-logged.
>
> Can't seem to find that specific info anywhere.
see man pf.conf and then search for allow-opts
-Otto
>
On Thu, Jan 2, 2020 at 12:27 PM Sonic wrote:
> I used:
> block proto igmp
More specifically:
block drop quick proto igmp
as I thought "return" would simply add extra traffic to the network.
Chris
On Thu, Jan 2, 2020 at 1:00 AM Sebastien Marie wrote:
> And by default, packets
> with ip-options are block-logged.
Can't seem to find that specific info anywhere.
> I suppose that adding an explicit rule with allow-opts should do the trick.
> depending your need (block or allow):
> blo
On Wed, Jan 01, 2020 at 12:33:30PM -0500, Sonic wrote:
> The pflogs on my firewall and on a new system I'm installing (-current
> with pretty much a default pf.conf) are flooded with igmp query
> entries. Neither system has a log rule for such action.
[...]
> Reason?
To quote pf.conf(5) manual (
pfctl -si
Status: Enabled for 1 days 23:53:56 Debug: err
State Table Total Rate
current entries 13
half-open tcp 0
searches 1008640.6/s
inserts
Sonic(sonicsm...@gmail.com) on 2020.01.01 12:33:30 -0500:
> The pflogs on my firewall and on a new system I'm installing (-current
> with pretty much a default pf.conf) are flooded with igmp query
> entries. Neither system has a log rule for such action.
>
> Ex:
> =
The pflogs on my firewall and on a new system I'm installing (-current
with pretty much a default pf.conf) are flooded with igmp query
entries. Neither system has a log rule for such action.
Ex:
===
rule 1/(match) pass in on em1: 192.168.1.20 > 224.0.0.1: igmp query
Fri, 30 Sep 2016 20:43:02 +0200 Walter Alejandro Iglesias
[...]
> The point is, I ask myself the same a lot of unix users probably are
> asking themselves, should I invest more time in educating myself in
> practices that in two days could be declared obsolete?
Hi Walter,
You've come to the righ
To the other people who answer me here, sorry for the delay, I took some
time to calm down and not degrade myself to the level of discussion some
person here proposed me.
Martin Brandenburg,
I know what pcap files are, I used them. But, as I said, I'm not an
expert, I didn't take in care that c
On Wed, Sep 28, 2016 at 02:36:10PM -0600, Theo de Raadt wrote:
> > So, *binary* logs. Sounds familiar to me. And then:
>
> Your type of person seems familiar to be me. Undeducated *check*
> opinioned *check* Contrasting authoritatively without any education
> to back it up
handled according to your PF rules.
> I must confess I'm one among those "run to the hills" paranoids. I'm
> not an expert, perhaps I'm judging pflog wrong but, anyway, I still
> prefer the traditional way, using cat, grep and tail.
Well, for for generally k
On 09/28/2016 04:25 PM, Walter Alejandro Iglesias wrote:
> And this "uncommon" practice among unix system administrators (sarcasm),
> needs a "workaround". You end with a file with a curious termination:
>
> Create the file /var/log/pflog.txt ...
You can name it pflog.log versus pflog.txt, i
practice among unix system administrators (sarcasm),
needs a "workaround". You end with a file with a curious termination:
Create the file /var/log/pflog.txt ...
I must confess I'm one among those "run to the hills" paranoids. I'm
not an expert, perhaps I
:
>
> The log file written by pflogd is in binary format and cannot be
> read using a text editor.
>
> So, *binary* logs. Sounds familiar to me. And then:
Your type of person seems familiar to be me. Undeducated *check*
opinioned *check* Contrasting authoritatively w
st confess I'm one among those "run to the hills" paranoids. I'm
> not an expert, perhaps I'm judging pflog wrong but, anyway, I still
> prefer the traditional way, using cat, grep and tail.
>
>
# file /var/log/pflog
/var/log/pflog: tcpdump capture file (littl
a "workaround". You end with a file with a curious termination:
Create the file /var/log/pflog.txt ...
I must confess I'm one among those "run to the hills" paranoids. I'm
not an expert, perhaps I'm judging pflog wrong but, anyway, I still
prefer the traditional way, using cat, grep and tail.
On 2014-04-04, Philip Guenther wrote:
> On Thu, Apr 3, 2014 at 12:18 AM, emigrant wrote:
>> After 64 days uptime(OpenBSD 5.4 i386) /var/log/pflog disappeared.
>>
>> Cron Daemon sent to me:
>>
>> Subject: Cron /bin/sh /etc/pflogrotate
>>
>> pkill:
On Fri, Apr 04, 2014 at 09:02:06PM +0200, emigrant wrote:
> You're right, probably pflogrotate script is buggy.
>
> root@master[~]ls /var/log/pflog
> ls: /var/log/pflog: No such file or directory
>
> wtf? where is my pflog file? :) interesting, because it worked almost 3 y
You're right, probably pflogrotate script is buggy.
root@master[~]ls /var/log/pflog
ls: /var/log/pflog: No such file or directory
wtf? where is my pflog file? :) interesting, because it worked almost 3 years
On 04 Apr 2014, at 04:55, Philip Guenther wrote:
> On Thu, Apr 3, 2014 at
On Thu, Apr 3, 2014 at 12:18 AM, emigrant wrote:
> After 64 days uptime(OpenBSD 5.4 i386) /var/log/pflog disappeared.
>
> Cron Daemon sent to me:
>
> Subject: Cron /bin/sh /etc/pflogrotate
>
> pkill: kvm_getprocs() failed
>
>
> Hmm, yes I use pflogrotate to change p
Hi everyone
After 64 days uptime(OpenBSD 5.4 i386) /var/log/pflog disappeared.
Cron Daemon sent to me:
Subject: Cron /bin/sh /etc/pflogrotate
pkill: kvm_getprocs() failed
Hmm, yes I use pflogrotate to change pflog -> pflog.txt . After copy pflog from
another machine everything back
Em 22-03-2014 08:39, Florian Obser escreveu:
> On Thu, Mar 20, 2014 at 06:14:39PM -0300, Giancarlo Razzolini wrote:
>> AFAIK, using anything beside proto 5 on pflow interfaces is broken, at
>> least on OpenBSD 5.4. I know there were some recent work in this area
>> that solves this issue.
> Nope, p
On Thu, Mar 20, 2014 at 06:14:39PM -0300, Giancarlo Razzolini wrote:
> AFAIK, using anything beside proto 5 on pflow interfaces is broken, at
> least on OpenBSD 5.4. I know there were some recent work in this area
> that solves this issue.
Nope, proto 9 was allways working. proto 10 had the proble
the interfaces in
>> promiscuous mode using the pcap library. Or running a tmux+tcpdump. A
>> bridge can also work, but it introduces complexity, especially when
>> filtering the packets.
> Based on further experiments motivated by your suggestions, I have concluded
> that I’ve
o work, but it introduces complexity, especially when
> filtering the packets.
Based on further experiments motivated by your suggestions, I have concluded
that I’ve been using the wrong tool(s)
for the job.
Since I’m using the OpenBSD box to just read all packets on an interface, I
shouldn’t be usi
em2 up
>
> ifconfig bridge0 add em2
> ifconfig bridge0 rule pass in on em2 tag tap_b
> ifconfig bridge0 up
>
> I’d like to configure pf as follows:
>
> Log all traffic on em2/bridge0 to (ideally a specific) pflog interface
>
> Also “log
in on em2 tag tap_b
ifconfig bridge0 up
I’d like to configure pf as follows:
Log all traffic on em2/bridge0 to (ideally a specific) pflog interface
Also “log” flows on em2/bridge0 to (ideally a specific) pflow interface
Leave em0 alone (in its default state), and
pflogif_list;
struct if_clonepflog_cloner =
IF_CLONE_INITIALIZER("pflog", pflog_clone_create, pflog_clone_destroy);
-struct ifnet *pflogifs[PFLOGIFS_MAX];/* for fast access */
-struct mbuf*pflog_mhdr = NULL, *pflog_mptr = NULL;
+int npflogi
On Thu, Apr 12, 2012 at 3:44 AM, Henning Brauer
wrote:
> diffs are for current of course but should work for 5.1 as well -
> dunno what you are trying.
>
Dear Henning,
I have upgraded my firewall to 5.1
could you please give ma a unified diff or something I can try
Thanks
Siju
On Thu, Apr 12, 2012 at 3:44 AM, Henning Brauer
wrote:
>
>
> diffs are for current of course but should work for 5.1 as well -
> dunno what you are trying.
>
Ok thanks :-)
I am running 5.0
--Siju
On Wed, Apr 11, 2012 at 3:14 PM, Henning Brauer
wrote:
> * patrick keshishian [2012-04-11 14:55]:
>> On Wed, Apr 11, 2012 at 12:20:30PM +0200, Henning Brauer wrote:
>> don't you need two different index vars for this next
>> section?
>
> no, why?
I put the caveat that I am not familiar with the
* patrick keshishian [2012-04-11 14:55]:
> On Wed, Apr 11, 2012 at 12:20:30PM +0200, Henning Brauer wrote:
> don't you need two different index vars for this next
> section?
no, why?
> > + for (i = 0; i < n; i++)
> > + if (i < npflogifs)
> > + p[i] = pflogifs[i];
>
* Siju George [2012-04-11 14:25]:
> On Wed, Apr 11, 2012 at 3:50 PM, Henning Brauer wrote:
> >
> > please try this & report back
> >
>
> Thanks Henning but I need some help :-(
>
> I got the following errors and I have attached the .rej files
diffs are for current of course but should work for
56 -
> @@ -80,6 +80,7 @@
> #endif
>
> void pflogattach(int);
> +int pflogifs_resize(size_t);
> int pflogoutput(struct ifnet *, struct mbuf *, struct sockaddr *,
> struct rtentry *);
> int pflogioctl(struct ifnet *, u_long, caddr_t);
>
On Wed, Apr 11, 2012 at 3:50 PM, Henning Brauer wrote:
>
> please try this & report back
>
Thanks Henning but I need some help :-(
I got the following errors and I have attached the .rej files
=
# patch -p0 < patch.if_pflog
Hmm... Looks like a unified di
,
struct rtentry *);
intpflogioctl(struct ifnet *, u_long, caddr_t);
@@ -91,16 +92,14 @@ LIST_HEAD(, pflog_softc)pflogif_list;
struct if_clone pflog_cloner =
IF_CLONE_INITIALIZER("pflog", pflog_clone_create, pflog_clone_destroy);
-struct ifnet *pflogif
On Wed, Apr 11, 2012 at 2:55 PM, Henning Brauer wrote:
>
> actually, bumping it should be absolutely safe.
>
> pretty dumb limit actually, we should just dynamically allocate the
> pflogifs array.
>
Thanks :-)
Siju
* Siju George [2012-04-10 08:16]:
> On Tue, Apr 10, 2012 at 11:40 AM, Andres Perera wrote:
> > altering the max might have consequences i don't know about:
> I will stick with 15 :-)
actually, bumping it should be absolutely safe.
pretty dumb limit actually, we should just dynamically allocate
On Tue, Apr 10, 2012 at 11:40 AM, Andres Perera wrote:
> altering the max might have consequences i don't know about:
>
I will stick with 15 :-)
> grep -nC5 PFLOGIFS_MAX /sys/net/if_pflog.h
> 27-#ifndef _NET_IF_PFLOG_H_
> 28-#define _NET_IF_PFLOG_H_
> 29-
> 30-#include
> 31-
> 32:#define P
altering the max might have consequences i don't know about:
grep -nC5 PFLOGIFS_MAX /sys/net/if_pflog.h
27-#ifndef _NET_IF_PFLOG_H_
28-#define _NET_IF_PFLOG_H_
29-
30-#include
31-
32:#define PFLOGIFS_MAX16
33-
34-struct pflog_softc {
35- struct ifnetsc_if; /* the
Hi,
I have /etc/hostname.pflog files from 1-25.
but only till 15 is available through ifconfig
pflog15: flags=41 mtu 33152
priority: 0
how do I get till pflog25?
Thanks
Siju
* Henning Brauer [2011-11-14 21:27]:
> while this is all correct, let me try to pahse it in a way that i
> think is clearer. the bpf hooks (aka where bpf grabs the packets) are
> "outside" pf, i. e. inbound packets hit pf before bpf and outgoing pf
^^^
e bpf grabs the packets) are
"outside" pf, i. e. inbound packets hit pf before bpf and outgoing pf
before bpf.
that leaves cases where packets traverse the stack more than once
(e. g. some encapsulations, some cases where pf makes changes to the
packet) aside for clarity. and pflog is special in
Am Sun, 13 Nov 2011 09:51:05 -0600
schrieb "Ted Wynnychenko" :
> With 4.5, I had snort listening to pflog0, because I understood that
> listening to the interface directly (e.g. "bge0") would not work
> since any packets dropped by pf would not be seen by snort.
pflog0 only shows the packets that
Hello
I am confused about something. I have recently upgraded from 4.5 to 4.9
(not 5.0 yet).
However, I have openbsd/pf as a firewall to protect a home network.
Now, even though I don't really understand it all, I had/have snort running
on the FW to see what kind of badness passes by.
With 4.
* Matt Van Mater [2011-08-22 23:14]:
> I am looking into why my
> pflog has these ambiguous entries that show source and destination as all
> zeros e.g. 0.0.0.0.0 > 0.0.0.0.0.
this fixes it. nsaddr/port and ndaddr/port were set up in pf_test_rule
and thus not set up if we pas
* Matt Van Mater [2011-08-22 23:14]:
> See my configuration at the bottom of this email. I am looking into why my
> pflog has these ambiguous entries that show source and destination as all
> zeros e.g. 0.0.0.0.0 > 0.0.0.0.0.
>
> I saw that there was a related thread earlie
Can one of th PF developers weigh in?
Is there anything more that I can do to help? E.g. formally list a
bug report, provide additional detail, act as tester, etc?
On 8/25/11, Kevin Chadwick wrote:
> On Thu, 25 Aug 2011 20:10:12 + (UTC)
> Stuart Henderson wrote:
>
>> Yes these are from the
On Thu, 25 Aug 2011 20:10:12 + (UTC)
Stuart Henderson wrote:
> Yes these are from the "log (all)", looks like a bug to me.
I wondered if it was the result of one of the optimisations. The state
making SYNs show the correct IP.
> By the way, this host is running as a virtual machine inside VMWare ESXi 4.1
> (I chose FreeBSD as the guest OS when I initially created the VM).
>
> Matt
>
> On Mon, Aug 22, 2011 at 5:09 PM, Matt Van Mater
> wrote:
>
>> Hi All,
>>
>> See my configuration at t
d the VM).
Matt
On Mon, Aug 22, 2011 at 5:09 PM, Matt Van Mater wrote:
> Hi All,
>
> See my configuration at the bottom of this email. I am looking into why my
> pflog has these ambiguous entries that show source and destination as all
> zeros e.g. 0.0.0.0.0 > 0.0.0.0.0.
>
Hi All,
See my configuration at the bottom of this email. I am looking into why my
pflog has these ambiguous entries that show source and destination as all
zeros e.g. 0.0.0.0.0 > 0.0.0.0.0.
I saw that there was a related thread earlier this year asking questions
that was unresolved/unconfir
2011/1/22 Johan Helsingius :
> Matteo,
>
>> all you need is at
>>
>>
http://www.openbsd.org/cgi-bin/man.cgi?query=tcpdump&apropos=0&sektion=0&manp
ath=OpenBSD+Current&arch=i386&format=html
>
> Thanks, but as I wrote:
>
>>> I am getting a fair bit of log lines that are shown as
>>> "rule def/(short)
> The "short" reason code indicates that the packet was truncated or too short
> and therefore was missing information required to make a packet filtering
> decision. This could be, for example, a packet that only contained the first
> few bytes of an IP datagram (or a header that states that it
On Sunday 23 January 2011, Johan Helsingius wrote:
> Matteo,
>
> > all you need is at
> >
> > http://www.openbsd.org/cgi-bin/man.cgi?query=tcpdump&apropos=0&sektion=0&;
> >manpath=OpenBSD+Current&arch=i386&format=html
>
> Thanks, but as I wrote:
> >> I am getting a fair bit of log lines that are sh
On Sat, Jan 22, 2011 at 10:38 AM, matteo filippetto
wrote:
>> the meaning of things like "(short)" - the tcpdump man
>> page only lists "short" as one of the possible values,
>> without explaining what it means.
> http://www.openbsd.org/cgi-bin/man.cgi?query=tcpdump&apropos=0&sektion=0&manpath=Op
Matteo,
> all you need is at
>
> http://www.openbsd.org/cgi-bin/man.cgi?query=tcpdump&apropos=0&sektion=0&manpath=OpenBSD+Current&arch=i386&format=html
Thanks, but as I wrote:
>> I am getting a fair bit of log lines that are shown as
>> "rule def/(short)", and I can't find anything explaining
>
> Another really stupid question - is the full output format
> of tcpdump when dumping the pflog0 device documented somewhere?
> I am getting a fair bit of log lines that are shown as
> "rule def/(short)", and I can't find anything explaining
> the meaning of things like "(short)" - the tcpdump man
Hi!
Another really stupid question - is the full output format
of tcpdump when dumping the pflog0 device documented somewhere?
I am getting a fair bit of log lines that are shown as
"rule def/(short)", and I can't find anything explaining
the meaning of things like "(short)" - the tcpdump man
page
Hello,
Running amd64 GENERIC.MP -current.
Started seeing truncated entries in pflog like this:
==
...rule 42/(match) block out on em0: [|ip]
==
They seemed to start after the last build to -current where this got logged
Hi,
I have these rules for the interface vr1
match out on vr1 inet from 172.16.0.0/12 to any nat-to (vr1) round-robin
pass in log (all, to pflog1) quick on vr0 inet from to any
flags S/SA keep state label route-to 122.247.14...@vr1
pass out log (all, to pflog3) quick on vr1 all flags S/SA keep
On Tue, Oct 27, 2009 at 02:25:03PM +0100, Rene Maroufi wrote:
> Hi,
>
> I have a (bridging) Firewall with OpenBSD 4.6 stable. In /var/log/pflog
> I can see many igmp-packets. But I have no "log" statement for these
> types of connections in my pf.conf. I have only a log s
Hi,
I have a (bridging) Firewall with OpenBSD 4.6 stable. In /var/log/pflog
I can see many igmp-packets. But I have no "log" statement for these
types of connections in my pf.conf. I have only a log statement for some
other hosts (with a different IP). Are igmp packets always logged
Hi,
I've a problem with logging packets in bridging mode with pf under -current.
My setup is a machine with em2 ad em3 interfaces in a bridge (no IP
address), witth a ruleset that looks like:
---cut---
admif=em0
table const { }
table const { }
table const { 10/8, 172.16/12, 192.168/16
tions that are not
> specifically allowed by our current rule set.
>
> While monitoring the pflog output, I occasionally see output that looks like
> this:
>
> Apr 24 09:49:46.420762 rule 150/(match) pass in on fxp1: 107.6.96.0 >
> 73.243.0.0: at-#0 18
> Apr 24 09:
On Fri, Apr 24, 2009 at 7:53 AM, Aner Perez wrote:
...
> While monitoring the pflog output, I occasionally see output that looks
like
> this:
>
> Apr 24 09:49:46.420762 rule 150/(match) pass in on fxp1: 107.6.96.0 >
73.243.0.0: at-#0 18
> Apr 24 09:49:46.420851 rule 150/(matc
.
While monitoring the pflog output, I occasionally see output that looks like
this:
Apr 24 09:49:46.420762 rule 150/(match) pass in on fxp1: 107.6.96.0 >
73.243.0.0: at-#0 18
Apr 24 09:49:46.420851 rule 150/(match) pass in on fxp1: 108.6.96.0 >
73.37.0.0: at-#0 21
Apr 24 09:49:46.420901 ru
not be enought. But I am sure that
it is good idea to keep all the the information of pflog files. So, you
have several ways to solve this problem:
1) Make a directory on some bigger partition and setup newsyslog by
editing /etc/newsyslog.conf to store archieved logs in that folder.
2) Move
why I'm
getting binary stuff in the logs?
I guess this show you just don't need to log things here as you never
read them.
man(8) pflogd
Display binary logs:
# tcpdump -n -e -ttt -r /var/log/pflog
And go read the faq on openbsd.org. They are a very big source o
On 1/12/2007, at 7:23 PM, Jake Conk wrote:
Thanks guys for your replies... I'll try to cut down on the all the
useless logging I'm doing but when I opened the log files up to see
what was inside them I only saw all this binary stuff. I assume thats
not what's supposed to be in the pflogs right?
On Nov 30, 2007 7:47 PM, NetOne - Doichin Dokov <[EMAIL PROTECTED]> wrote:
> Jake Conk P=P0P?P8Q P0:
>
> > Hello,
> >
> > I have my /var partitioned out to be 150mb which I thought was a
> > enough but every 2-3 days it gets full because I end up with a pflog
On Fri, 30 Nov 2007, Jake Conk wrote:
Hello,
I have my /var partitioned out to be 150mb which I thought was a
You're probably getting a lot of log hits on a "default block log all" at
the end of your rules. You can prevent a lot of crud by doing "block
quicks" w/o log statements for the fo
Jake Conk wrote:
I have to keep coming here each couple of days to check if that is
full and delete them. My question is, is this normal and I just
created my /var mount too small? I think the fact that my pflog is
that big is the actual problem, does anyone know of a way to fix this?
Well
Jake Conk P=P0P?P8QP0:
Hello,
I have my /var partitioned out to be 150mb which I thought was a
enough but every 2-3 days it gets full because I end up with a pflog
file that is ridiculously large! Right now I have one that is 53.6mb
and I have gotten them larger like 100mb +!! Because of this
Hello,
I have my /var partitioned out to be 150mb which I thought was a
enough but every 2-3 days it gets full because I end up with a pflog
file that is ridiculously large! Right now I have one that is 53.6mb
and I have gotten them larger like 100mb +!! Because of this my /var
partition fills up
Hi all,
I have tried to setup a new pflog interface to monitor ipsec traffic and it
works ok. Afterwards I have setup another pflogd daemon to store logs on another
pcap file under /var/log. But I have one question: how do i to configure
newsyslog.conf entry for this new pflogd daemon? If I
On Mon, Apr 10, 2006 at 09:27:53PM +0100, Gaby vanhegan wrote:
> On 10 Apr 2006, at 17:29, Joachim Schipper wrote:
>
> >> The only problem here is that I'm running 3.6 and pmacct requires
> >> libpcap >= 0.6, and 0.3 is what I have. I can't do an upgrade at the
> >> moment, there's too many varia
On 10 Apr 2006, at 17:29, Joachim Schipper wrote:
>> The only problem here is that I'm running 3.6 and pmacct requires
>> libpcap >= 0.6, and 0.3 is what I have. I can't do an upgrade at the
>> moment, there's too many variables, but if I were to build libpcap
>> from source, would it clobber the
On Mon, Apr 10, 2006 at 03:05:19PM +0100, Gaby vanhegan wrote:
> On 9 Apr 2006, at 18:55, Gaby vanhegan wrote:
>
> > And the winner is:
> >
> > pmacct.
>
> The only problem here is that I'm running 3.6 and pmacct requires
> libpcap >= 0.6, and 0.3 is what I have. I can't do an upgrade at the
On 9 Apr 2006, at 18:55, Gaby vanhegan wrote:
> And the winner is:
>
> pmacct.
The only problem here is that I'm running 3.6 and pmacct requires
libpcap >= 0.6, and 0.3 is what I have. I can't do an upgrade at the
moment, there's too many variables, but if I were to build libpcap
from sour
And the winner is:
pmacct.
This one is really quick and simple to put together, five minutes and
a configuration file later and I'm logging all traffic on all ports
in 10 minute time slices, broken down by source, destination, MAC,
port, etc. It also contains actual amounts of traffic too,
On Sun, Apr 09, 2006 at 04:28:58PM +0100, Gaby vanhegan wrote:
> On 9 Apr 2006, at 15:26, Stuart Henderson wrote:
>
> >>The thing with pflog is that I can't see which field (if any) is the
> >>packet size, which is what I'm interested in. I'm trying to
On 9 Apr 2006, at 15:26, Stuart Henderson wrote:
The thing with pflog is that I can't see which field (if any) is the
packet size, which is what I'm interested in. I'm trying to log how
much of which protocol eats what amount of my bandwidth, both inbound
and outbound.
Are th
On 2006/04/09 14:17, Gaby vanhegan wrote:
> On 9 Apr 2006, at 14:10, Andrew Veitch wrote:
>
> > Would pmacct help in this scenario? http://www.pmacct.org/
> > Not sure whether it could be configured to listen to pflog though.
>
> The thing with pflog is that I can'
quite work
> out what's going on. I have pf logging the traffic that I want to
> account for so /var/log/pflog is filling up nicely. Taking a few
> sample lines from the output of:
>
> # tcpdump -n -r /var/log/pflog
>
> 13:35:07.985465 220.135.151.10.1254 &g
On Sun, 9 Apr 2006, Gaby vanhegan wrote:
I'm trying to log how much of which protocol eats what amount of my
bandwidth, both inbound and outbound.
While I haven't used it in that fashion, I believe that this problem is
one of the things pmacct was designed to solve.
See page 17 of
http://ww
On 9 Apr 2006, at 14:10, Andrew Veitch wrote:
> Would pmacct help in this scenario? http://www.pmacct.org/
> Not sure whether it could be configured to listen to pflog though.
The thing with pflog is that I can't see which field (if any) is the
packet size, which is what I'
7;t been touched for years. The mailing archive
suggested IPAudit, but I'd rather use native tools if I can.
Would pmacct help in this scenario? http://www.pmacct.org/
Not sure whether it could be configured to listen to pflog though.
--
Andrew Veitch mailto:[EMAIL PROTECTED]http://erkle.org/
account for so /var/log/pflog is filling up nicely. Taking a few
sample lines from the output of:
# tcpdump -n -r /var/log/pflog
13:35:07.985465 220.135.151.10.1254 > 195.224.72.148.25: S
108231586:108231586(0) win 65535 (DF)
13:35:08.384197 195.224.72.148.59258 > 195.224.72.
Am Freitag, den 17.03.2006, 10:58 +0100 schrieb Mark Prins:
Hi,
> set loginterface ?
Wasn't configured, right. So I did this with the correct interface but
still the same problem. But thanks a lot for your hint!
Maybe this has nothing to do with my pflog-problem but I also don't
u
[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> wrote on :
> Hi,
>
> I want to log some pf-rules via pflog but unfortunately simply nothing
> gets logged although I think I did the correct steps:
>
> - created rules that include something like 'pass in log (all) o
Hi,
I want to log some pf-rules via pflog but unfortunately simply nothing
gets logged although I think I did the correct steps:
- created rules that include something like 'pass in log (all) on...'
(actually the rules themselves work and let packets pass)
- ifconfig up pflog0 (&#
most of them are
>> >>pretty minimal having a NATted LAN and the only traffic allowed in
>> >>(other than replies to outbound) is ssh.
>> >>
>> >>The pf.confs are pretty much modifications of a template one with just
>> >>the LAN IPs chan
n
> >>(other than replies to outbound) is ssh.
> >>
> >>The pf.confs are pretty much modifications of a template one with just
> >>the LAN IPs changing.
> >>
> >>The changes in /etc/* are also the same for all of them.
> >>
> >>Jus
und) is ssh.
>>
>>The pf.confs are pretty much modifications of a template one with just
>>the LAN IPs changing.
>>
>>The changes in /etc/* are also the same for all of them.
>>
>>Just one is not getting anything in pflog. pflogd is running.
>>
>>
s changing.
The changes in /etc/* are also the same for all of them.
Just one is not getting anything in pflog. pflogd is running.
Is there an empty /var/log/pflog, or *no* /var/log/pflog? (just guessing)
--
Darrin Chandler| Phoenix BSD Users Group
[EMAIL PROTECTED]
es in /etc/* are also the same for all of them.
Just one is not getting anything in pflog. pflogd is running. ps auxwww
says:
_pflogd 14121 0.0 0.1 640 244 ?? S 15Feb060:21.15
pflogd: [running] -s 116 -f /var/log/pflog (pflogd)
There are rules like:
block return-icmp in log quick from
I've turned to the "rulenum"
or "rdr" feature of tcpdump's filter criteria, which works on packets
logged by pf(4).
I know that if I simply enable logging on all of the packets I want to
see, using pf-based tcpdump filter criteria works like a charm. The
problem I have is
1 - 100 of 124 matches
Mail list logo
