Active mode IP address verification

cologic · Post by **cologic** » 2003-01-28 18:18

I've been sitting on the DCH++ hub for a while, and every few hours I receive this message:

<DCH++> Your client's IP is incorrectly configured, and you will therefore be disconnected. Either you have to enter the correct one in the IP field in your client settings or try passive mode. Your current ip is: <the IP from which the hub sees me logging in>

And it kicks me off the hub.

I am, in fact, correctly configured in active mode and can search, upload to, and download from passive users. At minimum, the hub should actually attempt to connect to the IP provided by the client before kicking it; ideally, it would simply provide an informational message.

Post by **arnetheduck** » 2003-01-30 06:43

Hm. Interesting. What it does is a nice little compare between the ip you're connected with and the ip seen in $search or $connect...unless you have two ip's assigned to the same machine, this should work pretty well, or have I missed something crucial? (or your client is sending strange ip:s...or your isp is changing your ip's if they're dynamic...)

ender · Post by **ender** » 2003-01-30 09:31

Arne, a suggestion: my hub similarly checks the IP, and informs the user (but doesn't disconnect him - just drops the search/connecttome request) - maybe the hub could automatically send $UserIP back, so that the client could automatically configure itself?

cologic · Post by **cologic** » 2003-01-30 09:56

I am logged in through an SSH tunnel. However, I don't want file transfers and search results going through that tunnel.

Thus, the hub sees me connect from the IP address of the computer running the SSH daemon, while my searches and $ConnectToMe's will come from a wholly separate computer, the one running the SSH client.

Sedulus · Post by **Sedulus** » 2003-01-31 10:23

some people have a fixed hostname, while having a dynamic IP.
DCH kicks ppl who send correct hostnames as well.
the $UserIP function would fix it for the users with a dynamic IP, but not for cologic (and the UserIP would have to be implemented first)

now a ConnectToMe is not that dangerous... but a Search could potentially ddos someone (a name server for instance). nmdch discards Search with a different IP, but allows the ConnectToMe. this means you can have semi-passive ppl.

so in order for the Search (with different IP) to be allowed, you'd have to check the user by connecting to it. (at login you'd have something like: $ConnectToMe <hostname/IP>:<port> Hub| )
would this be possible for the hub? i.e. handshaking / fetching username, and then store the IP/hostname and allow Searches and ConnectToMe's if the same (stored) address is used.

or would this kill the hubs bandwidth and/or cpu?

ivulfusbar · Post by **ivulfusbar** » 2003-01-31 12:45

On most hubs it possible to send fake IP in ConnectToMe, this can effectivly be used to get around ip-checks in hubs (hubs-scripts), i think that most hub if they want to support different ip in a ConnectToMe than the one the user actually uses must check this ip against allowed ip-to-enter ip-series.

cologic · Post by **cologic** » 2003-01-31 16:59

On most hubs it possible to send fake IP in ConnectToMe, this can effectivly be used to get around ip-checks in hubs (hubs-scripts), i think that most hub if they want to support different ip in a ConnectToMe than the one the user actually uses must check this ip against allowed ip-to-enter ip-series.

Any hub which doesn't provide its scripts a way to access the IP of a user as the hub sees it, and that forces them to trigger a $ConnectToMe or wait for a search I regard as broken in that respect. This isn't a good argument for an otherwise unnecessary restriction on how one may connect to a hub.

ivulfusbar · Post by **ivulfusbar** » 2003-01-31 19:09

[quote="cologic"][quote]On most hubs it possible to send fake IP in ConnectToMe, this can effectivly be used to get around ip-checks in hubs (hubs-scripts), i think that most hub if they want to support different ip in a ConnectToMe than the one the user actually uses must check this ip against allowed ip-to-enter ip-series.[/quote]
Any hub which doesn't provide its scripts a way to access the IP of a user as the hub sees it, and that forces them to trigger a $ConnectToMe or wait for a search I regard as broken in that respect. This isn't a good argument for an otherwise unnecessary restriction on how one may connect to a hub.[/quote]

I don't understand why you quote me, and what you are saying.. so i can't comment on it further, but anyway.. there are some flaws in the protocol that you can't do anything about...

Post by **arnetheduck** » 2003-02-01 08:53

Sedulus wrote:some people have a fixed hostname, while having a dynamic IP.
DCH kicks ppl who send correct hostnames as well.
the $UserIP function would fix it for the users with a dynamic IP, but not for cologic (and the UserIP would have to be implemented first)

Uhm, you're not allowed to send the host name in the ctm and search messages, it has to be a pure ip (parts of nmdc don't work if they get a name...)....

Anyway, this check is done to prevent people from sending searches and ctm:s on other people, and thus effectively dos'ing them...it's a little bit of the fxp protection some ftp servers have, that you're not allowed to fxp in/out of them...

Anyway, disconnect or no is easy to make into a hub setting...
(and I'm not a big fan of the userip thing...it leads to ugly bug reports such as "it works here but not there" and so on...)