Re: rad(8) question
yes, OK so how to use prefix range then ? What if I want explicitly set some IP as router? Sent with ProtonMail Secure Email. ‐‐‐ Original Message ‐‐‐ On Monday, February 25, 2019 12:33 AM, Delan Azabani wrote: > At 05:25, kolargol kolar...@protonmail.com wrote: > > > How should I fix it ? Or what I am doing wrong ? > > The link-local router address is correct. RFC 4861 § 4.2 says: > > > Source Address > > > MUST be the link-local address assigned to the > > interface from which this message is sent.
Re: Block/allow outgoing traffic by user or application?
On Sun, Feb 24, 2019 at 03:12:31PM +, Stuart Henderson wrote: Basically I'm trying to say, if you wanted to do it the other way round (pass by default, block certain traffic) you wouldn't be able to block everything. If you're trying to stop all possible paths something on the system might use to exfiltrate information then this is important (for example if ping(1) is available and you're not blocking ICMP, this could be used even as non-root with ping -p). I see. "If you're in a situtation that requires blocking everything, then you should block by default" seems logical enough. Not sure if there's any situation where you want to block by default but allow ICMP, that might be a bigger issue. I had no idea there was such a thing as SSH tun forwarding, thanks for telling me about it! :) A useful addition to the toolkit :) Do you know how (or how well!) it handles the performance issues associated with TCP-over-TCP? e.g http://sites.inka.de/bigred/devel/tcp-tcp.html https://unix.stackexchange.com/questions/34499/are-there-disadvantages-in-ssh-tunneling apropos: https://github.com/sshuttle/sshuttle
Re: Update man.openbsd.org with FreeBSD releases?
Hi Anton, li...@wrant.com wrote on Sun, Feb 24, 2019 at 09:00:27AM +0200: > Probably, FreeBSD-12.0 was positioned out of group in the drop down list. > The drop down list is (intentionally) not sorted https://man.openbsd.org/ Actually, i do keep the drop-down-list sorted, as follows: 1. OpenBSD-current 2. supported OpenBSD-stable releases, most recent first 3. POSIX 4. most important historical ancestors, most recent first 5. supported releases of sister *BSD projects 6. Linux man pages project 7. unsupported OpenBSD-stable releases, most recent first 8. older releases of sister *BSD projects 9. oder releases of the Linux man pages project > Thu, 21 Feb 2019 01:16:01 +0100 Ingo Schwarze >> I think i added FreeBSD-12.0 - not that long ago, two weeks maybe... > Could you please point to the cvsweb page for this list or the changelog? Neither exists. The file /var/www/man/manpath.conf is not under version control, and i don't think it needs to be. > There is one port (and package) of the POSIX manual pages, probably this: > https://cvsweb.openbsd.org/ports/books/man-pages-posix/ Yes, that is what the POSIX-2013 dropdown entry serves up. > Maybe there are none ports for the others in the list, Correct, the other dropdown entries are not derived from any ports. > and they are added manually, please kindly share details of the > process used to offer these. The ad-hoc scripts i use to set these up are nothing to be proud of. In a nutshell, the process is: 1. Download the distribution tarballs from an official distribution website of a sister *BSD project. 2. Extract them to a temporary working directory. 3. Reshuffle directories as far as that may be needed in the individual case. 4. Uncompress individual manual pages if they are compressed in the distribution tarballs. 5. Run makewhatis(8). 6. Move the resulting tree below /var/www/man/. 7. Edit /var/www/man/manpath.conf manually. I prefer to not publish the scripts. Whenever the sister projects modify details of the formats of their distribution tarballs, they are prone to needing slight modifications, and i'd hate getting people confused by old or broken versions floating around the web. Putting them under version control would be a waste of my time. There is no need to test and commit them. Basically, they are one-shot scripts. As soon as their job is done once, they are no longer of interest, not even to me. Yours, Ingo
Re: rad(8) question
At 05:25, kolargol wrote: > How should I fix it ? Or what I am doing wrong ? The link-local router address is correct. RFC 4861 § 4.2 says: > Source Address > MUST be the link-local address assigned to the > interface from which this message is sent.
HTTPD Receiving SIGUSR1 from parent
Hoping to clarify the necessity of HTTPD SIGUSR & specifically the following error located in the daemon log. httpd[59510]: parent_sig_handler: reopen requested with SIGUSR1 At this point it appears that SIGUSR1 is a definable signal. However the following command forcibly closes the current login & disconnects the current user. doas kill -SIGUSR1 $PPID The behavior of the above command leads me to suspect that perhaps pledge is interacting with process & signals. Regards Patrick
"bioctl -d" before shutdown
Excuseme that I ask instead of inspecting rc files. :) I do manually bioctl -c C -l /dev/XXX softraid0 and mount the resulting device. Should I manually unmount and do "bioctl -d " before shutdown? Or just shutdown? The umount will sure be done, but also the bioctl -d? Thanks Rodrigo
Re: emmc support on Ubiquiti Networks UniFi Security Gateway PRO-4
thanks everyone for their feedback. I ended up backing up internal emmc drive and disklabel dd if=/dev/rsd1c of=emmc_4G_backup/factory_linux.img bs=8225280 count=481 next step is install on internal drive. New question, is there a way to mount Squashfs filesystem on OpenBSD? file /mnt/squashfs.img /mnt/squashfs.img: Squashfs filesystem, little endian, version 4.0, 18463067392 bytes, 31682 inodes, blocksize: 4 bytes, created: Sat Dec 5 04:28:48 2015
rad(8) question
Hi,
I am playing with rad(8) in my LAN:
cat /etc/rad.conf
interface trunk0 {
prefix fd94:eb64:36ae:44b9::/64
default router yes
dns {
nameserver fd94:eb64:36ae:44b9::1
}
}
and IP addresses are assigned as expected, but problem is that rad(8) send
router address from link-local address-space (like fe80::aa3f:4f6c:ea26:6989 -
trunk0 interface) of the router, whereas correct router IP address should be
from prefix range.
How should I fix it ? Or what I am doing wrong ?
thanks,
kolargol
A (partial) vmmci(4) Linux implementation
I've been experimenting with implementing something like vmmci(4) for Linux guests. It's started to prove useful to myself so maybe others will benefit, even though there are currently some caveats[1]. https://github.com/voutilad/virtio_vmmci My primary use case is keeping some Linux guests constantly running in the background under the vmm(4) hypervisor on my laptop that sees quite a few suspend (zzz)/resume cycles throughout my day. It currently consists of 2 Linux kernel modules, one representing a virtio_pci implementation handling the quirks[2] of how vmd(8) exposes the vmm control device and the other module is the actual virtio driver implementation. I've tested it with a stock Ubuntu 18.0.4 install as well as with a newer v4.20.12 tweaked Linux kernel[3] and so far seems to build and work just fine using an OpenBSD snapshot from Monday 18 Feb as the host. It doesn't yet catch shutdown or restart events, but that's my next goal since I'd like to make sure I get clean shutdowns via `vmctl stop`. -Dave [1]: https://github.com/voutilad/virtio_vmmci#current-state--known-caveats [2]: https://github.com/voutilad/virtio_vmmci#learnings-from-virtio-hacking [3]: https://github.com/voutilad/linux
Re: Block/allow outgoing traffic by user or application?
Yes, right in the default pf.conf they block the pbuild user:
block return out log proto {tcp udp} user _pbuild
On 2/23/19 10:43 PM, Frank Beuth wrote:
Is it possible to restrict network access on a per-user or
per-application (rather than per-port) basis?
pf does not seem to have any capability to do this, maybe I missed
something.
Re: Block/allow outgoing traffic by user or application?
On 2019/02/24 21:44, Frank Beuth wrote: > On Sun, Feb 24, 2019 at 09:56:12AM -, Stuart Henderson wrote: > > PF 'user' should do the trick. Note: it only works for TCP/UDP but for > > this you should be able to do something like > > > > block all > > pass inet proto tcp to 192.0.2.1 port 22 user sshtunnel > > Thanks. You say "only works for TCP/UDP", what other things should I be > aware of? ICMP? Basically I'm trying to say, if you wanted to do it the other way round (pass by default, block certain traffic) you wouldn't be able to block everything. If you're trying to stop all possible paths something on the system might use to exfiltrate information then this is important (for example if ping(1) is available and you're not blocking ICMP, this could be used even as non-root with ping -p). > > However if possible I would suggest either ssh tun forwarding or a VPN. > > ssh socks forwarding is only for TCP which might be a bit restrictive, > > plus you'll need special setup for applications with socks that you won't > > need with tun forwarding or VPN. > > I had no idea there was such a thing as SSH tun forwarding, thanks for > telling me about it! :) A useful addition to the toolkit :)
Re: Block/allow outgoing traffic by user or application?
On Sun, Feb 24, 2019 at 09:56:12AM -, Stuart Henderson wrote: PF 'user' should do the trick. Note: it only works for TCP/UDP but for this you should be able to do something like block all pass inet proto tcp to 192.0.2.1 port 22 user sshtunnel Thanks. You say "only works for TCP/UDP", what other things should I be aware of? ICMP? However if possible I would suggest either ssh tun forwarding or a VPN. ssh socks forwarding is only for TCP which might be a bit restrictive, plus you'll need special setup for applications with socks that you won't need with tun forwarding or VPN. I had no idea there was such a thing as SSH tun forwarding, thanks for telling me about it! :)
Re: Block/allow outgoing traffic by user or application?
On 2019-02-24, Frank Beuth wrote: > On Sun, Feb 24, 2019 at 09:09:06AM +0100, Denis Fondras wrote: >>On Sun, Feb 24, 2019 at 01:43:08PM +0700, Frank Beuth wrote: >>> Is it possible to restrict network access on a per-user or per-application >>> (rather than per-port) basis? >>> >>> pf does not seem to have any capability to do this, maybe I missed >>> something. >>> >> >>Don't know what you are aiming to do but pf rules have a "user" keyword. >> > > Example: start an SSH tunnel with a SOCKS listener on localhost:8080, then > ensure all outgoing application traffic uses the SSH tunnel instead of the > shady public WiFi network I am connected to. > > In this case, it looks like that can be done by creating a user `sshtunnel`, > starting the SSH tunnel as that user, and then using the pf rule to block all > egress traffic which is not either to localhost or from user `sshtunnel`. > > Does that make sense? > > PF 'user' should do the trick. Note: it only works for TCP/UDP but for this you should be able to do something like block all pass inet proto tcp to 192.0.2.1 port 22 user sshtunnel However if possible I would suggest either ssh tun forwarding or a VPN. ssh socks forwarding is only for TCP which might be a bit restrictive, plus you'll need special setup for applications with socks that you won't need with tun forwarding or VPN.
Re: Block/allow outgoing traffic by user or application?
On Sun, Feb 24, 2019 at 09:09:06AM +0100, Denis Fondras wrote: On Sun, Feb 24, 2019 at 01:43:08PM +0700, Frank Beuth wrote: Is it possible to restrict network access on a per-user or per-application (rather than per-port) basis? pf does not seem to have any capability to do this, maybe I missed something. Don't know what you are aiming to do but pf rules have a "user" keyword. Example: start an SSH tunnel with a SOCKS listener on localhost:8080, then ensure all outgoing application traffic uses the SSH tunnel instead of the shady public WiFi network I am connected to. In this case, it looks like that can be done by creating a user `sshtunnel`, starting the SSH tunnel as that user, and then using the pf rule to block all egress traffic which is not either to localhost or from user `sshtunnel`. Does that make sense?
Re: Block/allow outgoing traffic by user or application?
On Sun, Feb 24, 2019 at 01:43:08PM +0700, Frank Beuth wrote: > Is it possible to restrict network access on a per-user or per-application > (rather than per-port) basis? > > pf does not seem to have any capability to do this, maybe I missed something. > Don't know what you are aiming to do but pf rules have a "user" keyword.
