Re: Rate limit the httpd web server for signup requests
On 6/12/24 10:32 PM, Chris Bennett wrote: It's not perfect, but I have a long list of regexes that I know are spam that I have my Perl code that processes the form block. Trying to block from a log is not very helpful. It can let through thousands of the same spam attempts before the log catches up to the attempts reaching the log, which is a pretty long time. I was just wondering if you've tried requiring email or SMS link to unique signup URL? Thank you, Paul
Re: Rate limit the httpd web server for signup requests
On 2024-06-11 15:41, Martin wrote: I already do some rate limiting with stateful tracking options for PF, which works really great for the stuff I use it for. I also use block lists of known bad IP addresses etc. But what useful methods exists that prevent spamming a HTML signup form from stuffing the database with useless signups? Naturally the accounts that haven't been validated one way or another gets deleted, but the initial signup is a problem as thousands upon thousands of requests are stored before deletion. I have tried blocking by IP, but this is difficult as the IP changes faster than it can be blocked. The User Agent is spoofed with random garbage. Honey pot empty hidden fields gets detected and ignored. Randomly generated form IDs that gets submitted and validated using a session cookie also doesn't work as the cookie is just stored and then send along. A simple CAPTCHA reduces some of the irrelevant noise, but the more sophisticated bots solves the CAPTCHA. Using Cloudflare's or Google's CAPTCHA is frowned upon by the real users, which I fully understand. So I was wondering, if some other clever method can reduce the noise? I haven't tried it and I'm not sure how useful it is in your case, but mCaptcha uses proof of work. https://mcaptcha.org/ Paul
Re: Relayd forward to multiple ports on one target host?
On 2024-05-02 07:32, Manuel Giraud wrote: table { 127.0.0.1 } table { 127.0.0.1 } table { 127.0.0.1 } On 2024-05-02 07:02, Zé Loff wrote: table { 10.17.16.10 } table { 10.17.16.10 } table { 10.17.16.10 } Multiple tables - I didn't see that! I'm going with something like this to keep things simple for myself: table { 192.0.2.99 } table { 192.0.2.99 } table { 192.0.2.99 } Thank you, Paul
Relayd forward to multiple ports on one target host?
Hello! I have an OpenBSD server that hosts multiple services listening on various ports (some projects have their own web server, some projects require a reverse proxy, some projects just use httpd, etc.). This server receives requests via relayd on a different server. I was hoping to not insert relayd between every request to the host, but it's not the end of the world if this is the only viable solution while using relayd. The requests to relayd go to domains (e.g., www.example.com, serviceone.example.com, servicetwo.example.com, etc.) for web services (ports 80 and 443), but I cannot figure out a way to specify a port on the target server to forward requests to when there are multiple ports (e.g., www is on port 80, serviceone is on port 8080, servicetwo is on port 3, etc.). Running relayd -n does not report syntax errors when there are multiple forward to rules for the same target server with different ports in the relay block, but I can't find a way to specify which request should go to which port. Thank you, Paul
cloudflare.cdn.openbsd.org has been down for days
Hello! Apologies if this was announced some place as planned and I missed it, but I just wanted to let everyone know that cloudflare.cdn.openbsd.org has been down for a few days now. pkg_add -nu https://cloudflare.cdn.openbsd.org/pub/OpenBSD/7.4/packages-stable/amd64/: TLS handshake failure: handshake failed: error:14004410:SSL routines:CONNECT_CR_SRVR_HELLO:sslv3 alert handshake failure https://cloudflare.cdn.openbsd.org/pub/OpenBSD/7.4/packages/amd64/: TLS handshake failure: handshake failed: error:14004410:SSL routines:CONNECT_CR_SRVR_HELLO:sslv3 alert handshake failure https://cloudflare.cdn.openbsd.org/pub/OpenBSD/7.4/packages/amd64/: empty Couldn't find updates for... Thank you, Paul
Re: relayd forward with tls
On 1/7/24 1:31 PM, Adriano Barbosa wrote: On Sun, Jan 07, 2024 at 05:21:04AM -0800, Paul Pace wrote: On 1/6/24 7:35 PM, Adriano Barbosa wrote: On Thu, Jan 04, 2024 at 06:57:10PM -0800, Paul Pace wrote: On 1/4/24 10:22 AM, Adriano Barbosa wrote: Hi! I'm trying to use relayd with multiple FQDNs mixing remote servers with and without tls: relayd -- fqdn1 --> 127.0.0.1 (no tls) -- fqdn2 --> x.x.x.x (with tls) I wrote my relayd.conf like this: table { 127.0.0.1 } table { x.x.x.x } http protocol https { tls keypair fqdn1 tls keypair fqdn2 match request header "Host" value "fqdn1" tag "fqdn1" pass request tagged "fqdn1" forward to match request header "Host" value "fqdn2" tag "fqdn2" pass request tagged "fqdn2" forward to } relay wwwtls { listen on egress port 443 tls protocol https forward to port 80 forward with tls to port 443 } With one forward requiring TLS in a relay block, relayd will require TLS for all forward statements in the relay block. I have fqdn2 working and fqdn1 giving a "curl: (52) Empty reply from server". Removing "with tls" on the second forward, fqdn1 works and fqdn2 gives a "Client sent an HTTP request to an HTTPS server." Is it possible to have relayd working on this scenario? What am I missing here? Obrigado! -- Adriano Thank you for the response. Digging a little more, I found that if I change the listen port from 443 to values other than 443 and 80, the "match request host" filter stops working. The behaviour is the same with or without "with tls" on the relay. With port 443: stable# curl --insecure https://fqdn1 Server 1 stable# curl --insecure https://fqdn2 Server 2 With port 4430 and allegedly any port other than 80 and 443: stable# curl --insecure https://fqdn1:4430 Server 1 stable# curl --insecure https://fqdn2:4430 Server 1 What does curl -vk show? Unfortunately, no difference. Follows: $ curl --insecure -vk https://fqdn2 * Host fqdn2:443 was resolved. * IPv6: (none) * IPv4: 127.0.0.1 * Trying 127.0.0.1:443... * Connected to fqdn2 (127.0.0.1) port 443 * ALPN: curl offers h2,http/1.1 * TLSv1.3 (OUT), TLS handshake, Client hello (1): * TLSv1.3 (IN), TLS handshake, Server hello (2): * TLSv1.3 (IN), TLS handshake, Unknown (8): * TLSv1.3 (IN), TLS handshake, Certificate (11): * TLSv1.3 (IN), TLS handshake, CERT verify (15): * TLSv1.3 (IN), TLS handshake, Finished (20): * TLSv1.3 (OUT), TLS handshake, Finished (20): * SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384 / [blank] / UNDEF * ALPN: server did not agree on a protocol. Uses default. * Server certificate: * subject: C=BR; ST=MS; L=DOU * start date: Jan 6 20:12:43 2024 GMT * expire date: Jan 5 20:12:43 2025 GMT * issuer: C=BR; ST=MS; L=DOU * SSL certificate verify result: self signed certificate (18), continuing anyway. * Certificate level 0: Public key type ? (4096/128 Bits/secBits), signed using sha256WithRSAEncryption * using HTTP/1.x GET / HTTP/1.1 Host: fqdn2 User-Agent: curl/8.5.0 Accept: */* < HTTP/1.1 200 OK < Connection: keep-alive < Content-Length: 18 < Content-Type: text/html < Date: Sun, 07 Jan 2024 21:23:24 GMT < Last-Modified: Sun, 07 Jan 2024 21:19:24 GMT < Server: OpenBSD httpd < Server 2 * Connection #0 to host fqdn2 left intact and $ curl --insecure -vk https://fqdn2:4430 * Host fqdn2:4430 was resolved. * IPv6: (none) * IPv4: 127.0.0.1 * Trying 127.0.0.1:4430... * Connected to fqdn2 (127.0.0.1) port 4430 * ALPN: curl offers h2,http/1.1 * TLSv1.3 (OUT), TLS handshake, Client hello (1): * TLSv1.3 (IN), TLS handshake, Server hello (2): * TLSv1.3 (IN), TLS handshake, Unknown (8): * TLSv1.3 (IN), TLS handshake, Certificate (11): * TLSv1.3 (IN), TLS handshake, CERT verify (15): * TLSv1.3 (IN), TLS handshake, Finished (20): * TLSv1.3 (OUT), TLS handshake, Finished (20): * SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384 / [blank] / UNDEF * ALPN: server did not agree on a protocol. Uses default. * Server certificate: * subject: C=BR; ST=MS; L=DOU * start date: Jan 6 20:12:43 2024 GMT * expire date: Jan 5 20:12:43 2025 GMT * issuer: C=BR; ST=MS; L=DOU * SSL certificate verify result: self signed certificate (18), continuing anyway. * Certificate level 0: Public key type ? (4096/128 Bits/secBits), signed using sha256WithRSAEncryption * using HTTP/1.x GET / HTTP/1.1 Host: fqdn2:4430 User-Agent: curl/8.5.0 Accept: */* < HTTP/1.1 200 OK < Connection: keep-alive < Content-Length: 18 < Content-Type: text/html < Date: Sun, 07 Jan 2024 21:25:42 GMT < Last-Modified: Sun, 07 Jan 2024 21:19:15 GMT < Server: OpenBSD httpd < Server 1 * Connection #0 to host fqdn2 left intact My best guess is httpd is not receiving a host header so is serving the first server block. Try setting relay
Re: relayd forward with tls
On 1/6/24 7:35 PM, Adriano Barbosa wrote: On Thu, Jan 04, 2024 at 06:57:10PM -0800, Paul Pace wrote: On 1/4/24 10:22 AM, Adriano Barbosa wrote: Hi! I'm trying to use relayd with multiple FQDNs mixing remote servers with and without tls: relayd -- fqdn1 --> 127.0.0.1 (no tls) -- fqdn2 --> x.x.x.x (with tls) I wrote my relayd.conf like this: table { 127.0.0.1 } table { x.x.x.x } http protocol https { tls keypair fqdn1 tls keypair fqdn2 match request header "Host" value "fqdn1" tag "fqdn1" pass request tagged "fqdn1" forward to match request header "Host" value "fqdn2" tag "fqdn2" pass request tagged "fqdn2" forward to } relay wwwtls { listen on egress port 443 tls protocol https forward to port 80 forward with tls to port 443 } With one forward requiring TLS in a relay block, relayd will require TLS for all forward statements in the relay block. I have fqdn2 working and fqdn1 giving a "curl: (52) Empty reply from server". Removing "with tls" on the second forward, fqdn1 works and fqdn2 gives a "Client sent an HTTP request to an HTTPS server." Is it possible to have relayd working on this scenario? What am I missing here? Obrigado! -- Adriano Thank you for the response. Digging a little more, I found that if I change the listen port from 443 to values other than 443 and 80, the "match request host" filter stops working. The behaviour is the same with or without "with tls" on the relay. With port 443: stable# curl --insecure https://fqdn1 Server 1 stable# curl --insecure https://fqdn2 Server 2 With port 4430 and allegedly any port other than 80 and 443: stable# curl --insecure https://fqdn1:4430 Server 1 stable# curl --insecure https://fqdn2:4430 Server 1 What does curl -vk show? Port 8080 also reproduces this last result. Is that the expected behaviour? BTW, I'm running 7.4. Please find relayd.conf and httpd.conf below. fqdn{1,2} are on /etc/hosts as 127.0.0.1 and the respective tls certificates exists in /etc/ssl and keys in /etc/ssl/private. Obrigado! -- Adriano # relayd.conf addr="127.0.0.1" table { 127.0.0.1 } table { 127.0.0.1 } http protocol https { tls keypair fqdn1 tls keypair fqdn2 match request header "Host" value "fqdn1" tag "fqdn1" pass request tagged "fqdn1" forward to match request header "Host" value "fqdn2" tag "fqdn2" pass request tagged "fqdn2" forward to } http protocol https2 { tls keypair fqdn1 tls keypair fqdn2 match request header "Host" value "fqdn1" tag "fqdn1" pass request tagged "fqdn1" forward to match request header "Host" value "fqdn2" tag "fqdn2" pass request tagged "fqdn2" forward to } relay wwwtls { listen on $addr port 443 tls protocol https forward to port 8080 forward to port 8081 } relay wwwtls2 { listen on $addr port 4430 tls protocol https2 forward to port 8080 forward to port 8081 } # httpd.conf addr="127.0.0.1" server "fqdn1" { listen on $addr port 8080 location "*" { root "/htdocs/server1" } } server "fqdn2" { listen on $addr port 8081 location "*" { root "/htdocs/server2" } }
Re: relayd forward with tls
On 1/4/24 10:22 AM, Adriano Barbosa wrote: Hi! I'm trying to use relayd with multiple FQDNs mixing remote servers with and without tls: relayd -- fqdn1 --> 127.0.0.1 (no tls) -- fqdn2 --> x.x.x.x (with tls) I wrote my relayd.conf like this: table { 127.0.0.1 } table { x.x.x.x } http protocol https { tls keypair fqdn1 tls keypair fqdn2 match request header "Host" value "fqdn1" tag "fqdn1" pass request tagged "fqdn1" forward to match request header "Host" value "fqdn2" tag "fqdn2" pass request tagged "fqdn2" forward to } relay wwwtls { listen on egress port 443 tls protocol https forward to port 80 forward with tls to port 443 } With one forward requiring TLS in a relay block, relayd will require TLS for all forward statements in the relay block. I have fqdn2 working and fqdn1 giving a "curl: (52) Empty reply from server". Removing "with tls" on the second forward, fqdn1 works and fqdn2 gives a "Client sent an HTTP request to an HTTPS server." Is it possible to have relayd working on this scenario? What am I missing here? Obrigado! -- Adriano
self-hosted man.openbsd.org script?
I have this vague memory of reading someone who posted a script, IIRC, to convert the system's man pages to HTML, or similar, into somewhere under /var/www and the pages worked just like the highly useful man.openbsd.org, and not like the plain text pages that everyone always posts to their websites. Does someone happen to know where that is? On 12/23/23 11:16 AM, Nick Holland wrote: On 12/19/23 15:38, Nick Holland wrote: Hello, man.openbsd.org, cvsweb.openbsd.org, openbsd.cs.toronto.edu and obsdacvs.cs.toronto.edu will be unavailable for site maintenance starting Thursday, December 21 about 6:00am ET (UTC-5) and hopefully be back up and running by Saturday, December 23, 6:00am ET. Sorry for any inconvenience. Nick. Unfortunately, it seems there's a problem impacting our servers, and everyone is celebrating the holiday. So ... return of man.openbsd.org, cvsweb.openbsd.org and the install and anoncvs mirrors will be delayed. Nick.
gzip-static option isn't working on default index
I have gzip-static set in a server block in httpd.conf. If I make the following request: curl -I -H 'Accept-Encoding: gzip,deflate' http://example.com the response has no Content-Encoding header and the Content-Length matches /var/www/htdocs/index.html. If I make the following request: curl -I -H 'Accept-Encoding: gzip,deflate' http://example.com/index.html the response includes Content-Encoding: gzip and the Content-Length matches /var/www/htdocts/index.html.gz. Is there some additional configuration required or is this the intended output for the option? Thank you, Paul
Re: Self-hosting OpenBSD server, any documentation?
On 7/8/23 1:03 AM, Theo de Raadt wrote: Jonathan Drews wrote: On Sat, Jul 8, 2023, at 01:42, Jonas Borchelt wrote: The book "Absolute OpenBSD" is an excellent choice to expand your knowledge of the OpenBSD operating system. It was written by Michael W. Lucas and is regarded as a comprehensive resource for beginners and advanced users alike. It covers various aspects of OpenBSD, including installation, network security, system administration, and more. Enjoy reading it! There is another book by Michael Lucas that may be of benefit: "Httpd and Relayd Mastery". You can buy it as a *.pdf from Tilted Windmill Press. One day I really should try this self-hosting which seems to be all the rage. For those of us not very good at promoting, it turns out to be a very self-serving endeavor.
Re: relayd filter
On 6/5/23 3:15 PM, Nick Bouliane wrote: Hi, in relayd.conf I'm trying to do : pass from 192.168.1.1 path "/something.html" If I individually specify the "from" or the "path", it works but when I combine both, it doesn't work. Nowadays, when I come upon this I just use tags and move on. Something like this might work: match path "/something.html" tag something pass from 192.168.1.1 tagged something Am I missing something or if it's just not possible ? Or is there another way to express this another way ? thank you, Nick
Re: httpd(8) and PHP - more details in error log
On 10/4/21 11:45 PM, openbsd.l...@krottmayer.com wrote: Hi, I use PHP on OpenBSD's HTTPD for my private web page. In the default configuration it's hard to debug an PHP error, because I don't see a time or the specific request on which the error occurred. Is there a configuration for PHP or HTTPD to print more details in the error log? Thanks in advance! You can send httpd logs to syslog by setting log syslog This will log the timestamps, but still not IP addresses in the error log. See: https://www.mail-archive.com/bugs@openbsd.org/msg15344.html Paul
Re: Swap disklabel partition location?
On 9/15/21 10:30 AM, Theo de Raadt wrote: The kernel will automatically add swap if it is partition b. If it is not partition b, it will get added later by fstab entries. Almost noone does this. If you put a filesystem on partition b, I would be surprised if something causes you problems later, you are fighting against decades of practice. You can allocate the 'b' storage near the end of your partition, rather than in-order with the other filesystems. I suspect a series of operations with with 'Resize', 'delete' and allocating new space will get you storage near the end. And then yes, you should be able to re-allocate it in the future, upon a reboot. But it is also possible that you'll hit bugs in the disklabel editor, since I've never heard of anyone doing this. Paul Pace wrote: Hello! I am wondering if there is some requirement to have the swap disklabel partition always as partition b? I have a VPS where I might prefer to put swap at the end so when the VPS RAM and storage is increased, I can increase swap size, as needed, but I can't figure out why this might be a bad idea. I have so far only found in the FAQ on Disk Setup: b: The boot disk's b partition is usually a swap partition. And this isn't clear to me that: when there is a swap partition it must be on b, but if there is no swap partition then b is something else, or if it means that usually the swap partition is put on the b partition but can be on some other partition. Thank you, Paul Thank you, that is very helpful. I will choose an appropriate time in the future to experiment with this.
Swap disklabel partition location?
Hello! I am wondering if there is some requirement to have the swap disklabel partition always as partition b? I have a VPS where I might prefer to put swap at the end so when the VPS RAM and storage is increased, I can increase swap size, as needed, but I can't figure out why this might be a bad idea. I have so far only found in the FAQ on Disk Setup: > b: The boot disk's b partition is usually a swap partition. And this isn't clear to me that: when there is a swap partition it must be on b, but if there is no swap partition then b is something else, or if it means that usually the swap partition is put on the b partition but can be on some other partition. Thank you, Paul
Non-default partitions and upgrades
Hello! I generally try and run things as a project recommends, but I am wondering about running different additional partitions (e.g., add /var/www) or changing partition letter (e.g., move /var to the end for convenient VPS expansion). I know it isn't the biggest thing in the world, but would this ever have an impact on running version upgrades? Thank you, Paul
Client-authenicated TLS handshake with relayd
Hello! I am putting a small server behind Cloudflare that currently is configured to serve everything through relayd. I want to use their option of client-authenticated TLS handshakes, but I can't see a way to do it with relayd - is this possible? It does look like I could use httpd tls client ca option (assuming I'm understanding the man page), which I can use if relayd doesn't support this. Thank you! Paul
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