Re: interface modifiers :network and :0 picking different subnets for IPv6
On Mon, 27 Jan 2020, Paul de Weerd wrote:
> Hi all,
>
> Following up from my previous (PEBKAC) issue[1], I kept working on my
> ruleset. I found, what I believe to be, another issue. Here's the
> reduced ruleset that reproduces the problem:
> [snip details]
>
> The problem is in the IPv6 rules. Here "em1:network" expands to the
> global unicast network configured on the interface but "em1:0" expands
> to the link-local address. This doesn't really make sense to me. If
> both would expand to the link-local version, that would be unfortunate
> but understandable. I'm hoping to have both expand to the global
> unicast version ("from 2a02:898:28:300::/64 to ! 2a02:898:28:300::1").
>
> Why is pfctl picking different addresses for these two modifiers?
> [...]
> Is there a way to tell pf to use the global unicast address for em1:0
> other than hardcoding the address in the ruleset?
Hi Paul,
Does the patch below help?
I think you have found an oversight in the original implementation of
':0', which defines a non-alias as the first defined address (of the given
address family) [0]. The patch makes ':0' skip link-local addresses,
matching the behaviour of ':network'.
best,
Richard.
[0] sbin/pfctl/pfctl_parser.c 1.186 ifa_lookup()
Index: sbin/pfctl/pfctl_parser.c
===
RCS file: /cvs/src/sbin/pfctl/pfctl_parser.c,v
retrieving revision 1.342
diff -u -p -u -p -r1.342 pfctl_parser.c
--- sbin/pfctl/pfctl_parser.c 17 Oct 2019 21:54:28 - 1.342
+++ sbin/pfctl/pfctl_parser.c 28 Jan 2020 03:11:27 -
@@ -1546,6 +1546,8 @@ ifa_lookup(const char *ifa_name, int fla
continue;
if ((flags & PFI_AFLAG_NETWORK) && p->ifindex > 0)
continue;
+ if ((flags & PFI_AFLAG_NOALIAS) && p->ifindex > 0)
+ continue;
if (last_if == NULL || strcmp(last_if, p->ifname))
got4 = got6 = 0;
last_if = p->ifname;
changed UpdateHostKeys behaviour in current?
I've just updated to the latest snap, and now every SSH connection I make is asking me to accept updated hostkeys. $ ssh somehost Learned new hostkey: RSA SHA256: Learned new hostkey: ED25519 SHA256: Accept updated hostkeys? (yes/no): I see that some changes have been occurring around UpdateHostKeys - https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.bin/ssh/ssh.c Eg https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.bin/ssh/ssh.c?rev=1.415=text/x-cvsweb-markup Is this expected behaviour? Kind of creepy to have every connection ask to accept new host keys at the same time! Thanks
Re: FreeBSD daemon(8)-like command for OpenBSD
I generally do this on a user level with some editors like emacs, cuz I run spacemacs which is prone to crashes, cuz of over 9000 plugins Small improvement: Keep a PID file, along with pgrep, because of multiple emacs-server instances It has worked a bit better than simple pgrep If anyone has any improvements, would love to know. --- Aisha blog.aisha.cc On 2020-01-27 18:21, dagricha...@speakeasy.net wrote: Irresponsible people like myself have been known to put cron jobs in place to look for, and if necessary restart crashy daemons. This could referred to as a kludge, though many would argue that is to mild an aspersion to cast upon it. PID=`pgrep gloob` if [ -z "$PID" ] then /usr/local/bin/gloob -f poor_security_a_bad_idea_to_run.conf fi Dag H. Richards - Distinguished Dunning-Kruger Fellow 2020 as seen on unixadminsgonewild.com On Mon, 27 Jan 2020 22:41:00 +0100, Ingo Schwarze wrote: Hi Patrick, Patrick Kristiansen wrote on Mon, Jan 27, 2020 at 08:13:28PM +0100: Is there something like the FreeBSD daemon(8) command for OpenBSD, which can run a process in the background and restart it if it crashes? Absolutely not, we are strongly convinced this is an utterly stupid idea and a serious security risk. If a daemon crashes, it has a bug. Many bugs that cause crashes are also exploitable. So if a daemon crashes, you first have to understand why it crashed, fix or at least mitigate the bug, and can only restart it afterwards. Restarting it automatically is an irresponsible thing to do. If a daemon keeps crashing so frequently that you can only run it in production with automatic restarts, then running it at all is irresponsible in the first place. Yours, Ingo Hi Patrick, Patrick Kristiansen wrote on Mon, Jan 27, 2020 at 08:13:28PM +0100: Is there something like the FreeBSD daemon(8) command for OpenBSD, which can run a process in the background and restart it if it crashes? Absolutely not, we are strongly convinced this is an utterly stupid idea and a serious security risk. If a daemon crashes, it has a bug. Many bugs that cause crashes are also exploitable. So if a daemon crashes, you first have to understand why it crashed, fix or at least mitigate the bug, and can only restart it afterwards. Restarting it automatically is an irresponsible thing to do. If a daemon keeps crashing so frequently that you can only run it in production with automatic restarts, then running it at all is irresponsible in the first place. Yours, Ingo
Re: FreeBSD daemon(8)-like command for OpenBSD
Irresponsible people like myself have been known to put cron jobs in place to look for, and if necessary restart crashy daemons. This could referred to as a kludge, though many would argue that is to mild an aspersion to cast upon it. PID=`pgrep gloob` if [ -z "$PID" ] then /usr/local/bin/gloob -f poor_security_a_bad_idea_to_run.conf fi Dag H. Richards - Distinguished Dunning-Kruger Fellow 2020 as seen on unixadminsgonewild.com On Mon, 27 Jan 2020 22:41:00 +0100, Ingo Schwarze wrote: Hi Patrick, Patrick Kristiansen wrote on Mon, Jan 27, 2020 at 08:13:28PM +0100: > Is there something like the FreeBSD daemon(8) command for OpenBSD, > which can run a process in the background and restart it if it > crashes? Absolutely not, we are strongly convinced this is an utterly stupid idea and a serious security risk. If a daemon crashes, it has a bug. Many bugs that cause crashes are also exploitable. So if a daemon crashes, you first have to understand why it crashed, fix or at least mitigate the bug, and can only restart it afterwards. Restarting it automatically is an irresponsible thing to do. If a daemon keeps crashing so frequently that you can only run it in production with automatic restarts, then running it at all is irresponsible in the first place. Yours, Ingo Hi Patrick, Patrick Kristiansen wrote on Mon, Jan 27, 2020 at 08:13:28PM +0100: > Is there something like the FreeBSD daemon(8) command for OpenBSD, > which can run a process in the background and restart it if it > crashes? Absolutely not, we are strongly convinced this is an utterly stupid idea and a serious security risk. If a daemon crashes, it has a bug. Many bugs that cause crashes are also exploitable. So if a daemon crashes, you first have to understand why it crashed, fix or at least mitigate the bug, and can only restart it afterwards. Restarting it automatically is an irresponsible thing to do. If a daemon keeps crashing so frequently that you can only run it in production with automatic restarts, then running it at all is irresponsible in the first place. Yours, Ingo
Re: FreeBSD daemon(8)-like command for OpenBSD
Hi Patrick, Patrick Kristiansen wrote on Mon, Jan 27, 2020 at 08:13:28PM +0100: > Is there something like the FreeBSD daemon(8) command for OpenBSD, > which can run a process in the background and restart it if it > crashes? Absolutely not, we are strongly convinced this is an utterly stupid idea and a serious security risk. If a daemon crashes, it has a bug. Many bugs that cause crashes are also exploitable. So if a daemon crashes, you first have to understand why it crashed, fix or at least mitigate the bug, and can only restart it afterwards. Restarting it automatically is an irresponsible thing to do. If a daemon keeps crashing so frequently that you can only run it in production with automatic restarts, then running it at all is irresponsible in the first place. Yours, Ingo
FreeBSD daemon(8)-like command for OpenBSD
Hi everyone, Is there something like the FreeBSD daemon(8) command for OpenBSD, which can run a process in the background and restart it if it crashes? That is, is there a command that comes with OpenBSD's base image with these capabilities? Surprisingly, Google hasn't revealed anything useful to me. Thanks, Patrick Kristiansen
Re: match two conditions in relayd(8)
Joel Carnat(j...@carnat.net) on 2020.01.27 18:21:43 +0100:
> Hi,
>
> I'm setting up an HTTP(S) Reverse Proxy with relayd(8).
>
> I have one listener with multiple FQDN allowed.
> But I also have a common path that must be treated separately.
>
> As for now, I have:
> http protocol "https" {
> match request header "Host" value "one.domain.local" forward to
> match request header "Host" value "two.domain.local" forward to
> match request path "/common/*" forward to
> }
> relay "domain.local" {
> listen on egress port 443 tls
> protocol "https"
> forward toport 80 check tcp
> forward toport 80 check tcp
> forward to port 80 check tcp
> }
>
> With this configuration, both "/common/" are rendered by .
> But I want
> "one.domain.local/*" to be rendered by
> "one.domain.local/common/" to be rendered by
> "two.domain.local/*" to be rendered by
> "two.domain.local/common/" to be rendered by
>
> Is there some way to achieve this?
Try using "quick" or possibly "tag" and "tagged".
/Benno
match two conditions in relayd(8)
Hi,
I'm setting up an HTTP(S) Reverse Proxy with relayd(8).
I have one listener with multiple FQDN allowed.
But I also have a common path that must be treated separately.
As for now, I have:
http protocol "https" {
match request header "Host" value "one.domain.local" forward to
match request header "Host" value "two.domain.local" forward to
match request path "/common/*" forward to
}
relay "domain.local" {
listen on egress port 443 tls
protocol "https"
forward toport 80 check tcp
forward toport 80 check tcp
forward to port 80 check tcp
}
With this configuration, both "/common/" are rendered by .
But I want
"one.domain.local/*" to be rendered by
"one.domain.local/common/" to be rendered by
"two.domain.local/*" to be rendered by
"two.domain.local/common/" to be rendered by
Is there some way to achieve this?
Thank you.
Re: Catastrophic
On Mon, 27 Jan 2020 at 13:59, Justin Noor wrote: > > Hello community, > > I'm looking for any advice on how to troubleshoot some strange and > catastrophic behavior on my OpenBSD machine. Seemingly out of nowhere, it > started freezing to the extent that only a forced shutdown (holding down > the power button) gets me out of it. I suspect it's some kind of hardware > failure, but I'm not 100% sure. It crashes when xenodm is running. > Especially with firefox--it crashes instantly. If I disable xenodm it runs > fine. I am unable to send any log files or anything. I had to send this > email from a different machine. I can take pictures of log files and > transfer the information, but I'm not sure where to start. Any feedback > would be greatly appreciated. You should have old copies of messages in /var/log: oc@OpenBSD:~$ ls /var/log/messages* /var/log/messages /var/log/messages.1.gz /var/log/messages.0.gz /var/log/messages.2.gz -- Ottavio Caruso
Re: Catastrophic
A full dmesg would certainly help. Also, do you see anything in /var/log/messages? On Mon, Jan 27, 2020 at 4:01 PM Justin Noor wrote: > > Hello community, > > I'm looking for any advice on how to troubleshoot some strange and > catastrophic behavior on my OpenBSD machine. Seemingly out of nowhere, it > started freezing to the extent that only a forced shutdown (holding down > the power button) gets me out of it. I suspect it's some kind of hardware > failure, but I'm not 100% sure. It crashes when xenodm is running. > Especially with firefox--it crashes instantly. If I disable xenodm it runs > fine. I am unable to send any log files or anything. I had to send this > email from a different machine. I can take pictures of log files and > transfer the information, but I'm not sure where to start. Any feedback > would be greatly appreciated. > > Machine specs: > > Version: 6.6 Current (always up-to-date) > Architecture: amd64 > Kernel: '$ uname -a' OpenBSD myhost.myhost.com 6.6 GENERIC#601 amd64 > Chipset: AMD Ryzen 5 > GPU: Radeon RX 560 series, amdgpu0: msi > > Thank you, > > Justin Noor
Catastrophic
Hello community, I'm looking for any advice on how to troubleshoot some strange and catastrophic behavior on my OpenBSD machine. Seemingly out of nowhere, it started freezing to the extent that only a forced shutdown (holding down the power button) gets me out of it. I suspect it's some kind of hardware failure, but I'm not 100% sure. It crashes when xenodm is running. Especially with firefox--it crashes instantly. If I disable xenodm it runs fine. I am unable to send any log files or anything. I had to send this email from a different machine. I can take pictures of log files and transfer the information, but I'm not sure where to start. Any feedback would be greatly appreciated. Machine specs: Version: 6.6 Current (always up-to-date) Architecture: amd64 Kernel: '$ uname -a' OpenBSD myhost.myhost.com 6.6 GENERIC#601 amd64 Chipset: AMD Ryzen 5 GPU: Radeon RX 560 series, amdgpu0: msi Thank you, Justin Noor
interface modifiers :network and :0 picking different subnets for IPv6
Hi all,
Following up from my previous (PEBKAC) issue[1], I kept working on my
ruleset. I found, what I believe to be, another issue. Here's the
reduced ruleset that reproduces the problem:
[root@ferrari] # cat pf.tmp
IntIF=em1
# only allow DNS to the unbound instance listening on em1 (v4 and v6)
block in on $IntIF proto { tcp, udp } from $IntIF:network to ! $IntIF:0 port
domain
[root@ferrari] # pfctl -nvf pf.tmp
IntIF = "em1"
block drop in on em1 inet6 proto tcp from 2a02:898:28:300::/64 to !
fe80::2e0:67ff:fe15:cc6d port = 53
block drop in on em1 inet6 proto udp from 2a02:898:28:300::/64 to !
fe80::2e0:67ff:fe15:cc6d port = 53
block drop in on em1 inet proto tcp from 192.168.150.0/24 to ! 192.168.150.1
port = 53
block drop in on em1 inet proto udp from 192.168.150.0/24 to ! 192.168.150.1
port = 53
The problem is in the IPv6 rules. Here "em1:network" expands to the
global unicast network configured on the interface but "em1:0" expands
to the link-local address. This doesn't really make sense to me. If
both would expand to the link-local version, that would be unfortunate
but understandable. I'm hoping to have both expand to the global
unicast version ("from 2a02:898:28:300::/64 to ! 2a02:898:28:300::1").
Why is pfctl picking different addresses for these two modifiers?
This is the interface configuration:
[root@ferrari] # ifconfig em1
em1: flags=808843 mtu 1500
lladdr 00:e0:67:15:cc:6d
description: LAN
index 2 priority 0 llprio 3
groups: lan
media: Ethernet autoselect (1000baseT full-duplex,rxpause,txpause)
status: active
inet6 fe80::2e0:67ff:fe15:cc6d%em1 prefixlen 64 scopeid 0x2
inet6 2a02:898:28:300::1 prefixlen 64
inet6 2a02:898:28:300::2 prefixlen 128
inet 192.168.150.1 netmask 0xff00 broadcast 192.168.150.255
inet 192.168.150.2 netmask 0x
Is there a way to tell pf to use the global unicast address for em1:0
other than hardcoding the address in the ruleset?
Cheers,
Paul 'WEiRD' de Weerd
[1]: https://marc.info/?l=openbsd-misc=157994923220390=2
--
>[<++>-]<+++.>+++[<-->-]<.>+++[<+
+++>-]<.>++[<>-]<+.--.[-]
http://www.weirdnet.nl/
