Re: Linux Foundation to fund OpenSSL
AHLSENGIRARD, EDWARD F CTR USAF AFSOC AFSOC A6/A6OK edward.ahlsengirard.2@us.af.mil writes: This just in: http://www.theinquirer.net/inquirer/news/2347534/linux-foundation-thro\ ws-money-at-openssl-staffing-post-heartbleed If tweets attributed to the Linux Foundation are anything to go by, this does not necessarly mean they have decided against supporting LibreSSL yet. IIRC they said all options are on the table when it comes to LibreSSL, so I guess we, the unwashed masses, will just have to wait and let the OpenBSD Foundation continue the effort to persuade this lot and everybody else to contribute. - Peter -- 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: encrypted vnd Fwd: CVS: cvs.openbsd.org: src
On Fri, May 30, 2014 at 19:45, Jonathan Thornburg wrote: What will be the right way to achieve such a nested-encryption setup once encrypted vnd goes away? Is/will it be safe (i.e., free from data corruption, deadlock, or other kernel badness) to nest softraid crypto volumes? Short answer: it should be. Long answer: if it's not, it would be better to know about problems now rather than later, no?
Re: hibernate fails to restore on i386
On Fri, May 30, 2014 at 09:38:20PM -0700, Mike Larkin wrote: I've got a couple of diffs pending for corruption during unpack during resume. I hope to get those in in the next few days. Thank you, I'll keep an eye out for them. I fixed the format specifier. Thanks. Thanks!
netflow srcip and dstip reversed for redirected traffic
Hi,
I'm trying to understand and measure traffic on relatively large and
complicated pf firewall, and for this purpose I am exporting netflow
data with pflow to nfsen/nfdump.
For the time being, I have set pflow on external interface in outbound
direction:
pass out on $if_ext inet all keep state (pflow)
On collector (nfsen), I want to see interface numbers so i can create
interface filter:
% nfdump -R 2014 -s if/bytes
Top 10 In/Out If ordered by bytes:
If Flows(%) Packets(%) Bytes(%) pps bps bpp
519396(100.0) 300683(100.0) 186.7 M(100.0)316984 620
719109(98.5)299769(99.7)186.6 M(100.0)316976 622
0 287( 1.5) 914( 0.3)83170( 0.0) 0 33090
Another mailing list member told me I can find about interface numbers
with snmpwalk:
% snmpwalk -v2c -c community -On IP.ADD.RE.SS
.1.3.6.1.2.1.2.2.1.2.5 = STRING: bnx1
.1.3.6.1.2.1.2.2.1.2.7 = STRING: carp2
Ok, now I know interface 5 is bnx1 ($if_ext), and I want to know what
comes in:
% nfdump -R 2014 -s dstip/bytes 'in if 5'
Top 10 Dst IP Addr ordered by bytes:
Dst IP AddrFlows(%) Packets(%) Bytes(%)
10.20.0.1510754(62.9) 323834(52.9) 324.9 M(63.7)
10.20.4.99 462( 2.7)10496( 1.7)9.4 M( 1.8)
178.148.77.734( 0.0) 6681( 1.1)7.7 M( 1.5)
First two addresses really are on my internal network, and I know first
one is return web traffic to my proxy, and the second one return web
traffic to another internal host.
But the last address is not on my network. Let's see records for this
address:
nfdump -R 2014 -n 10 -s record/bytes 'in if 5' | grep 178.148.77.73
TCP 193.53.106.35:443 - 178.148.77.73:49193 56067.6 M
TCP 193.53.106.35:443 - 178.148.77.73:49191 31395342
TCP 193.53.106.35:443 - 178.148.77.73:49192 40418674
TCP 193.53.106.35:443 - 178.148.77.73:49190 35816798
Ok, these are redirected incoming requests to HTTPS server on my
internal network:
pass in on $if_ext inet proto tcp from any to $pub_web port { 80 443 } \
rdr-to $priv_web keep state
But source and destination IP adresses are reversed!
Here's what pf's state table shows:
$ sudo pfctl -ss | grep 178.148.77.73
all tcp 10.20.0.36:443 (193.53.106.35:443) - 178.148.77.73:49377
all tcp 178.148.77.73:49377 - 10.20.0.36:443
all tcp 10.20.0.36:443 (193.53.106.35:443) - 178.148.77.73:49378
all tcp 178.148.77.73:49378 - 10.20.0.36:443
all tcp 10.20.0.36:443 (193.53.106.35:443) - 178.148.77.73:49379
all tcp 178.148.77.73:49379 - 10.20.0.36:443
all tcp 10.20.0.36:443 (193.53.106.35:443) - 178.148.77.73:49380
all tcp 178.148.77.73:49380 - 10.20.0.36:443
How could this be corrected? Am I configuring pf incorrectly? Or is
there a problem with how pflow exports data? Or is pfdump parsing the
data incorrectly?
Thank you in advance,
--
Marko Cupać
up-to-date extattr diffs?
Hi, extattr used to be part of OpenBSD but it was removed. Does anybody have up-to-date diffs to enable this? I'd like to play with glusterfs/ceph on OpenBSD but they both depend on extattr to work. jirib
Using OpenBSD for Malware Analysis
Hi everyone, Has anyone used OpenBSD to perform malware analysis? I know radare2 is in ports so was just wondering if anyone had any experience. I know most analysis is done using Linux distros but I'd prefer to use OpenBSD if feasible. Thanks, Shane
Re: netflow srcip and dstip reversed for redirected traffic
Marko Cupa??(marko.cu...@mimar.rs) on 2014.05.31 13:03:18 +0200:
Hi,
I'm trying to understand and measure traffic on relatively large and
complicated pf firewall, and for this purpose I am exporting netflow
data with pflow to nfsen/nfdump.
For the time being, I have set pflow on external interface in outbound
direction:
pass out on $if_ext inet all keep state (pflow)
On collector (nfsen), I want to see interface numbers so i can create
interface filter:
% nfdump -R 2014 -s if/bytes
Top 10 In/Out If ordered by bytes:
If Flows(%) Packets(%) Bytes(%) pps bps bpp
519396(100.0) 300683(100.0) 186.7 M(100.0)316984 620
719109(98.5)299769(99.7)186.6 M(100.0)316976 622
0 287( 1.5) 914( 0.3)83170( 0.0) 0 33090
Another mailing list member told me I can find about interface numbers
with snmpwalk:
% snmpwalk -v2c -c community -On IP.ADD.RE.SS
.1.3.6.1.2.1.2.2.1.2.5 = STRING: bnx1
.1.3.6.1.2.1.2.2.1.2.7 = STRING: carp2
Ok, now I know interface 5 is bnx1 ($if_ext), and I want to know what
comes in:
% nfdump -R 2014 -s dstip/bytes 'in if 5'
Top 10 Dst IP Addr ordered by bytes:
Dst IP AddrFlows(%) Packets(%) Bytes(%)
10.20.0.1510754(62.9) 323834(52.9) 324.9 M(63.7)
10.20.4.99 462( 2.7)10496( 1.7)9.4 M( 1.8)
178.148.77.734( 0.0) 6681( 1.1)7.7 M( 1.5)
First two addresses really are on my internal network, and I know first
one is return web traffic to my proxy, and the second one return web
traffic to another internal host.
But the last address is not on my network. Let's see records for this
address:
nfdump -R 2014 -n 10 -s record/bytes 'in if 5' | grep 178.148.77.73
TCP 193.53.106.35:443 - 178.148.77.73:49193 56067.6 M
TCP 193.53.106.35:443 - 178.148.77.73:49191 31395342
TCP 193.53.106.35:443 - 178.148.77.73:49192 40418674
TCP 193.53.106.35:443 - 178.148.77.73:49190 35816798
Ok, these are redirected incoming requests to HTTPS server on my
internal network:
pass in on $if_ext inet proto tcp from any to $pub_web port { 80 443 } \
rdr-to $priv_web keep state
But source and destination IP adresses are reversed!
Here's what pf's state table shows:
$ sudo pfctl -ss | grep 178.148.77.73
all tcp 10.20.0.36:443 (193.53.106.35:443) - 178.148.77.73:49377
all tcp 178.148.77.73:49377 - 10.20.0.36:443
all tcp 10.20.0.36:443 (193.53.106.35:443) - 178.148.77.73:49378
all tcp 178.148.77.73:49378 - 10.20.0.36:443
all tcp 10.20.0.36:443 (193.53.106.35:443) - 178.148.77.73:49379
all tcp 178.148.77.73:49379 - 10.20.0.36:443
all tcp 10.20.0.36:443 (193.53.106.35:443) - 178.148.77.73:49380
all tcp 178.148.77.73:49380 - 10.20.0.36:443
How could this be corrected? Am I configuring pf incorrectly? Or is
there a problem with how pflow exports data? Or is pfdump parsing the
data incorrectly?
The simple answer: It's complicated.
The complicated answer: the pf state is used to keep track of both
directions of the traffic flow. When the state times out, _two_ flows are
created, one for each direction of traffic, you can see this in
copy_flow_ipfix_4_data() in /usr/src/sys/net/if_pflow.c.
For NAT/RDR its a bit more complicated, so what you are seeing might be
'normal' or a problem.
nfdump should be able to show you both directions of this traffic. Please
check what in and out interface is recorded for each flow, ie grep for
178.148.77.73 but dont restrict on the interface.
Also, please show a dmesg - we need to know what version you are running.
/Benno
Requested upstream patch to use OpenBSD's malloc
I opened a ticket with upstream to use OpenBSD's malloc by default. https://rt.perl.org/Public/Bug/Display.html?id=122000 Perl was setup to use perl's malloc on OpenBSD by default in 2010. https://rt.perl.org/Public/Bug/Display.html?id=75742 The perl in OpenBSD base has always used OpenBSD's malloc, and I believe that is what OpenBSD users will expect, even building perl themselves. If you have opinions that may sway the perl5-porters, please chime in on the above ticket #122000. l8rZ, -- andrew - http://afresh1.com People who invent random theories which only defend the vendor must have been beaten as children. Beaten with sticks. At least, that's my theory. -- Theo De Raadt
