Re: counting dropped packets for pf

[Mihai Popescu]

> ... better badly does work ...

If it so, then it should not be done from the start.
A bad implementation can trigger other problems.
Try to think a little bit. ( hint: Chernobyl)

Re: counting dropped packets for pf

[3]

> On Fri, Mar 30, 2018 at 9:58 AM, 3  wrote:
>> perhaps my poor english prevented you from understanding the question

> perhaps

>> my initial approach does work. u are have comments about route-to?

> If people do not understand the words you use to represent the ideas
> you were thinking, does that matter?
i showed my idea on the example of pf's config- this language should
be familiar to you

> If there are more efficient ways of accomplishing the same thing, is
> it important?
no more effective ways. the variant with pfctl is a kolhoz-style(ugly
and ineffective), it requires a lot of work to convert data into
netflow format

> [regardless, I am going back to lurking and trying to figure out a
> good way to install current on a system I use.]

> Thanks,

Re: counting dropped packets for pf

[Raul Miller]

On Fri, Mar 30, 2018 at 10:35 AM, 3  wrote:
> i showed my idea on the example of pf's config- this language should
> be familiar to you
...
> no more effective ways. the variant with pfctl is a kolhoz-style(ugly
> and ineffective), it requires a lot of work to convert data into
> netflow format

You did indeed show some rules that would do something if you replace
some of their text with something else but which do not address the
issue you had earlier labeled "impossible".

But, if you will excuse me, I have a lot of work to do.

-- 
Raul

Re: counting dropped packets for pf

[Raul Miller]

On Fri, Mar 30, 2018 at 9:58 AM, 3  wrote:
> perhaps my poor english prevented you from understanding the question

perhaps

> my initial approach does work. u are have comments about route-to?

If people do not understand the words you use to represent the ideas
you were thinking, does that matter?

If there are more efficient ways of accomplishing the same thing, is
it important?

[regardless, I am going back to lurking and trying to figure out a
good way to install current on a system I use.]

Thanks,

-- 
Raul

Re: counting dropped packets for pf

[3]

> On 03/30/18 13:32, 3 wrote:

>> people like you do not understand what better badly does work than
>> well not works. and it is not our(not ordinary users) fault that the

> Seriously, cipher, you're just spewing word salad again.

> And it sounds vaguely like abuse, aimed at people who were in fact
> offering useful suggestions.
to give useful suggestions first need to understand the question.
perhaps my poor english prevented you from understanding the question

> Some of us were able to decipher what we thought was your problem
> (wanting to record dropped packets) and offered suggestions on how to do
> that along with the explanation why your original approach was never
> going to work.
my initial approach does work. u are have comments about route-to?

> If you really want to record your dropped packets in a netflow format,
> there's nothing stopping you from implementing just that.
in next time remind yourself that you can surgery on your own, instead
of going to a surgeon

> Whether your implementation will be accepted back the OpenBSD source
> tree is of course a different and separate question.
i am a ordinary user(not a surgeon) and have already talked about it,
but my poor english..

> One thing is certain, though: Spewing abuse-ish word salad at mailing
> lists is not going to get you anywhere.
sorry about that -_- i should have left as soon as i understand we
were living in different worlds

Re: counting dropped packets for pf

[Peter N. M. Hansteen]

On 03/30/18 13:32, 3 wrote:

> people like you do not understand what better badly does work than
> well not works. and it is not our(not ordinary users) fault that the

Seriously, cipher, you're just spewing word salad again.

And it sounds vaguely like abuse, aimed at people who were in fact
offering useful suggestions.

Some of us were able to decipher what we thought was your problem
(wanting to record dropped packets) and offered suggestions on how to do
that along with the explanation why your original approach was never
going to work.

If you really want to record your dropped packets in a netflow format,
there's nothing stopping you from implementing just that.

Whether your implementation will be accepted back the OpenBSD source
tree is of course a different and separate question.

One thing is certain, though: Spewing abuse-ish word salad at mailing
lists is not going to get you anywhere.

-- 
Peter N. M. Hansteen, member of the first RFC 1149 implementation team
http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/
"Remember to set the evil bit on all malicious network traffic"
delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.

Re: counting dropped packets for pf

[3]

>> You would need a 1/4" wrench and a screwdriver tip that fits an impact 
>> driver.

> I want to see you using your method for a deep sunken screw inside a
> cylindrical channel of a case.
> You can give a chance to the other guy, too.
> People like you do not understand concepts like evolution, smart
> tools, unix simplicity, KISS, etc.

people like you do not understand what better badly does work than
well not works. and it is not our(not ordinary users) fault that the
progress of obsd is only to cut poorly functioning parts without
giving anything instead. teo and your ideal fucking unix system is
"hello, world!" with two remote holes in the default install. but you
are too d^Hstubborn to understand that such a system is not necessary
for ordinary users. i like pf and i hate dirty monkey's style of
linux, but there will come a time when this will not be enough to
choose obsd

Re: counting dropped packets for pf

[edgar]

On Mar 30, 2018 4:08 AM, Mihai Popescu  wrote:
>
> > You would need a 1/4" wrench and a screwdriver tip that fits an impact 
> > driver.
>
> I want to see you using your method for a deep sunken screw inside a
> cylindrical channel of a case.
> You can give a chance to the other guy, too.
> People like you do not understand concepts like evolution, smart
> tools, unix simplicity, KISS, etc.
>

First let me say I believe '3' to be a bit of an arsehole and was surprised he 
received any helpful responses. However the above is a perfect example of Unix. 
Perhaps you haven't used '|' to combine utility programs.  

Re: counting dropped packets for pf

[Mihai Popescu]

> You would need a 1/4" wrench and a screwdriver tip that fits an impact driver.

I want to see you using your method for a deep sunken screw inside a
cylindrical channel of a case.
You can give a chance to the other guy, too.
People like you do not understand concepts like evolution, smart
tools, unix simplicity, KISS, etc.

Re: counting dropped packets for pf

[3]

> man pf.conf is your friend, please consult there before letting
> resentment stew for years next time, huh?

why are you silent? do you have the courage to admit that the famous
russian comedian zadornov was right when said "ну тупые!"? ;)

Re: counting dropped packets for pf

[3]

> On 03/28/18 22:03, 3 wrote:

>> maybe im so dumb and blind to see pflow here.. and maybe deal not in
>> me. where is pflow?

> pflow gets the data it exports from the state table.
> Blocked connections do not create state table entries.
> This means that pflow does not have the information you're looking for.
> You can still get detailed information about blocked connection
> attempts, in the aggregate via labels as I showed you, or from pflog.
> You could even have your block rules logged to a separate pflog interface.
> Others have alredy pointed you at other alternatives. Obsessing about
> pflow unfortunately isn't going to get you anywhere. Exploring the other
> options might.

i accept your challenge! ^^
but first i will describe my scheme of pf.conf(this is important):

block all # default block
match from (self) tag PASS # default output

match bla-bla1 to (self) tag PASS
match bla-bla2 to (self) tag PASS
..
match bla-blaN to (self) tag PASS

match from lan:network tag PASS # its actually an anchor here, loadable from 
match to lan:network tag PASS   # another file, but it does not matter

match out on egress inet from !(self) tagged PASS nat-to (egress) # nat
pass quick tagged PASS # one(no other) final pass

-- in this place we have all the packets that were not accepted and
that will be later blocked by the default block.
-- we need only those who entered on egress(pppoe0 for me):
pass in quick on pppoe0 all route-to(vether0 10.0.0.1) keep state (pflow) # any 
fake inteface is here
-- now all these packets selected by us get back to the entrance of the 
rules(before default block).
-- we can leave them as they are, but its better to delete them:
block quick on vether0 # need to place as the first rule
-- lets see what we have got if enable logging:

Mar 29 20:42:46.984161 rule 92/(match) [uid 0, pid 54243] pass in on pppoe0: 
24.201.182.114.46574 > 188.235.31.7.36824: [udp sum ok] udp 20 [tos 0x70] (ttl 
53, id 5542, len 48)
Mar 29 20:42:46.984176 rule 0/(match) [uid 0, pid 54243] block out on vether0: 
24.201.182.114.46574 > 188.235.31.7.36824: [udp sum ok] udp 20 [tos 0x70] (ttl 
53, id 5542, len 48)
.. and more(i found four matching packets in this interval, but it is difficult 
to synchronize pf's log and log of the flowd)

process_flow: ACCEPT flow FLOW recv_time 2018-03-29T20:43:42.634715 proto 17 
tcpflags 00 tos 00 agent [127.0.0.1] src [24.201.182.114]:46574 dst 
[188.235.31.7]:36824 gateway [0.0.0.0] packets 3 octets 144 in_if 7 out_if 0 
sys_uptime_ms 2h20m51s.000 time_sec 2018-03-29T20:43:42 time_nanosec 634520582 
netflow ver 5 flow_start 2h19m55s.000 flow_finish 2h20m5s.000 src_AS 0 
src_masklen 0 dst_AS 0 dst_masklen 0 engine_type 10752 engine_id 10752 seq 
11273 source 0 crc32  
output_flow_enqueue: offset 1624 alloc 16384 

-- what you say? ;)

Re: counting dropped packets for pf

[3]

Вы писали 29 марта 2018 г., 16:35:45:

> On Wed, Mar 28, 2018, at 7:10 PM, 3 wrote:
>> > 3(ba...@yandex.ru) on 2018.03.28 23:03:27 +0300:
>> >> > On 03/28/18 15:04, 3 wrote:
>> >> >> hi guys. when the pflow option first appeared, i was surprised by the
>> >> >> stupidity of those who implemented it- pflow could not be specified
>> >> >> for block-rules, i.e. dropped packets were not taken into account. as
>> i understand- no kosher ways. im asking for illegal ways. many years
>> ago there was no way either, but i found a way out. i dont think you
>> are dumber than me
>> 

> You are asking, "How do I use a wrench as a screwdriver?"

yep. and comrade ed...@pettijohn-web.com understand me.

hello, edgar. you are smart ^_^

Re: counting dropped packets for pf

[edgar]

On Mar 29, 2018 8:35 AM, Eric Furman  wrote:
>
> On Wed, Mar 28, 2018, at 7:10 PM, 3 wrote:
> > > 3(ba...@yandex.ru) on 2018.03.28 23:03:27 +0300:
> > >> > On 03/28/18 15:04, 3 wrote:
> > >> >> hi guys. when the pflow option first appeared, i was surprised by the
> > >> >> stupidity of those who implemented it- pflow could not be specified
> > >> >> for block-rules, i.e. dropped packets were not taken into account. as
> > i understand- no kosher ways. im asking for illegal ways. many years
> > ago there was no way either, but i found a way out. i dont think you
> > are dumber than me
> > 
>
> You are asking, "How do I use a wrench as a screwdriver?"
>

You would need a 1/4" wrench and a screwdriver tip that fits an impact driver.

Re: counting dropped packets for pf

[Eric Furman]

On Wed, Mar 28, 2018, at 7:10 PM, 3 wrote:
> > 3(ba...@yandex.ru) on 2018.03.28 23:03:27 +0300:
> >> > On 03/28/18 15:04, 3 wrote:
> >> >> hi guys. when the pflow option first appeared, i was surprised by the
> >> >> stupidity of those who implemented it- pflow could not be specified
> >> >> for block-rules, i.e. dropped packets were not taken into account. as
> i understand- no kosher ways. im asking for illegal ways. many years
> ago there was no way either, but i found a way out. i dont think you
> are dumber than me
> 

You are asking, "How do I use a wrench as a screwdriver?"

Re: counting dropped packets for pf

[Peter N. M. Hansteen]

On 03/28/18 22:03, 3 wrote:

> maybe im so dumb and blind to see pflow here.. and maybe deal not in
> me. where is pflow?

pflow gets the data it exports from the state table.

Blocked connections do not create state table entries.

This means that pflow does not have the information you're looking for.

You can still get detailed information about blocked connection
attempts, in the aggregate via labels as I showed you, or from pflog.

You could even have your block rules logged to a separate pflog interface.

Others have alredy pointed you at other alternatives. Obsessing about
pflow unfortunately isn't going to get you anywhere. Exploring the other
options might.

-- 
Peter N. M. Hansteen, member of the first RFC 1149 implementation team
http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/
"Remember to set the evil bit on all malicious network traffic"
delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.

Re: counting dropped packets for pf

[Stuart Henderson]

On 2018-03-28, 3  wrote:
> hi guys. when the pflow option first appeared, i was surprised by the
> stupidity of those who implemented it- pflow could not be specified
> for block-rules, i.e. dropped packets were not taken into account. as
> a result of this approach, the usefulness of pflow sought to zero for
> those cases where traffic really had to be counted. but then i found
> the way out- the default blocking rule first duplicated packets on a
> special, only for this created localhost, which had only one rule -
> receiving all incoming packets and the pflow option set, this allowed
> to take into account dropped packets too. now i updated system, and
> saw that the low level taken by developers fell even lower- now it is
> impossible to specify dub-to for block-rules. i dont know how to get
> around this now, im a simple user and tired of fighting hands-from-ass
> developers. can anyone share their hacks for this?
>
> ps: sry for my english

The English is mostly readable, the attitude is rather abrasive though.

pflow hooks into pf states. There is no state for a blocked packet.
I think you'll be happier with a BPF-based flow capture tool, there
are two in ports.

Re: counting dropped packets for pf

[Sebastian Benoit]

3(ba...@yandex.ru) on 2018.03.29 02:10:29 +0300:
> > 3(ba...@yandex.ru) on 2018.03.28 23:03:27 +0300:
> >> > On 03/28/18 15:04, 3 wrote:
> >> >> hi guys. when the pflow option first appeared, i was surprised by the
> >> >> stupidity of those who implemented it- pflow could not be specified
> >> >> for block-rules, i.e. dropped packets were not taken into account. as
> >> 
> >> > hm. you've suffered nine years of this stupidity of others but have not
> >> > been able to add labels to your block rules?
> >> 
> >> > Just as an experiment I added labels to the block rules on my
> >> > most-easily-reachable-from-here gateway, as in
> >> 
> >> > block log (all) label blockgen
> >> > block drop log (all) quick from  label portalbrutes
> >> > block drop log (all) quick from  label abusives
> >> > block drop log (all) quick from  label webtrash
> >> > block drop log (all) quick from  label bruteforce
> >> 
> >> > block drop log (all) quick from  label longterm
> >> > block in log (all) on ! lo0 proto tcp to port 6000:6010 label remotex11
> >> 
> >> > and voila, pfctl -sl gives me after a few minutes
> >> 
> >> > [Wed Mar 28 16:15:29] peter@skapet:~$ sudo pfctl -vsl
> >> > blockgen 3739 452 19856 448 19664 4 192 0
> >> > portalbrutes 3739 0 0 0 0 0 0 0
> >> > abusives 3739 301 14681 301 14681 0 0 0
> >> > webtrash 3438 0 0 0 0 0 0 0
> >> > bruteforce 3438 0 0 0 0 0 0 0
> >> > longterm 3438 0 0 0 0 0 0 0
> >> > remotex11 3438 0 0 0 0 0 0 0
> >> 
> >> > man pf.conf is your friend, please consult there before letting
> >> > resentment stew for years next time, huh?
> >> 
> >> maybe im so dumb and blind to see pflow here.. and maybe deal not in
> >> me. where is pflow?
> 
> > pflow can't export data for blocked packets.
> > It also does not send statistics.
> 
> i understand- no kosher ways.

yes is a kosher way: send a diff.

> im asking for illegal ways. many years
> ago there was no way either, but i found a way out. i dont think you
> are dumber than me

Re: counting dropped packets for pf

[3]

> 3(ba...@yandex.ru) on 2018.03.28 23:03:27 +0300:
>> > On 03/28/18 15:04, 3 wrote:
>> >> hi guys. when the pflow option first appeared, i was surprised by the
>> >> stupidity of those who implemented it- pflow could not be specified
>> >> for block-rules, i.e. dropped packets were not taken into account. as
>> 
>> > hm. you've suffered nine years of this stupidity of others but have not
>> > been able to add labels to your block rules?
>> 
>> > Just as an experiment I added labels to the block rules on my
>> > most-easily-reachable-from-here gateway, as in
>> 
>> > block log (all) label blockgen
>> > block drop log (all) quick from  label portalbrutes
>> > block drop log (all) quick from  label abusives
>> > block drop log (all) quick from  label webtrash
>> > block drop log (all) quick from  label bruteforce
>> 
>> > block drop log (all) quick from  label longterm
>> > block in log (all) on ! lo0 proto tcp to port 6000:6010 label remotex11
>> 
>> > and voila, pfctl -sl gives me after a few minutes
>> 
>> > [Wed Mar 28 16:15:29] peter@skapet:~$ sudo pfctl -vsl
>> > blockgen 3739 452 19856 448 19664 4 192 0
>> > portalbrutes 3739 0 0 0 0 0 0 0
>> > abusives 3739 301 14681 301 14681 0 0 0
>> > webtrash 3438 0 0 0 0 0 0 0
>> > bruteforce 3438 0 0 0 0 0 0 0
>> > longterm 3438 0 0 0 0 0 0 0
>> > remotex11 3438 0 0 0 0 0 0 0
>> 
>> > man pf.conf is your friend, please consult there before letting
>> > resentment stew for years next time, huh?
>> 
>> maybe im so dumb and blind to see pflow here.. and maybe deal not in
>> me. where is pflow?

> pflow can't export data for blocked packets.
> It also does not send statistics.

i understand- no kosher ways. im asking for illegal ways. many years
ago there was no way either, but i found a way out. i dont think you
are dumber than me

Re: counting dropped packets for pf

[Sebastian Benoit]

3(ba...@yandex.ru) on 2018.03.28 23:03:27 +0300:
> > On 03/28/18 15:04, 3 wrote:
> >> hi guys. when the pflow option first appeared, i was surprised by the
> >> stupidity of those who implemented it- pflow could not be specified
> >> for block-rules, i.e. dropped packets were not taken into account. as
> 
> > hm. you've suffered nine years of this stupidity of others but have not
> > been able to add labels to your block rules?
> 
> > Just as an experiment I added labels to the block rules on my
> > most-easily-reachable-from-here gateway, as in
> 
> > block log (all) label blockgen
> > block drop log (all) quick from  label portalbrutes
> > block drop log (all) quick from  label abusives
> > block drop log (all) quick from  label webtrash
> > block drop log (all) quick from  label bruteforce
> 
> > block drop log (all) quick from  label longterm
> > block in log (all) on ! lo0 proto tcp to port 6000:6010 label remotex11
> 
> > and voila, pfctl -sl gives me after a few minutes
> 
> > [Wed Mar 28 16:15:29] peter@skapet:~$ sudo pfctl -vsl
> > blockgen 3739 452 19856 448 19664 4 192 0
> > portalbrutes 3739 0 0 0 0 0 0 0
> > abusives 3739 301 14681 301 14681 0 0 0
> > webtrash 3438 0 0 0 0 0 0 0
> > bruteforce 3438 0 0 0 0 0 0 0
> > longterm 3438 0 0 0 0 0 0 0
> > remotex11 3438 0 0 0 0 0 0 0
> 
> > man pf.conf is your friend, please consult there before letting
> > resentment stew for years next time, huh?
> 
> maybe im so dumb and blind to see pflow here.. and maybe deal not in
> me. where is pflow?

pflow can't export data for blocked packets.
It also does not send statistics.

Re: counting dropped packets for pf

[3]

> https://man.openbsd.org/pflow.4

> On Wed, Mar 28, 2018 at 4:03 PM, 3  wrote:

>> On 03/28/18 15:04, 3 wrote:
 >>> hi guys. when the pflow option first appeared, i was surprised by the
 >>> stupidity of those who implemented it- pflow could not be specified
 >>> for block-rules, i.e. dropped packets were not taken into account. as

 >> hm. you've suffered nine years of this stupidity of others but have not
 >> been able to add labels to your block rules?

 >> Just as an experiment I added labels to the block rules on my
 >> most-easily-reachable-from-here gateway, as in

 >> block log (all) label blockgen
 >> block drop log (all) quick from  label portalbrutes
 >> block drop log (all) quick from  label abusives
 >> block drop log (all) quick from  label webtrash
 >> block drop log (all) quick from  label bruteforce

 >> block drop log (all) quick from  label longterm
 >> block in log (all) on ! lo0 proto tcp to port 6000:6010 label remotex11

 >> and voila, pfctl -sl gives me after a few minutes

 >> [Wed Mar 28 16:15:29] peter@skapet:~$ sudo pfctl -vsl
 >> blockgen 3739 452 19856 448 19664 4 192 0
 >> portalbrutes 3739 0 0 0 0 0 0 0
 >> abusives 3739 301 14681 301 14681 0 0 0
 >> webtrash 3438 0 0 0 0 0 0 0
 >> bruteforce 3438 0 0 0 0 0 0 0
 >> longterm 3438 0 0 0 0 0 0 0
 >> remotex11 3438 0 0 0 0 0 0 0

 >> man pf.conf is your friend, please consult there before letting
 >> resentment stew for years next time, huh?

> maybe im so dumb and blind to see pflow here.. and maybe deal not in
>  me. where is pflow?

continue your thought. we have the output of the pfctl -vsl command,
which in this form is useless, since the output is needed in the
netflow format. there is a man pflow - one piece(its not clear why we
need it if we abandoned the pflow and went to the output of pfctl
-vsl). how do cooking a netflow stream from this?

Re: counting dropped packets for pf

[sven falempin]

https://man.openbsd.org/pflow.4

On Wed, Mar 28, 2018 at 4:03 PM, 3  wrote:

> > On 03/28/18 15:04, 3 wrote:
> >> hi guys. when the pflow option first appeared, i was surprised by the
> >> stupidity of those who implemented it- pflow could not be specified
> >> for block-rules, i.e. dropped packets were not taken into account. as
>
> > hm. you've suffered nine years of this stupidity of others but have not
> > been able to add labels to your block rules?
>
> > Just as an experiment I added labels to the block rules on my
> > most-easily-reachable-from-here gateway, as in
>
> > block log (all) label blockgen
> > block drop log (all) quick from  label portalbrutes
> > block drop log (all) quick from  label abusives
> > block drop log (all) quick from  label webtrash
> > block drop log (all) quick from  label bruteforce
>
> > block drop log (all) quick from  label longterm
> > block in log (all) on ! lo0 proto tcp to port 6000:6010 label remotex11
>
> > and voila, pfctl -sl gives me after a few minutes
>
> > [Wed Mar 28 16:15:29] peter@skapet:~$ sudo pfctl -vsl
> > blockgen 3739 452 19856 448 19664 4 192 0
> > portalbrutes 3739 0 0 0 0 0 0 0
> > abusives 3739 301 14681 301 14681 0 0 0
> > webtrash 3438 0 0 0 0 0 0 0
> > bruteforce 3438 0 0 0 0 0 0 0
> > longterm 3438 0 0 0 0 0 0 0
> > remotex11 3438 0 0 0 0 0 0 0
>
> > man pf.conf is your friend, please consult there before letting
> > resentment stew for years next time, huh?
>
> maybe im so dumb and blind to see pflow here.. and maybe deal not in
> me. where is pflow?
>
>


-- 
--
-
Knowing is not enough; we must apply. Willing is not enough; we must do

Re: counting dropped packets for pf

[3]

> On 03/28/18 15:04, 3 wrote:
>> hi guys. when the pflow option first appeared, i was surprised by the
>> stupidity of those who implemented it- pflow could not be specified
>> for block-rules, i.e. dropped packets were not taken into account. as

> hm. you've suffered nine years of this stupidity of others but have not
> been able to add labels to your block rules?

> Just as an experiment I added labels to the block rules on my
> most-easily-reachable-from-here gateway, as in

> block log (all) label blockgen
> block drop log (all) quick from  label portalbrutes
> block drop log (all) quick from  label abusives
> block drop log (all) quick from  label webtrash
> block drop log (all) quick from  label bruteforce

> block drop log (all) quick from  label longterm
> block in log (all) on ! lo0 proto tcp to port 6000:6010 label remotex11

> and voila, pfctl -sl gives me after a few minutes

> [Wed Mar 28 16:15:29] peter@skapet:~$ sudo pfctl -vsl
> blockgen 3739 452 19856 448 19664 4 192 0
> portalbrutes 3739 0 0 0 0 0 0 0
> abusives 3739 301 14681 301 14681 0 0 0
> webtrash 3438 0 0 0 0 0 0 0
> bruteforce 3438 0 0 0 0 0 0 0
> longterm 3438 0 0 0 0 0 0 0
> remotex11 3438 0 0 0 0 0 0 0

> man pf.conf is your friend, please consult there before letting
> resentment stew for years next time, huh?

maybe im so dumb and blind to see pflow here.. and maybe deal not in
me. where is pflow?

Re: counting dropped packets for pf

[Peter N. M. Hansteen]

On 03/28/18 15:04, 3 wrote:
> hi guys. when the pflow option first appeared, i was surprised by the
> stupidity of those who implemented it- pflow could not be specified
> for block-rules, i.e. dropped packets were not taken into account. as

hm. you've suffered nine years of this stupidity of others but have not
been able to add labels to your block rules?

Just as an experiment I added labels to the block rules on my
most-easily-reachable-from-here gateway, as in

block log (all) label blockgen
block drop log (all) quick from  label portalbrutes
block drop log (all) quick from  label abusives
block drop log (all) quick from  label webtrash
block drop log (all) quick from  label bruteforce

block drop log (all) quick from  label longterm
block in log (all) on ! lo0 proto tcp to port 6000:6010 label remotex11

and voila, pfctl -sl gives me after a few minutes

[Wed Mar 28 16:15:29] peter@skapet:~$ sudo pfctl -vsl
blockgen 3739 452 19856 448 19664 4 192 0
portalbrutes 3739 0 0 0 0 0 0 0
abusives 3739 301 14681 301 14681 0 0 0
webtrash 3438 0 0 0 0 0 0 0
bruteforce 3438 0 0 0 0 0 0 0
longterm 3438 0 0 0 0 0 0 0
remotex11 3438 0 0 0 0 0 0 0

man pf.conf is your friend, please consult there before letting
resentment stew for years next time, huh?

-- 
Peter N. M. Hansteen, member of the first RFC 1149 implementation team
http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/
"Remember to set the evil bit on all malicious network traffic"
delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.