4 ms·

> Instead of using UDP he reads the firewall log. Hah! I'd never seen this before, but in a fit of pique driven by ssh scanning one day I did a similar patter

by thrwaway1985882 2y ago

> Instead of using UDP he reads the firewall log. Hah! I'd never seen this before, but in a fit of pique driven by ssh scanning one day I did a similar pattern on my OpenBSD router: I added a block in log to a high port in pf.conf, wired up a little shell script that did tcpdump on pflog0 and watched for a packet to come in, then added the IP to the allow port 22 table. I knocked on the door three times, two of which were testing, and ended up throwing it all out in favor of wireguard & making SSH no longer listen on em0, which seems infinitely less silly.

bongobingo1 2y ago
I know its very minor, but are there ergonomic improvements possible to this setup besides shell aliases/functions around pairing `wg-up host && ssh host && wg-down host`? I agree that ultimately, with wg in the kernel, this is a much simpler setup.
- thrwaway1985882 2y ago
  From the OpenBSD perspective, I just populate /etc/hostname.wg0 on my laptop with my wg configuration ... and I can immediately `ssh router` at home or on the road :-) IOW, why ever down the connection? Why not start your tunnel immediately when the network comes up and leave it running until the network goes down?
  - bongobingo1 2y ago
    I was thinking about doing this to multiple different servers and thought they could all share the same vpn network address for simpler configuration but now that I think about it doing that might run into constant server-key-changed warnings from SSH.
    - thrwaway1985882 2y ago
      If you need a management vlan, make one. Wireguard interfaces are _cheap and easy_ - there's no reason not to set up an interface for normal client traffic that sshd doesn't listen on, and an interface for just sshd with different ACLs and routing logic if you want.
- Jnr 2y ago
  You don't really have to do that. Wireguard is very silent protocol. Even when you bring up the interface, unless you are sending anything to that interface, it will not redo the handshake. So you can keep it up all the time. This is why you sometimes have to enable PersistentKeepalive on peers that are behind NAT and are calling in to the server. Without them keeping up the connection NAT would simply close it down and you wouldn't be able to connect.
mr_mitm 2y ago
Well, tcpdump is explicitely not what you want to do in this case as Moxie points out, but other than that i guess, yes, it's similar.
- thrwaway1985882 2y ago
  > Well, tcpdump is explicitely not what you want to do in this case as Moxie points out Why's that? E: oh, if you aren't familiar with OpenBSD I might get the confusion – pflogd/the kernel (not me!) watches the actual network device and dumps to a file. So the actual "knocking" daemon I bodged together is one part running as a privsep user watching a log file and giving IPs to the other part which just adds to the pf table allowing access. My threat model didn't include people who can fuck with pflog(4) to attack tcpdump(8) - I'm sure they're out there, and if they wanted to be they'd already be in my network (or already are).
  - mr_mitm 2y ago
    Ah, that makes sense. I actually didn't know that about openbsd.

bongobingo1 2y ago

I know its very minor, but are there ergonomic improvements possible to this setup besides shell aliases/functions around pairing `wg-up host && ssh host && wg-down host`? I agree that ultimately, with wg in the kernel, this is a much simpler setup.

thrwaway1985882 2y ago
From the OpenBSD perspective, I just populate /etc/hostname.wg0 on my laptop with my wg configuration ... and I can immediately `ssh router` at home or on the road :-) IOW, why ever down the connection? Why not start your tunnel immediately when the network comes up and leave it running until the network goes down?
- bongobingo1 2y ago
  I was thinking about doing this to multiple different servers and thought they could all share the same vpn network address for simpler configuration but now that I think about it doing that might run into constant server-key-changed warnings from SSH.
  - thrwaway1985882 2y ago
    If you need a management vlan, make one. Wireguard interfaces are _cheap and easy_ - there's no reason not to set up an interface for normal client traffic that sshd doesn't listen on, and an interface for just sshd with different ACLs and routing logic if you want.
Jnr 2y ago
You don't really have to do that. Wireguard is very silent protocol. Even when you bring up the interface, unless you are sending anything to that interface, it will not redo the handshake. So you can keep it up all the time. This is why you sometimes have to enable PersistentKeepalive on peers that are behind NAT and are calling in to the server. Without them keeping up the connection NAT would simply close it down and you wouldn't be able to connect.

mr_mitm 2y ago

Well, tcpdump is explicitely not what you want to do in this case as Moxie points out, but other than that i guess, yes, it's similar.

thrwaway1985882 2y ago
> Well, tcpdump is explicitely not what you want to do in this case as Moxie points out Why's that? E: oh, if you aren't familiar with OpenBSD I might get the confusion – pflogd/the kernel (not me!) watches the actual network device and dumps to a file. So the actual "knocking" daemon I bodged together is one part running as a privsep user watching a log file and giving IPs to the other part which just adds to the pf table allowing access. My threat model didn't include people who can fuck with pflog(4) to attack tcpdump(8) - I'm sure they're out there, and if they wanted to be they'd already be in my network (or already are).
- mr_mitm 2y ago
  Ah, that makes sense. I actually didn't know that about openbsd.