Filesystem corruption on OpenBSD routers after power outage?

2019-06-04 Thread Mogens Jensen
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?

2019-06-17 Thread Mogens Jensen
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


Problems configuring Unbound?

2019-08-29 Thread Mogens Jensen
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


fw_update verify firmware?

2020-05-14 Thread Mogens Jensen
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: athn(4): hidenwid?

2020-07-20 Thread Mogens Jensen
‐‐‐ 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



Prohibit WiFi interface from transmitting?

2020-07-05 Thread Mogens Jensen
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



Re: OpenBSD Readonly File System

2020-06-22 Thread Mogens Jensen
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

2020-06-25 Thread Mogens Jensen
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





athn(4): hidenwid?

2020-07-16 Thread Mogens Jensen
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



pf: antispoof with dynamic IP address?

2021-05-21 Thread Mogens Jensen
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?

2021-05-22 Thread Mogens Jensen
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