Re: Recommended options to block bruteforce requests on udp
On 06/09/2022 19:07, Stuart Henderson wrote: On 2022-09-06, Carlos López Martínez wrote: I have a very important question with massive requests to udp ports. Until now I had the following options configured: (max-src-conn 30, max-src-conn-rate 10/1, overload flush global) I have several services published through udp, most importantly WireGuard, but I'm not sure about activating those options. For exmaple, using the following options for tcp: (max-src-conn 10, max-src-conn-rate 15/5, overload flush global) several IPs goes to bruteforce table ... but for udp, nothing and t it seems strange to me. Is my config ok or do you see some gotchas? Those options are for TCP which requires 2-way communications and is relatively hard to spoof unless you're on the network path. UDP is often trivial to spoof (there are still a fair number of end-user ISPs/colos that still don't do ingress filtering) so blocking based on potentially faked IP addresses (e.g. someone spoofing packets with source IPs that belong to google/some big cdn/root name servers/etc could cause a lot of disruption if they could trigger a block). So PF doesn't do this. It's explained a bit in pf.conf(5) as well. Understood ... Many thanks Stuart for your explanation. -- Best regards, C. L. Martinez
Re: Is OpenBSD suited for old Dell Precision T5500 (Dual Xeon X5675, 72GB RAM)
On 9/6/22 21:52, Erling Westenvik wrote: Hello, A friend donated an old Dell Precision T5500 workstation, a heavy bastard with dual Xeon X5675 and 72GB RAM which still packs a punch I believe. At least it does for me. I would like it to replace my old i7 3770k. However, I'm starting to have doubts: 1) On initial boot (with 7.1 release, on a usb stick) it more or less immediately panicked into ddb when I tried to pipe dmesg into a file on the usb stick. I took out the NVMe-card, and whether or not that was the problem the machine anyhow behaved better long enough for me to get network and do a fw_update. sure sounds like it could be a bad USB stick. Very common. For important things, I have learned to write zeros over the entire USB stick before expecting it to actually work. Nothing to do with the T5500. NVMe?? don't think I have that in mine...But then, I probably wasn't looking. This an add-on board? I'd certainly strip it down as much as possible. 2) After fw_update the radeondrm was detected and I got a nice 2560x1600 console. However, before it would give me a login prompt the machine got stuck with repeating complaints about "ehci_device_clear_toggle: queue active". So – USB related, right? Very well! Out with the usb stick, in with an old SSD with OpenBSD 6.7. 3) The machine behaves better, xenodm starts fine with cwm, but it won't resume after suspend (zzz). haven't tried suspending. Thing has been on pretty much 24x7 for five+ years. Some or all of the above problems may have solutions, trivial or not, but more problems may perhaps lurk under the surface..? So I guess my question is if someone knows whether these Dell machines are known to be error prone in general, or problematic with OpenBSD in particular, and if I should stop before wasting time!? well, I have one, looks very similar to yours. I've been using it for quite a few years, this message is being composed on it, in fact. Like it enough that when a friend of mine told me he had another one, I got it as a spare. In short: you have a potentially good machine. I have no idea of the condition that yours is actually in, but "Run OpenBSD on a T5500? Yes". Nick. OpenBSD 7.2-beta (GENERIC.MP) #702: Sun Aug 21 00:29:07 MDT 2022 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 34340835328 (32749MB) avail mem = 33282695168 (31740MB) random: good seed from bootblocks mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.5 @ 0xf0450 (102 entries) bios0: vendor Dell Inc. version "A16" date 05/28/2013 bios0: Dell Inc. Precision WorkStation T5500 acpi0 at bios0: ACPI 3.0 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP SSDT APIC BOOT ASF! MCFG HPET TCPA DMAR _RAT SLIC SSDT acpi0: wakeup devices VBTN(S4) PCI0(S5) PCI1(S5) PCI2(S5) PCI3(S5) PCI5(S5) PCI6(S5) KBD_(S3) USB0(S3) USB1(S3) USB2(S3) USB3(S3) USB4(S3) USB5(S3) PCI8(S5) PCIA(S5) [...] acpitimer0 at acpi0: 3579545 Hz, 24 bits acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Xeon(R) CPU X5670 @ 2.93GHz, 3192.40 MHz, 06-2c-02 cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,POPCNT,AES,NXE,PAGE1GB,RDTSCP,LONG,LAHF,PERF,ITSC,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,MELTDOWN cpu0: 32KB 64b/line 8-way D-cache, 32KB 64b/line 4-way I-cache, 256KB 64b/line 8-way L2 cache, 12MB 64b/line 16-way L3 cache cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges cpu0: apic clock running at 133MHz cpu0: mwait min=64, max=64, C-substates=0.2.1.1, IBE cpu1 at mainbus0: apid 2 (application processor) cpu1: Intel(R) Xeon(R) CPU X5670 @ 2.93GHz, 3192.02 MHz, 06-2c-02 cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,POPCNT,AES,NXE,PAGE1GB,RDTSCP,LONG,LAHF,PERF,ITSC,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,MELTDOWN cpu1: 32KB 64b/line 8-way D-cache, 32KB 64b/line 4-way I-cache, 256KB 64b/line 8-way L2 cache, 12MB 64b/line 16-way L3 cache cpu1: smt 0, core 1, package 0 cpu2 at mainbus0: apid 4 (application processor) cpu2: Intel(R) Xeon(R) CPU X5670 @ 2.93GHz, 3192.02 MHz, 06-2c-02 cpu2: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,POPCNT,AES,NXE,PAGE1GB,RDTSCP,LONG,LAHF,PERF,ITSC,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,MELTDOWN cpu2: 32KB 64b/line 8-way D-cache, 32KB 64b/line 4-way I-cache, 256KB 64b/line 8-way L2 cache, 12MB 64b/line 16-way L3 cache cpu2: smt 0, core 2, package 0 cpu3 at mainbus0: apid 16 (application
Is OpenBSD suited for old Dell Precision T5500 (Dual Xeon X5675, 72GB RAM)
Hello, A friend donated an old Dell Precision T5500 workstation, a heavy bastard with dual Xeon X5675 and 72GB RAM which still packs a punch I believe. At least it does for me. I would like it to replace my old i7 3770k. However, I'm starting to have doubts: 1) On initial boot (with 7.1 release, on a usb stick) it more or less immediately panicked into ddb when I tried to pipe dmesg into a file on the usb stick. I took out the NVMe-card, and whether or not that was the problem the machine anyhow behaved better long enough for me to get network and do a fw_update. 2) After fw_update the radeondrm was detected and I got a nice 2560x1600 console. However, before it would give me a login prompt the machine got stuck with repeating complaints about "ehci_device_clear_toggle: queue active". So – USB related, right? Very well! Out with the usb stick, in with an old SSD with OpenBSD 6.7. 3) The machine behaves better, xenodm starts fine with cwm, but it won't resume after suspend (zzz). Some or all of the above problems may have solutions, trivial or not, but more problems may perhaps lurk under the surface..? So I guess my question is if someone knows whether these Dell machines are known to be error prone in general, or problematic with OpenBSD in particular, and if I should stop before wasting time!? Sincerely, Erling OpenBSD 7.1 (GENERIC.MP) #465: Mon Apr 11 18:03:57 MDT 2022 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 77290508288 (73709MB) avail mem = 74930786304 (71459MB) random: good seed from bootblocks mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.5 @ 0xf0450 (102 entries) bios0: vendor Dell Inc. version "A18" date 10/15/2018 bios0: Dell Inc. Precision WorkStation T5500 acpi0 at bios0: ACPI 3.0 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP SSDT APIC BOOT ASF! MCFG HPET TCPA _RAT SLIC SSDT acpi0: wakeup devices VBTN(S4) PCI0(S5) PCI1(S5) PCI2(S5) PCI3(S5) PCI5(S5) PCI6(S5) USB0(S3) USB1(S3) USB2(S3) USB3(S3) USB4(S3) USB5(S3) PCI8(S5) PCIA(S5) PCIB(S5) acpitimer0 at acpi0: 3579545 Hz, 24 bits acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 32 (boot processor) cpu0: Intel(R) Xeon(R) CPU X5675 @ 3.07GHz, 3325.54 MHz, 06-2c-02 cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,POPCNT,AES,NXE,PAGE1GB,RDTSCP,LONG,LAHF,PERF,ITSC,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,MELTDOWN cpu0: 256KB 64b/line 8-way L2 cache cpu0: smt 0, core 0, package 1 mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges cpu0: apic clock running at 132MHz cpu0: mwait min=64, max=64, C-substates=0.2.1.1, IBE cpu1 at mainbus0: apid 34 (application processor) cpu1: Intel(R) Xeon(R) CPU X5675 @ 3.07GHz, 3325.01 MHz, 06-2c-02 cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,POPCNT,AES,NXE,PAGE1GB,RDTSCP,LONG,LAHF,PERF,ITSC,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,MELTDOWN cpu1: 256KB 64b/line 8-way L2 cache cpu1: smt 0, core 1, package 1 cpu2 at mainbus0: apid 36 (application processor) cpu2: Intel(R) Xeon(R) CPU X5675 @ 3.07GHz, 3325.01 MHz, 06-2c-02 cpu2: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,POPCNT,AES,NXE,PAGE1GB,RDTSCP,LONG,LAHF,PERF,ITSC,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,MELTDOWN cpu2: 256KB 64b/line 8-way L2 cache cpu2: smt 0, core 2, package 1 cpu3 at mainbus0: apid 48 (application processor) cpu3: Intel(R) Xeon(R) CPU X5675 @ 3.07GHz, 3325.01 MHz, 06-2c-02 cpu3: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,POPCNT,AES,NXE,PAGE1GB,RDTSCP,LONG,LAHF,PERF,ITSC,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,MELTDOWN cpu3: 256KB 64b/line 8-way L2 cache cpu3: smt 0, core 8, package 1 cpu4 at mainbus0: apid 50 (application processor) cpu4: Intel(R) Xeon(R) CPU X5675 @ 3.07GHz, 3325.01 MHz, 06-2c-02 cpu4: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,POPCNT,AES,NXE,PAGE1GB,RDTSCP,LONG,LAHF,PERF,ITSC,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,MELTDOWN cpu4: 256KB 64b/line 8-way L2 cache cpu4: smt 0, core 9, package 1 cpu5 at mainbus0: apid 52 (application processor) cpu5: Intel(R) Xeon(R) CPU X5675 @ 3.07GHz, 3325.01 MHz, 06-2c-02 cpu5: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MT
Re: Recommended options to block bruteforce requests on udp
On 2022-09-06, Carlos López Martínez wrote: > I have a very important question with massive requests to udp ports. > Until now I had the following options configured: > > (max-src-conn 30, max-src-conn-rate 10/1, overload flush > global) > > I have several services published through udp, most importantly > WireGuard, but I'm not sure about activating those options. For exmaple, > using the following options for tcp: > > (max-src-conn 10, max-src-conn-rate 15/5, overload flush > global) > > several IPs goes to bruteforce table ... but for udp, nothing and t > it seems strange to me. > > Is my config ok or do you see some gotchas? Those options are for TCP which requires 2-way communications and is relatively hard to spoof unless you're on the network path. UDP is often trivial to spoof (there are still a fair number of end-user ISPs/colos that still don't do ingress filtering) so blocking based on potentially faked IP addresses (e.g. someone spoofing packets with source IPs that belong to google/some big cdn/root name servers/etc could cause a lot of disruption if they could trigger a block). So PF doesn't do this. It's explained a bit in pf.conf(5) as well. -- Please keep replies on the mailing list.
Recommended options to block bruteforce requests on udp
Hi all, I have a very important question with massive requests to udp ports. Until now I had the following options configured: (max-src-conn 30, max-src-conn-rate 10/1, overload flush global) I have several services published through udp, most importantly WireGuard, but I'm not sure about activating those options. For exmaple, using the following options for tcp: (max-src-conn 10, max-src-conn-rate 15/5, overload flush global) several IPs goes to bruteforce table ... but for udp, nothing and t it seems strange to me. Is my config ok or do you see some gotchas? -- Best regards, C. L. Martinez
