Re: Linux Foundation to fund OpenSSL
"AHLSENGIRARD, EDWARD F CTR USAF AFSOC AFSOC A6/A6OK" 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