Opened 7 years ago

Closed 6 years ago

#727 closed enhancement (not a bug)

Prevent i2p router from getting configured with a private IP address

Reported by: guest Owned by: zzz
Priority: minor Milestone: 0.9.3
Component: router/transport Version: 0.9.2
Keywords: Cc: zab@…
Parent Tickets:

Description

Hi,
I'm seeing so many packets getting rejected by my firewall that I think this common misconfiguration could be prevented by a little tweak.
Bad I2P packet example: source: some 192.168.0.0/16 address (on my WAN link!), destination : my I2P router, on I2P port.
I know the 3 classic private subnets are "banned" in I2P, but I think preventing I2P router from getting such an adress would benefit the whole network.

elgo

Subtickets

Change History (19)

comment:1 Changed 7 years ago by zzz

  • Component changed from unspecified to router/transport
  • Owner set to zzz

I added some checks on /confignet in the console a couple weeks ago (~0.9.2-3), to catch IP and port problems sooner. But non-public IPs were already caught later, in the transports.

In any case, we don't set the source IP on either TCP or UDP packets, and it's not possible to do so unless running as root.

So this isn't an I2P bug. Either you are misreading your firwall logs or this is some sort of attempted attack by somebody spoofing source IPs. If the latter, more info on the packets would be interesting (TCP or UDP? size?)

comment:2 Changed 7 years ago by zab

  • Cc zab@… added

Spoofed UDP packets? I would think there would at least basic checks for private addresses. More details pls.

comment:3 Changed 7 years ago by zzz

Found one place where we weren't validating incoming IP/port, in SSU PeerTestManager?, fixed in 0.9.2-9

comment:4 Changed 7 years ago by zzz

-9 was insufficient. Much better validation in 0.9.2-10. Also includes some minor improvements for relay messages.

comment:5 Changed 7 years ago by zzz

Due to a SSU doc error, and other mistakes, -10 broke both peer test reply handling and relay request handling. Fixed in -12. Testing continues.

comment:6 Changed 7 years ago by guest

Hi again,

I noticed these "private subnet" sourced packets in my firewall logs (pfsense), but I confirmed this by capturing some on my WAN interface with tcpdump (mainly to verify they weren't forwarded to my I2P box).
Not related to current issue: Do you think it's worth creating another trac "issue" for all the TCP segments pfsense rejects (like 50/min, and 95% with TCP:FPA flags and 5% with TCP:RA flags). Everything else is fine. I don't know if he conciders these segments as not "correct"/RFC compliant/unrelated to some already terminated TCP connection.

Elgo

comment:7 Changed 7 years ago by zzz

More validation in 0.9.2-13.

We still have the original question - tell us more about the private subnet packets - size, protocol, source address, etc.

Re: pfense, no idea what all that means. If you can translate it into something that we can understand and actually do something about, sure.

comment:8 Changed 7 years ago by zab

Do you think it's worth creating another trac "issue" for all the TCP segments pfsense rejects

I2P runs on a JVM which uses the standard underlying OS TCP sockets. There are no special tweaks of any kind; in fact the java API does not allow any modifications below a BSD socket layer. So, if you are seeing some TCP oddities this could be very bad.

So yes, open a separate trac ticket for this so we don't confuse the issues. If it's not a problem we'll just close it.

comment:9 Changed 7 years ago by zab

Just to make sure we're parsing the following statement correctly:

I confirmed this by capturing some on my WAN interface with tcpdump

Did you receive incoming UDP packets whose source address in the datagram was a private address

OR

Did you receive incoming TCP traffic that contained a private address somewhere in the payload?

OR

Something entirely different?

comment:10 Changed 7 years ago by guest

Right, my bad, here is some data (I could prepare a .pcap file, but I guess it's useless since, well ciphered I2P protocol :)). I replace my actual public IP but left other data untouched. 8889 is my TCP&UDP I2P port. Be assured that I don't have any 192.168.1.0/24 in my local network, and pppoe1 is my WAN interface.

tcpdump -vv -i pppoe1 net 192.168.0.0/16
tcpdump: listening on pppoe1, link-type NULL (BSD loopback), capture size 96 bytes
20:01:06.372013 IP (tos 0x0, ttl 57, id 38664, offset 0, flags [DF], proto TCP (6), length 340)
    192.168.1.47.49378 > MYPUBLICIP.8889: Flags [FP.], seq 1892381159:1892381447, ack 3876734302, win 33120, options [nop,nop,TS val 508510049 ecr 51855053], length 288
20:01:15.975950 IP (tos 0x0, ttl 113, id 43597, offset 0, flags [DF], proto TCP (6), length 328)
    192.168.1.35.2194 > MYPUBLICIP.8889: Flags [FP.], seq 2414623035:2414623323, ack 600446065, win 65535, length 288
20:01:15.976052 IP (tos 0x0, ttl 64, id 53757, offset 0, flags [DF], proto ICMP (1), length 68)
    MYPUBLICIP > 192.168.1.35: ICMP host MYPUBLICIP unreachable, length 48
        IP (tos 0x0, ttl 113, id 43597, offset 0, flags [DF], proto TCP (6), length 328)
    192.168.1.35.2194 > MYPUBLICIP.8889: Flags [FP.], seq 0:288, ack 1, win 65535, length 288
20:02:10.507625 IP (tos 0x0, ttl 57, id 27250, offset 0, flags [DF], proto TCP (6), length 340)
    192.168.1.47.49378 > MYPUBLICIP.8889: Flags [FP.], seq 0:288, ack 1, win 33120, options [nop,nop,TS val 508510689 ecr 51855053], length 288

See timestamps, these misaddressed packets are quite frequent.
And yeah, I now understand what you mean, I2P is not responsible for the final "source IP address" that is set, Operating System is (as only root can "forge" packets). Still... strange, as I'm not recieving any packet of this type for any other service than I2P (only port 8889 shows up in my captures).

Btw, pfsense is just the firewall software I'm using (http://www.pfsense.org/). I'll create another ticket for TCP oddities.

Regards,
Elgo
(edit: damn, was writing as zab posting, completely locking my edit:))

comment:11 follow-up: Changed 7 years ago by zab

How the !@#$ is this even possible?

... 192.168.1.47.49378 > MYPUBLICIP.8889 ...

Something is very wrong with this picture and I don't think I2P has anything to do with it. Do you have such ip in your private LAN? Some client application? WTF???

P.S. Elgo, please register a user.

comment:12 in reply to: ↑ 11 Changed 7 years ago by elgo

Replying to zab:

How the !@#$ is this even possible?

... 192.168.1.47.49378 > MYPUBLICIP.8889 ...

Something is very wrong with this picture and I don't think I2P has anything to do with it. Do you have such ip in your private LAN? Some client application? WTF???

As I said, there is no 192.168.1.0/24 subnet in my LAN. Such traffic originated from "private subnets from WAN" is only related to I2P port. Oh, and I don't have any WIFI network nor I suspect any already compromised device on my side.

I am pretty amazed too. WTF indeed.

comment:13 Changed 7 years ago by elgo

Hi,
I can confirm it doesn't seem related to a firewall/pfsense bug, as I did another capture on the bare WAN physical link (ethernet card, not the final pppoe interface which is build onto it, and is kinda software processed), I see now ethernet headers -> vlan header -> pppoe -> ip and... still 192.168.0.0/16 sourced packets 8|
Funny things, they all are TCP segments, no UDP.

comment:14 Changed 7 years ago by zab

I have no idea how this is even possible. Even if an i2p router gets configured with a private address that should get translated to public at the NAT or dropped on the first hop, no?

Did you talk to whoever is providing your internet connectivity? Anyone else have any ideas?

comment:15 Changed 7 years ago by elgo

Here is my thoughts: given that nobody can have a fonctional network with a private subnet directly on Internet (either NAT disabled or no NAT at all), let's assume this is intended.
What makes me think it's intended, is that all "wrong" segments I get are too similar to each others to be piece of legitimate traffic: I only get segments with weird activated flags: like Fin and Push, or Reset? Why? There is no established connection...
In the scenario I think about, it could be some sort of attack (you tell me if this can be possible), coming from a non-vanilla I2P software (rogue client?):
*use of "private address sourced" packet to get to an i2p router, to bypass possible loosy firewall filtering (tricking it to see it as local traffic, if rules like NAT reflection are activated and incorrectly processed)
*I2P payload containing data aimed at: initiating illigitimate tunnel? Redirecting traffic or disclose some info? Maybe real address is in there (I don't know I2P PDU) so that data is correctly returned to attacker via a new "legit" I2P flow.

I don't wanna make a film from this :) I may be wrong from the beginning, in fact.

comment:16 Changed 7 years ago by zzz

All the bugs and vulnerabilities I can think of are related to UDP. This ticket was a great benefit, as I fixed a big pile of them in the dev builds I referenced above.

For you, it sounds like bugs in your pppoe, or your external router/modem hardware, or even a problem on your ISP's side. A more general capture tool like wireshark may help.

One other possibility is an MTU problem. Is the MTU set correctly on your pppoe interface? 0.9.2 contains MTU fixes on the UDP side, but of course it should all just happen automatically for TCP.

comment:17 Changed 7 years ago by elgo

Ok, let's state about this for my part:
*it's not a "pppoe bug" of my firewall box. Because 2nd capture was directly made from physical interface (see previous "post"). Plus It's not related to PPP headers in any way.
*not a modem bug: I don't have modem (only firewall), it's a fiber connection (yes, with pppoe on it, "internet according to orange ISP")
*problem on my ISP side (orange.fr): surely, for routing these packets and not dropping them in the first place. Clearly. But they are here, my ISP won't generate them...
*a more general capture with wireshark? I used tcpdump to capture traffic, and wireshark to anaylse it afterwards, it won't change anything IMHO.
*MTU problem... I don't how it would be related to IP layer. Correctly set on my part (I checked), and as you said, wouldn't explain this (as ony TCP is concerned by now).

I concede that:
*I don't expect any "solution" nor "official" answer, I just created this ticket to see if you thought it would be related to I2P. If no, then good :) (and glad it could trigger some new fixes around :))
*I shouldn't see this traffic... damn right.

Still, what makes me nervous:
*I don't get any traffic of this sort for any other public service I provide (they aren't as world-widely used as I2P instance, of course, except freenet I could get back online to compare).
*theses private sourced packets have the same TCP flags enabled than many others TCP segments dropped by my firewall (I'll create another ticket when I have time to properly gather data). And I don't get why I only see private sourced packets trying to close TCP connection when I don't get any trying to establish one.

Regards.

comment:18 Changed 7 years ago by zab

problem on my ISP side (orange.fr): surely, for routing these packets and not dropping them in the first place. Clearly. But they are here, my ISP won't generate them...

I would ask them what they think. This is the weirdest thing I've ever seen. Sorry I can't be of any further help.

comment:19 Changed 6 years ago by guest

  • Resolution set to not a bug
  • Status changed from new to closed
Note: See TracTickets for help on using tickets.