5 ms·

As stated, "If you're trying to default deny new outbound connections and build an allow-list for MS resources, you'll have your work cut out for you". If you'

by aksss 5y ago

As stated, "If you're trying to default deny new outbound connections and build an allow-list for MS resources, you'll have your work cut out for you". If you're trying to secure your consumption of their product by explicitly allowing communication with only pre-authorized domains, they are still finite in number. The quantity is more than 1, but less than infinity. You can build such a list if you want to, which would exclude office366.ru. I'm not sure I understand the problem - that you must authorize thirty domains instead of one? Or are we arguing a principle here that one domain should be all that the entire Microsoft product catalogue ever uses? I confess, I may fail to see how one domain vs two vs twenty-two known domains is going to matter, but I am curious to learn more. What are you attempting to do on that domain front?

inetknght 5y ago
> I confess, I may fail to see how one domain vs two vs twenty-two known domains is going to matter, but I am curious to learn more. What are you attempting to do on that domain front? 1. Use pihole 2. Use Firefox. 3. Install umatrix. Open its ruleset and add a rule: * * * block 4. Install noscript 5. Then start adding domains as needed -- first on umatrix, then on the pihole, then on noscript Nearly all sites will be readable with only their domain enabled (and all else including cookies, CSS, images, scripts, etc) blocked. Most sites work great with only CSS and images unblocked. This is literally the way that the internet is supposed to work. But a few bad actors, such as Microsoft, have made necessary the complications of cookieblocks, scriptblocks, adblocks, dnsblocks, and etc. You can't log in without cookies. So those are the first things to enable on sites that you need to log in. Some sites work great with just cookies, CSS, and images. Some sites use cross-site requests to do account lookups though. In those sites, you can't log in without XHR. So those are enabled next. And in some few places, like Microsoft, you can't login without scripts and "other". Microsoft wants to fingerprint your device for "security". But that security is, at best, broken. I argue it's much more malicious. Further, in most websites, you only need to enable these things for one or two domains to be able to log in. Google requires three or four depending on the login workflow. Stackoverflow requires two. Microsoft? Hahaha, I gave up after six. Now I exclusively use Microshit's sites in its own dedicated virtual machine isolated from everything else with its own pihole and separate lookup rules because I can't trust that it won't add yet another domain that's "needed". I can't trust that a third party won't abuse a wide open system like that to sneak in some additional requirement while trying to figure out what works to get logged in. What am I attempting to do on that domain front? I am attempting to demonstrate that a site doesn't talk willy-nilly to every fucking body else and provide fifty million avenues for: * cross-site request forgeries * cookie hijacks * script injections * encryption certificate expiration/hijack * domain name expiration/hijack * look-alike/typo names "office365.com" vs "0ffice365.com" vs "office-365.io" vs "office-365.azure.com" vs "ms-office-365.cloudfront.net" vs ... * there's no way I can write an exhaustive list for you
- aksss 5y ago
  > I'm attempting to demonstrate Well, have fun with that. I guess I still don't understand why you're worried about office366-type domains if you're whitelisting allowable domains to begin with. Anyway, everyone's risk analysis is different, sounds like you're managing yours accordingly.

by aksss 5y ago

inetknght 5y ago

> I confess, I may fail to see how one domain vs two vs twenty-two known domains is going to matter, but I am curious to learn more. What are you attempting to do on that domain front? 1. Use pihole 2. Use Firefox. 3. Install umatrix. Open its ruleset and add a rule: * * * block 4. Install noscript 5. Then start adding domains as needed -- first on umatrix, then on the pihole, then on noscript Nearly all sites will be readable with only their domain enabled (and all else including cookies, CSS, images, scripts, etc) blocked. Most sites work great with only CSS and images unblocked. This is literally the way that the internet is supposed to work. But a few bad actors, such as Microsoft, have made necessary the complications of cookieblocks, scriptblocks, adblocks, dnsblocks, and etc. You can't log in without cookies. So those are the first things to enable on sites that you need to log in. Some sites work great with just cookies, CSS, and images. Some sites use cross-site requests to do account lookups though. In those sites, you can't log in without XHR. So those are enabled next. And in some few places, like Microsoft, you can't login without scripts and "other". Microsoft wants to fingerprint your device for "security". But that security is, at best, broken. I argue it's much more malicious. Further, in most websites, you only need to enable these things for one or two domains to be able to log in. Google requires three or four depending on the login workflow. Stackoverflow requires two. Microsoft? Hahaha, I gave up after six. Now I exclusively use Microshit's sites in its own dedicated virtual machine isolated from everything else with its own pihole and separate lookup rules because I can't trust that it won't add yet another domain that's "needed". I can't trust that a third party won't abuse a wide open system like that to sneak in some additional requirement while trying to figure out what works to get logged in. What am I attempting to do on that domain front? I am attempting to demonstrate that a site doesn't talk willy-nilly to every fucking body else and provide fifty million avenues for: * cross-site request forgeries * cookie hijacks * script injections * encryption certificate expiration/hijack * domain name expiration/hijack * look-alike/typo names "office365.com" vs "0ffice365.com" vs "office-365.io" vs "office-365.azure.com" vs "ms-office-365.cloudfront.net" vs ... * there's no way I can write an exhaustive list for you

aksss 5y ago
> I'm attempting to demonstrate Well, have fun with that. I guess I still don't understand why you're worried about office366-type domains if you're whitelisting allowable domains to begin with. Anyway, everyone's risk analysis is different, sounds like you're managing yours accordingly.