Linkedin 2FA, Caching Performance, OVH TCP 445 SMB, IP address, Network Reachability

Post date: Sep 3, 2017 4:50:55 AM

• LinkedIn 2FA repeatedly failing. Enhancing security is easy, if you just disable login option completely and prevent everyone from logging in. That also efficiently prevents build up of data which might need protection. That's awesome. I can honestly claim, I'm running the worlds most secure website. It's in my head, and I haven't even told everyone about it, and there's no hardware or software involved. So there aren't any bugs ore exploits. Nor there's any user data. It's perfection! (FYI, this entry is from a long backlog)
• About read caching and performance. Once back in DOS and CD-ROM days. We bought pretty awesome drive. It was 7 CD changer with 4x CD-ROM drive. Due to minimal buffering and multi user access to the BBS system, the most awesome trolling method was accessing several disks from the CD-ROM drive simultaneously. Changing disk took like 10 - 15 seconds. And then user would get a few kilobytes of data, and then it would trigger change to access the next disk. Only a few releases later the software contained option to cache the downloads to HDD, so that users downloading stuff from multiple disks wouldn't basically bring the whole system down due to extreme I/O lag. Btw. Because the system didn't contain parallel I/O queues. The CD-ROM trick also blocked any HDD I/O and CPU usage, due to I/O wait and blocking I/O operations. Making it totally impossible to use the system for the users. Like trying just to read private messages. Of course because the operations wasn't being spooled, this situation usually lead to case, where users would get extremely annoyed and probably disconnect, until there were only one user downloading from CD-ROM changer disks again. The system was usually on high demand, so this caused funny spike in login attempts. Due to lag, and users disconnected and the system became free for more users. Which find out that it's so slow it can't be used and disconnected. It's just like the lagged websites, those might get highest user visitor count ever, due to users trying to reload the site, until giving up. Therefore getting high visitor count can be gotten by providing extremely bad service on purpose. On normal day the system could handle something like 20 - 50 users with dual access lines. But on this kind of day, the login count could be easily 10x more. The same users came back a few hours later trying again to read the messages. If it still failed, they would try again later.
• OVH and TCP port 445 which is used for SMB protocol is being blocked. I also used portquiz.net to trouble shoot some networking issues, and guess what. The service is also hosted at OVH, so that just confused me even more, before I realized what was happening. I also used one Linux server for trouble shooting, and everything worked fine. But it was hosted on OVH and that's why it worked, because it was OVH intranet traffic. I got totally confused before I figured out the facts. After rechecking everything and starting to sum up the data I've collected. I thought that I'll try from one Windows server hosted on OVH and it worked. So it seems that OVH is blocking TCP PORT 445 SMB even if they claim they're not. All ports open, except 445. World wide total blocking of port 445 doesn't make any sense after all. This is one of the reasons why you should really well know your tools and configurations. Because otherwise those might just add extra confusion, instead of actually providing solutions / answers. But of course this is nothing new. Keep in mind that correlation does not imply causation. Bit extra testing from home where I know my network configuration 100% and tracing using TCP SYN packets confirmed it. SMB / TCP 445 port traffic is dropped at OVH network edge. Sigh. Testing with several random ports, and using several different ISPs result is always the same. Yet everything works if the same tests are run from another server inside OVH network. Ok, that's it. One thing which also mislead me is that if the ports 135-139 are accessible, the error message while connecting to server changes. Giving impression that those traditional NB ports could be used for communication. But after all everything fails, because 445 is blocked. For inbound connections GRC ShieldsUp scan is a true classic. I even had long discussion with OVH helpdesk, and they said that blocking TCP port 445 is mandatory. I guess we should thank Microsoft providing so bad code that it leads to global TCP port blocking by port number? Eh.
• In P2P network discussions there was often question how to define if node got "full Internet access or not". My answer was that it can't be determined. And that's the only truth. Having access to A, B, C doesn't mean full access. Nor not having access, means that there wouldn't be access to any other parts. Working connection now, doesn't mean that the same connectivity would be there 15 minutes later, and so on. Also the IP address for outbound traffic can be different than for inbound traffic. Or the IP can be dynamically assigned on connection creation from a pool. So address changes per TCP connection / UDP outbound 'connection'. As well as the IP / port for any inbound / outbound address can be defined separately. So if you connect from port 500 to port 1000 to IP a. It doesn't mean that port 600 to port 500 to ip B would work. Nor that the IP address would be same for that connection than it was for the previous connection. My firewall allows me to define route and IP based on any basic criterion. protocol, source, destination, port, ip, etc. Yes, it means that SMTP out can even use different AS and service provider than connection to port 80... Even if the destination IP is the same.