Re: Is CVE-2019-5598 affecting openbsd
On June 19, 2019 8:23:59 AM GMT+03:00, Theo de Raadt wrote: >Strahil Nikolov wrote: > >> I was wondering if CVE-2019-5598 is actually affecting openBSD. I'm >> asking as FreeBSD is usually several versions behind and this one >> might not affect PF in recent openBSD versions. > >https://www.openbsd.org/errata63.html#p031_pficmp > >031: SECURITY FIX: March 22, 2019 All architectures >A state in pf could pass ICMP packets to a destination IP address >that did not match the state. > >https://www.openbsd.org/errata64.html#p015_pficmp > >015: SECURITY FIX: March 22, 2019 All architectures >A state in pf could pass ICMP packets to a destination IP address >that did not match the state. > >You probably had trouble connecting the dots because the original >report >was March 19, fixed on March 20, released as errata + syspatch on March >22. then we shipped the 6.5 release on May 1. > >So that means 6.5 shipped without the problem. > >FreeBSD finally release something on May 14. > >https://ftp.openbsd.org/pub/OpenBSD/patches/6.3/common/031_pficmp.patch.sig > >You may also find it hard to believe it took two nearly months for them >to merge a fix from OpenBSD which applied with mininum fuzz, validate >it, and then ship it to users. Also, that was done without mentioning >that >the fix was taken from an OpenBSD repair job which got done within 24 >hours >of the initial report. Rah rah for themselves, I suppose. Hi Theo, Thanks for the reply. Yes , I really missed that. I'm on 6.5 , so I'm good. Good Job to all developers ! This speed is really impressive. Best Regards, Strahil Nikolov
Re: Is CVE-2019-5598 affecting openbsd
Strahil Nikolov wrote: > I was wondering if CVE-2019-5598 is actually affecting openBSD. I'm > asking as FreeBSD is usually several versions behind and this one > might not affect PF in recent openBSD versions. https://www.openbsd.org/errata63.html#p031_pficmp 031: SECURITY FIX: March 22, 2019 All architectures A state in pf could pass ICMP packets to a destination IP address that did not match the state. https://www.openbsd.org/errata64.html#p015_pficmp 015: SECURITY FIX: March 22, 2019 All architectures A state in pf could pass ICMP packets to a destination IP address that did not match the state. You probably had trouble connecting the dots because the original report was March 19, fixed on March 20, released as errata + syspatch on March 22. then we shipped the 6.5 release on May 1. So that means 6.5 shipped without the problem. FreeBSD finally release something on May 14. https://ftp.openbsd.org/pub/OpenBSD/patches/6.3/common/031_pficmp.patch.sig You may also find it hard to believe it took two nearly months for them to merge a fix from OpenBSD which applied with mininum fuzz, validate it, and then ship it to users. Also, that was done without mentioning that the fix was taken from an OpenBSD repair job which got done within 24 hours of the initial report. Rah rah for themselves, I suppose.
Is CVE-2019-5598 affecting openbsd
Hi All, I was wondering if CVE-2019-5598 is actually affecting openBSD. I'm asking as FreeBSD is usually several versions behind and this one might not affect PF in recent openBSD versions. Best Regards, Strahil Nikolov
Re: LACP inquiry
On Tue, Jun 18, 2019 at 12:31:30PM -0700, Lyndon Nerenberg wrote: > > The panic indicated that there was no memory left and > > was in UFS region. Since this is the only change I did in the last few > > month > > s > > I'm guessing there is a memory leak in the LACP routines, somewhere. > > Seems unlikely. We run LACP trunks on all our firewalls and nginx > load balancers. Each of those machines pushes a steady 150 Mb/s of > traffic through the trunk interfaces, 24 hours a day. > > Are you doing any NFS mounts? I've seen panicks in the past due > to stuck NFS servers causing clients to run out of mbufs. But that > was a long time ago, so it's just a hint based on the panic being > near the filesystem code ... Seeing the actual panic traceback > would help. > > --lyndon Hmmm, you are probably right, here. I'll look at sendbuggin' the panic string and backtrace later today. To answer your question, no NFS mounts. Regards, -peter
Re: howto verify keydisk backup
On Tue, Jun 18, 2019 at 5:37 PM shadrock uhuru wrote: > > hi everyone > my keydisk is on a compactflash sandisk ultra 2 card, > which was created during disk encryption > > doas disklabel sd1 > # /dev/rsd1c: > type: SCSI > disk: SCSI disk > label: USB CARD READER > duid: ea53e532b5ae2a0f > flags: > bytes/sector: 512 > sectors/track: 63 > tracks/cylinder: 255 > sectors/cylinder: 16065 > cylinders: 31 > total sectors: 501760 > boundstart: 64 > boundend: 498015 > drivedata: 0 > > 16 partitions: > # size offset fstype [fsize bsize cpg] > a:16001 64 RAID > c:501760 0 unused > > > i boot my laptop (samsung np300e5A) with this connected to a card > reader connected to a usb port and i'm able to boot without a problem > > I HAVE A cruzer memory stick to use as a BACKUP keydisk > > doas disklabel sd3 > # /dev/rsd3c: > type: SCSI > disk: SCSI disk > label: Cruzer Fit > duid: 7fe58412fc668f9e > flags: > bytes/sector: 512 > sectors/track: 63 > tracks/cylinder: 255 > sectors/cylinder: 16065 > cylinders: 972 > total sectors: 15630336 > boundstart: 64 > boundend: 15615180 > drivedata: 0 > > 16 partitions: > #size offset fstype [fsize bsize cpg] > a:16001 64RAID > c: 156303360 unused > > using the backup instruction on the openbsd faq i create an image of the > keydisk > > dd bs=8192 skip=1 if=/dev/rsd1a of=backup-keydisk.img > > 999+1 records in > 999+1 records out > 8184320 bytes transferred in 2.251 secs (3634754 bytes/sec) > > i restore the image to the backup usb memory stick using > > dd bs=8192 seek=1 if=backup-keydisk.img of=/dev/rsd3a > > 999+1 records in > 999+1 records out > 8184320 bytes transferred in 1.744 secs (4690370 bytes/sec) > I might be speaking out of turn here, but I'm pretty sure you want to dd rsdXc, that images the entire disk, not just the a partition. > > when i try to boot off the backup usb memory stick i get > using drive 0 partition 3 > no os > > i tried to verify the keydisk image with diff using > > doas diff /dev/rsd1a backup-keydisk.img > Binary files /dev/rsd1a and backup-keydisk.img differ > --- > > is there a problem with the hardware combination of usb sticks i use for > keydisk backup > or the commands i use especially the diff command to try and verify the image > file ? > > shadrock >
howto verify keydisk backup
hi everyone my keydisk is on a compactflash sandisk ultra 2 card, which was created during disk encryption doas disklabel sd1 # /dev/rsd1c: type: SCSI disk: SCSI disk label: USB CARD READER duid: ea53e532b5ae2a0f flags: bytes/sector: 512 sectors/track: 63 tracks/cylinder: 255 sectors/cylinder: 16065 cylinders: 31 total sectors: 501760 boundstart: 64 boundend: 498015 drivedata: 0 16 partitions: # size offset fstype [fsize bsize cpg] a:16001 64 RAID c:501760 0 unused i boot my laptop (samsung np300e5A) with this connected to a card reader connected to a usb port and i'm able to boot without a problem I HAVE A cruzer memory stick to use as a BACKUP keydisk doas disklabel sd3 # /dev/rsd3c: type: SCSI disk: SCSI disk label: Cruzer Fit duid: 7fe58412fc668f9e flags: bytes/sector: 512 sectors/track: 63 tracks/cylinder: 255 sectors/cylinder: 16065 cylinders: 972 total sectors: 15630336 boundstart: 64 boundend: 15615180 drivedata: 0 16 partitions: #size offset fstype [fsize bsize cpg] a:16001 64RAID c: 156303360 unused using the backup instruction on the openbsd faq i create an image of the keydisk dd bs=8192 skip=1 if=/dev/rsd1a of=backup-keydisk.img 999+1 records in 999+1 records out 8184320 bytes transferred in 2.251 secs (3634754 bytes/sec) i restore the image to the backup usb memory stick using dd bs=8192 seek=1 if=backup-keydisk.img of=/dev/rsd3a 999+1 records in 999+1 records out 8184320 bytes transferred in 1.744 secs (4690370 bytes/sec) when i try to boot off the backup usb memory stick i get using drive 0 partition 3 no os i tried to verify the keydisk image with diff using doas diff /dev/rsd1a backup-keydisk.img Binary files /dev/rsd1a and backup-keydisk.img differ --- is there a problem with the hardware combination of usb sticks i use for keydisk backup or the commands i use especially the diff command to try and verify the image file ? shadrock
reinstalling boot blocks
Hi, I want to reinstall safely boot blocks as the installer does, how can I do it? best from the CD-ROM let me summarize the situation: - I had 6.4 not booting correctly (partition boot size issue) - I upgraded 6.5, and all works, boots fine - actually it did not work, certain things make the kernel crash (but can't report properly, I can't produce a dmesg, etc.. wifi makes a kernel panic) - after two or three panics the machine does not boot anymore, I did run fsck It looks early crashing, like reverting to the previous situation. I wonder if the filesystem may corrupt that way? First thing I'd try is to reinstall just the boot loader and stuff, but the standard way doesn't work from installer, but I bet a command does it! As soon as I get the box booting again, I try to report the bad wireless kernel crashes. Thanks, Riccardo
Re: IPTV handling on OpenBSD soft router
Yes, I too thought that the table could be the reason and even tried to completely comment out the rules with this table. That did not help and I later understood why. The rules with the table affect the network stream on egress port which is vether0 by me. But these rules do not apply neither to em0 nor em2. These are part of the same virtual bridge0 as vether0 but they are not filtered. As I understand if the iptv stream is blocked by PF it should be logged by the rule "block log all". But there are no packets when I do "tcpdump -n -e -i pflog0 not ifname vether0 and action block" -- Best regardsMaksim Rodin 18:41, 18 июня 2019 г., Stuart Henderson : On 2019-06-18, Максим wrote: � When I disable PF and use tcpdump to monitor network activity on em2 � (where the IPTV box is connected) I see a stream of udp packets (something like this: � 233.33.210.7:5050) � This stream is interrupted in several seconds when I enable PF again. It probably doesn't help that you have the multicast address range in your table ..
Re: LACP inquiry
> The panic indicated that there was no memory left and > was in UFS region. Since this is the only change I did in the last few month > s > I'm guessing there is a memory leak in the LACP routines, somewhere. Seems unlikely. We run LACP trunks on all our firewalls and nginx load balancers. Each of those machines pushes a steady 150 Mb/s of traffic through the trunk interfaces, 24 hours a day. Are you doing any NFS mounts? I've seen panicks in the past due to stuck NFS servers causing clients to run out of mbufs. But that was a long time ago, so it's just a hint based on the panic being near the filesystem code ... Seeing the actual panic traceback would help. --lyndon
LACP inquiry
Hi,
I had for the longest time a trunk0 on my router with failover mode. I redid
the config on last friday to have trunk LACP on the Netgear switch instead.
Here is my config:
{internet}---[octeon router]---[netgear switch]===[Lanner 6 port firewall]
I have drawn the === in there to indicate that there is 2 cat5e cables going
to the Lanner, let's call it uranus for its hostname.
Today I returned to my apartment after being gone from it for 3 days to find
uranus had panic'ed. The panic indicated that there was no memory left and
was in UFS region. Since this is the only change I did in the last few months
I'm guessing there is a memory leak in the LACP routines, somewhere. Or I have
misconfigured something. Here is an ifconfig output of trunk0 on uranus:
>
trunk0: flags=8947 mtu
1500
lladdr 00:90:0b:19:56:04
index 10 priority 0 llprio 3
trunk: trunkproto lacp
trunk id: [(8000,00:90:0b:19:56:04,4054,,),
(0080,00:00:00:00:00:00,,,)]
trunkport em5 lacp_state actor
activity,aggregation,sync,collecting,distributing,defaulted
trunkport em5 lacp_state partner
aggregation,sync,collecting,distributing
trunkport em5 active,collecting,distributing
trunkport em0 lacp_state actor
activity,aggregation,sync,collecting,distributing,defaulted
trunkport em0 lacp_state partner
aggregation,sync,collecting,distributing
trunkport em0 active,collecting,distributing
groups: trunk egress
media: Ethernet autoselect
status: active
<-
My config for trunk0 looks like this:
uranus$ more /etc/hostname.trunk0
trunkport em0
trunkport em5
trunkproto lacp
inet 192.168.177.40 255.255.255.0 192.168.177.255
inet6 2001:db8:0:30::142 64
up
So my question for the short term is, is there anything I'm missing in this
config? Do i need to set any priorities or anything?
Because it worked right away, I get a good ping from another host on the
netgear switch:
beta$ ping uranus
PING uranus.internal.centroid.eu (192.168.177.40): 56 data bytes
64 bytes from 192.168.177.40: icmp_seq=0 ttl=255 time=0.490 ms
64 bytes from 192.168.177.40: icmp_seq=1 ttl=255 time=0.415 ms
64 bytes from 192.168.177.40: icmp_seq=2 ttl=255 time=0.526 ms
64 bytes from 192.168.177.40: icmp_seq=3 ttl=255 time=0.424 ms
^C
--- uranus.internal.centroid.eu ping statistics ---
4 packets transmitted, 4 packets received, 0.0% packet loss
round-trip min/avg/max/std-dev = 0.415/0.464/0.526/0.046 ms
I'm looking at Rich Seiferts Switch book section 9.5.8 (LACP), but it'll take
me a bit to make sense of it all, meanwhile I'M recompiling with LACP_DEBUG in
hopes I see something in dmesg that indicates that there is functions exiting
without perhaps free'ing some memory?
If someone has a successful lacp setup and don't have my problems can you let
me know what you're doing different?
Best Regards,
-peter
Re: IPTV handling on OpenBSD soft router
On 2019-06-18, Максим wrote: > When I disable PF and use tcpdump to monitor network activity on em2 > (where the IPTV box is connected) I see a stream of udp packets (something > like this: > 233.33.210.7:5050) > This stream is interrupted in several seconds when I enable PF again. It probably doesn't help that you have the multicast address range in your table ..
Sidenote: Filesystem corruption on OpenBSD routers after power outage?
> Even after many tries, I have not yet been able to corrupt the > filesystem so fsck cannot repair it without manual intervention. Another less severe corner fail case I have found is that on a couple of buggy 386 laptops (that will be replaced soon anyway) with temperamental over temp shutdowns on some bootups (and now failing host controller, I'm guessing due to age/damage). I have found LOST+FOUND can fill up the filesystem, preventing library and kernel randomisation from taking affect. I have a script to check and remove older LOST+FOUND files. It's unlikely that there would be anything important lost on these browsing machines anyway. I guess a proper solution would be thorny?
Is it possible to build bioctl -c C -l ... on a bioctl -c 1 -l ... ?
Hello misc, 3 years ago I tried to build a "bioctl -c C -l ... " over a "bioctl -c 1 -l ..." on a hetzner server and I failed. Is it possible to do so, and when, what are the requirements? Thank you in advance. -Heiko
Re: relayd shows ssh sessions as idle
On Mon, Jun 17, 2019 at 11:56:08PM +0200, Sebastian Benoit wrote:
> Joel Carnat(j...@carnat.net) on 2019.06.12 16:10:25 +0200:
> > Hi,
> >
> > I have configured relayd(8) on my vmd(8) host so that I can connect to
> > the running VMs using SSH.
> >
> > Using relayctl(8), I can see that those sessions have the same value for
> > age and idle ; even when something happens in the SSH sessions.
> >
> > Is this expected or an error in my relayd.conf ?
> >
> > Thanks.
> >
> >
> > # config snippet
> >
> > protocol sshtcp {
> > tcp { nodelay, socket buffer 65536 }
>
> this uses the implicit "splice" option.
>
> If you add "no splice" to the tcp options, the idle time will be reset.
>
> The reason is this: After connection setup, relayd "splices" the socket
> connecting to the ssh client to the socket connecting to the ssh server.
> After that, the kernel takes care of transfering data between the client
> connection and the forward connection. relayd does not see the traffic
> anymore.
>
> It will only touch the connection again, when a maximum number of bytes are
> transfered, or a timeout triggers.
>
> For tcp connections, the max number of bytes is unlimited, and the timeout
> is set toyour session timeout.
>
> (For http connections, the max number of bytes is smaller, because relayd
> wants to look at the headers of the next http request).
>
> So relayd cannot know if the connection has been idle. It will only know
> when it reaches "session timeout". If you dont like this, use "no splice".
> However, that makes the connection slower and consume more cpu.
>
> /Benno
>
Thanks a lot for this detailled explanation.
I'll check cpu consumption and connection speed to see if I'd rather
stick with a long timeout configuration.
Regards,
Jo
Re: IPTV handling on OpenBSD soft router
When I disable PF and use tcpdump to monitor network activity on em2
(where the IPTV box is connected) I see a stream of udp packets (something like
this:
233.33.210.7:5050)
This stream is interrupted in several seconds when I enable PF again.
--
Best regards
Maksim Rodin
17.06.2019, 10:20, "Peer" :
> Could it be that your IPTV is using a non-IP protocoll, e.g. an ethertype
> which is not IPv4 nor IPv6, but something different? Like Powerline, G.hn or
> so? -- And which is blocked by pf?There are several protocol and type fields
> on the different layers (MAC, IP, TCP/UDP), and I recently noticed that tools
> and man pages do not always identify them very clearly or are somewhat
> misnamed (for historical reasons I'd say).Btw., I'm looking for a pointer to
> packet formats of ethertypes 0x88e1 and 0x8912, which my current filter
> bubble or info availability didn't allow me to find until now. They show up
> in tcpdump although they are not TCP nor even IP, and wireshark doesn't
> decrypt the payload, which I'm interested in.
> Ursprüngliche Nachricht Von: Родин Максим
> Datum: 16.06.19 22:16 (GMT+01:00) An: OpenBSD general
> usage list Betreff: [misc] IPTV handling on OpenBSD soft
> router Hello,I am trying to set up an IPTV-box behind a soft router.When my
> internet (iptv) provider installed the IPTV box he said thatI need a switch
> before my soft router to let IPTV stream successfully pass to the IPTV box.I
> thought that a virtual bridge interface would be enough for this purpose.I
> created a bridge0 interface and added three interfaces to it:em0 - a physical
> one which delivers internet and iptv from my provider.em2 - a physical one to
> which the IPTV-box is connected and which receives a mac binded ip address
> from the local network of my provider(100.65.129.0/24).vether0 - a virtual
> one which receives an external ip address from dhcp server of my provider (it
> therefore belongs to egress group) and through which my home computers access
> the internet using NAT ({ vether1 em1 em3 athn0 }).When PF is disabled the
> IPTV-box is working.When PF is enabled the IPTV box works for several seconds
> and then the picture freezes. When I change to another TV channel it works
> again for several seconds and then it freezes again.My pf settings are listed
> below (I used some of the config in PF user's guide)I do no filtering on the
> ports needed (em0, em2)When I do:tcpdump -n -e -i pflog0 not ifname vether0It
> shows no blocked packetsWhat am I
> missing?""router
> root ~ # cat /etc/pf.conf# $OpenBSD: pf.conf,v 1.54 2014/08/23 05:49:42
> deraadt Exp $## See pf.conf(5) and /etc/examples/pf.confint_if = "{ vether1
> em1 em3 athn0 }"table { 0.0.0.0/8 10.0.0.0/8 127.0.0.0/8
> 169.254.0.0/16 \ 172.16.0.0/12 192.0.2.0/24 224.0.0.0/3 \
> 192.168.0.0/16 198.18.0.0/15 198.51.100.0/24 \ 203.0.113.0/24
> }table persist file "/etc/pf/bad_ip"block log allset block-policy
> dropset loginterface egressset skip on lomatch out on egress inet from
> (vether1:network) to any nat-to (egress:0)block in quick on egress from
> to anyblock return out quick on egress from any to pass
> out quick inetpass in on $int_if inet# IPTVpass on em2pass on em0#pass in on
> egress inet proto tcp from ! to (egress) port 22pass in on egress
> inet proto tcp from ! to (egress) port 80pass in on egress inet
> proto { tcp udp } from any to (egress) port { 51413 22034 6890:6999 6881 }
> rdr-to 192.168.1.4pass in on egress inet proto { tcp udp } from any to
> (egress) port { 5 } rdr-to 192.168.1.65#block return # block stateless
> traffic#pass # establish keep-state# By default, do not permit remote
> connections to X11#block return in on ! lo0 proto tcp to port
> 6000:6010""" --
> Best regardsMaksim Rodin
