Old thread, but wondering if any updates?
I posted this way back in 2017 but i'm wondering if anything has changed... https://marc.info/?l=openbsd-misc&m=149613307021262&w=2 Is the 16Tb restriction been removed for full disk encryption? Thanks
Re: suggestions for USB printer (maybe even with scanner)?
On 6/2/20 7:26 am, Adam Thompson wrote: > I don't know what you need in a printer, and I don't know what you mean > by cheap, so... YMMV. > > However, I've found Brother **LASER** printers to be very good, and most > of them support PCL6 and/or PS3. > For example, the HL-L2370DW can only connect via USB, and supports PCL6, > and currently sells for ~C$150-160. Somewhat related, does this hold true for their Ethernet-connected printers as well? We have an Epson WF-7510 which is due for replacement and while I can set up OpenBSD on a small box to act as a print server, having something I can point OpenBSD's lpd or cups at over a network is helpful too. -- Stuart Longland (aka Redhatter, VK4MSL) I haven't lost my mind... ...it's backed up on a tape somewhere.
Re: Detecting DoH using PF
On Mon, Feb 17, 2020 at 1:19 PM Erik Lauritsen wrote: > Is a DNS over HTTPS recognizable somehow so that it can be fingerprinted > and redirected or blocked using pf? > > I am thinking about the ability of PF to detect when requests are coming from > a windows machine for example. As Paul asked, what's the reason behind your question? Privacy? The solution for you depends on you how much work you want to do and what you have for a network, devices, and applications. Blocking requests is a reasonable solution with some caveats. Remember that you'd have to keep the configuration updated, though probably infrequently. Applications and devices may use their own factory-set DNS settings and not those specified by your DHCP server, so they may fail if they can't connect to a server blocked in pf(4). This means that some things you can't fully configure like IOT devices, TVs, game consoles, or that one thing your boss likes may not work or may not work after a future update. This isn't as much of a problem if the network can be segmented so that the pf(4) rules apply to only certain devices, but it does involve a little extra work. Redirecting or relaying the request requires some form of deep packet inspection since the requests are encrypted. This also requires a local certificate authority that is trusted by the devices on the network, which may not be possible for everything on it. Devices like those listed above may fail. Again, this may not be an issue if you can segment your network so that you're only relaying the requests from the devices that you can install the local CA certificate on, but I'm not sure if a program to relay DoH requests exists anyway. As far as I'm aware, "enterprise policies" can be used to disable DoH in some OSes and applications. All devices and applications have to support them and be configured to use them to fully block them. Things that don't support them will get through. Again, you have to think about your situation and what you want to accomplish. If the above shortcomings are okay with you, pick the one that works best for your situation. That said, this is what I do personally for my own network: I don't knowingly use any devices, OSes, or applications on my network that use DoH other than Firefox, and all my main devices--desktop, laptop, phone, tablet--are known to obey the DNS settings from dhcpd(8). My network is also segmented. My current "works well enough for me" solution to cover Firefox without changing its settings on every device is to add this to my unbound.conf(5): # By default, disable DoH for Firefox. # https://support.mozilla.org/en-US/kb/configuring-networks-disable-dns-over-https local-zone: "use-application-dns.net" always_nxdomain This means that all the things I really care about privacy-wise with regards to DoH are fine. Be aware that Firefox apparently still uses DoH if the setting is turned on in its preferences. For what it's worth, the OpenBSD port of Firefox disables DoH by default. Tim
deny unknown-clients
Hi All,
I'm running openbsd current and running dhcpd, on all of my subnets I
use "deny unknown-clients;" and comment out the range.
I have a wireless access point defined in one subnet (192.168.0.0/24),
but not in another (192.168.1.0/24). When I move the ethernet cable
from the interface where it's defined to the other interface, where it's
not defined, it still picks up an address, is this by design?
Clients that are not defined anywhere in the dhcpd.conf do get denied
addresses.
subnet 192.168.0.0 netmask 255.255.255.0 {
option routers 192.168.0.254;
option domain-name-servers 192.168.0.254;
# range 192.168.0.33 192.168.0.127;
deny unknown-clients;
host eap245 { hardware ethernet 78:da:d4:35:33:d0; fixed-address
192.168.0.1; }
}
subnet 192.168.1.0 netmask 255.255.255.0 {
option routers 192.168.1.254;
option domain-name-servers 192.168.1.254;
# range 192.168.1.33 192.168.1.127;
deny unknown-clients;
}
Thanks in advance.
softraid i/o errors, crypto blocks
I've had Postgresql data on an encrypted external USB drive (encrypted via the OpenBSD FAQ instructions) for about a year and it's worked great. Recently, I started gettting dmesg messages saying softraid i/o error and it listed various crypto blocks: Feb 18 09:04:14 freda /bsd: softraid0: chunk sd4a already in use Feb 18 09:04:22 freda /bsd: softraid0: sd5: i/o error 0 @ CRYPTO block 27xxx Feb 18 09:04:22 freda /bsd: softraid0: sd5: i/o error 0 @ CRYPTO block 6xx Feb 18 09:04:31 freda /bsd: softraid0: sd5: i/o error 0 @ CRYPTO block 1624932xxx Feb 18 09:04:31 freda /bsd: softraid0: sd5: i/o error 0 @ CRYPTO block 1624811xxx In this case, it happened when I tried to mount a second external encrypted drive. (I don't recall if this is what always triggers the problem.) My drive with Postgresql running was sd5i. I always mount the drives with the DUID after running bioctl. The sd4a above refers to RAID on the second encrypted drive I had plugged in and just run /sbin/bioctl -c C -l softraid0 DUIDHERE.a on. I'm running OpenBSD 6.6-current (GENERIC.MP) #648: Sun Feb 16 13:54:33 MST 2020 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP Currently, I have Postgresql 12.1p1 but it happened when the previous external drive had 11.6 data also. At this point of course I can no longer access my data. If I reboot then / also fails to unmount. Rebooting is successful though after filesystem checks. Next time it happens I will take a picture of the messages. I thought my external drive was bad so I switched to a new one, but the same thing happened today. So I am just wondering if anyone else has recently started experiencing this sort of problem. I haven't lost any data since I backup early and often, and in any case, fsck has fixed things so far.
Re: USB printer?
On Mon, Feb 17, 2020 at 06:47:49PM +0100, Claus Assmann wrote: > I got a > HP DeskJet 2630 > printer and connected it via usb > I tried to use it "directly", i.e., /etc/printcap: > usb:lp=/dev/ulpt0:sd=/var/spool/output/usb:sf:sh:tr=^D: > as mentioned in the original mail > > but this results in an "output error" after I started lpd > and used > lpr doc.ps > > ulpt0 at uhub0 port 4 configuration 1 interface 1 "HP DeskJet 2600 series" > rev 2.00/1.00 addr 2 > ulpt0: using bi-directional mode > ugen0 at uhub0 port 4 configuration 1 "HP DeskJet 2600 series" rev 2.00/1.00 > addr 2 > ulpt0: output error > > I didn't try to set up cups or similar stuff as that seems > to be overkill for my simple use case and probably results > in the same USB error? > If someone has this kind of printer connected via USB: I am > interested in the config. Try the cups-filters package and follow the instructions given in the file /usr/local/share/doc/pkg-readmes/cups-filters You can't avoid the printer drivers from cups but you may be able to get away with running lpd(8) instead of cupsd. You will also need a2ps and a suitable printer driver (foo2zjs in my case). Here are the packages I use for my HP LaserJet 1020: a2ps-4.14p15format files for printing on PostScript printers cups-filters-1.25.6 OpenPrinting CUPS filters foo2zjs-20190909driver for ZjStream wire protocol compatible printers Note however that ulpt(4) recognizes my printer and loads firmware for it. If firmware is also required for your model to work (I have no idea if it is) then the ulpt driver would need to be modified to do that, too. $ cat /etc/printcap lp|local line printer|HP-LaserJet_1020:\ :lf=/var/log/lpd-errs:\ :sd=/var/spool/output/lpd:\ :lp=/dev/ulpt0:\ :if=/etc/foomatic/direct/filter.sh:\ :sh:\ :mx#0: And the filter script is this: $ cat /etc/foomatic/direct/filter.sh #!/bin/sh # for debugging: #echo "$*" >> /tmp/filter-args args=`getopt cw:l:i:j:n:h: $*` if [ $? -ne 0 ] then echo 'Usage: [-c] -wwidth -llength -iindent -n login -h host acct-file' exit 2 fi set -- $args while [ $# -ne 0 ] do case "$1" in -c) flag="$1"; shift;; -o|-w|-l|-i|-j|-n|-h) oarg="$2"; shift; shift;; --) shift; break;; esac done /usr/local/bin/a2ps -BRq --columns=1 -o - | \ /usr/local/bin/foomatic-rip -P HP-LaserJet_1020 \ --ppd /etc/foomatic/direct/HP-LaserJet_1020.ppd
Re: Smartphone Alternatives
Hi there. I have yet to see a smartphone I would trust with anything important. Nowadays I have a real laptop for computer stuff and leech free wifi, and a Nokia feature phone from 2016. I tried to get an Android phone into a "secure state" by replacing the OS with LineageOS, but the Android base is just very bad. The encryption subsystem encrypts what it wants and leaves the rest unprotected, proxy settings across the OS are not applied consistently... Two days after I left it in a state I liked, my favourite mare stepped on it accidentally. Predrag Punosevac wrote: > Hi, > > I would firstly like to apologize to developers as the question I am > about to ask has little to do with OpenBSD. However, in my experience > the number of security conscious people lurking on this mailing list is > such that I could not resist. > > Long story short one of my virtual servers (running Red Hat) got hacked > by cryptomining folks. I noticed 100% load on CPUs coming out of a cron > job and traced everything to a cryptomining scripts. Sure enough there > was an ssh-key .ssh/authorized_keys which was not suppose to be there. > Incidentally, I had to turn off Duo 2-factor authentication as one of my > users insisted on having GUI access via X2go-client. > > I am not much of a security expert so my instinct is that account was > compromised by scooping account information from a browser cash or my > "smart" phone while reading email from Office 365. I have log files and > I am going through them. Browser cash problem hopefully will be offset > now when I have 2-factor enabled for Office 365 email and using only > browser on my locked down OpenBSD desktop. > > However, that still leaves me with a damn Android smartphone. I already > deleted/disabled email clients but the more I look the more I feel > stupid for having that crap. I am looking now at purchasing something > like Nokia 106. Note that I use one of USA T-Mobile plans and my current > smartphone works well across the globe. It looks like Nokia 106 doesn't > work in Europe. > > I would appreciate any advises, comments, suggestions on the choice of > mobile device for basic phone calls and texting. It would be painful to > carry around a small laptop for web browsing, maps, and few other > useful things but it looks like I am heading there. > > Thanks for your help. > > Predrag Punosevac > > -- OpenPGP Key Fingerprint: BB5A C2A2 2CAD ACB7 D50D C081 1DB9 6FC4 5AB7 92FA
Re: USB printer?
In my belief, you _must install hpcups. And if you use the usb then you _must disable ulpt in the kernel. See /usr/local/share/doc/pkg-readmes/cups
Re: Full disk encryption including /boot, excluding bootloader?
On Tue, Feb 18, 2020 at 08:05:29AM +0100, Paul de Weerd wrote: On Tue, Feb 18, 2020 at 05:12:25AM +, Frank Beuth wrote: | Yes, it's a cool way to combine things to get unexpected functionality. | I haven't dug into the bootloader much... is there a reasonably easy way | to get the USB-stick-bootloader to boot the hard drive partition by | default? Best way to dig into the bootloader is by starting at its fine manpage which you can read online at http://man.openbsd.org/man8/amd64/boot.8 The quick answer is `echo 'boot sr0a:/bsd' > /etc/boot.conf` (on the USB-stick's root filesystem). Thanks!
Re: Full disk encryption including /boot, excluding bootloader?
> Are there any downsides though? For example, would resume from > hibernation still work for such a setup? It should work with hibernation without any problems, but i did not test this extensively. > > More so, for the less knowledgeable of us, how does this relate to > UEFI's "Secure Boot"? I can only hope OpenBSD will support it some > day, at least for amd64. Debian has implemented it for the last major > release, Debian 10. Secure Boot as defined by the UEFI specification works with cryptographic signatures instead of just measuring. Meaning there is also a Chain in which every component has to verify the Signature of the next one. The downside of this approach is, that in order to verify any signature, you need some keys that you trust. If your name is Microsoft, than you can get every vendor to include your keys inside the firmware and your bootloader can be verified. This is obviously very convenient for the user. If you are not Microsoft and your signature key is not included in the firmware, than users have to sign the boot components manually and add their keys to the firmware. To sum it up. I think that SecureBoot was the right choice for Microsoft but for FOSS the TPM approach is less hassle for the user. Also measuring can not only be done for the executable itself, but also for the data it uses. That way buffer overflow attacks can also be detected. The signature based approach can not do that. In the next few days i will write a email to misc containing a small manual and all the source code. Best Regards Julius
Re: Full disk encryption including /boot, excluding bootloader?
Make sure no one has physical access to you machine! EVER. Lock it away. That way no 'Evil Maid' or any one else can access it! This is not hard. Why is this a thing? If someone has physical access to you box then it is Game Over! All of these fantasy efforts are BS. Physically secure your hardware people! You are deluding yourselves.
Re: Detecting DoH using PF
Hello *,
for detecting DNS over HTTPS traffic without interfering with the connection,
perhaps
these articles might be helpful:
-
https://dshield.org/forums/diary/Is+it+Possible+to+Identify+DNS+over+HTTPs+Without+Decrypting+TLS/25616
-
https://dshield.org/forums/diary/More+DNS+over+HTTPS+Become+One+With+the+Packet+Be+the+Query+See+the+Query/25628
Thanks, and best regards,
Peter Müller
> Hi Erik,
>
> On Mon, Feb 17, 2020 at 06:07:59PM +, Erik Lauritsen wrote:
> | Hi,
> |
> | Is a DNS over HTTPS recognizable somehow so that it can be fingerprinted
> | and redirected or blocked using pf?
>
> I haven't studied this in close detail, but since it's just a "normal"
> (albeit generally small) HTTPS request, I doubt they can be easily
> fingerprinted. But I wonder: what is your interest?
>
> My concern is not users using safe (encrypted) transports for their
> DNS lookups, but users unwittingly sending their data to certain large
> companies. To that end I've populated a table in pf with IP addresses
> from https://en.wikipedia.org/wiki/Public_recursive_name_server and
> simply have
>
> block out log from any to
>
> to prevent anyone on the local network from accessing them. Some of
> them are more popular than others but it works well enough:
>
> # pfctl -vvt openrecursor -T show | awk '/\[/ {p+=$4; b+=$6} END {print p, b}'
> 14672 1100046
>
> so 14672 packets / 1100046 bytes blocked to these open recursors.
> Note that the rule blocks both DoH as well as 'normal' DNS or DoT
> requests.
>
> | I am thinking about the ability of PF to detect when requests are coming
> from
> | a windows machine for example.
>
> OS fingerprinting looks at TCP characteristics; DoH requests are
> inside an encrypted transport and (probably) hard to discern from
> 'normal' HTTPS traffic.
>
> Cheers,
>
> Paul 'WEiRD' de Weerd
>
Re: Full disk encryption including /boot, excluding bootloader?
On Mon, Feb 17, 2020 at 04:09:57PM +0100, Julius Zint wrote: I'm not really in a position to reflash my machine but I would still be curious for details. There is no need to reflash your firmware if the system has a integrated and supported TPM 1.2 chip. The prototype uses a Static Root of Trust for Measurment (SRTM) approach where the Chain of Trust is extended from a small immutable firmware part up to boot(8). Every component in the boot chain is responsible for measuring the components, that it hands control over the system. Measuring just means calculating the hash and sending it to the TPM. The following example is the Chain of Trust from my test system Lenovo Thinkpad X240 with OpenBSD. 1: Core Static Root of Trust for Measurment (C-SRTM) (immutable part of the Firmware) 2: Firmware (including OptionROMS) 3: MBR (mbr(8)) 4: PBR (biosboot(8)) 5: boot(8) (residing in the softraid(4) metadata when FDE is enabled) I changed the mbr(8) and biosboot(8) to support measuring their next component. Because there is very little available space left in the 440 byte of the mbr(8) startprogram, you have to choose between CHS and measurement support at compile time. boot(8) got support via a machine specific command to seal and unseal a secret of your choosing to any drive. Sealing and unsealing means encrypting/decrypting data depending on the state of the Platform Control Registers (PCR). PCRs are in the TPM NVRAM and store the measurements. With the laptop being in a trusted state, you can seal a secret and store it on a usb drive. When you want to verify, that the software components are unchanged, you plug in the usb drive and unseal the secret. If the output shows the correct secret and you were the only person knowing it, than there is a very high chance that the early boot components are unchanged. Some feedback from the OpenBSD community on this would also be appreciated. Are there enought people interessted in a Trusted Boot with OpenBSD? That sounds awesome! Hope you are working on upstreaming your changes. Are there any downsides though? For example, would resume from hibernation still work for such a setup? More so, for the less knowledgeable of us, how does this relate to UEFI's "Secure Boot"? I can only hope OpenBSD will support it some day, at least for amd64. Debian has implemented it for the last major release, Debian 10. Thanks!
