Re: Feedback on redesigned OpenBSD.org
To me, it looks just "different" rather than particularly better (except on mobile browsers, where I find the redesigned one a bit worse by having the links hidden away down the bottom. Scrolling to read the text on mobile browsers with the existing version is a bit of a nuisance, but so is scrolling to access the links in this rework). And "different" is a bit of a problem, there are at least 7 associated websites which intentionally have the same basic design, which now no longer match up. (I found v1 a lot worse than the existing one, mostly due to overriding browser default font/colour choices and disabling underlining for links). -- Please keep replies on the mailing list.
Re: Feedback on redesigned OpenBSD.org
On Sat 12 Aug 2023, Stuart Henderson wrote: > > To me, it looks just "different" rather than particularly better > (except on mobile browsers, where I find the redesigned one a bit worse > by having the links hidden away down the bottom. Scrolling to read the > text on mobile browsers with the existing version is a bit of a > nuisance, but so is scrolling to access the links in this rework). > > And "different" is a bit of a problem, there are at least 7 associated > websites which intentionally have the same basic design, which now > no longer match up. > > (I found v1 a lot worse than the existing one, mostly due to overriding > browser default font/colour choices and disabling underlining for links). As someone using the current website both on desktop and phone, the only thing that has ever sprung to mind as a possible improvement would be to constrain the line length, as I often have to tighten the window a bit (interestingly, a good line length tends to be around 80 characters [1] and where have we heard that number before?). On man.openbsd.org there is a fixed line length, just that it is a tiny bit too wide for reading comfort. [1]: https://practicaltypography.com/line-length.html I honestly like the current design. It is functional and stands out when so many other projects seem to have spent too much time on style rather than substance.
Problem with nsd not being reloaded.
To Whom It May Concern I am using nsd, which runs by default on OpenBSD 7.2 amd64. To update the zone file after changes have been made. # rcctl reload nsd would result in nsd(failed) and cannot be updated. As far as I could find, restarting the host seems to be the only way to update the zone information. How can I use the rcctl command to reload the zo information, as I am having trouble dealing with this? - # more rc.conf.local nsd_flags= smtpd_flags=NO sshd_flags=NO unbound_flags= Yours faithfully, --- WATANABE, Takeo t...@kasaneiro.jp
Re: Problem with nsd not being reloaded.
On Sat 12 Aug 2023, WATANABE Takeo wrote: > > I am using nsd, which runs by default on OpenBSD 7.2 amd64. > To update the zone file after changes have been made. > > # rcctl reload nsd > > would result in > > nsd(failed) > > and cannot be updated. > > As far as I could find, restarting the host seems to be > the only way to update the zone information. > > How can I use the rcctl command to reload the zo information, > as I am having trouble dealing with this? > > - > # more rc.conf.local > > nsd_flags= > smtpd_flags=NO > sshd_flags=NO > unbound_flags= No solution, but I am experiencing the same issue on OpenBSD 7.3. You do not need a restart though, you can just dig out the NSD PIDs with grep(1) and ps(1); then pass them to kill(1) and then use rcctl(8). Not pretty, but it works as I have not had the time to dig into what the underlying problem is. etc/rc.conf.local: nsd_flags= var/nsd/etc/nsd.conf: server: hide-version: yes verbosity: 1 database: "" remote-control: control-enable: yes control-interface: /var/run/nsd.sock ---8<---
Re: Problem with nsd not being reloaded.
On 2023-08-12, Pontus Stenetorp wrote: > On Sat 12 Aug 2023, WATANABE Takeo wrote: >> >> I am using nsd, which runs by default on OpenBSD 7.2 amd64. >> To update the zone file after changes have been made. >> >> # rcctl reload nsd >> >> would result in >> >> nsd(failed) >> >> and cannot be updated. >> >> As far as I could find, restarting the host seems to be >> the only way to update the zone information. >> >> How can I use the rcctl command to reload the zo information, >> as I am having trouble dealing with this? >> >> - >> # more rc.conf.local >> >> nsd_flags= >> smtpd_flags=NO >> sshd_flags=NO >> unbound_flags= > > No solution, but I am experiencing the same issue on OpenBSD 7.3. You > do not need a restart though, you can just dig out the NSD PIDs with > grep(1) and ps(1); then pass them to kill(1) and then use rcctl(8). Not > pretty, but it works as I have not had the time to dig into what the > underlying problem is. > > etc/rc.conf.local: > > nsd_flags= > > var/nsd/etc/nsd.conf: > > server: > hide-version: yes > verbosity: 1 > database: "" > > remote-control: > control-enable: yes > control-interface: /var/run/nsd.sock > > ---8<--- > > No problems here with "rcctl reload nsd" on 7.3 or 2-week-old -current, though typically I use "nsd-control reload " after a change. Any clues from rcctl -d reload nsd? Anything relevant in logs? If not try bumping up the detail level e.g. "verbosity: 3" -- Please keep replies on the mailing list.
Re: Problem with nsd not being reloaded.
WATANABE Takeo: > I am using nsd, which runs by default on OpenBSD 7.2 amd64. > To update the zone file after changes have been made. > > As far as I could find, restarting the host seems to be > the only way to update the zone information. nsd-control(8) -- Christian "naddy" Weisgerber na...@mips.inka.de
Re: Feedback on redesigned OpenBSD.org
On Sat, Aug 12, 2023 at 07:21:24PM +0900, Pontus Stenetorp wrote: > On Sat 12 Aug 2023, Stuart Henderson wrote: > > > > To me, it looks just "different" rather than particularly better > > (except on mobile browsers, where I find the redesigned one a bit worse > > by having the links hidden away down the bottom. Scrolling to read the > > text on mobile browsers with the existing version is a bit of a > > nuisance, but so is scrolling to access the links in this rework). > > > > And "different" is a bit of a problem, there are at least 7 associated > > websites which intentionally have the same basic design, which now > > no longer match up. > > > > (I found v1 a lot worse than the existing one, mostly due to overriding > > browser default font/colour choices and disabling underlining for links). > > As someone using the current website both on desktop and phone, the > only thing that has ever sprung to mind as a possible improvement would > be to constrain the line length, as I often have to tighten the window a > bit (interestingly, a good line length tends to be around 80 > characters [1] and where have we heard that number before?). On > man.openbsd.org there is a fixed line length, just that it is a tiny > bit too wide for reading comfort. > I have always found that 72 characters is a bit better than 80. In CSS, that would be 72ch. Versus 80ch. I often adjust the width of the window my browser is in to control that width, assuming the website doesn't fight me and force horizontal scrolling. I have key bindings on fvwm2/3 to do that. But definitely add the viewport to the head. Nothing bad can happen with that and FWIW, it bumps up OpenBSD in many searching algorithms (assuming that that is desirable). -- Chris Bennett
Assistance Needed with Wireguard VPN Configuration and pf Rules on OpenBSD 7.3
Dear OpenBSD Mailing List Community,
I hope this email finds you well. I am writing to seek your expertise
and guidance regarding a Wireguard VPN configuration and pf rules on my
OpenBSD 7.3 system. I have successfully set up a Wireguard VPN using
the provided interface configuration, and the VPN is operational as
intended. However, I have encountered a challenge while attempting to
implement pf rules to restrict access to SSH login and port number 80
based on specific IP addresses.
Below is the pf rule settings I have applied:
set skip on lo
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
# Port build user does not need network
block return in quick on bwfm0 proto tcp from ! 192.168.0.229 to bwfm0
port ssh
block return in quick on wg0 proto udp from ! 10.0.8.2 to wg0 port 80
block return in quick on bwfm0 proto tcp from ! 192.168.0.229 to bwfm0
port 80
block return out log proto {tcp udp} user _pbuild
pass in on egress proto tcp from any to any port 22
pass out on egress inet from (wg0:network) nat-to (bwfm0:0)
The objective of these rules is to restrict SSH login and access to port
80 exclusively for the machine with the IP address 192.168.0.229 when
the OpenBSD system is connected to the bwfm0 network interface. While
the rule for SSH login and IP address 192.168.0.229 is functioning as
expected, I have encountered an issue with the rule pertaining to port
80 and IP address 10.0.8.2, which is allocated by Wireguard (wg0)
during active Wireguard connections.
The problem arises when attempting to enforce the restriction on port 80
with IP address 10.0.8.2. Despite the pf rule in place, it seems that
Wireguard is overriding the restriction. For instance, devices with
assigned IP addresses such as 10.0.8.3 or 10.0.8.4, which are within
the Wireguard network, can access both SSH login and port 80, contrary
to the intended restriction.
I am providing the Wireguard configuration below for your reference:
[Interface]
ListenPort = 51820
PrivateKey = oPernzzF+Kl499z2TMU6wDdrDpnDN6/e630Q=
[Peer]
PublicKey = yyhY5Blx+PxCHu/wK7QgrXHQ34RmTi//zynVA=
AllowedIPs = 10.0.8.2/32
PersistentKeepalive = 25
[Peer]
PublicKey = dQO6ACctkgepDtWxGrHuGFdvaO9qfrL4mmjA=
AllowedIPs = 10.0.8.3/32
PersistentKeepalive = 25
I would greatly appreciate your insights, suggestions, and expertise in
resolving this issue. Your assistance will be invaluable in helping me
achieve the desired access restrictions while maintaining the
functionality of the Wireguard VPN.
Thank you for your time and consideration.
--
Soubheek Nath
Fifth Estate
Kolkata, India
soubheekn...@gmail.com
Re: Pausing/Freezing issues with Protectli FW4B
On 8/11/23 7:06 PM, Tim Baumgard wrote: On Fri, Aug 11, 2023 at 5:56 PM Stuart Henderson wrote: On 2023-08-11, Tim Baumgard wrote: I'm having an issue with my Protectli FW4B that's become more of a problem lately. Essentially, it's the same thing that this person [0] encountered. IIRC those are the machines that have problems if there's no display connected I put in a dummy HDMI plug from another piece of tricky hardware, and that seems to have fixed it. 200 pings and not a single spike over 1 ms. Thanks! For what ever it's worth, I did order my ProtectLi like 6 months ago and yes it is not the FW4B, but the VP2420. But the first thing I did on this, is the REQUEST Core Boot, NOT the "vendor American Megatrends Inc. version "5.11" date 06/18/2021" one. FYI. There is an update BIOS available for this. Your not running the latest one. Last release was "August 31, 2021" https://kb.protectli.com/kb/bios-versions-for-the-vault/?seq_no=2 Not saying it would fix your problem, but I had issue with BIOS on SuperMicro servers that didn't load bios after the date was later the 2020 or something and had the hardest time to upgrade the BIOS and after that I swear to myself to NEVER use ANY servers or computers that do not have core boot or support it. I never look back. May be this might fix your problem too. I do not know for sure. Just my $0.02 worst for that ever it is. Daniel
Re: Feedback on redesigned OpenBSD.org
On Fri, Aug 11, 2023 at 10:38:46PM -0400, Amelia A Lewis wrote: On Fri, 11 Aug 2023 20:11:02 -0600, Theo de Raadt wrote: When did it become an assumption that we would adopt any of these changes? I don't think that it did become an assumption, but as a number of people have responded to the initial design, to the point that the designer offered a revision, I thought I might add to the discussion. I apologize if it was out place to do so. The debate - since three days now - strongly suggests, that at least some of those contributing to the debate were assuming that a change of the looks of openbsd.org might be accepted. Otherwise: what sense would it make to debate it here? The point tho seems: there were at least two threads over the last 11 years on that topic: 2012: "OpenBSD's webpage desing" https://marc.info/?l=openbsd-misc&w=2&r=4&s=desing+webpage&q=b 2016: "Suggestion: new webpage for openbsd.org" https://marc.info/?t=14634695033&r=2&w=2 Result: Just compare the archived version of the site from 2011 to the present one: https://web.archive.org/web/20111223000626/http://www.openbsd.org/ So to make sure my effort is making sense: what I most certainly would have done before working on a redesign of the current page would have been to ask its maintainers, whether they wanted the change. And if yes: what sort of change. Because obviously it's, well: their page. Not mine. Plus: they probably have specific needs that I don't know about for the coding of it, to make it compatible with the frequent changes of it: updates, announcement of patches etc. - Meaning: Before doing any attempt to rewrite the code, I would have asked the current maintainers about the constraints for a change. Theo de Raadt about a rewrite of openbsd.org in 2016: -- https://marc.info/?l=openbsd-misc&m=146378604413389&w=2 "We rarely do whole-scale replacements of anything in OpenBSD, unless there is compelling reason the old should be discarded. I have probably received 500+ proposals for website rewrites, a handful with the effort already expended. This is another offer which will be rejected. It is kind of sad. I think the site is fine. [ ... ] I agree there would be value in small tweaks to improve the view for narrow displays. This is a project that does rapid incremental changes. This entire concept of throw-it-away, you-want-the-new-warts; I don't get where it comes from." -- Nice weekend, everyone!
Re: Virtio fix for testing
Andrew Cagney writes: > Ref: https://marc.info/?l=openbsd-tech&m=168458764424059&w=2 > https://marc.info/?l=openbsd-misc&m=168071258109433&w=2 I see you found a similar issue and even a fix, good job. I believe misc@ is a better place for such questions, so I'm cc'ing that. > Is there a way to get an updated ISO or kernel with the fix? Have you tried a snapshot? They are produced pretty regularly. The project only has resource for the releases and snapshots. So if you need a build with a back port, you are likely in the best position to do that. Thanks Greg
fyi: ftp.openbsd.org: download connection breaks over slow lines
Hello. 'Appeared as forceful breaks, ie, there were no seconds without any activity, but real breaks from now to then. Just in case anyone feels the desire to look and tune, or whatever. -rw-rw 1 ports ports461016 Aug 12 19:05 openssh-9.4p1.tar.gz.partial $ curl --continue-at - --compressed -O https://ftp.openbsd.org/pub/OpenBSD/OpenSSH/portable/openssh-9.4p1.tar.gz % Total% Received % Xferd Average Speed TimeTime Time Current Dload Upload Total SpentLeft Speed 24 1801k 24 448k0 0 7226 0 0:04:15 0:01:03 0:03:12 8000 curl: (18) transfer closed with 1386342 bytes remaining to read $ curl --continue-at - --compressed -O https://ftp.openbsd.org/pub/OpenBSD/OpenSSH/portable/openssh-9.4p1.tar.gz ** Resuming transfer from byte position 458752 % Total% Received % Xferd Average Speed TimeTime Time Current Dload Upload Total SpentLeft Speed 33 1353k 33 448k0 0 7283 0 0:03:10 0:01:02 0:02:08 8000 curl: (18) transfer closed with 927590 bytes remaining to read $ curl --continue-at - --compressed -O https://ftp.openbsd.org/pub/OpenBSD/OpenSSH/portable/openssh-9.4p1.tar.gz ** Resuming transfer from byte position 917504 % Total% Received % Xferd Average Speed TimeTime Time Current Dload Upload Total SpentLeft Speed 49 905k 49 448k0 0 7171 0 0:02:09 0:01:03 0:01:06 4000 curl: (18) transfer closed with 468838 bytes remaining to read $ curl --continue-at - --compressed -O https://ftp.openbsd.org/pub/OpenBSD/OpenSSH/portable/openssh-9.4p1.tar.gz ** Resuming transfer from byte position 1376256 % Total% Received % Xferd Average Speed TimeTime Time Current Dload Upload Total SpentLeft Speed 97 457k 97 448k0 0 7146 0 0:01:05 0:01:04 0:00:01 9364 curl: (18) transfer closed with 10086 bytes remaining to read $ curl ipv4.icanhazip.com 217.144.132.164 $ curl --continue-at - --compressed -O https://ftp.openbsd.org/pub/OpenBSD/OpenSSH/portable/openssh-9.4p1.tar.gz ** Resuming transfer from byte position 1835008 % Total% Received % Xferd Average Speed TimeTime Time Current Dload Upload Total SpentLeft Speed 100 10086 100 100860 0 9417 0 0:00:01 0:00:01 --:--:-- 9426 $ ll openssh-9.* -rw-rw 1 ports ports 1835850 Jul 19 23:22 openssh-9.3p2.tar.gz -rw-rw 1 ports ports 461016 Aug 12 19:05 openssh-9.4p1.tar.gz.partial -rw-rw 1 ports ports 1845094 Aug 12 19:12 openssh-9.4p1.tar.gz $ rm openssh-9.4p1.tar.gz.partial Thanks and Ciao! --steffen | |Der Kragenbaer,The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)
Re: Feedback on redesigned OpenBSD.org
On Sat, Aug 12, 2023 at 06:23:07PM +0200, Wolfgang Pfeiffer wrote: > > On Fri, Aug 11, 2023 at 10:38:46PM -0400, Amelia A Lewis wrote: > > On Fri, 11 Aug 2023 20:11:02 -0600, Theo de Raadt wrote: > > > When did it become an assumption that we would adopt any of these > > > changes? > > > > I don't think that it did become an assumption, but as a number of > > people have responded to the initial design, to the point that the > > designer offered a revision, I thought I might add to the discussion. I > > apologize if it was out place to do so. > > The debate - since three days now - strongly suggests, that at least > some of those contributing to the debate were assuming that a change > of the looks of openbsd.org might be accepted. Otherwise: what sense > would it make to debate it here? > > The point tho seems: there were at least two threads over the last 11 > years on that topic: > > 2012: > "OpenBSD's webpage desing" > https://marc.info/?l=openbsd-misc&w=2&r=4&s=desing+webpage&q=b > > 2016: > "Suggestion: new webpage for openbsd.org" > https://marc.info/?t=14634695033&r=2&w=2 > > Result: > Just compare the archived version of the site from 2011 to the > present one: > https://web.archive.org/web/20111223000626/http://www.openbsd.org/ > > So to make sure my effort is making sense: what I most certainly would > have done before working on a redesign of the current page would have > been to ask its maintainers, whether they wanted the change. And if > yes: what sort of change. Because obviously it's, well: their page. > Not mine. Plus: they probably have specific needs that I don't know > about for the coding of it, to make it compatible with the frequent > changes of it: updates, announcement of patches etc. - Meaning: Before > doing any attempt to rewrite the code, I would have asked the > current maintainers about the constraints for a change. > > Theo de Raadt about a rewrite of openbsd.org in 2016: > > -- > https://marc.info/?l=openbsd-misc&m=146378604413389&w=2 > > "We rarely do whole-scale replacements of anything in OpenBSD, unless > there is compelling reason the old should be discarded. I have > probably received 500+ proposals for website rewrites, a handful with > the effort already expended. This is another offer which will be > rejected. It is kind of sad. > > I think the site is fine. [ ... ] I agree there would be value in > small tweaks to improve the view for narrow displays. > > This is a project that does rapid incremental changes. This entire > concept of throw-it-away, you-want-the-new-warts; I don't get where > it comes from." > > -- > > Nice weekend, everyone! > >From what I am reading in this thread, nobody seems to agree about what they really want. I think that that is a pretty good sign that a consensus is not going to happen. openbsd.org is on CVS. OpenBSD comes with a built-in httpd. As long as it's not publicly available, anyone can run a copy and insert whatever CSS meets their needs. The current website version can be updated from CVS. Just change the stylesheet link to whatever your favorite styling looks like and you are good. If you don't know how to write CSS, learn it. What doesn't require learning something new to use or contribute to OpenBSD? Nothing. That is my opinion. I definitely do not get a vote, especially since I have never even submitted a diff for the website. Unless I am using my phone, I give it a 50% chance that I will be using a text browser to view the site. I use lynx 100% to look at the packages and installation files. It just works. -- Chris Bennett
Re: [cpb_m...@bennettconstruction.us: I would like help matching my outgoing domains to the right IP for smtpd]
It's the weekend. I will see if anyone has any advice later. I will spend my time looking at perhaps solving the problem with a filter and using tcpdump and the debug features of smtpd to follow what I come up with. -- Chris Bennett
My /usr cleaning campaign..
Hello, Do not panic, I do not want to erase you, users of OpenBSD.. In prevision of my next sysupgrade I just found myself in the need to free up space from /usr where I just remain with 2.1gb free.. Indeed I feel these gb few although, I know, requirement is 1.1gb of free space for a successful upgrade. Almost this is what OpenBSD says to myself.. I already used "sysclean" to check stuff but without much (space) luck.. I found instead /usr/share/relink/kernel/GENERIC.MP (636M) that is good to not have, eventually. Is it safe to move away or erase it? Any other suggestion for my /usr cleaning campaign? ;D Thanks! -- Daniele Bonini
Re: Assistance Needed with Wireguard VPN Configuration and pf Rules on OpenBSD 7.3
First off, unless you faked your private and public keys, please change
them as soon as possible.
You've just made yourself volunerable to cyber attacks!
If I understand you correctly, you want to be able to SSH and HTTP only
over WireGuard, right?
In that case, on your WireGuard server:
# Block access to SSH and HTTP from everyone except for your WireGuard network
pass in quick on wg0 proto tcp from 10.0.8.0/24 to any port {22, 80}
block in quick on egress proto tcp from any to any port {22, 80}
>From your specifications, it's not quite clear whether your network is
accessible from the outside or not, whether you're using a dynamic IP or
static IP, how your router is configured, and all else, because
requirements change depending on these details.
If you're using a dynamic IP, and both your server and clienbts are
within the same network, there's a good chance that this setup is
unnecessary, given that using a WireGuard VPN makes sense if the server
is remote and normally accessible from the outside, and you want to make
it only accessible from the inside.
As for your WireGuard config, you might want to add the Address to your
"[Interface]" block like this for example:
Address = 10.0.8.1/24
Not necessarily required to get it working, but would still add an extra
layer of security if you generate a preshared key on each peer, then on
both your server and peers:
[Peer]
...
PreSharedKey = (output)
...
To generate the preshared key (only do this on your peers):
wg genpsk > preshared.key
On 2023年08月12日 20:30, SOUBHEEK NATH wrote:
> Dear OpenBSD Mailing List Community,
>
> I hope this email finds you well. I am writing to seek your expertise
> and guidance regarding a Wireguard VPN configuration and pf rules on my
> OpenBSD 7.3 system. I have successfully set up a Wireguard VPN using
> the provided interface configuration, and the VPN is operational as
> intended. However, I have encountered a challenge while attempting to
> implement pf rules to restrict access to SSH login and port number 80
> based on specific IP addresses.
>
> Below is the pf rule settings I have applied:
>
> set skip on lo
> 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
>
> # Port build user does not need network
> block return in quick on bwfm0 proto tcp from ! 192.168.0.229 to bwfm0
> port ssh
> block return in quick on wg0 proto udp from ! 10.0.8.2 to wg0 port 80
> block return in quick on bwfm0 proto tcp from ! 192.168.0.229 to bwfm0
> port 80
> block return out log proto {tcp udp} user _pbuild
>
> pass in on egress proto tcp from any to any port 22
>
> pass out on egress inet from (wg0:network) nat-to (bwfm0:0)
>
> The objective of these rules is to restrict SSH login and access to port
> 80 exclusively for the machine with the IP address 192.168.0.229 when
> the OpenBSD system is connected to the bwfm0 network interface. While
> the rule for SSH login and IP address 192.168.0.229 is functioning as
> expected, I have encountered an issue with the rule pertaining to port
> 80 and IP address 10.0.8.2, which is allocated by Wireguard (wg0)
> during active Wireguard connections.
>
> The problem arises when attempting to enforce the restriction on port 80
> with IP address 10.0.8.2. Despite the pf rule in place, it seems that
> Wireguard is overriding the restriction. For instance, devices with
> assigned IP addresses such as 10.0.8.3 or 10.0.8.4, which are within
> the Wireguard network, can access both SSH login and port 80, contrary
> to the intended restriction.
>
> I am providing the Wireguard configuration below for your reference:
>
> [Interface]
> ListenPort = 51820
> PrivateKey = oPernzzF+Kl499z2TMU6wDdrDpnDN6/e630Q=
>
> [Peer]
> PublicKey = yyhY5Blx+PxCHu/wK7QgrXHQ34RmTi//zynVA=
> AllowedIPs = 10.0.8.2/32
> PersistentKeepalive = 25
>
> [Peer]
> PublicKey = dQO6ACctkgepDtWxGrHuGFdvaO9qfrL4mmjA=
> AllowedIPs = 10.0.8.3/32
> PersistentKeepalive = 25
>
> I would greatly appreciate your insights, suggestions, and expertise in
> resolving this issue. Your assistance will be invaluable in helping me
> achieve the desired access restrictions while maintaining the
> functionality of the Wireguard VPN.
>
> Thank you for your time and consideration.
> --
> Soubheek Nath
> Fifth Estate
> Kolkata, India
> soubheekn...@gmail.com
>
--
lain.
Did you know that?
90% of all emails sent on a daily basis are being sent in plain text, and it's
super easy to intercept emails as they flow over the internet?
Never send passwords, tokens, personal information, or other volunerable
information without proper PGP encryption!
If you're writing your emails unencrypted, please consider sending PGP
encrypted emails for security reasons.
You can find my PGP public key at: https://fair.moe/lain.asc
Every good email client is able to send encrypted emails.
If yours can't, then you shoul
Re: Assistance Needed with Wireguard VPN Configuration and pf Rules on OpenBSD 7.3
I failed to come up with reasons for using a preshared key, so I've let
ChatGPT generate reasons for me:
Certainly! WireGuard's use of a preshared key (PSK) adds an additional layer of
symmetric encryption to the standard asymmetric encryption. Here's a brief
explanation of the advantage:
1. **Symmetric vs. Asymmetric Encryption**: WireGuard primarily uses asymmetric
encryption, where each party has a pair of keys (public and private). Symmetric
encryption, on the other hand, utilizes the same key for both encryption and
decryption. By adding a PSK, WireGuard incorporates both types of encryption.
2. **Additional Security Layer**: The PSK is mixed into the encryption process
along with the standard public and private keys. Even if an attacker could
somehow compromise the asymmetric part (though practically very difficult),
they would still need the PSK to decrypt the communication.
3. **Protection Against Quantum Attacks**: Though still theoretical at this
point, quantum computers could eventually break the Diffie-Hellman key exchange
used in many encryption protocols. By using a PSK, WireGuard adds protection
against this potential future vulnerability.
4. **Simplicity**: WireGuard's design is intended to be simple and easy to
implement. The use of a PSK aligns with this philosophy by providing a
straightforward way to bolster security.
Here's an example of how you would generate and implement a preshared key in
WireGuard:
Generate the PSK:
```bash
wg genpsk
```
You would then add the generated key to both the client and server
configurations:
Server's `wg0.conf`:
```ini
[Peer]
PublicKey = CLIENT_PUBLIC_KEY
PresharedKey = GENERATED_PRESHARED_KEY
AllowedIPs = CLIENT_IP/32
```
Client's `wg0.conf`:
```ini
[Peer]
PublicKey = SERVER_PUBLIC_KEY
PresharedKey = GENERATED_PRESHARED_KEY
AllowedIPs = 0.0.0.0/0
Endpoint = SERVER_IP:PORT
```
In summary, adding a PSK provides an extra layer of security that complements
the existing asymmetric encryption, protects against potential quantum attacks,
and adheres to WireGuard's principles of simplicity and effectiveness.
On 2023年08月13日 10:22, lain. wrote:
> First off, unless you faked your private and public keys, please change
> them as soon as possible.
> You've just made yourself volunerable to cyber attacks!
>
> If I understand you correctly, you want to be able to SSH and HTTP only
> over WireGuard, right?
> In that case, on your WireGuard server:
>
> # Block access to SSH and HTTP from everyone except for your WireGuard network
> pass in quick on wg0 proto tcp from 10.0.8.0/24 to any port {22, 80}
> block in quick on egress proto tcp from any to any port {22, 80}
>
> From your specifications, it's not quite clear whether your network is
> accessible from the outside or not, whether you're using a dynamic IP or
> static IP, how your router is configured, and all else, because
> requirements change depending on these details.
> If you're using a dynamic IP, and both your server and clienbts are
> within the same network, there's a good chance that this setup is
> unnecessary, given that using a WireGuard VPN makes sense if the server
> is remote and normally accessible from the outside, and you want to make
> it only accessible from the inside.
>
> As for your WireGuard config, you might want to add the Address to your
> "[Interface]" block like this for example:
> Address = 10.0.8.1/24
>
> Not necessarily required to get it working, but would still add an extra
> layer of security if you generate a preshared key on each peer, then on
> both your server and peers:
> [Peer]
> ...
> PreSharedKey = (output)
> ...
>
> To generate the preshared key (only do this on your peers):
> wg genpsk > preshared.key
>
> On 2023年08月12日 20:30, SOUBHEEK NATH wrote:
> > Dear OpenBSD Mailing List Community,
> >
> > I hope this email finds you well. I am writing to seek your expertise
> > and guidance regarding a Wireguard VPN configuration and pf rules on my
> > OpenBSD 7.3 system. I have successfully set up a Wireguard VPN using
> > the provided interface configuration, and the VPN is operational as
> > intended. However, I have encountered a challenge while attempting to
> > implement pf rules to restrict access to SSH login and port number 80
> > based on specific IP addresses.
> >
> > Below is the pf rule settings I have applied:
> >
> > set skip on lo
> > 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
> >
> > # Port build user does not need network
> > block return in quick on bwfm0 proto tcp from ! 192.168.0.229 to bwfm0
> > port ssh
> > block return in quick on wg0 proto udp from ! 10.0.8.2 to wg0 port 80
> > block return in quick on bwfm0 proto tcp from ! 192.168.0.229 to bwfm0
> > port 80
> > block return out log proto {tcp udp} user _pbuild
> >
> > pass in on egress proto tcp from any
Re: My /usr cleaning campaign..
On Sun, Aug 13, 2023 at 02:31:44AM +0200, Daniele B. said: I found instead /usr/share/relink/kernel/GENERIC.MP (636M) that is good to not have, eventually. Is it safe to move away or erase it? Leave it alone. Any other suggestion for my /usr cleaning campaign? ;D You have sufficient free space to safely proceed with the upgrade. Why potentially risk deleting something you don't understand? I would suggest either: - Proceed with the upgrade. - Reinstall the system from scratch with a larger /usr. -- Please direct replies to the list.
Re: My /usr cleaning campaign..
Thanks for this one Matthew. Looking further, I noticed.. - /usr/local/share/gtk-doc (=131MB), html doc completed of some vary .png files.. I guess this could be not only an endemic problem of my stick as gtk-doc is not installed here: I'm not in the need of GTK C code documentation - /usr/local/share/doc (=118MB) and.. - what about /usr/local/share/gir-1.0 (70M) ? I'd like almost to delete ./gtk-doc and move ./doc to eg. /home/ (with sensibly more space) with a link to among the toppings.. ;D Matthew Ernisse wrote: > On Sun, Aug 13, 2023 at 02:31:44AM +0200, Daniele B. said: > >I found instead /usr/share/relink/kernel/GENERIC.MP (636M) that is > >good to not have, eventually. Is it safe to move away or erase it? > > Leave it alone. > > >Any other suggestion for my /usr cleaning campaign? ;D > > You have sufficient free space to safely proceed with the upgrade. > Why potentially risk deleting something you don't understand? > > I would suggest either: > - Proceed with the upgrade. > - Reinstall the system from scratch with a larger /usr. -- Daniele Bonini Project Owner and Author http://5mode.com via Massimo Gorki 23 40128 splash.ooo/g/Bologna Italy +390514086280 +393314029415 -- This message is confidential, including all materials contained inside or attached to this email, and intended only for the addressee. If you have received this message in error, please delete it from your systems. You are hereby notified that distribution or copying of its content is strictly prohibited. For information about 5 Mode visit http://5mode.com
Re: My /usr cleaning campaign..
Thanks for this one Matthew. Looking further, I noticed.. - /usr/local/share/gtk-doc (=131MB), html doc completed of some vary .png files.. I guess this could be not only an endemic problem of my stick as gtk-doc is not installed here: I'm not in the need of GTK C code documentation - /usr/local/share/doc (=118MB) and.. - what about /usr/local/share/gir-1.0 (70M) ? I'd like almost to delete ./gtk-doc and move ./doc to eg. /home/ (with sensibly more space) with a link to among the toppings.. ;D -- Daniele Bonini Matthew Ernisse wrote: > On Sun, Aug 13, 2023 at 02:31:44AM +0200, Daniele B. said: > >I found instead /usr/share/relink/kernel/GENERIC.MP (636M) that is > >good to not have, eventually. Is it safe to move away or erase it? > > Leave it alone. > > >Any other suggestion for my /usr cleaning campaign? ;D > > You have sufficient free space to safely proceed with the upgrade. > Why potentially risk deleting something you don't understand? > > I would suggest either: > - Proceed with the upgrade. > - Reinstall the system from scratch with a larger /usr.
