5 ms·

Asymmetric Routing Around the Firewall

58 points by sprawl_ 2y ago

unethical_ban 2y ago
>Later, when I realized that inbound traffic was bypassing the firewall, I notified UC Berkeley’s Information Security Office of the potential security vulnerability, but their response was somewhat lacking in urgency. So we’ll see. If I were on their infosec team I wouldn't ignore it, but also, infosec and network often different silos. If network was already notified, infosec can't do much but complain. And, it seems the network was somewhat secure anyway. Any inbound scan or malicious traffic would get dropped going outbound, since there was no session on the outbound firewall.
- jiehong 2y ago
  Except maybe for UDP traffic a la Tailscale
- ikiris 2y ago
  > Any inbound scan or malicious traffic would get dropped going outbound There are lots of types of maliciousness that would not be affected by this.
  - unethical_ban 2y ago
    True. I was thinking exfil and communication. Of course fuzzing/DoS is doable.
    - ikiris 2y ago
      i mean, you can have a full session via dns chat this way pretty easily
chaz6 2y ago
I have run into this, and I got tipped off by the very specific session timeout that was set on the firewall. The session would come up and work for around 30 seconds, then stop. The outbound packets were going to the firewall but being returned from a different address on the same subnet. The firewall would stop forwarding the outbound packets after the session expired since it did not observe the session being established (as the reply packets did not traverse the firewall).
deleted 2y ago
[deleted]
tranxen 2y ago
Glad you found out. Good job ! Also usually firewalls are not decreasing packets IP TTL which make them invisble to traceroute. You are lucky this one does not.
- Hikikomori 2y ago
  All I've worked with do by default, but you can turn it off.
brevitea 2y ago
[dead]
floating-io 2y ago
I would think that a network that even has a physical path capable of bypassing a firewall would be considered broken by design... Or at least insecure.
- chatmasta 2y ago
  As long as you want to hear back from the server you send a packet to, you’ll always be able to “reverse tunnel” into a firewall. This is because source ports are ephemerally allocated, which is a necessity unless you want to have a maximum of one HTTP connection at a time. That said, a proper firewall implementation would only allow traffic back to a source port that is in the routing table as having an established connection. But that’s a stateful firewall (vs. stateless) and comes with its own set of complexities.
- whatupmiked 2y ago
  Networks change all the time. You don’t want to rerun cable everyday. You can configure a router to not use a path, even though that path physically exists.
  - Hikikomori 2y ago
    Not like this though. Someone connected two different routing domains and set up routing, or they use the same config for ospf for different routing domains which you shouldn't do.
- ikiris 2y ago
  physical is bad enough. Logical is the horror part

58 points by sprawl_ 2y ago

>Later, when I realized that inbound traffic was bypassing the firewall, I notified UC Berkeley’s Information Security Office of the potential security vulnerability, but their response was somewhat lacking in urgency. So we’ll see. If I were on their infosec team I wouldn't ignore it, but also, infosec and network often different silos. If network was already notified, infosec can't do much but complain. And, it seems the network was somewhat secure anyway. Any inbound scan or malicious traffic would get dropped going outbound, since there was no session on the outbound firewall.

jiehong 2y ago
Except maybe for UDP traffic a la Tailscale
ikiris 2y ago
> Any inbound scan or malicious traffic would get dropped going outbound There are lots of types of maliciousness that would not be affected by this.
- unethical_ban 2y ago
  True. I was thinking exfil and communication. Of course fuzzing/DoS is doable.
  - ikiris 2y ago
    i mean, you can have a full session via dns chat this way pretty easily

chaz6 2y ago

I have run into this, and I got tipped off by the very specific session timeout that was set on the firewall. The session would come up and work for around 30 seconds, then stop. The outbound packets were going to the firewall but being returned from a different address on the same subnet. The firewall would stop forwarding the outbound packets after the session expired since it did not observe the session being established (as the reply packets did not traverse the firewall).

deleted 2y ago

[deleted]

tranxen 2y ago

Glad you found out. Good job ! Also usually firewalls are not decreasing packets IP TTL which make them invisble to traceroute. You are lucky this one does not.

Hikikomori 2y ago
All I've worked with do by default, but you can turn it off.

brevitea 2y ago

[dead]

floating-io 2y ago

I would think that a network that even has a physical path capable of bypassing a firewall would be considered broken by design... Or at least insecure.

chatmasta 2y ago
As long as you want to hear back from the server you send a packet to, you’ll always be able to “reverse tunnel” into a firewall. This is because source ports are ephemerally allocated, which is a necessity unless you want to have a maximum of one HTTP connection at a time. That said, a proper firewall implementation would only allow traffic back to a source port that is in the routing table as having an established connection. But that’s a stateful firewall (vs. stateless) and comes with its own set of complexities.
whatupmiked 2y ago
Networks change all the time. You don’t want to rerun cable everyday. You can configure a router to not use a path, even though that path physically exists.
- Hikikomori 2y ago
  Not like this though. Someone connected two different routing domains and set up routing, or they use the same config for ospf for different routing domains which you shouldn't do.
ikiris 2y ago
physical is bad enough. Logical is the horror part