Re: What are the security features in OpenBSD 6.0 that are by default disabled?

[Otto Moerbeek]

On Sat, Oct 15, 2016 at 03:57:57PM -0500, Patrick Dohman wrote:

> The daily security out being emailed is also default disabled ;)
> 
> The monthly & weekly outs never seem to work either.

nonsense. daily security is mailed *if it is non-empty*. Same goes for
weekly and mothly.

-Otto

iked - how to keep traffic outside the tunnel?

[Ted Wynnychenko]

Hello
I recently moved from ipsec/npppd to ikev2.

Making the change went easily enough.

However, there is  something that I can't seem to figure out.

I am using ikev2/ipsec to create a tunnel between two networks.  Each network
faces the internet through a openbsd gateway which gets is public IP via DHCP.


Local Net   --> IPSEC GW--> Internet<--
IPSEC GW<-- Remote Net
10.3.0.0/16 10.3.0.20 (int)
192.168.0.1 (int)   192.168.0.0/24
73.208.x.x (public DHCP)
99.23.x.x (public DHCP)


The iked.conf file on each end is relatively simple.
The "local" end:

ikev2 "static_vpn" quick passive ipcomp esp from 10.3.0.0/16 to 192.168.0.0/24
peer 99.23.x.x srcid local.domain.com dstid remote.domain.com

And, on the "remote" end:

ikev2 "static_vpn" active ipcomp esp from 192.168.0.0/24 to 10.3.0.0/16 peer
73.208.x.x srcid remote.domain.com dstid local.domain.com

This works without an issue.  The tunnel is created, and all traffic gets
forwarded from the two networks as expected.

I can also contact (ssh) the "remote" IPSEC GW from a client on the "local" net
via the tunnel (i.e. using 192.168.0.1 as the destination).

But, if I try to connect to the "remote" IPSEC GW using its public IP
(99.23.x.x) from a client on the "local" net, there is no connection.

If I take the tunnel down, then I can connect (ssh) to the public IP of the
remote IPSEC GW again.

But, I don't understand why the traffic destined for the public IP of the remote
IPSEC GW is (apparently??) being intercepted by iked.

The way I read the man page, I was under the impression that only traffic for
"192.168.0.0/24" would be encapsulated in the tunnel (using the rules above);
and that traffic destined for the public IP of the "peer" would be ignored by
iked.

Is there something I am missing?

Thanks

Re: relayd.conf error

[trondd]

On Sat, October 15, 2016 10:47 am, Ali H. Fardan wrote:
> Hey misc@, I'm having issues with relayd.conf. this is the error I get
> when I try to run relayd:
>
>
> # rcctl -df start relayd
> doing _rc_parse_conf
> doing _rc_quirks
> relayd_flags empty, using default ><
> doing _rc_parse_conf /var/run/rc.d/relayd
> doing _rc_quirks
> doing rc_check
> relayd
> doing rc_pre
> host_dns: chat.freenode.net resolves to more than 1 hosts
> host_dns: irc.oftc.net resolves to more than 1 hosts
> /etc/relayd.conf:11: syntax error
> /etc/relayd.conf:12: protocol irctls defined twice
> /etc/relayd.conf:17: syntax error
> /etc/relayd.conf:18: protocol irctls defined twice
> /etc/relayd.conf:23: syntax error
> /etc/relayd.conf:24: protocol irctls defined twice
> /etc/relayd.conf:31: syntax error
> no actions, nothing to do
> doing _rc_rm_runfile
> (failed)
> #
>
>
> using this config:
>
>
> # cat /etc/relayd.conf
> protocol "irctls" {
>  tcp { nodelay, sack }
> }
>
> table { chat.freenode.net }
> table { irc.oftc.net }
> table{ irc.swepipe.se }
> table { irc.krustykrab.restaurant }
>
> relay "freenode" {
>  listen 127.0.0.1 port 7000
>  protocol "irctls"
>  forward with tls to  port 6697
> }
>
> relay "oftc" {
>  listen 127.0.0.1 port 7001
>  protocol "irctls"
>  forward with tls to  port 6697
> }
>
> relay "efnet" {
>  listen 127.0.0.1 port 7002
>  protocol "irctls"
>  forward with tls to  port 6697
> }
>
> relay "volatile" {
>  listen on 127.0.0.1 port 7003
>  protocol "irctls"
>  forward with tls to  6697
> }
> #
>
>
> by the way, this config used to work the last time I tried it on my
> last server, not this though, have relayd.conf syntax change in last
> update?
>

Re-check your config like the errors say.  You're not consistantly using
the correct syntax.

This has an error:
listen 127.0.0.1 port 7000
This does not:
listen on 127.0.0.1 port 7003

This has an error:
forward with tls to  6697
The rest of your forward to lines do not.


Tim.

support for AMD Radeon RX400 series

[lawgiver]

I've acquired an AMD Sapphire Nitro Radeon RX460 video card, a
recently released (August 2016) GPU which is attractive for its
good performance and low TDP.  On amd64-current #2488 Sep 24 2016
it is detected as:

vga1 at pci1 dev 0 function 0 vendor "ATI", unknown product 0x67ef rev 0xcf

There is currently no listed support for this series in the 
manpage, so as expected radeondrm does not attach and there 
is no KMS or X acceleration.

AMD released[0] an open source Linux driver along with the hardware.
Because this card has a new (Polaris) chipset, does/will support for
this chipset in OpenBSD eventually come from upstream somewhere or
from an OpenBSD developer doing a driver port (in which case, would
a hardware donation have value)?

[0] http://www.phoronix.com/scan.php?page=article=amdgpu-rx480-linux=2

OT: While exploring the source tree at /usr/src/sys/dev/pci/drm/radeon/
I found a few typo nits, would patches come here?

Re: What are the security features in OpenBSD 6.0 that are by default disabled?

[bytevolcano]

On Fri, 14 Oct 2016 20:50:20 +0200
"thrph.i...@gmail.com"  wrote:

> or this kind...
> 
> " The only truly secure system is one that is powered off, cast in a
> block of concrete and sealed in a lead-lined room with armed guards -
> and even then I have my doubts. "
> 

It needs to be stored under a filing cabinet in a disused lavatory with
a sign on the door saying Beware of the Leopard.

Re: What are the security features in OpenBSD 6.0 that are by default disabled?

[Patrick Dohman]

The daily security out being emailed is also default disabled ;)

The monthly & weekly outs never seem to work either.

Regards
Patrick


> On Oct 15, 2016, at 11:20 AM, Peter Janos  wrote:
> 
> remote supervisor/console solutions are still turned on while the server
> is off, so simply powering off the OS isn't enough.there were/will be
> many bugs for these remote console solutions too Sent: Friday, October
> 14, 2016 at 9:48 PM
> From: "Raul Miller" 
> To: "thrph.i...@gmail.com" 
> Cc: "OpenBSD general usage list" 
> Subject: Re: What are the security features in OpenBSD 6.0 that are by
> default disabled?On Fri, Oct 14, 2016 at 2:50 PM, thrph.i...@gmail.com
>  wrote:
>> " The only truly secure system is one that is powered off, cast in a
> block of concrete and sealed in a lead-lined room with armed guards - and
> even then I have my doubts. "
> 
> Powered off works surprisingly well for some other operating systems.
> 
> --
> Raul

Re: What are the security features in OpenBSD 6.0 that are by default disabled?

[Raul Miller]

If that is a real issue for you, you should be building your own
hardware and monitoring the electromagnetic spectrum.

-- 
Raul



On Sat, Oct 15, 2016 at 12:20 PM, Peter Janos  wrote:
> remote supervisor/console solutions are still turned on while the server is
> off, so simply powering off the OS isn't enough.
> there were/will be many bugs for these remote console solutions too
>
> Sent: Friday, October 14, 2016 at 9:48 PM
> From: "Raul Miller" 
> To: "thrph.i...@gmail.com" 
> Cc: "OpenBSD general usage list" 
> Subject: Re: What are the security features in OpenBSD 6.0 that are by
> default disabled?
> On Fri, Oct 14, 2016 at 2:50 PM, thrph.i...@gmail.com
>  wrote:
>> " The only truly secure system is one that is powered off, cast in a block
>> of concrete and sealed in a lead-lined room with armed guards - and even
>> then I have my doubts. "
>
> Powered off works surprisingly well for some other operating systems.
>
> --
> Raul

Re: What are the security features in OpenBSD 6.0 that are by default disabled?

[Peter Janos]

remote supervisor/console solutions are still turned on while the server
is off, so simply powering off the OS isn't enough.there were/will be
many bugs for these remote console solutions too Sent: Friday, October
14, 2016 at 9:48 PM
From: "Raul Miller" 
To: "thrph.i...@gmail.com" 
Cc: "OpenBSD general usage list" 
Subject: Re: What are the security features in OpenBSD 6.0 that are by
default disabled?On Fri, Oct 14, 2016 at 2:50 PM, thrph.i...@gmail.com
 wrote:
> " The only truly secure system is one that is powered off, cast in a
block of concrete and sealed in a lead-lined room with armed guards - and
even then I have my doubts. "

Powered off works surprisingly well for some other operating systems.

--
Raul

relayd.conf error

[Ali H. Fardan]

Hey misc@, I'm having issues with relayd.conf. this is the error I get
when I try to run relayd:


# rcctl -df start relayd
doing _rc_parse_conf
doing _rc_quirks
relayd_flags empty, using default ><
doing _rc_parse_conf /var/run/rc.d/relayd
doing _rc_quirks
doing rc_check
relayd
doing rc_pre
host_dns: chat.freenode.net resolves to more than 1 hosts
host_dns: irc.oftc.net resolves to more than 1 hosts
/etc/relayd.conf:11: syntax error
/etc/relayd.conf:12: protocol irctls defined twice
/etc/relayd.conf:17: syntax error
/etc/relayd.conf:18: protocol irctls defined twice
/etc/relayd.conf:23: syntax error
/etc/relayd.conf:24: protocol irctls defined twice
/etc/relayd.conf:31: syntax error
no actions, nothing to do
doing _rc_rm_runfile
(failed)
#


using this config:


# cat /etc/relayd.conf
protocol "irctls" {
tcp { nodelay, sack }
}

table { chat.freenode.net }
table { irc.oftc.net }
table{ irc.swepipe.se }
table { irc.krustykrab.restaurant }

relay "freenode" {
listen 127.0.0.1 port 7000
protocol "irctls"
forward with tls to  port 6697
}

relay "oftc" {
listen 127.0.0.1 port 7001
protocol "irctls"
forward with tls to  port 6697
}

relay "efnet" {
listen 127.0.0.1 port 7002
protocol "irctls"
forward with tls to  port 6697
}

relay "volatile" {
listen on 127.0.0.1 port 7003
protocol "irctls"
forward with tls to  6697
}
#


by the way, this config used to work the last time I tried it on my
last server, not this though, have relayd.conf syntax change in last
update?