Cyberwar, OVH SMB, User Identification, GAE, Integrations, Telegram

Post date: Sep 17, 2017 5:05:59 AM

• Friend watched Zero Days Cyberwar Stuxnet documentary and got worried. Don't worry. There's practically nothing you can do about it. If you're getting targeted, they'll get it. So it's pointless to worry about it. You can harden systems, but it won't stop certain actors. Worrying about it, is like worrying how you can protect your summer cottage from intercontinental nuclear weapons. Well, you can't.
• About OVH and TCP/445 blocking / filtration. They claim it's mandatory to filter TCP/445 RPC/SMB traffic on network edge. Because without filtering hackers would get it. I guess it's better I don't say my honest opinion about that rationalization. But oh well. Just like with many rules, if someone is stupid, it doesn't mean everyone would be stupid. But that's often a concept which is way too hard for many to understand. Yet on the other hand they claim that all ports are open, which is obviously bs, when some ports are being filtered. Traditional we're lying to customers making things seem better.
• Web and cloud services are being used as a proxy in monitoring and identity tracking? Some services require sending them information about official identification documentation. This is just a way to gather information about the users. As example account is suspended until official identification information is provided, even if any rules wouldn't have been violated. Usually if basic rules are violated account is immediately suspended without option to reactivate it. Of course this isn't anything new and it's just one way to abuse and harness power. Let's say you open account for some confidential use, then some parties get interested about it. Then they ask the service provider to close down the account and ask for official identification like a copy of passport. Then it's up to the user to decide if they want to provide that information, if they will provide invalid information or if they simply accept the suspension and continue without the service. This is huge problem with cloud services, you can basically get locked out of the service at anytime. And it's totally arbitrary when this will happen. On the other hand, as possible service provider, I also understand this. If I'm running service X, I should be able to select the users totally freely. I can delete whatever I want, whenever I want as well as block users from accessing the service or add additional requirements for users to get continued access to the service. No warranties whatsoever. Yet, this is kind of risk to the users, which naturally should accept it the possibility for this. Yet asking such information might undermine security and privacy, in some specific cases, and denying pseudonymous operations, even if any law isn't being violated.
• Previous statement is also one of the reasons why I'm not running anything on Google Cloud Platform / Google App Engine anymore. They could at anytime without any reason close the service(s) down. Of course I've got multiple off-site & cloud backups. But in general that's a huge risk, because App Engine apps aren't easily transportable to "any" provider around the world. Same applies for the people going for AWS or Azure. It's huge risk. Your business might be gone tomorrow and fixing it to run on other platforms, depending on how badly it's designed, might take months.
• About integrations, I'm just mentioning that also shared memory, database, message queues, message passing, FTP, HTTP, REST, XML, JSON, SOAP, CSV, PUB/SUB, pure TCP, UDP, etc, whatever can be naturally used. - It's just the same stuff, in different packet. Some people seem to think it's big deal, but it really isn't. It's just getting "message through" using whatever means available. I've seen so many guys seriously stuck with minor details without seeing the large abstract picture. When building house you could spend two years selecting suitable nails, and discussing if screws or nails should be used and what kind of metal alloy those should be. But it'll be probably highly unproductive. It's of course different story if you're doing your PhD about different nail alloys and plating techniques and how those last decades of different environmental factors.
• Telegram's HTML5 web implementation is awesome. Even if there would be a marginal platform which wouldn't have native Telegram client, you could always fall back to their great HTML5 implementation, with push notifications etc.
• Something different: Reminded my self about XB-1 from Boom Supersonic and Kh-55.