MSGID: 61f54d99   
   REPLY: <10j5o6e$3etcd$2@dont-email.me> 24f5d47f   
   PID: PyGate 1.5.2   
   TID: PyGate/Linux 1.5.2   
   CHRS: CP1252 2   
   TZUTC: 0000   
   REPLYADDR invalid@invalid.invalid   
   REPLYTO 3:633/10 UUCP   
   The Natural Philosopher writes:   
   > On 01/01/2026 11:34, Richard Kettlewell wrote:   
   >> The Natural Philosopher writes:   
   >>> On 31/12/2025 20:18, Richard Kettlewell wrote:   
   >>>> NAT does not offer any protection. The reason that a typical domestic   
   >>>> NAT-equipped router protects you from inbound connections is that it   
   >>>> has a firewall as well. (Getting a packet addressed to your internal   
   >>>> addresses to your external interface is inconvenient for many   
   >>>> attackers, for sure, but straightforward for your ISP or anyone who   
   >>>> can hack or coerce them.)   
   >>>   
   >>> How?   
   >>> Genuine question.   
   >> Same as routing any other packet. Make sure there?s an appropriate   
   >> routing table entry for the customer addresses on the ISP?s   
   >> customer-facing router (and whatever intermediate routers there are   
   >> between that and the attack source), then call socket/connect/write.   
   >> The question is then what the customer router does with it.   
   >> * If it follows the strong end system then the packet is discarded   
   >> before NAT even comes into the question.   
   >> Linux follows the weak end system model by default, so this   
   >> possibility doesn?t apply to Linux-based router unless someone has   
   >> taken the trouble to change its behavior somehow.   
   >> * If there?s a basically competent firewall on the customer router   
   >> then   
   >> the packet is discard by that.   
   >> * If there?s a NAT then it gets to look at the packet, but it won?t   
   >> match any of the rules that enable translation, so it will not be   
   >> modified at this stage.   
   >    
   > Ah. I misunderstood your original post. Sure the ISP can send an   
   > internally addressed packet to your router. If it wants to lose its   
   > customer base.   
      
   * The police turn up with a warrant and inform you that if you don?t   
    help them break into a certain customer?s network, you will go to   
    prison.   
      
   * The mafia turn up with a gun, and inform you that if you don?t help   
    them break into a certain customer?s network, you will be shot.   
      
   * A teenager who follows full-disclosure exploits the latest zero day to   
    break into the ISP?s network, and from there to as many customers as   
    they can reach.   
      
   * An ISP staff member suspects that a friend who happens to be a   
    customer is having an affair with their wife. Overwhelmed by jealousy   
    they decide to attempt to hack the customer?s computers.   
      
   You can probably imagine more scenarios.   
      
   > But will that get forwarded along?   
   >   
   >> * All that?s now left is normal routing, so the packet passes on to its   
   >> destination on the customer network.   
   >> https://www.greenend.org.uk/rjk/tech/nat.html has a worked example.   
   >>   
   > I can't believe that my router would accept arbitrary packets with   
   > an internal destination address on its external facing port...   
      
   It probbaly doesn?t: it might use the strong end system model, and if   
   not it might have a firewall preventing it. But whatever its   
   configuration, it?s not NAT that stops it.   
      
   > if the destination is not in its tables, it will be automatically   
   > discarded...   
      
   The internal network destination address _is_ in its routing table.   
   That?s how it sends legitimate packets back to the internal network   
   (e.g. when an internal host pings the router).   
      
   On my router:   
      
    $ ip route show|grep 172.17.207.0   
    172.17.207.0/24 dev br0 proto kernel scope link src 172.17.207.1   
      
   (172.17.207.0 is my internal network.)   
      
   --    
   https://www.greenend.org.uk/rjk/   
      
   --- PyGate Linux v1.5.2   
    * Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)   
   SEEN-BY: 105/81 106/201 128/187 129/14 305 153/7715 154/110 218/700   
   SEEN-BY: 226/30 227/114 229/110 112 134 200 206 275 300 317 400 426   
   SEEN-BY: 229/428 470 616 664 700 705 266/512 291/111 292/854 320/219   
   SEEN-BY: 322/757 342/200 396/45 460/58 633/10 280 414 418 420 422   
   SEEN-BY: 633/509 2744 712/848 770/1 902/26 2320/105 5020/400 5075/35   
   PATH: 633/10 280 229/426   
      
|