[HN Gopher] Asymmetric Routing Around the Firewall
       ___________________________________________________________________
        
       Asymmetric Routing Around the Firewall
        
       Author : sprawl_
       Score  : 57 points
       Date   : 2024-04-11 21:42 UTC (4 days ago)
        
 (HTM) web link (devnonsense.com)
 (TXT) w3m dump (devnonsense.com)
        
       | unethical_ban wrote:
       | >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.
        
         | ikiris wrote:
         | > 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 wrote:
           | True. I was thinking exfil and communication. Of course
           | fuzzing/DoS is doable.
        
             | ikiris wrote:
             | i mean, you can have a full session via dns chat this way
             | pretty easily
        
         | jiehong wrote:
         | Except maybe for UDP traffic a la Tailscale
        
       | chaz6 wrote:
       | 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).
        
       | tranxen wrote:
       | 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 wrote:
         | All I've worked with do by default, but you can turn it off.
        
       | floating-io wrote:
       | 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.
        
         | ikiris wrote:
         | physical is bad enough. Logical is the horror part
        
         | chatmasta wrote:
         | 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 wrote:
         | 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 wrote:
           | 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.
        
       ___________________________________________________________________
       (page generated 2024-04-15 23:01 UTC)