Discussion:
counting dropped packets for pf
3
2018-03-28 13:04:26 UTC
Permalink
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
Peter N. M. Hansteen
2018-03-28 14:17:32 UTC
Permalink
Post by 3
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 <portalbrutes> label portalbrutes
block drop log (all) quick from <abusives> label abusives
block drop log (all) quick from <webtrash> label webtrash
block drop log (all) quick from <bruteforce> label bruteforce

block drop log (all) quick from <longterm> 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] ***@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.
3
2018-03-28 20:03:27 UTC
Permalink
Post by Peter N. M. Hansteen
Post by 3
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 <portalbrutes> label portalbrutes
block drop log (all) quick from <abusives> label abusives
block drop log (all) quick from <webtrash> label webtrash
block drop log (all) quick from <bruteforce> label bruteforce
block drop log (all) quick from <longterm> 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
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?
sven falempin
2018-03-28 21:03:10 UTC
Permalink
https://man.openbsd.org/pflow.4
Post by 3
Post by Peter N. M. Hansteen
Post by 3
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 <portalbrutes> label portalbrutes
block drop log (all) quick from <abusives> label abusives
block drop log (all) quick from <webtrash> label webtrash
block drop log (all) quick from <bruteforce> label bruteforce
block drop log (all) quick from <longterm> 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
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
3
2018-03-28 21:19:00 UTC
Permalink
Post by sven falempin
https://man.openbsd.org/pflow.4
Post by Peter N. M. Hansteen
Post by 3
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 <portalbrutes> label portalbrutes
block drop log (all) quick from <abusives> label abusives
block drop log (all) quick from <webtrash> label webtrash
block drop log (all) quick from <bruteforce> label bruteforce
block drop log (all) quick from <longterm> 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
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?
Sebastian Benoit
2018-03-28 22:59:32 UTC
Permalink
Post by 3
Post by Peter N. M. Hansteen
Post by 3
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 <portalbrutes> label portalbrutes
block drop log (all) quick from <abusives> label abusives
block drop log (all) quick from <webtrash> label webtrash
block drop log (all) quick from <bruteforce> label bruteforce
block drop log (all) quick from <longterm> 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
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.
3
2018-03-28 23:10:29 UTC
Permalink
Post by Sebastian Benoit
Post by 3
Post by Peter N. M. Hansteen
Post by 3
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 <portalbrutes> label portalbrutes
block drop log (all) quick from <abusives> label abusives
block drop log (all) quick from <webtrash> label webtrash
block drop log (all) quick from <bruteforce> label bruteforce
block drop log (all) quick from <longterm> 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
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
Sebastian Benoit
2018-03-29 06:43:32 UTC
Permalink
Post by 3
Post by Sebastian Benoit
Post by 3
Post by Peter N. M. Hansteen
Post by 3
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 <portalbrutes> label portalbrutes
block drop log (all) quick from <abusives> label abusives
block drop log (all) quick from <webtrash> label webtrash
block drop log (all) quick from <bruteforce> label bruteforce
block drop log (all) quick from <longterm> 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
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.
Post by 3
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
Eric Furman
2018-03-29 13:35:45 UTC
Permalink
Post by 3
Post by 3
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?"
3
2018-03-29 14:25:16 UTC
Permalink
Post by Eric Furman
Post by 3
Post by 3
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 ***@pettijohn-web.com understand me.

hello, edgar. you are smart ^_^
Peter N. M. Hansteen
2018-03-29 10:41:45 UTC
Permalink
Post by 3
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.
3
2018-03-29 18:11:33 UTC
Permalink
Post by Peter N. M. Hansteen
Post by 3
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 00000000
output_flow_enqueue: offset 1624 alloc 16384

-- what you say? ;)
3
2018-03-30 06:44:41 UTC
Permalink
Post by Peter N. M. Hansteen
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 "ну тупые!"? ;)
Stuart Henderson
2018-03-29 08:40:34 UTC
Permalink
Post by 3
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.
e***@pettijohn-web.com
2018-03-29 14:10:26 UTC
Permalink
Post by Eric Furman
Post by 3
Post by 3
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.
Mihai Popescu
2018-03-30 09:08:21 UTC
Permalink
Post by e***@pettijohn-web.com
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.
3
2018-03-30 11:32:28 UTC
Permalink
Post by Mihai Popescu
Post by e***@pettijohn-web.com
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
Peter N. M. Hansteen
2018-03-30 12:18:41 UTC
Permalink
Post by 3
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.
3
2018-03-30 13:58:53 UTC
Permalink
Post by Peter N. M. Hansteen
Post by 3
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
Post by Peter N. M. Hansteen
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?
Post by Peter N. M. Hansteen
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
Post by Peter N. M. Hansteen
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..
Post by Peter N. M. Hansteen
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
Raul Miller
2018-03-30 14:17:53 UTC
Permalink
Post by 3
perhaps my poor english prevented you from understanding the question
perhaps
Post by 3
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
Raul Miller
2018-03-30 15:19:08 UTC
Permalink
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
e***@pettijohn-web.com
2018-03-30 11:23:49 UTC
Permalink
Post by Mihai Popescu
Post by e***@pettijohn-web.com
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.
Mihai Popescu
2018-03-30 20:29:49 UTC
Permalink
... 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)

Loading...