home bbs files messages ]

Just a sample of the Echomail archive

<< oldest | < older | list | newer > | newest >> ]

 Message 21768 
 Richard Kettlewell to All 
 Re: RPi associating two IPs with its one 
 01 Jan 26 12:26:53 
 
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


<< oldest | < older | list | newer > | newest >> ]

(c) 1994,  bbs@darkrealms.ca