MITM attacks - can they be ISP specific?

[tankman1989]

I've notices some really strange behavior on my computer depending upon which Internet connection I am using. (Os is Linux & I have 6 networks, 3 dedicted internal - no internet connection and 3 with Internet connections.

Using the same machine, if my primary (ISP1) is busy downloading a large file, I'll use my secondary (ISP2) connection for web surfing and SSH login. MANY times when I log into my server via SSH on ISP2 I often get a notice from BASH telling me that the authentication key has changed ad that MITM is a possibility. Also, if I go to the web-portal of the site that also hosts my ssh server, the font looks totally different than on ISP1 (IDK how many people notice this, but I can tell some things are very clear. If I use ISP3 to login via web portal or SSH, I don't get the warning message nor the strange font - so I switch back again and the strangeness appears.

I'be talked to the company that hosts and they said it wasn't a problem that they could see (meaning they couldn't find a prolem on their end) but I know this is messed up.


I also did this on a Windows 7 laptop and get same results on the 3 ISP's.

Has anyone ever heard of something like this and if so, what can I do about it. Any suggestions are greatly appreciated!

 

[OaksLabs]

Long story short it depends where you think the man-in-the-middle is. If he is on ISP2's network, then yes, he is specific to that ISP. However, I don't think you're actually experiencing a MITM attack.

I suspect that ISP2 has "route flapping" going on, where they have a problem router somewhere in their network core, and as a result during your SSH session sees your session ID change IP addresses and it thinks that this change of IP addresses is a man-in-the-middle. [NOTE: This is more of a loose analogy than anything else, the server doesn't actually see the IP address of the last hop.] The use of caching proxies or load balancers by ISP2 that are not properly configured are also plausible explanations.

More information would be useful. If you really want to diagnose this issue, the following would be useful:

• The types of connection of each ISp (ie. DSL, cable, dial-up, etc).
• The speeds of each connection.
• Two traces of the route from your PC to the server (after however long it takes for the error on ISP2 to popup).
  

  REM Windows syntax for tracert redirected to a file
  tracert SERVERNAME >ISPNAME.txt

  
  
• A dump of the mtr (my trace route, normally native in linux) statistics for each ISP.