5 ms·

This is great, afaik Google Drive stuff is a nightmare for SoCs as they don't want to block the whole domain.

ocdtrekkie 5y ago
One easy to block is storage.googleapis.com ...Regularly used to host malware, but legitimate users generally throw their own domain in front of any usage of that service.
- ricardobayes 5y ago
  No don't do that, this is exactly why IT/opsec is hated in organizations. False positives.
  - ocdtrekkie 5y ago
    I have so far seen a single instance where a legitimate organization sent someone a storage.googleapis.com URL. I have seen literally hundreds of phishing emails do it. Which is to say, the problem is organizations using storage.googleapis.com URLs, not organizations blocking them. And probably Google should be doing a better job policing content on their content domains if they don't want them to be blocked by default. (Similarly, all Chrome Web Store extensions should be blocked by default, with an allowlist for requested and vetted ones... there's simply too much malware to default to anything else.) I'd love to block Google Drive by default too, but there is enough legitimate use that at present that would cause too many false positives, and it's a balancing act.
    - profmonocle 5y ago
      > Which is to say, the problem is organizations using storage.googleapis.com URLs, not organizations blocking them. Blocking this domain definitely isn't common, at least not in large organizations. Several of my company's B2B apps use Google Cloud Storage (it's just Google Cloud's version of S3) and have always used storage.googleapis.com/bucketname rather than bucketname.storage.googleapis.com. (AFAIK it was the default URL format shown in their documentation when I last looked at it years ago.) We've had to deal with overzealous corporate web filters now and then - comes with the territory of B2B apps - but I've never heard of storage.googleapis.com being blocked. It'd be pretty straightforward for us to change it if a customer had trouble, but we'd probably gently push back and ask them to whitelist the domain before doing so.
      - ocdtrekkie 5y ago
        I would say in my professional experience, I've only once seen someone legitimately directly need to pull content through storage.googleapis.com (whether bucketname.storage.googleapis.com or not). My assumption is public-facing entities tend to serve content via their own domains to end user clients. I'd be comfortable whitelisting a bucket subdomain, but as I said, it's only come up once, so we worked around it the one time. And I've blocked a lot of phishing sites this way. I'd highly recommend large organizations follow suit. :)
    - ricardobayes 5y ago
      Why don't you use a vendor that provides the concrete URLs as IOCs to block?
      - ocdtrekkie 5y ago
        That's fine for blocking malicious content that's already been reported. But if there's no legitimate need to allow the domain, why not block it entirely and prevent even being the ground zero for a new URL? If my organization is likely enough to be targeted intentionally, the chance of having an attack directly solely at my organization (and hence, likely a URL not found by other parties already) is much higher as well.

One easy to block is storage.googleapis.com ...Regularly used to host malware, but legitimate users generally throw their own domain in front of any usage of that service.

ricardobayes 5y ago
No don't do that, this is exactly why IT/opsec is hated in organizations. False positives.
- ocdtrekkie 5y ago
  I have so far seen a single instance where a legitimate organization sent someone a storage.googleapis.com URL. I have seen literally hundreds of phishing emails do it. Which is to say, the problem is organizations using storage.googleapis.com URLs, not organizations blocking them. And probably Google should be doing a better job policing content on their content domains if they don't want them to be blocked by default. (Similarly, all Chrome Web Store extensions should be blocked by default, with an allowlist for requested and vetted ones... there's simply too much malware to default to anything else.) I'd love to block Google Drive by default too, but there is enough legitimate use that at present that would cause too many false positives, and it's a balancing act.
  - profmonocle 5y ago
    > Which is to say, the problem is organizations using storage.googleapis.com URLs, not organizations blocking them. Blocking this domain definitely isn't common, at least not in large organizations. Several of my company's B2B apps use Google Cloud Storage (it's just Google Cloud's version of S3) and have always used storage.googleapis.com/bucketname rather than bucketname.storage.googleapis.com. (AFAIK it was the default URL format shown in their documentation when I last looked at it years ago.) We've had to deal with overzealous corporate web filters now and then - comes with the territory of B2B apps - but I've never heard of storage.googleapis.com being blocked. It'd be pretty straightforward for us to change it if a customer had trouble, but we'd probably gently push back and ask them to whitelist the domain before doing so.
    - ocdtrekkie 5y ago
      I would say in my professional experience, I've only once seen someone legitimately directly need to pull content through storage.googleapis.com (whether bucketname.storage.googleapis.com or not). My assumption is public-facing entities tend to serve content via their own domains to end user clients. I'd be comfortable whitelisting a bucket subdomain, but as I said, it's only come up once, so we worked around it the one time. And I've blocked a lot of phishing sites this way. I'd highly recommend large organizations follow suit. :)
  - ricardobayes 5y ago
    Why don't you use a vendor that provides the concrete URLs as IOCs to block?
    - ocdtrekkie 5y ago
      That's fine for blocking malicious content that's already been reported. But if there's no legitimate need to allow the domain, why not block it entirely and prevent even being the ground zero for a new URL? If my organization is likely enough to be targeted intentionally, the chance of having an attack directly solely at my organization (and hence, likely a URL not found by other parties already) is much higher as well.