Re: fido2 hardware key with PIN in browsers
Interesting, I am also looking for such a device for quite some time. Ppl using functional ones under obsd pla let me lnow About your question, I believe you need to do a tail -f /var/log/messages before plugging the device, and sending a dmesg also so ppl @misc can help you out On Friday, April 7, 2023, wrote: > Dear list, > > > I have a USB hardware security key > GoTrust Idem Key > and while I can use it on linux in a chromium browser > to login to some services -- you have to input a PIN > number and then touch the key -- it seems to not work > on OpenBSD (neither chrome nor firefox). > > Is this process supported on OpenBSD or there is > no such functionality available now? > > Thank you for any comments. > > > Best regards, > Ruda > > > -- Atenciosamente, Fabio Martins (+5521) 97914-8106 (Signal) https://www.linkedin.com/in/fabio1337br/
Re: OpenBSD 7.2 on Oracle Cloud
Try to add an entry in grub like in this article: https://raby.sh/installing-openbsd-on-ovhs-vps-2016-kvm-machines.html On Wednesday, April 5, 2023, Antun Matanović wrote: > I'm trying to set up OpenBSD on an Always Free VM.Standard.E2.1.Micro > instance and I keep getting a page fault (log included below). > I created an instance using the default Oracle Linux 8 image with all > default settings except for disabling in-transit encryption. From > there I just dd'd the install72.img to /dev/sda and rebooted into the > cloud shell.I also used `set tty com0` as suggested here: > https://www.alextsang.net/articles/20221022-132025/index.html > I also tried starting the instance using the Ubuntu image, disabling > all the Oracle Cloud Agent services as well as writing the > miniroot72.img but nothing worked. > Here is the output: > >> OpenBSD/amd64 BOOTX64 3.62 > boot> > cannot open hd0a:/etc/random.seed: No such file or directory > booting hd0a:/7.2/amd64/bsd.rd: 3916484+1639424+3884040+0+704512 > [109+438912+292606]=0xa61d70 > entry point at 0x1001000 > Copyright (c) 1982, 1986, 1989, 1991, 1993 > The Regents of the University of California. All rights reserved. > Copyright (c) 1995-2022 OpenBSD. All rights reserved. > https://www.OpenBSD.org > > OpenBSD 7.2 (RAMDISK_CD) #725: Tue Sep 27 12:02:48 MDT 2022 > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/RAMDISK_CD > real mem = 1049554944 (1000MB) > avail mem = 1013784576 (966MB) > random: good seed from bootblocks > mainbus0 at root > bios0 at mainbus0: SMBIOS rev. 2.8 @ 0x3f94 (9 entries) > bios0: > bios0: QEMU Standard PC (i440FX + PIIX, 1996) > acpi0 at bios0: ACPI 1.0 > acpi0: tables DSDT FACP APIC HPET BGRT > acpimadt0 at acpi0 addr 0xfee0: PC-AT compat > cpu0 at mainbus0: apid 0 (boot processor) > cpu0: AMD EPYC 7551 32-Core Processor, 3594.00 MHz, 17-01-02 > cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA, > CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL, > SSSE3,FMA3,CX16,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE, > AES,XSAVE,AVX,F16C,RDRAND,HV,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP, > LONG,LAHF,CMPLEG,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW, > TOPEXT,CPCTR,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2, > RDSEED,ADX,SMAP,CLFLUSHOPT,SHA,IBPB,VIRTSSBD,XSAVEOPT, > XSAVEC,XGETBV1,XSAVES > cpu0: 64KB 64b/line 2-way D-cache, 64KB 64b/line 2-way I-cache, 512KB > 64b/line 16-way L2 cache, 16MB 64b/line 16-way L3 cache > cpu0: apic clock running at 1830MHz > cpu at mainbus0: not configured > ioapic0 at mainbus0: apid 0 pa 0xfec0, version 11, 24 pins > acpihpet0 at acpi0: 1 Hz > acpiprt0 at acpi0: bus 0 (PCI0) > "ACPI0006" at acpi0 not configured > acpipci0 at acpi0 PCI0 > acpicmos0 at acpi0 > com0 at acpi0 COM1 addr 0x3f8/0x8 irq 4: ns16550a, 16 byte fifo > com0: console > "QEMU0001" at acpi0 not configured > "PNP0A06" at acpi0 not configured > "PNP0A06" at acpi0 not configured > "PNP0A06" at acpi0 not configured > "QEMU0002" at acpi0 not configured > "ACPI0010" at acpi0 not configured > acpicpu at acpi0 not configured > pvbus0 at mainbus0: KVM > pci0 at mainbus0 bus 0 > 0:2:0: rom address conflict 0x/0x1 > pchb0 at pci0 dev 0 function 0 "Intel 82441FX" rev 0x02 > "Intel 82371SB ISA" rev 0x00 at pci0 dev 1 function 0 not configured > pciide0 at pci0 dev 1 function 1 "Intel 82371SB IDE" rev 0x00: DMA, > channel 0 wired to compatibility, channel 1 wired to compatibility > pciide0: channel 0 ignored (disabled) > pciide0: channel 1 ignored (disabled) > uhci0 at pci0 dev 1 function 2 "Intel 82371SB USB" rev 0x01: apic 0 int 11 > "Intel 82371AB Power" rev 0x03 at pci0 dev 1 function 3 not configured > "Bochs VGA" rev 0x02 at pci0 dev 2 function 0 not configured > virtio0 at pci0 dev 3 function 0 "Qumranet Virtio Network" rev 0x00 > vio0 at virtio0: address 02:00:17:03:5f:26 > virtio0: msix shared > virtio1 at pci0 dev 4 function 0 "Qumranet Virtio SCSI" rev 0x00 > vioscsi0 at virtio1: qsize 128 > scsibus0 at vioscsi0: 255 targets > uvm_fault(0x8190a468, 0x8, 0, 1) -> e > fatal page fault in supervisor mode > trap type 6 code 0 rip 8123622b cs 8 rflags 10282 cr2 8 cpl e > rsp 81a06670 > gsbase 0x818f6ff0 kgsbase 0x0 > panic: trap type 6, code=0, pc=8123622b > > The operating system has halted. > Please press any key to reboot. > > -- Atenciosamente, Fabio Martins (+5521) 97914-8106 (Signal) https://www.linkedin.com/in/fabio1337br/
Re: Folks are there any tips to improve page load times on smokeping running on OpenBSD
Inline On Tuesday, March 7, 2023, Claudio Jeker > > > No need to collect flamegraphs, the issue is massive contention on the > kernel lock because of high IO load. I see similar behaviour with iogen. > Currently competing read and write calls clash with the async buffer > handling which also requires the kernel lock to finish their work. So more > concurrency makes it worse. Fixing this is a major task. Can a ramdisk improve the performance while there are no changes in the code? > > -- > :wq Claudio > > -- Atenciosamente, Fabio Martins (+5521) 97914-8106 (Signal) https://www.linkedin.com/in/fabio1337br/
[no subject]
-- Atenciosamente, Fabio Martins (+5521) 97914-8106 (Signal) https://www.linkedin.com/in/fabio1337br/
Re: Atom code environment
On Monday, May 9, 2022, Alexis wrote: > > jeanfrancois writes: > > Specifically the multiline work is very helpful that ought to be >> enough. Have I missed other editors with this ? >> > > There are extensions for both Vim and Emacs for this, e.g.: > > https://github.com/mg979/vim-visual-multi > > https://github.com/magnars/multiple-cursors.el > > > Alexis. > > I like/use vim very much, but also geany sometimes -- Atenciosamente, Fabio Martins (+5521) 97914-8106 (Signal) https://www.linkedin.com/in/fabio1337br/
Re: deep packet inspection over no TLS/SSL traffic
On Sunday, May 8, 2022, Riccardo Giuntoli wrote: > Hello there, I've got a little wireless service provider where the edge > connect to different VPS providers in many geographic locations. One of > them, based in US, is applying DMCA doing DPI above no encrypted traffic. > > Now all my VPS are OpenBSD I want to apply the same policy to not incur in > service problems or fees. > > Want I want to archive is redirect all no TLS/SSL traffic to an engine > (nDPI? relayd?) that could after interact with PF using an anchor. > > Someone got an idea to do this? > > Kindly regards, > > -- > Name: Riccardo Giuntoli > Email: tag...@gmail.com > Location: sant Pere de Ribes, BCN, Spain > PGP Key: 0x67123739 > PGP Fingerprint: CE75 16B5 D855 842FAB54 FB5C DDC6 4640 6712 3739 > Key server: hkp://wwwkeys.eu.pgp.net > Would this solution be ok? Setup a VPN (wireguard?) between the USA VPS and other VPS in a different region ( Asia for example). Let 443 and other tls ports (465, 993) go normally via USA default route for the VPS. All other ports will use PF binat to masquerade the non-tls traffic via the Asian endpoint of the VPN. Cheers. -- Atenciosamente, Fabio Martins (+5521) 97914-8106 (Signal) https://www.linkedin.com/in/fabio1337br/
Re: OpenBSD ftp and libtls: how to use session resumption with -S
On Sunday, May 8, 2022, Hiltjo Posthuma wrote: > > > The actual HTTP data sent (not just the package data itself) is not > immediately > visible, filterable or changed by a MiTM. They also cannot easily see which > packages are installed or filter errata's, right? > > -- > Kind regards, > Hiltjo > > There is a good presentation on that, presented to me a while back when I questioned full https on pkg_add. But basically, https does not solve confidentiality and MiTM is avoided by using checksum and signify. -- Atenciosamente, Fabio Martins (+5521) 97914-8106 (Signal) https://www.linkedin.com/in/fabio1337br/
Re: relayd blocking by IP
On Thursday, May 5, 2022, Stuart Henderson wrote: > > > not quite, PF is looking up the IP in the table to decide which port > number to use > > then the different port number is handled in relayd to pick between > two contexts: > > one does not inspect Host (for those requests coming from > addresses on "geoallow") > > the other (for all other requests) does inspect Host > > > Understood. Also possible this way. -- Atenciosamente, Fabio Martins (+5521) 97914-8106 (Signal) https://www.linkedin.com/in/fabio1337br/
Re: relayd blocking by IP
On Thursday, May 5, 2022, Marcus MERIGHI wrote: > Hello Stuart, Hello Fabio, > > thanks for reading and suggesting! > > > Exactly, though it is going to be relayd that is listening and > forwarding to the application (or not, in case of geoblocking). > > Marcus > This way you are only blocking per IP, not Host. I thought you needed to analyze the "Host: " inside the request before taking the decision, per this statement: - I need to block http/s traffic, but only for some Host: header values. I.e. domain "xyz.abc" should be reachable, domain "klm.opq" not, both behind the same IP. -- If https traffic inspection is not necessary, no need to add a reverse proxy/httpd. -- Atenciosamente, Fabio Martins (+5521) 97914-8106 (Signal) https://www.linkedin.com/in/fabio1337br/
Re: relayd blocking by IP
On Wednesday, May 4, 2022, Stuart Henderson wrote: > On 2022-05-04, Marcus MERIGHI wrote: > > Hello! > > > > I need to block http/s traffic, but only for some Host: header values. > > I.e. domain "xyz.abc" should be reachable, domain "klm.opq" not, both > > behind the same IP. > > > > This rules out blocking with PF. > > > ... > > > > Thanks in advance for any pointers! > > Maybe redirect connections from the PF table to a different port, then > handle the two ports differently in relayd? > > -- > Please keep replies on the mailing list. This may be possible to do via httpd listening on different ports for each domain, since they share the same IP address. -- Fabio Martins -- Atenciosamente, Fabio Martins (+5521) 97914-8106 (Signal) https://www.linkedin.com/in/fabio1337br/
Subscribe
Subscribe -- Atenciosamente, Fabio Martins (+5521) 97914-8106 (Signal) https://www.linkedin.com/in/fabio1337br/
Re: Syspatch failed
On 2021-11-26 13:37, Goetz Schultz wrote: Hello list, I found the issue and have rectified it. All working again. Thanks and regards Goetz R Schultz >8 Quis custodiet ipsos custodes? /"\ \ / ASCII Ribbon Campaign X against HTML e-mail / \ 8< On 25/11/2021 21:06, Goetz Schultz wrote: Hello list, I am a bit stuck with syspatch. When running syspatch it is "doing nothing" - coming back with exit code "1". So far I assume something fails. I checked dmesg and systemlogs, but nothing in there. Any hints? I tried various entries in installurl, but nothing helped. Any clue where else to look? I can curl/wget to the installurl-locations. Is it worth to share the issue? Or was it too specific? Regards, -- Fabio
Re: pkg_add with certificate pinning
On 2021-11-19 08:12, Stuart Henderson wrote: On 2021-11-19, Fabio Martins wrote: Sorry if it is a bit off-topic. After reading an article about rogue CA's: https://www.theregister.com/2021/11/19/web_trust_certificates/ I wonder if there is any advantage of using certificate pinning in the process of pkg_add / sysupgrade / pkg_* while updating OpenBSD packages. There doesn't seem a real advantage here. In terms of checking that files are from a known source, pkg_add checks signatures with signify (so updates over plain http are OK really). Also the checks are done with a tight pledge(7) restriction (and decompressors aren't called until signatures have been checked, they are also restricted). In terms of confidentiality, you can figure out a lot from what's available in the clear even with HTTPS. The IP addresses obviously. SNI hostnames. Request/response lengths are visible, and with a known set of files that anyone can easily fetch like packages (and known interdepencies) this makes it possible to figure out what's installed to some level of accuracy (IIRC espie@ did some research into this). The article you show talks about maliciously implanted root certs, typically installed on "managed" systems (corporate environment etc), or by malware. If something is changing that (/etc/ssl/cert.pem) without your knowledge you have bigger problems. Changes to that do show up in daily security mails though if somebody can change the file they can surely change the script too. If you really want to, you can do cert pinning. Put the desired ca certificate into a separate file, see ftp's -T cafile option, and pass the parameter from pkg_add via the FETCH_CMD variable. But I think it's not really worthwhile here. @stuart @Yifei Thanks for the inputs. Understood it isn't worth doing.
Re: pkg_add with certificate pinning
On 2021-11-19 06:57, Yifei Zhan wrote: On 21/11/19 06:26AM, Fabio Martins wrote: Sorry if it is a bit off-topic. After reading an article about rogue CA's: https://www.theregister.com/2021/11/19/web_trust_certificates/ I wonder if there is any advantage of using certificate pinning in the process of pkg_add / sysupgrade / pkg_* while updating OpenBSD packages. OpenBSD does not use PKI/web of trust for integrity validation, thus I don't think certificate pinning makes sense for those operations. Instead, OpenBSD uses signify(1) with pubkeys in /etc/signify/ for that purpose. Well said. I believe it would only improve confidentiality, as rogue middleware appliances would not be able to inspect the content of package updates.
pkg_add with certificate pinning
Sorry if it is a bit off-topic. After reading an article about rogue CA's: https://www.theregister.com/2021/11/19/web_trust_certificates/ I wonder if there is any advantage of using certificate pinning in the process of pkg_add / sysupgrade / pkg_* while updating OpenBSD packages. -- Fabio http://nabundapode.com.br/
Re: sysupgrade fails due to "CHECK AND RESET DATE" ?
0 function 0 "Intel Apollo Lake Host" rev 0x0b inteldrm0 at pci0 dev 2 function 0 "Intel HD Graphics 505" rev 0x0b drm0 at inteldrm0 inteldrm0: msi, BROXTON, gen 9 azalia0 at pci0 dev 14 function 0 "Intel Apollo Lake HD Audio" rev 0x0b: msi azalia0: codecs: Realtek ALC255, Intel/0x280a, using Realtek ALC255 audio0 at azalia0 "Intel Apollo Lake TXE" rev 0x0b at pci0 dev 15 function 0 not configured ahci0 at pci0 dev 18 function 0 "Intel Apollo Lake AHCI" rev 0x0b: msi, AHCI 1.3.1 ahci0: PHY offline on port 0 ahci0: port 1: 6.0Gb/s scsibus1 at ahci0: 32 targets sd0 at scsibus1 targ 1 lun 0: naa.50026b7783a249ed sd0: 228936MB, 512 bytes/sector, 468862128 sectors, thin ppb0 at pci0 dev 19 function 0 "Intel Apollo Lake PCIE" rev 0xfb: msi pci1 at ppb0 bus 1 ppb1 at pci0 dev 19 function 1 "Intel Apollo Lake PCIE" rev 0xfb: msi pci2 at ppb1 bus 2 ppb2 at pci0 dev 19 function 2 "Intel Apollo Lake PCIE" rev 0xfb: msi pci3 at ppb2 bus 3 re0 at pci3 dev 0 function 0 "Realtek 8168" rev 0x0c: RTL8168G/8111G (0x4c00), msi, address e0:d5:5e:e7:50:4f rgephy0 at re0 phy 7: RTL8251 PHY, rev. 0 ppb3 at pci0 dev 19 function 3 "Intel Apollo Lake PCIE" rev 0xfb: msi pci4 at ppb3 bus 4 re1 at pci4 dev 0 function 0 "Realtek 8168" rev 0x0c: RTL8168G/8111G (0x4c00), msi, address e0:d5:5e:e7:50:51 rgephy1 at re1 phy 7: RTL8251 PHY, rev. 0 xhci0 at pci0 dev 21 function 0 "Intel Apollo Lake xHCI" rev 0x0b: msi, xHCI 1.0 usb0 at xhci0: USB revision 3.0 uhub0 at usb0 configuration 1 interface 0 "Intel xHCI root hub" rev 3.00/1.00 addr 1 pcib0 at pci0 dev 31 function 0 "Intel Apollo Lake LPC" rev 0x0b ichiic0 at pci0 dev 31 function 1 "Intel Apollo Lake SMBus" rev 0x0b: polling iic0 at ichiic0 spdmem0 at iic0 addr 0x50: 8GB DDR3 SDRAM PC3-12800 SO-DIMM isa0 at pcib0 isadma0 at isa0 pckbc0 at isa0 port 0x60/5 irq 1 irq 12 pcppi0 at isa0 port 0x61 spkr0 at pcppi0 lpt0 at isa0 port 0x378/4 irq 7 vmm0 at mainbus0: VMX/EPT efifb at mainbus0 not configured vscsi0 at root scsibus2 at vscsi0: 256 targets softraid0 at root scsibus3 at softraid0: 256 targets root on sd0a (777a9c2ac8686d59.a) swap on sd0b dump on sd0b drm:pid0:rc6_supported *NOTICE* RC6 and powersaving disabled by BIOS inteldrm0: 1024x768, 32bpp wsdisplay0 at inteldrm0 mux 1 wsdisplay0: screen 0-5 added (std, vt100 emulation) sysupgrade left some files in /: panki$ cat /auto_upgrade.conf Location of sets = disk Pathname to the sets = /home/_sysupgrade/ Set name(s) = done Directory does not contain SHA256.sig. Continue without verification = yes and also kernels: panki$ ls -al /bsd* -rwx-- 1 root wheel 21012161 Oct 18 22:45 /bsd -rwx-- 1 root wheel 21011609 Oct 18 22:35 /bsd.booted -rw--- 1 root wheel 4205670 May 13 11:32 /bsd.rd -rw--- 1 root wheel 20913725 May 13 11:32 /bsd.sp -rw--- 1 root wheel 4208189 Oct 18 22:43 /bsd.upgrade Here is my fstab: panki$ cat /etc/fstab 777a9c2ac8686d59.b none swap sw 777a9c2ac8686d59.a / ffs rw 1 1 777a9c2ac8686d59.l /home ffs rw,nodev,nosuid 1 2 777a9c2ac8686d59.d /tmp ffs rw,nodev,nosuid 1 2 777a9c2ac8686d59.f /usr ffs rw,nodev 1 2 777a9c2ac8686d59.g /usr/X11R6 ffs rw,nodev 1 2 777a9c2ac8686d59.h /usr/local ffs rw,wxallowed,nodev 1 2 777a9c2ac8686d59.k /usr/obj ffs rw,nodev,nosuid 1 2 777a9c2ac8686d59.j /usr/src ffs rw,nodev,nosuid 1 2 777a9c2ac8686d59.e /var ffs rw,nodev,nosuid 1 2 the disk is installed with uefi: panki$ doas fdisk sd0 Disk: sd0 Usable LBA: 64 to 468862064 [468862128 Sectors] #: type [ start: size ] 1: EFI Sys [ 64: 960 ] 3: OpenBSD [ 1024: 468861041 ] Is there any chance that "CHECK AND RESET THE DATE" is the issue? THe "CHECK AND RESET THE DATE" message has nothing to do with the upgrade process. Where exactly the date is cheked? The kernel compares the date of the unmoun of / wit the date from the real time clock and if there is a big difference, it will print that messsage. I'm pretty sure, the date is correct, and ntpd is running panki$ ntpctl -ss 4/5 peers valid, constraint offset -1s, clock synced, stratum 2 panki$ date Mon Oct 18 23:17:18 MSK 2021 How can I assist to fix this? Try to find out why bsd.upgrade is not booted. Do you have boot.conf? That might give you a clue. -Otto Recently I had a similar problem, dunno if it is related. sysupgrade failed in the 1st boot after: -- Mounting root filesystem (mount -o ro /dev/sd0a /mnt)... OK. Force checking of clean non-root filesystems? [no] no umount: /mnt: Device busy Can't umount sd0a! cp: /mnt/var/log/ai.log.27965: Read-only file system chmod: /mnt/var/log/ai.log.27965: No such file or directory /autoinstall: cannot create /mnt/etc/rc.firsttime: Read-only files ystem -- So I upgraded manually with an USB stick. Turns out that the hard drive had a few bad sectors who couldn't be read properly. -- Fabio Martins
Re: Some Thoughts on resolv.conf.tail Deprecation
My solution for an static resolv.conf for a long time has been: chattr +i /etc/resolv.conf .. and now disable resovld, of course. If folks use another solution, would be glad to know. -- Fabio Martins On 2021-11-11 17:28, Zé Loff wrote: On Thu, Nov 11, 2021 at 05:36:07PM +, beebeet...@posteo.de wrote: Hi all, I was reading the manual page of resolv.conf(5) today and realized that paragraph on resolv.conf.tail has disappeared since the upgrade to 7.0, so I assume that resolv.conf.tail has been deprecated in response to resolvd being enabled by default. Previously, my backup strategy was to back up the customized system configuration files, which involves backing up resolv.conf.tail, but not resolv.conf. With the new behaviour in 7.0, it appears that my best shot is to back up resolv.conf, which constantly gets edited by resolvd(8). This seems less than ideal. I am not sure about what problem you are trying to solve. Won't the lines added by resolvd be overwritten anyway the first time you use the backed up file? I gave it some thoughts, and came up with an alternative solution to handling resolv.conf: - If resolvd is enabled, then resolv.conf is overidden entirely by resolvd, no more blending of user-edited and auto-configured information is involved. A new resolvd.conf needs to be introduced to instruct resolvd to add static defaults and stuff; - If resolvd is not enabled, then the contents of resolv.conf.tail gets copied to resolv.conf at system start. To me it seems that this is cleaner than the current solution to resolv.conf in that static and dynamic configurations is clearly separated instead of being blended into a one file. What are your thought on this? Thanks!
Odd wget --timeout behaviour
Hi misc, Playing with wget I am getting an odd behaviour related to --timeout It takes about 7 minutes for the process to die inside a 6.9 VM (vmd) and 2 minutes in real hardware running 6.8, both with internet down but DNS resolving ok. to reproduce (with internet not connected): $ time wget --timeout=5 -q -O - https://www.url.com/test.php my scenario is wget being called inside a script in a while loop, but can be reproduced in the prompt as well: --- inside vmd: OpenBSD p2p69.my.domain 6.9 GENERIC#328 amd64 Every 2.0s: ps wwaxu | grep wget | egrep -v grep Thu Feb 18 13:22:04 2021 support 61283 0.0 2.3 1800 5724 p1 S+ 1:17PM0:00.07 wget --timeout=5 -q -O - https://www.bitstreet.com.br/ip.php .. timeout expires after about 7 minutes (1:17 - 1:24) for new process to appear (script) Every 2.0s: ps wwaxu | grep wget | egrep -v grep Thu Feb 18 13:24:19 2021 support 44021 0.0 2.3 1812 5764 p1 S+ 1:24PM0:00.07 wget --timeout=5 -q -O - https://www.bitstreet.com.br/ip.php real hardware: OpenBSD laptop.my.domain 6.8 GENERIC.MP#4 amd64 laptop$ time wget --timeout=5 -q -O - https://www.bitstreet.com.br/ip.php 2m25.46s real 0m00.03s user 0m00.03s system --- -- Fabio Martins GPG: 0xCC59C123 Fingerprint: D06E 24DE 2A72 1BB3 A1A0 C790 E51E 33C4 CC59 C123
Re: ACME client doesn't renew certificate (6.9-beta)
On Tue, February 16, 2021 1:47 pm, Teno Deuter wrote: > OpenBSD 6.9-beta (GENERIC) #328: Mon Feb 15 10:31:18 MST 2021 > > I run: > > # acme-client -vF <>.com > acme-client: /etc/ssl/<>.com.crt: certificate valid: 89 days > left > acme-client: /etc/ssl/<>.com.crt: forcing renewal > acme-client: https://acme-v02.api.letsencrypt.org/directory: directories > acme-client: acme-v02.api.letsencrypt.org: DNS: 172.65.32.248 > acme-client: > https://acme-v02.api.letsencrypt.org/acme/finalize/86925799/7946011420: > certificate > acme-client: order.status 3 > acme-client: > https://acme-v02.api.letsencrypt.org/acme/cert/045439171e7c06c448e2584a12e832150e60: > certificate > acme-client: /etc/ssl/<>.com.crt: created > acme-client: /etc/ssl/<>.com.fullchain.pem: created > > but when I access it in Firefox I get a warnung because: > > Let's Encrypt > Validity > Not Before 11/1/2020, 9:25:02 PM (Eastern European Standard Time) > Not After 1/30/2021, 9:25:02 PM (Eastern European Standard Time) > > Thank you > Did you restarted httpd? Can you post your acme-client.conf? I usually run like this: # acme-client -f /etc/acme-client.conf MYDOMAIN.com.br Fabio Martins
Re: sysupgrade failure logs
On Tue, February 16, 2021 1:16 pm, Mitch K. wrote: > > I've been unaware of sysupgrade until now. Looks like it was introduced > in 6.6. > > I've done several dot release upgrades manually. The process is > straightforward and > well-documented, like the rest of OpenBSD. It took me ~15-30 minutes per > system. Great learning opportunity too. > > Mitch K. I agree it is a great learn opportunity to upgrade releases by hand, will look into it. But also in the other hand, this is the kind of tool that can put this great OS into the mainstream use - cloud providers/VPS resellers adoption/offering for instance. Fabio Martins
Re: sysupgrade failure logs
On Mon, February 15, 2021 11:14 am, Ed Ahlsen-Girard wrote: > I am confident that I can speak for for ... a non-zero number of > people who use sysupgrade the way it says to on the box and would miss > it if it went away. > +1 . Its simple to use, stable, convenient, luckly will bring more people to use the OS, and can normalize the various update scripts being used.
Re: pkg_add and an authenticating proxy
Works here for me: export http_proxy="http://user:password@127.0.0.1:/; && pkg_add -nu > Hi, > I was wondering if there was any way on how to allow pkg_add to use an > authenticating http-proxy ? Unluckily I cannot > find any documentation on the matter. > > Thanks alot so far. > > Best regards, > Stephan > > -- Fabio Martins PHOSPHORUS NETWORKS https://phosphorusnetworks.com/
Re: Any plans to support newer Loongson-based systems?
I believe loongson people are primaly after running some Linux distros for their processor (new ones), but maybe if you ask them directly about their plans to donate people's effort / hardware to OpenBSD, might be a good start: I asked some months ago about buying Loongson out of China to play wth, but got no luck. main point of contact inside Loongson, at least for for alpine Linux port, is this one: maybe some others can help: www.loongson.cn be safe. -- Fabio Martins > According to https://www.openbsd.org/loongson.html only some old > Loongson-based systems are supported. > > Are there any plans to support the more recent Loongson 3A3000- or the > current 3A4000-based systems? > > I do not know where OpenBSD MIPS developers are located. > Apparently the Loongson-based systems are not easily available outside > China, but it seems Chinese merchants are selling 3A4000+mainboard > bundles for somewhat less than 500 â¬, though I do not know if any of > them ship outside China. > > Philipp > >
Re: chattr on OpenBSD???
> On Fri, Apr 17, 2020 at 09:14:49AM -0600, Todd C. Miller wrote: >> On Fri, 17 Apr 2020 09:11:15 -0600, "Raymond, David" wrote: >> >> > I noticed that chattr exists on OpenBSD. The man page says it applies >> > to Linux file systems (ext* etc). Two questions: >> > >> > 1. Does this also apply to OpenBSD's fast file system? (The man page >> > would suggest not.) >> >> No. >> I see here "chattr +i" does set the uchg flag in a ffs filesystem. root@localhost:~# ls -lo /etc/resolv.conf -rw-r--r-- 1 root wheel - 21 Mar 13 08:18 /etc/resolv.conf root@localhost:~# chattr +i /etc/resolv.conf root@localhost:~# ls -lo /etc/resolv.conf -rw-r--r-- 1 root wheel uchg 21 Mar 13 08:18 /etc/resolv.conf >> > 2. If not, is it of any use on OpenBSD? >> >> Not unless you are using one of the Linux ext* file systems on >> OpenBSD. For native OpenBSD file systems you can use the BSD >> chflags(8) command. >> >> - todd >> >> > > At least lsattr shows flags set by chflags. > > -- > Henri Järvinen > > -- Fabio Martins
Re: pf-badhost-0.3 released
Hi Jordan, Thanks for the good work. Great solution to replace third-party adblockers addons in browsers. Blocked 100% ads in my tests. Regards, -- Fabio Martins > Hey folks, > > Last time I posted about this, I got a fair bit of interest and I've had > quite a few downloads and enquiries about pf-badhost, so I figured I'd > share here that I've updated the script. > > pf-badhost and unbound-adblock are both now at version 0.3, released > earlier today. > > I highly encourage anybody running an older version of these scripts to > update to the latest version, as I have made a number of significant > improvements to the security and robustness of the script. > > Links to the scripts can be found here: > > www.geoghegan.ca/pfbadhost.html > www.geoghegan.ca/unbound-adblock.html > > Regards, > Jordan > > >
Re: Full disk encryption including /boot, excluding bootloader?
>>> How do you do this on OpenBSD? >>@frank: https://www.openbsd.org/faq/faq14.html#softraidFDEkeydisk > > That's telling me how to use a keydisk -- how to put the softraid FDE > encryption key material on a USB disk. > > If an evil made came by and got access to my machine, they would still > be able to tamper with the bootloader code to harvest the FDE password > when I returned. > > I want to put the whole bootloader (including the code used to decrypt > the softraid-FDE-encrypted root-partition-containing media) on a USB > disk. > > This way the evil maid would have nothing to tamper with. They still would have plenty of firmware to target/infect, usually under 3 minutes with a screwdriver and dedicated hardware. If going this path, buy a safe and lock the computer while away from it. -Fabio Martins
Re: Replace PF rule + inetd Proxy with 2 PF rules
Nick, Indeed Working. Thanks. >> >> May be a dumb question, but do you have net.inet.ip.forwarding=1 set? >> > > Neither can I believe had forgotten it, but I think you nailed it. > Will test monday and let know. > > Thanks in advance. > > -fm > >> >> tcpdump of a successful test connection: >> c.c.c.c = remote test client on internet
Re: Replace PF rule + inetd Proxy with 2 PF rules
> > May be a dumb question, but do you have net.inet.ip.forwarding=1 set? > Neither can I believe had forgotten it, but I think you nailed it. Will test monday and let know. Thanks in advance. -fm > > tcpdump of a successful test connection: > c.c.c.c = remote test client on internet > r.r.r.r = firewall external IP > > pf# tcpdump -ni vmx1 port 8099 or host 129.128.5.194 > tcpdump: listening on vmx1, link-type EN10MB > 14:34:09.270237 c.c.c.c.63091 > r.r.r.r.8099: S 3178148684:3178148684(0) > win 64240 [tos 0x20] > 14:34:09.270303 r.r.r.r.62530 > 129.128.5.194.80: S > 3178148684:3178148684(0) win 64240 8,nop,nop,sackOK> [tos 0x20] > 14:34:09.342800 129.128.5.194.80 > r.r.r.r.62530: S > 3355699325:3355699325(0) ack 3178148685 win 16384 1460,nop,nop,sackOK,nop,wscale 6> (DF) [tos 0x20] > 14:34:09.342830 r.r.r.r.8099 > c.c.c.c.63091: S 3355699325:3355699325(0) > ack 3178148685 win 16384 [tos 0x20] > 14:34:09.372450 c.c.c.c.63091 > r.r.r.r.8099: . ack 1 win 1026 [tos 0x20] > 14:34:09.372461 c.c.c.c.63091 > r.r.r.r.8099: P 1:436(435) ack 1 win > 1026 [tos 0x20] > 14:34:09.372477 r.r.r.r.62530 > 129.128.5.194.80: . ack 1 win 1026 [tos > 0x20] > 14:34:09.372500 r.r.r.r.62530 > 129.128.5.194.80: P 1:436(435) ack 1 win > 1026 [tos 0x20] > 14:34:09.450714 129.128.5.194.80 > r.r.r.r.62530: P 1:197(196) ack 436 > win 273 (DF) [tos 0x20] > 14:34:09.450716 129.128.5.194.80 > r.r.r.r.62530: . 197:1657(1460) ack > 436 win 273 (DF) [tos 0x20] > 14:34:09.450759 r.r.r.r.8099 > c.c.c.c.63091: P 1:197(196) ack 436 win > 273 [tos 0x20] > 14:34:09.450774 r.r.r.r.8099 > c.c.c.c.63091: . 197:1657(1460) ack 436 > win 273 [tos 0x20] > > >
Re: Replace PF rule + inetd Proxy with 2 PF rules
I am trying now only with the redirect to www.openbsd.org, if it works, I
am sure it can be adapted to my case.
Unfortunately still no success.
# pf.conf:
ext_if="xnf0"
match in log on $ext_if proto tcp from any to ($ext_if) port 8099 tag RDR \
rdr-to 129.128.5.194 port 80
match out log on $ext_if proto tcp to 129.128.5.194 port 80 received-on \
$ext_if nat-to $ext_if
match out log quick on $ext_if inet all tagged RDR \
nat-to $ext_if
server_open="{ 80,110,443,25,587,465 }"
pass in log on $ext_if inet proto tcp from any port 1024:65535 to $ext_if
port $server_open tag n_traffic
#block all to start
block all
pass quick tagged RDR
pass quick tagged n_traffic
pass out on $ext_if
>
>
> On 2/14/2020 6:30 AM, Fabio Martins wrote:
>> Hi Nick,
>>
>> Thanks. I applied both rules below, unfortunately I am still only
>> hitting
>> rule number #1 (rdr-to). nat-to is never reached (added "log" on each to
>> test). I tried inverting the order, too, but no luck.
>>
>> #1
>> match in on $ext_if proto tcp from to ($ext_if) port 25 \
>> rdr-to 200.200.200.200 port
>>
>> #2
>> match out on $ext_if proto tcp to 200.200.200.200 port received-on
>> \
>> $ext_if nat-to ($ext_if)
>>
>> --
>> Fabio Martins
>>
>
> Odd, are you allowing the traffic with an appropriate pass rule later?
>
> I use tagging for rules related to rdr and nat to keep things simple,
> here is the full working setup I used to bounce port 8099 on the
> external interface to www.openbsd.org port 80.
>
> #Fun reverse redirection of www.openbsd.org
> match in on $ext_if proto tcp from any to ($ext_if) port 8099 tag RDR
> rdr-to 129.128.5.194 port 80
> match out on $ext_if proto tcp to 129.128.5.194 port 80 received-on
> $ext_if nat-to $ext_if
>
> #block all to start
> block log all
> pass quick tagged RDR
> pass out on $ext_if
>
>
> Make sure you are testing from an external host of course.
>
>
>
>
>
Re: Replace PF rule + inetd Proxy with 2 PF rules
Hi Nick, Thanks. I applied both rules below, unfortunately I am still only hitting rule number #1 (rdr-to). nat-to is never reached (added "log" on each to test). I tried inverting the order, too, but no luck. #1 match in on $ext_if proto tcp from to ($ext_if) port 25 \ rdr-to 200.200.200.200 port #2 match out on $ext_if proto tcp to 200.200.200.200 port received-on \ $ext_if nat-to ($ext_if) -- Fabio Martins > Hi Fabio, > > I believe this will do what you want, seemed to work in quick testing > here, adjust to suit your environment. > > > match in on $ext_if proto tcp from to ($ext_if) port 25 > rdr-to 200.200.200.200 port > match out on $ext_if proto tcp to 200.200.200.200 port received-on > $ext_if nat-to ($ext_if) >
Replace PF rule + inetd Proxy with 2 PF rules
Hi, I am trying to redirect + NAT incoming packets without the need of a TCP Proxy. Currently I have the following setup to redirect hosts abusing SMTP to an email trap: inetd listening in 127.0.0.1:8000 and redirecting to an external host # inetd.conf 127.0.0.1:8000 stream tcp nowait _inetd_proxy /usr/bin/nc nc -w 20 200.200.200.200 and + pf rule redirecting the hosts: # pf.conf table persist file "/etc/pf/tables/spammers.txt pass in log on egress proto tcp from to any port 25 \ rdr-to 127.0.0.1 port 8000 I am trying to remove the inetd from the setup. With Linux iptables I would do a DNAT + MASQUERADE, but with PF I already tried: # pf.conf #1 pass in log on xnf0 proto tcp from to any port nat-to xnf0 #2 pass in log on egress proto tcp from to any port 25 \ rdr-to 200.200.200.200 port Rule #2 is correctly applied and changes the destination address to 200.200.200.200, but rule #1 (NAT) isnt applied. I believe it is possible to NAT an external connection without using a TCP Proxy. Tried also the example from here: https://www.openbsd.org/faq/pf/rdr.html pass in on $int_if proto tcp from $int_net to egress port 80 rdr-to $server pass out on $int_if proto tcp to $server port 80 received-on $int_if nat-to $int_if Without success. Thanks! -- Fabio Martins
Re: Advices on AD implementation with OpenBSD
Thanks all for the answers. jca pointed out: "OpenBSD doesn't support "POSIX" ACLs or extended attributes so DC support is a pain (eg sysvol shares, etc)." Code wasn't stripped from source, but need work to be enabled at least with trivial database (tdb) to support ACLs/xattr. After that, see what the core dump is about. If I found out, future discussion @ports Thanks. -- Fabio Martins http://www.nabundapode.com.br/ > Hello! > > fm+obsd+misc+l...@phosphorusnetworks.com (Fabio Martins), 2019.12.26 (Thu) > 20:26 (CET): >> I am drawing a scenario to replace the Windows 2003 Server with OpenBSD, >> acting as AD/DC and firewall. There is a need to share folders and > > AFAIK this is the current status of samba AD/DC on OpenBSD: > > "This update doesn't include lmdb support (now the default upstream); >and doesn't fix the AD DC support in the samba daemon either." > > https://marc.info/?l=openbsd-ports=157019016817459 > > There have been updates (and downgrades) since then, but nothing > indicates that AD/DC works. Have not tried myself in a lng time. > > Marcus >
Advices on AD implementation with OpenBSD
Hi, I have a scenario with mixed WinXP (old I know) and Win10 machines. Domain Controller is Windows 2003 Server. I am drawing a scenario to replace the Windows 2003 Server with OpenBSD, acting as AD/DC and firewall. There is a need to share folders and printers, restrict access to folders based on logins, and no GPO are needed at all. Is it possible with the current samba+winbind? Anyone has done it before? Thanks for 6.6! -- Fabio Martins http://www.nabundapode.com.br/
Re: Moving a system disk from one server to another
I would go for: #pkg_info -a # @ old machine clean install on new machine #pkg_add (with list from old machine) #rsync # (config files + home directories + /var/) cheers. -- Fabio Martins PHOSPHORUS NETWORKS https://phosphorusnetworks.com/en/ > Hello al, > > Just bought a new server and wanted to see what the practicality would be > of moving my disk from > one box to the other. Its a stock 6.3 install, fully patched, with a few > packages. The old > processor is a VIA based CPU running generic i386 kernel. The new box is > based on an Intel Celeron > J1900 64-bit CPU. > > My thought is it should move over and boot up on the stock generic i386 > kernel, at which time I > could update to 64-bit or just wait until 6.4 comes out and then update. > > Curious if you think this will work, or should I just do a clean install. > > TIA, > > Jay > >
