fw_update verify firmware?
I was just trying out the fw_update program on OpenBSD 6.5, deleting/ installing all the firmware and was wondering if fw_update will verify the files before installing? There is a SHA256.sig in the remote firmware directory, but no indication from fw_update, even with verbose output, if this is actually used. After looking at the source and manpage of fw_update, it was still not clear to me if files are checked against SHA256.sig. For syspatch, it's easy to tell from both source, manpage and program output. Normally I would just assume that fetched files are verified, but maybe in the case with fw_update, the rationale is that firmware files are binary blobs so we can't know if they are malicious anyway, therefore no reason to bother with verification. As firmware is fetched over plain HTTP, I guess that in case of no verification it would in theory make the system vulnerable to a MITM attack, but I'm no expert. Regards, Mogens Jensen
Re: OpenBSD Readonly File System
Tuesday, June 9, 2020 7:59 AM, Vertigo Altair wrote:
> Hi Misc,
> I have a firewall device and I'm using OpenBSD on it.
Last year I had to configure an OpenBSD 6.5 firewall for use in a
remote location, and was concerned about power loss corrupting the
filesystem and making the system unbootable without manual
intervention. As I did not want to modify OpenBSD in unsupported ways,
I decided to test what kind of damage power loss could do, by
randomly removing and applying power to the firewall, many many times.
What I found was that 99% of the time, the system would just repair the
filesystem and boot without problems, but if by chance the power was
removed at a short time window during kernel relinking, the kernel
would become corrupt and leave the system completely unbootable and
not easy to repair. It was suggested to me that I tried to mount root
partition with the sync option, so I arranged the partition layout in a
way that would make it feasible and added the option to fstab.
Only other problem I found, was that a few times after removing power
when writing a large file, the system would require me to run fsck -y
manually, this is by design, but I decided it was more important to me
that the system could boot unattended, with a minuscule risk of
completely ruining the filesystem, so I wrote a small unsupported patch
for the rc script (sorry if the formatting gets messed up by posting):
The patch has only been tested on OpenBSD 6.5.
---
Index: src/etc/rc
===
RCS file: /cvs/src/etc/rc,v
retrieving revision 1.536
diff -u -p -u -p -r1.536 rc
--- src/etc/rc 1 Apr 2019 11:39:46 - 1.536
+++ src/etc/rc 20 Aug 2019 22:47:49 -
@@ -1,5 +1,8 @@
# $OpenBSD: rc,v 1.536 2019/04/01 11:39:46 tedu Exp $
+# NOTE: The do_fsck() function has been patched to run 'fsck -y' if an
+# automatic file system check fails with exit code 8.
+
# System startup script run by init on autoboot or after single-user.
# Output and error are redirected to console by init, and the console is the
# controlling terminal.
@@ -271,8 +274,14 @@ do_fsck() {
echo "Reboot failed; help!"
exit 1
;;
- 8) echo "Automatic file system check failed; help!"
- exit 1
+ 8) echo "Automatic file system check failed; trying fsck -y"
+ fsck -y
+ case $? in
+ 0) ;;
+ *) echo "Could not repair file system unattended; help!"
+ exit 1
+ ;;
+ esac
;;
12) echo "Boot interrupted."
exit 1
---
After mounting root filesystem with sync option and applying the patch,
I was no longer able to make the system unbootable by power loss in my
test setup. It may be possible, but the risk is now so small that it is
not a concern for me and the risk of something else breaking is
probably bigger. During operation in remote location, the system has
always been able to completely boot after a power loss so far.
So while it was not possible for me to not make any unsupported
modifications at all, I think it is a very small change compared to
have read only filesystems. Anyone who knows OpenBSD, will be able to
manage the firewall without special instructions.
Regards,
Mogens Jensen
Re: OpenBSD Readonly File System
On Wednesday, June 24, 2020 10:58 PM, Aaron Mason wrote: > Auto filesystem repair is bad juju. Indeed, but an unbootable network appliance thousands of miles away, is much much worse. Regards, Mogens Jensen
Prohibit WiFi interface from transmitting?
I've installed OpenBSD 6.7 on a system that have an athn(4) wireless network adapter. Before setting up this device, I wanted to verify the configuration of pf, unbound etc. which required the interface to have an IP address, so I added the following line to /etc/hostname.athn0: inet 192.168.10.1 255.255.255.0 This enabled the interface, which allowed pf, unbound etc. to start: # ifconfig athn0 athn0: flags=8843 mtu 1500 lladdr XX:XX:XX:XX:XX:XX index 4 priority 4 llprio 3 groups: wlan media: IEEE802.11 autoselect (DS1) status: no network ieee80211: nwid "" inet 192.168.10.1 netmask 0xff00 broadcast 192.168.10.255 However, it also automatically made the interface start scanning: # netstat -W athn0 | grep scans 1 active scans started 0 passive scans started Is it possible to configure the athn0 interface with an IP address, but prohibit any kind of wireless communication? The reason for this is that I have to verify many systems with different configuration, which requires athn0 to be configured with an IP address. I want to do the verification and install patches before any wireless communication happens, as I can't guarantee that none of the devices within wireless range are malicious. Regards, Mogens Jensen
athn(4): hidenwid?
I'm testing an athn(4) wireless adapter (Qualcomm Atheros AR9280) in "Host AP" mode on OpenBSD 6.7 (amd64). While trying the hidenwid flag, I discovered that the ESSID is sent in responses to unspecified probe requests. This can be seen by capturing packets on another machine with wireless adapter in monitor mode. The ifconfig(8) manpage says this: "The ‘hidenwid’ flag will hide the network ID (ESSID) in beacon frames when operating in Host AP mode. It will also prevent responses to probe requests with an unspecified network ID." I can confirm that no ESSID is sent in beacon frames, but the adapter will both respond to probe requests and also add the ESSID to those responses. In athn(4) manpage under "CAVEATS" there is no information about problems with the hidenwid flag. # cat /etc/hostname.athn0 mediaopt hostap mode 11g chan 6 nwid TEST-AP wpakey 123456789 nwflag hidenwid inet 192.168.10.1 255.255.255.0 192.168.10.255 # ifconfig athn0 athn0: flags=8843 mtu 1500 lladdr XX:XX:XX:XX:XX:XX index 4 priority 4 llprio 3 groups: wlan media: IEEE802.11 autoselect mode 11g hostap status: active ieee80211: nwid TEST-AP chan 6 bssid XX:XX:XX:XX:XX:XX -95dBm \ wpakey wpaprotos wpa2 wpaakms psk wpaciphers ccmp wpagroupcipher ccmp \ hidenwid inet 192.168.10.1 netmask 0xff00 broadcast 192.168.10.255 Does anyone have an idea what could be the problem? I'm not trying to start a discussion on whether hiding the ESSID is ridiculous or not, I'm just testing different things, so I know which features work and which don't. Regards, Mogens Jensen
Re: athn(4): hidenwid?
‐‐‐ Original Message ‐‐‐ On Thursday, July 16, 2020 9:33 AM, Stefan Sperling wrote: > Nevermind, I have found the problem. Thanks. BTW some time ago I watched your EuroBSDcon 2017 talk on device driver development. I found this introduction very clear and interesting. Regards, Mogens Jensen
Problems configuring Unbound?
I'm using OpenBSD 6.5 and trying to configure "views" in Unbound. This is the configuration file: === server: interface: 0.0.0.0 access-control: 192.168.0.0/24 allow access-control-view: 192.168.0.0/24 firstview local-zone: "local." static local-data: "cups.local. IN A 192.168.1.1" view: name: "firstview" local-zone: "local." static local-data: "gateway.local. IN A 192.168.0.1" view-first: yes forward-zone: name: "." forward-addr: 8.8.8.8 === The problem is that Unbound will not use the global local-zone tree after no match is found in a view, even though view-first is set to yes. This is output from a client in 192.168.0.0/24 when running Unbound with the above configuration file: === client:~$ host -t cups.local Host cups.local not found: 3(NXDOMAIN) client:~$ host -t gateway.local gateway.local has address 192.168.0.1 === If I remove "access-control-view: 192.168.0.0/24 firstview" and try again from the same client: === client:~$ host -t cups.local cups.local has address 192.168.1.1 client:~$ host -t gateway.local Host gateway.local not found: 3(NXDOMAIN) === What could I be doing wrong? Thanks. Mogens Jensen
pf: antispoof with dynamic IP address?
The antispoof directive will expand to two block rules with IP address
of the interface, so I would think that with a dynamic IP, the interface
should be surrounded in parentheses like this:
antispoof for (wi0)
But this seems to be wrong, as I have not read any guide or FAQ that
does this, e.g. the "Building a router" guide found at
https://www.openbsd.org/faq/pf/example1.html#pf
In the gateway configuration, egress group is surrounded with
parentheses in multiple places, but not with antispoof:
antispoof quick for { egress $wired $wifi }
Why should this not be
antispoof quick for { (egress) $wired $wifi }
or
antispoof quick for { (egress:0) $wired $wifi }
Another thing I was wondering about while reading the manpage for
pf.conf:
===
The simplest mechanism to block everything by default and only pass
packets that match explicit rules is specify a first filter rule of:
block all
===
Is it not even simpler to just specify the filter rule as block without
all, they seem to expand identical?
Thanks.
Mogens Jensen
Re: pf: antispoof with dynamic IP address?
On Friday, May 21, 2021 8:22 AM, Peter N. M. Hansteen wrote: > quoting pf.conf(5): > > " The antispoof directive expands to a set of filter rules which will block > all traffic with a source IP from the network(s) directly connected to > the specified interface(s) from entering the system through any other > interface." > > This means essentially that the sample rules would fail to be effective > only if the interface you antispoof for has switched networks. I think > that is a relatively rare event for running firewalls and not doing a ruleset > reload. I'm still struggling with understanding why it works, please bear with me. Let's say I'm assigned dynamic IP address 192.0.2.5/24 from my ISP on external interface em0. antispoof em0 inet Expands to: block drop in on ! em0 inet from 192.0.2.0/24 to any block drop in inet from 192.0.2.5 to any At some point when the IP lease is renewed, the ISP has assigned an address from another block e.g. 203.0.113.21/24. I would now think that the block rules created by antispoof are obsolete as they are not updated with the new address, but why should it still work without interface name in parentheses? Thanks. Mogens Jensen
DHCP options and dhcpleased?
Is it possible to use dhcp-options(5) with dhcpleased? I need to use the DHCP option "dhcp-requested-address" with client requests. The option works with dhclient, but I understand that this daemon will be removed from base system in the future, so I prefer to use dhcpleased but it seems I can't use other options than the ones documented in dhcpleased.conf(5). Best regards, Mogens Jensen
Filesystem corruption on OpenBSD routers after power outage?
I'm going to build a router for use in a remote location, and I have chosen OpenBSD 6.5 for the task. Unfortunately, it's not possible to protect the router with an UPS, so it will have to be resilient enough to survive sudden power outages and still boot without manual intervention. In the past I have built a few Linux based routers and they were configured to run from RAM. I have made some research to see if this is also possible on OpenBSD and found that, while there are solutions to have / read-only, none of this is officially supported. Can anyone with experience running OpenBSD routers without UPS, tell if filesystem corruption is going to be a problem after power outages, or if there are any officially supported ways to make the system resilient enough to not break after a power outage? I'm using an mSATA disk with MLC flash in the router. Thanks in advance. Mogens Jensen
Re: Filesystem corruption on OpenBSD routers after power outage?
Since posting this question I have been trying to intentionally corrupt the router filesystem, by simulating power outages while writing files and various other things. Even after many tries, I have not yet been able to corrupt the filesystem so fsck cannot repair it without manual intervention. However, if power is removed while the 'reorder_kernel' script runs, the system will become completely unbootable. I could do this multiple times. A situation could be that the electric grid is unstable, so power will return and a new outage will occur shortly after, if this happens during the boot process at the exact time 'reorder_kernel' is running, the system will break because of a corrupt kernel and repair is not possible remotely. Is there a way to avoid 'reorder_kernel' during the boot process and run it manually instead? Thanks in advance. Mogens Jensen
