Re: pf adaptive syncookie
On 2020-12-18, mabi wrote: > Hi, > > I see quite some syn flood packets on my OpenBSD firewall filling up the > state table for nothing. So I thought let's try the pf's adaptive syncookies. > I am just not quite sure what the percentage used by start and stop relate to. > > In the pf.conf man page the following is written: > > "pf will enable syncookie mode when a given percentage of the state table is > used up by half-open TCP connections..." > > That "given percentage" does it compare the "half-open tcp" value of the > state table (as seen in "pfctl -si") with the amount of "current entries" in > the state table? or does it compare it with the limit of maximum states I > have defined in my pf.conf (value of "set limit states") ? > > Thank you in advance for any precisions. > > Regards, > Mabi > > It's something like "what % of max allowed states is half-open tcp". Watch out as there are some bugs in this area, definitely thewith accounting of half-open connections can be wildly off sometimes (triggering adaptive syncookies when they shouldn't really be triggered) and I think also with the behaviour when they're active, I have had it trigger spuriously and then a bunch of connections failing when triggered, so monitor it carefully if you enable this.
Re: Enhancing Privacy in 2020 attached screenshot
On 20/12/16 22:55, pipus wrote: > haha Stuart. > Always there to make a low IQ entrance :) Ever hear of Dunning-Kruger, pipus? https://lsa.umich.edu/psych/news-events/all-news/faculty-news/the-dunning-kruger-effect-shows-why-some-people-think-they-re-gr.html I hope you can look inward and find peace. Meditate and aim to be better than you were yesterday. With some practice and dedication, who knows...maybe you can become a valuable asset. In other words, a little more like Stuart. ;) -- https://amissing.link
Content-Security-Policy makes page render differently
When I load a page from OpenBSD served with relayd and httpd with
Content-Security-Policy set to default-src self, I can see that a basic
HTML page that normally renders with all of the text in the center is
now rendered on the left.
I have this currently configured with http://mostlybsd.com not loading
the header and https://mostlybsd.com loading the header.
I have also served the same HTML file in an Ubuntu server with nginx and
with the header enabled the page still renders in the center.
Is there something I am missing?
I have configured relayd with the following:
log state changes
log connection
prefork 10
list="ECDHE-RSA-CHACHA20-POLY1305:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256"
ipv4="45.32.193.189"
table { 127.0.0.1 }
http protocol "https" {
tls ciphers $list
tls keypair mostlybsd.com
return error
match request header set "X-Forwarded-For" value "$REOTE_ADDR"
match request header set "X-Forwarded-Port" value "$REMOTE_PORT"
match response header set "Content-Security-Policy" value \
"default-src 'self'"
match response header set "Referrer-Policy" value "no-referrer"
match response header set "Strict-Transport-Security" value \
"max-age=15552000; includeSubDomains; preload"
match response header set "X-Content-Type-Options" value "nosniff"
match response header set "X-Frame-Options" value "SAMEORIGIN"
match response header set "X-XSS-Protection" value "1; mode=block"
match method GET tag ok
match method HEAD tag ok
block
pass tagged ok forward to
}
relay "https" {
listen on $ipv4 port https tls
protocol "https"
forward to port 8080
}
relay "http" {
listen on $ipv4 port http
forward to port 8080
}
Thank you,
Paul
Re: Content-Security-Policy makes page render differently
Paul Pace writes: > When I load a page from OpenBSD served with relayd and httpd with > Content-Security-Policy set to default-src self, I can see that a basic > HTML page that normally renders with all of the text in the center is > now rendered on the left. > > I have this currently configured with http://mostlybsd.com not loading > the header and https://mostlybsd.com loading the header. > > [...] > > Is there something I am missing? You are missing that "style-src 'self'" does not allow
Re: Content-Security-Policy makes page render differently
Paul Pace writes: > When I load a page from OpenBSD served with relayd and httpd with > Content-Security-Policy set to default-src self, I can see that a basic > HTML page that normally renders with all of the text in the center is > now rendered on the left. When you enable content security policy, it will block inline styles. You would need to look at the headers to see what the ubuntu/nginx setup is adding to allow them. https://content-security-policy.com/examples/allow-inline-style/ Allan
Re: OpenBSD Readonly File System
Hey, I read that message about Freeradius not being able to access /dev/null in a setup where /dev is mounted on an mfs -based filesystem.I'm running similar setup (for years now) - OpenBSD on a USB stick. EVERYTHING is mounted read-only, except /var, /tmp, /dev and /jails, which are mfs - based. Now what I've noticed in particular about /dev is this: for this mfs-based /dev to work I HAD TO leave the initial /dev directory populated with dev files just as it was from the installation. Or else, run MAKEDEV in there -- but make sure it is filled with devices with original permissions etc. When I tried to mount mfs over EMPTY /dev directory, the resulting devices were not accessible. The same proved true about /var. So in order to install packages, I had to remount /usr /var read-write, then install && remount ro. Otherwise it won't work. Hope that helps With kindest regards, Kostya Berger
BeagleBone Black: no good seed
After an upgrade of BegleBone Black to current/armv7 (previous and current dmesg attached), this is the diff: --- beaglebone-black.20201013 Fri Dec 18 19:12:12 2020 +++ beaglebone-black.20201216 Fri Dec 18 19:12:12 2020 @@ -1,8 +1,8 @@ -OpenBSD 6.8-current (GENERIC) #0: Tue Oct 13 19:14:31 CEST 2020 -h...@bbb.stare.cz:/usr/src/sys/arch/armv7/compile/GENERIC +OpenBSD 6.8-current (GENERIC) #356: Wed Dec 16 14:58:22 MST 2020 +dera...@armv7.openbsd.org:/usr/src/sys/arch/armv7/compile/GENERIC real mem = 477319168 (455MB) -avail mem = 457330688 (436MB) -random: good seed from bootblocks +avail mem = 457285632 (436MB) +random: boothowto does not indicate good seed mainbus0 at root: TI AM335x BeagleBone Black cpu0 at mainbus0 mpidr 0: ARM Cortex-A8 r3p2 cpu0: 32KB 64b/line 4-way L1 VIPT I-cache, 32KB 64b/line 4-way L1 D-cache I am puzzled by the "boothowto does not indicate good seed" message. Can someone please illuminate me? Is the randomness gathering on the BBB no longer considered good enough? Thank you Jan OpenBSD 6.8-current (GENERIC) #0: Tue Oct 13 19:14:31 CEST 2020 h...@bbb.stare.cz:/usr/src/sys/arch/armv7/compile/GENERIC real mem = 477319168 (455MB) avail mem = 457330688 (436MB) random: good seed from bootblocks mainbus0 at root: TI AM335x BeagleBone Black cpu0 at mainbus0 mpidr 0: ARM Cortex-A8 r3p2 cpu0: 32KB 64b/line 4-way L1 VIPT I-cache, 32KB 64b/line 4-way L1 D-cache cpu0: 256KB 64b/line 8-way L2 cache omap0 at mainbus0 prcm0 at omap0 rev 0.2 dmtimer0 at omap0 rev 3.1 dmtimer1 at omap0 rev 3.1 simplebus0 at mainbus0: "ocp" intc0 at simplebus0 rev 5.0 omsysc0 at simplebus0: "target-module" simplebus1 at simplebus0: "interconnect" "wkup_m3" at simplebus1 not configured simplebus2 at simplebus1: "segment" simplebus3 at simplebus1: "segment" simplebus4 at simplebus1: "segment" omsysc1 at simplebus4: "target-module" simplebus5 at omsysc1: "prcm" omcm0 at simplebus5: "per-cm" omclock0 at omcm0: "l4ls-clkctrl" omclock1 at omcm0: "l3s-clkctrl" omclock2 at omcm0: "l3-clkctrl" omclock3 at omcm0: "l4hs-clkctrl" omclock4 at omcm0: "pruss-ocp-clkctrl" omclock5 at omcm0: "cpsw-125mhz-clkctrl" omclock6 at omcm0: "lcdc-clkctrl" omclock7 at omcm0: "clk-24mhz-clkctrl" omcm1 at simplebus5: "wkup-cm" omclock8 at omcm1: "l4-wkup-clkctrl" omclock9 at omcm1: "l3-aon-clkctrl" omclock10 at omcm1: "l4-wkup-aon-clkctrl" omcm2 at simplebus5: "mpu-cm" omclock11 at omcm2: "mpu-clkctrl" omcm3 at simplebus5: "l4-rtc-cm" omclock12 at omcm3: "l4-rtc-clkctrl" omcm4 at simplebus5: "gfx-l3-cm" omclock13 at omcm4: "gfx-l3-clkctrl" omcm5 at simplebus5: "l4-cefuse-cm" omclock14 at omcm5: "l4-cefuse-clkctrl" "prm" at simplebus5 not configured "prm" at simplebus5 not configured "prm" at simplebus5 not configured "prm" at simplebus5 not configured omsysc2 at simplebus4: "target-module" simplebus6 at omsysc2: "scm" syscon0 at simplebus6: "scm_conf" pinctrl0 at simplebus6 "control" at simplebus6 not configured "wkup_m3_ipc" at simplebus6 not configured "dma-router" at simplebus6 not configured omsysc3 at simplebus4: "target-module" omgpio0 at omsysc3: rev 0.1 gpio0 at omgpio0: 32 pins omsysc4 at simplebus4: "target-module" com0 at omsysc4: ti16750, 64 byte fifo com0: console omsysc5 at simplebus4: "target-module" tiiic0 at omsysc5 rev 0.11 iic0 at tiiic0 "ti,tps65217" at iic0 addr 0x24 not configured "atmel,24c256" at iic0 addr 0x50 not configured nxphdmi0 at iic0 addr 0x70: rev 0x0301 nxphdmi0: no display detected omsysc6 at simplebus4: "target-module" omsysc7 at simplebus4: "target-module" "timer" at omsysc7 not configured omsysc8 at simplebus4: "target-module" omdog0 at omsysc8 rev 0.1 omsysc9 at simplebus4: "target-module" "rtc" at omsysc9 not configured simplebus7 at simplebus0: "interconnect" simplebus8 at simplebus7: "segment" omsysc10 at simplebus8: "target-module" omsysc11 at simplebus8: "target-module" omsysc12 at simplebus8: "target-module" omsysc13 at simplebus8: "target-module" omsysc14 at simplebus8: "target-module" "mcasp" at omsysc14 not configured omsysc15 at simplebus8: "target-module" omsysc16 at simplebus8: "target-module" "timer" at omsysc16 not configured omsysc17 at simplebus8: "target-module" "timer" at omsysc17 not configured omsysc18 at simplebus8: "target-module" "timer" at omsysc18 not configured omsysc19 at simplebus8: "target-module" "timer" at omsysc19 not configured omsysc20 at simplebus8: "target-module" "timer" at omsysc20 not configured omsysc21 at simplebus8: "target-module" "timer" at omsysc21 not configured omsysc22 at simplebus8: "target-module" omgpio1 at omsysc22: rev 0.1 gpio1 at omgpio1: 32 pins omsysc23 at simplebus8: "target-module" ommmc0 at omsysc23 sdmmc0 at ommmc0: 4-bit, sd high-speed, mmc high-speed omsysc24 at simplebus8: "target-module" omsysc25 at simplebus8: "target-module" "mailbox" at omsysc25 not configured omsysc26 at simplebus8: "target-module" "spinlock" at omsysc26 not configured simplebus9 at simplebus7: "segment" omsysc27 at
Re: pf adaptive syncookie
On 2020-12-18, mabi wrote: > ‐‐‐ Original Message ‐‐‐ > On Friday, December 18, 2020 10:48 AM, Stuart Henderson > wrote: > >> It's something like "what % of max allowed states is half-open tcp". >> Watch out as there are some bugs in this area, definitely thewith >> accounting of half-open connections can be wildly off sometimes >> (triggering adaptive syncookies when they shouldn't really be triggered) >> and I think also with the behaviour when they're active, I have had >> it trigger spuriously and then a bunch of connections failing when >> triggered, so monitor it carefully if you enable this. > > Thank you for your precisions. > > This means that if I want to start using syncookies when I have over 40'000 > half-open tcp states and stop using it when it is back down to 30'000 > halt-open tcp states I would use the following pf.conf parameter: > > set syncookies adaptive (start 4%, end 3%) > > Note that my max allowed states is set to 1'000'000. > > I guess this is better even if somehow imprecise than having syncookies set > to "always"... > > What is the best way to monitor the usage of adaptive syncookies? In the > output of "pfctl -si" I don't see any relevant metric for syncookies. You'll see a rising count in pfctl -ss "synproxy" if they're active. And if it's anything like when I try it, you'll see some TCP connections failing when it is active too. Not everything fails. but e.g. if I have "set syncookies always" on a router, and run "ftp -o- http://www.facebook.com/; from a machine behind it, it fails every time (it appears to connect immediately, but of course that's just syncookies - I never get a response after making a request over it until I disblae syncookies again). In that case where syncookies are active but things are failing I see PROXY and SYN_SENT states in pfctl -ss e.g. all tcp 157.240.221.35:80 <- 82.68.199.130:16476 PROXY:DST all tcp 82.68.199.130:16476 -> 157.240.221.35:80 SYN_SENT:CLOSED So I strongly recommend trying it with 'always' and see if things are broken for you. Otherwise if you set 'adaptive' you may get an unpleasant surprise sometime maybe much later when they do actually trigger.
pf adaptive syncookie
Hi, I see quite some syn flood packets on my OpenBSD firewall filling up the state table for nothing. So I thought let's try the pf's adaptive syncookies. I am just not quite sure what the percentage used by start and stop relate to. In the pf.conf man page the following is written: "pf will enable syncookie mode when a given percentage of the state table is used up by half-open TCP connections..." That "given percentage" does it compare the "half-open tcp" value of the state table (as seen in "pfctl -si") with the amount of "current entries" in the state table? or does it compare it with the limit of maximum states I have defined in my pf.conf (value of "set limit states") ? Thank you in advance for any precisions. Regards, Mabi
Re: pf adaptive syncookie
‐‐‐ Original Message ‐‐‐ On Friday, December 18, 2020 10:48 AM, Stuart Henderson wrote: > It's something like "what % of max allowed states is half-open tcp". > Watch out as there are some bugs in this area, definitely thewith > accounting of half-open connections can be wildly off sometimes > (triggering adaptive syncookies when they shouldn't really be triggered) > and I think also with the behaviour when they're active, I have had > it trigger spuriously and then a bunch of connections failing when > triggered, so monitor it carefully if you enable this. Thank you for your precisions. This means that if I want to start using syncookies when I have over 40'000 half-open tcp states and stop using it when it is back down to 30'000 halt-open tcp states I would use the following pf.conf parameter: set syncookies adaptive (start 4%, end 3%) Note that my max allowed states is set to 1'000'000. I guess this is better even if somehow imprecise than having syncookies set to "always"... What is the best way to monitor the usage of adaptive syncookies? In the output of "pfctl -si" I don't see any relevant metric for syncookies.
