5 ms·

Proper opsec is you blackhole all traffic when the vpn isn’t active.

duxup 5y ago
Personally I’d feel most comfortable with a separate hardware VPV solution that won’t let anything through leaving the local software to do its thing.
ziml77 5y ago
Is there a good reason for that to not be the default when using a VPN? At the very least it should be easy to configure. I remember when I tried using a VPN on Ubuntu a bunch of years ago, I had to set up iptables rules even though the VPN connection could be configured through the network manager GUI.
- therein 5y ago
  With wireguard since there is no "connection" to be maintained, you could argue this is a non-issue.
  - mynameisvlad 5y ago
    But Wireguard itself relies on an active internet connection, which needs to still be set up to not fall back on in case the wg connection deactivates.
    - midasuni 5y ago
      > With wireguard since there is no "connection" to be maintained
      - mynameisvlad 5y ago
        What does that even mean? Let's say you have a Wireguard configuration, wg0 which runs off ens0. If your wg0 connection dies, for whatever reason (let's say the remote server goes down), your computer falls back to ens0. What does "not having a connection to be maintained" change about this?
        OJFord 5y ago
        GP's just taking issue with the word 'connection', it's fine, I think it's clear.
        midasuni 5y ago
        It’s really not. If you have a route down your WireGuard interface, it’s not going to stop should the end point of that interface no longer be routable.
        megous 5y ago
        Wireguard will keep contacting the remote server. You'd have to delete the wg0 interface or delete the default route for packets to go out via ens0. Wireguard only has "connection" in a sense that it caches some runtime information about the peer's endpoint, but endpoint configuration is static. I guess, too much magic automation on top of this is not the best thing for opsec, including having some daemon that can disable your wireguard interface or reconfigure the network if it doesn't like something. You want your network configuration to be static and predictable, regardless of some temporary failures. Basic wireguard kernel primitives will give you that.
        mynameisvlad 5y ago
        > You'd have to delete the wg0 interface or delete the default route for packets to go out via ens0 So... You'd have to do work to properly blackhole traffic when wg0 goes down. However long it takes to reconnect, you still will automatically fall back down to ens0 while it's down unless you do something to stop that.
        midasuni 5y ago
        How does wg0 go down?
        megous 5y ago
        wg0 doesn't go down by itself. Packets are always delivered to wg interface as long as it is marked as 'UP' (or 'enabled', if 'UP' sounds to you like having anything to do with some kind of "connection") when your routing table directs them there. When they hit the wg interface when the other endpoint is unreachable for whatever reason, they are either dropped, or queued, or get ICMP unreachable response generated for them, depending on situation. This is done internally by wireguard.
    - OJFord 5y ago
      A good (the best?) way to solve that is 'the new namespace solution' described at the bottom of the page here: https://www.wireguard.com/netns/ https://www.wireguard.com/netns/ In brief, you move your physical eth/wlan device to a new namespace, and create the wg device in that namespace but then move it to the init ns. By default (and without root) everything will use the init ns and only be able to reach the physical device via wg. If it's not active, nothing will even reach your NIC, nevermind the internet.
      - kortilla 5y ago
        +1 to this being the safest way. No physical nic for your traffic to fallback to. The downside is this isn’t supported by any GUIs that I know of so it’s a pretty miserable workflow for WiFi.
fomine3 5y ago
I prefer to have separate VPN'd network that never routed to other connection.
rmbyrro 5y ago
We have to admit the guy is consistent, at the least. He drove employer's security to ruins on purpose, and did the same to himself. I can't believe someone can literally destroy its life for BTC. Imagine his family and close friends. His parents probably thought he was a tech wizard genius. And now he destroyed his reputation, his employer's, and he'll be behind bars for quite a few years. I hope he doesn't have kids. And picture: he could have been the guy who did a great job "fixing" employer's lack of security. Have that on his resume, tell lessons learned on real world practice. Why the hell would he even think about the FBI route in the first place?
- vasco 5y ago
  > And picture: he could have been the guy who did a great job "fixing" employer's lack of security This is not really a thing. It's very hard to get recognition or even a shared understanding of the risk mitigation. As everything else in the world, it's way easier to reward someone for things that happen (new functionality) than rewarding someone for preventing things happening (hack).
  - aksss 5y ago
    I completely disagree. You may not get recognition with the people at the front desk, but you absolutely can get recognition from your peers inside a company and (as valuable?) people outside the company. Some of this has to be the result of your own work and marketing - conferences, getting clearance to talk about the work you've done (which is good marketing for the company if sold correctly), speaking engagements, etc. If you think the recognition just comes as automatic as wages, then you're doing it wrong, but are correct in that no much will be forthcoming.
    - pbronez 5y ago
      Classic example of the Do Stuff / Tell People You Did Stuff balance. This stuff is arcane and invisible by default. The coordination and communication tasks that surround the direct work are important. One was to strike a good balance here is a security roadmap. Write down the adverse outcomes that would be a problem for your business. Write down the possible mitigations, how much they cost to implement and how strong they are. Propose a plan that continuously improves security in a cost effective way. Highlight significant things you can’t defend against yet, and explain how you could address them sooner with more funding. Show the plan to leadership, get it approved, and get to work. Every month / quarter / sprint, write down what you did, show where you are the roadmap, and adjust the roadmap to reflect any changes in business priorities.

Personally I’d feel most comfortable with a separate hardware VPV solution that won’t let anything through leaving the local software to do its thing.

ziml77 5y ago

Is there a good reason for that to not be the default when using a VPN? At the very least it should be easy to configure. I remember when I tried using a VPN on Ubuntu a bunch of years ago, I had to set up iptables rules even though the VPN connection could be configured through the network manager GUI.

therein 5y ago
With wireguard since there is no "connection" to be maintained, you could argue this is a non-issue.
- mynameisvlad 5y ago
  But Wireguard itself relies on an active internet connection, which needs to still be set up to not fall back on in case the wg connection deactivates.
  - midasuni 5y ago
    > With wireguard since there is no "connection" to be maintained
    - mynameisvlad 5y ago
      What does that even mean? Let's say you have a Wireguard configuration, wg0 which runs off ens0. If your wg0 connection dies, for whatever reason (let's say the remote server goes down), your computer falls back to ens0. What does "not having a connection to be maintained" change about this?
      - OJFord 5y ago
        GP's just taking issue with the word 'connection', it's fine, I think it's clear.
        midasuni 5y ago
        It’s really not. If you have a route down your WireGuard interface, it’s not going to stop should the end point of that interface no longer be routable.
      - megous 5y ago
        Wireguard will keep contacting the remote server. You'd have to delete the wg0 interface or delete the default route for packets to go out via ens0. Wireguard only has "connection" in a sense that it caches some runtime information about the peer's endpoint, but endpoint configuration is static. I guess, too much magic automation on top of this is not the best thing for opsec, including having some daemon that can disable your wireguard interface or reconfigure the network if it doesn't like something. You want your network configuration to be static and predictable, regardless of some temporary failures. Basic wireguard kernel primitives will give you that.
        mynameisvlad 5y ago
        > You'd have to delete the wg0 interface or delete the default route for packets to go out via ens0 So... You'd have to do work to properly blackhole traffic when wg0 goes down. However long it takes to reconnect, you still will automatically fall back down to ens0 while it's down unless you do something to stop that.
        midasuni 5y ago
        How does wg0 go down?
        megous 5y ago
        wg0 doesn't go down by itself. Packets are always delivered to wg interface as long as it is marked as 'UP' (or 'enabled', if 'UP' sounds to you like having anything to do with some kind of "connection") when your routing table directs them there. When they hit the wg interface when the other endpoint is unreachable for whatever reason, they are either dropped, or queued, or get ICMP unreachable response generated for them, depending on situation. This is done internally by wireguard.
  - OJFord 5y ago
    A good (the best?) way to solve that is 'the new namespace solution' described at the bottom of the page here: https://www.wireguard.com/netns/ https://www.wireguard.com/netns/ In brief, you move your physical eth/wlan device to a new namespace, and create the wg device in that namespace but then move it to the init ns. By default (and without root) everything will use the init ns and only be able to reach the physical device via wg. If it's not active, nothing will even reach your NIC, nevermind the internet.
    - kortilla 5y ago
      +1 to this being the safest way. No physical nic for your traffic to fallback to. The downside is this isn’t supported by any GUIs that I know of so it’s a pretty miserable workflow for WiFi.

fomine3 5y ago

I prefer to have separate VPN'd network that never routed to other connection.

rmbyrro 5y ago

We have to admit the guy is consistent, at the least. He drove employer's security to ruins on purpose, and did the same to himself. I can't believe someone can literally destroy its life for BTC. Imagine his family and close friends. His parents probably thought he was a tech wizard genius. And now he destroyed his reputation, his employer's, and he'll be behind bars for quite a few years. I hope he doesn't have kids. And picture: he could have been the guy who did a great job "fixing" employer's lack of security. Have that on his resume, tell lessons learned on real world practice. Why the hell would he even think about the FBI route in the first place?

vasco 5y ago
> And picture: he could have been the guy who did a great job "fixing" employer's lack of security This is not really a thing. It's very hard to get recognition or even a shared understanding of the risk mitigation. As everything else in the world, it's way easier to reward someone for things that happen (new functionality) than rewarding someone for preventing things happening (hack).
- aksss 5y ago
  I completely disagree. You may not get recognition with the people at the front desk, but you absolutely can get recognition from your peers inside a company and (as valuable?) people outside the company. Some of this has to be the result of your own work and marketing - conferences, getting clearance to talk about the work you've done (which is good marketing for the company if sold correctly), speaking engagements, etc. If you think the recognition just comes as automatic as wages, then you're doing it wrong, but are correct in that no much will be forthcoming.
  - pbronez 5y ago
    Classic example of the Do Stuff / Tell People You Did Stuff balance. This stuff is arcane and invisible by default. The coordination and communication tasks that surround the direct work are important. One was to strike a good balance here is a security roadmap. Write down the adverse outcomes that would be a problem for your business. Write down the possible mitigations, how much they cost to implement and how strong they are. Propose a plan that continuously improves security in a cost effective way. Highlight significant things you can’t defend against yet, and explain how you could address them sooner with more funding. Show the plan to leadership, get it approved, and get to work. Every month / quarter / sprint, write down what you did, show where you are the roadmap, and adjust the roadmap to reflect any changes in business priorities.