Why are hacking attempts coming from IP addresses owned by Google?Many Stack Overflow users' pages have no Google PageRank and they are not indexed, why?Why are Google and AOL results different?Javascript - Detect if user is coming from a Google Adwords adShould WHMCS hacking attemps that never succeed be important to me?Are these hacking attempts or something less sinister?Any suggestions for a change detection system?Securing webserver from spam/phishing/malware - beyond RBLs?Why is Google downloading binaries from my web site and using bandwidth?Why are these Google cookies being downloaded?Security Issue - Harmful content

Re-submission of rejected manuscript without informing co-authors

What is the command to reset a PC without deleting any files

Can a planet have a different gravitational pull depending on its location in orbit around its sun?

Why was the "bread communication" in the arena of Catching Fire left out in the movie?

Shall I use personal or official e-mail account when registering to external websites for work purpose?

aging parents with no investments

Can I find out the caloric content of bread by dehydrating it?

Copycat chess is back

How could a lack of term limits lead to a "dictatorship?"

Domain expired, GoDaddy holds it and is asking more money

Is Social Media Science Fiction?

Are white and non-white police officers equally likely to kill black suspects?

Extreme, but not acceptable situation and I can't start the work tomorrow morning

Crop image to path created in TikZ?

Is it wise to focus on putting odd beats on left when playing double bass drums?

Is it legal to have the "// (c) 2019 John Smith" header in all files when there are hundreds of contributors?

Does it makes sense to buy a new cycle to learn riding?

What does 'script /dev/null' do?

Where else does the Shulchan Aruch quote an authority by name?

What are the advantages and disadvantages of running one shots compared to campaigns?

Does the average primeness of natural numbers tend to zero?

How can I fix this gap between bookcases I made?

Why is my log file so massive? 22gb. I am running log backups

New order #4: World



Why are hacking attempts coming from IP addresses owned by Google?


Many Stack Overflow users' pages have no Google PageRank and they are not indexed, why?Why are Google and AOL results different?Javascript - Detect if user is coming from a Google Adwords adShould WHMCS hacking attemps that never succeed be important to me?Are these hacking attempts or something less sinister?Any suggestions for a change detection system?Securing webserver from spam/phishing/malware - beyond RBLs?Why is Google downloading binaries from my web site and using bandwidth?Why are these Google cookies being downloaded?Security Issue - Harmful content






.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty margin-bottom:0;








1















I catch, save, and report all suspicious or malicious acts against my servers. Among the things I track are port scans on vulnerable ports (including the default ports for SSH, RDP, Plesk, and Webmin, none of which are in use on any of my servers), and actual failed login attempts to any protected service.



Alongside the usual suspects from present and formerly-communist states, I find a tremendous number of attempts by Google's bots not only to scan ports, but to actively attempt to log into password-protected services.



I understand that Google's spiders search the Interwebs for new and changed Web pages, which is why I whitelist their servers when I catch them hitting honeypots. But why the hell are they port scanning for service ports, and even worse, actively trying to log in to privileged services?



Check out these three links:



https://www.abuseipdb.com/check/130.211.246.128



https://www.abuseipdb.com/check/35.201.183.224



https://www.abuseipdb.com/check/35.204.251.155



Every AbuseIPDB user is free to word the attack reports however they like. Some, like me, give a generic description of the kind of attack to avoid revealing too much information. Others just post whatever their firewalls spit out.



Using whatever terminology, however, all of the pages contain multiple references to Google actively attempting to log in to services (they seem to have a special fondness for SSH and FTP), and failing due to authentication errors. Making actual login attempts goes way beyond Web crawling and, in my opinion, goes way over the line of acceptable behavior.



So what's this all about? Unauthorized penetration testing? That would be the most-defensible (and least-illegal) reason. So giving Google the benefit of the doubt and assuming that that's what they're doing, what's the proper response?



Other than when their bots hit HTTP honeypots, which could be dismissed as accidental, I block Google's IP's when they engage in what looks like mischief, just as I would block any other malicious IP. I didn't give them permission to do any of this; so as far as I'm concerned, they're no better than any other common hacker, cracker, or miscreant.










share|improve this question






























    1















    I catch, save, and report all suspicious or malicious acts against my servers. Among the things I track are port scans on vulnerable ports (including the default ports for SSH, RDP, Plesk, and Webmin, none of which are in use on any of my servers), and actual failed login attempts to any protected service.



    Alongside the usual suspects from present and formerly-communist states, I find a tremendous number of attempts by Google's bots not only to scan ports, but to actively attempt to log into password-protected services.



    I understand that Google's spiders search the Interwebs for new and changed Web pages, which is why I whitelist their servers when I catch them hitting honeypots. But why the hell are they port scanning for service ports, and even worse, actively trying to log in to privileged services?



    Check out these three links:



    https://www.abuseipdb.com/check/130.211.246.128



    https://www.abuseipdb.com/check/35.201.183.224



    https://www.abuseipdb.com/check/35.204.251.155



    Every AbuseIPDB user is free to word the attack reports however they like. Some, like me, give a generic description of the kind of attack to avoid revealing too much information. Others just post whatever their firewalls spit out.



    Using whatever terminology, however, all of the pages contain multiple references to Google actively attempting to log in to services (they seem to have a special fondness for SSH and FTP), and failing due to authentication errors. Making actual login attempts goes way beyond Web crawling and, in my opinion, goes way over the line of acceptable behavior.



    So what's this all about? Unauthorized penetration testing? That would be the most-defensible (and least-illegal) reason. So giving Google the benefit of the doubt and assuming that that's what they're doing, what's the proper response?



    Other than when their bots hit HTTP honeypots, which could be dismissed as accidental, I block Google's IP's when they engage in what looks like mischief, just as I would block any other malicious IP. I didn't give them permission to do any of this; so as far as I'm concerned, they're no better than any other common hacker, cracker, or miscreant.










    share|improve this question


























      1












      1








      1








      I catch, save, and report all suspicious or malicious acts against my servers. Among the things I track are port scans on vulnerable ports (including the default ports for SSH, RDP, Plesk, and Webmin, none of which are in use on any of my servers), and actual failed login attempts to any protected service.



      Alongside the usual suspects from present and formerly-communist states, I find a tremendous number of attempts by Google's bots not only to scan ports, but to actively attempt to log into password-protected services.



      I understand that Google's spiders search the Interwebs for new and changed Web pages, which is why I whitelist their servers when I catch them hitting honeypots. But why the hell are they port scanning for service ports, and even worse, actively trying to log in to privileged services?



      Check out these three links:



      https://www.abuseipdb.com/check/130.211.246.128



      https://www.abuseipdb.com/check/35.201.183.224



      https://www.abuseipdb.com/check/35.204.251.155



      Every AbuseIPDB user is free to word the attack reports however they like. Some, like me, give a generic description of the kind of attack to avoid revealing too much information. Others just post whatever their firewalls spit out.



      Using whatever terminology, however, all of the pages contain multiple references to Google actively attempting to log in to services (they seem to have a special fondness for SSH and FTP), and failing due to authentication errors. Making actual login attempts goes way beyond Web crawling and, in my opinion, goes way over the line of acceptable behavior.



      So what's this all about? Unauthorized penetration testing? That would be the most-defensible (and least-illegal) reason. So giving Google the benefit of the doubt and assuming that that's what they're doing, what's the proper response?



      Other than when their bots hit HTTP honeypots, which could be dismissed as accidental, I block Google's IP's when they engage in what looks like mischief, just as I would block any other malicious IP. I didn't give them permission to do any of this; so as far as I'm concerned, they're no better than any other common hacker, cracker, or miscreant.










      share|improve this question
















      I catch, save, and report all suspicious or malicious acts against my servers. Among the things I track are port scans on vulnerable ports (including the default ports for SSH, RDP, Plesk, and Webmin, none of which are in use on any of my servers), and actual failed login attempts to any protected service.



      Alongside the usual suspects from present and formerly-communist states, I find a tremendous number of attempts by Google's bots not only to scan ports, but to actively attempt to log into password-protected services.



      I understand that Google's spiders search the Interwebs for new and changed Web pages, which is why I whitelist their servers when I catch them hitting honeypots. But why the hell are they port scanning for service ports, and even worse, actively trying to log in to privileged services?



      Check out these three links:



      https://www.abuseipdb.com/check/130.211.246.128



      https://www.abuseipdb.com/check/35.201.183.224



      https://www.abuseipdb.com/check/35.204.251.155



      Every AbuseIPDB user is free to word the attack reports however they like. Some, like me, give a generic description of the kind of attack to avoid revealing too much information. Others just post whatever their firewalls spit out.



      Using whatever terminology, however, all of the pages contain multiple references to Google actively attempting to log in to services (they seem to have a special fondness for SSH and FTP), and failing due to authentication errors. Making actual login attempts goes way beyond Web crawling and, in my opinion, goes way over the line of acceptable behavior.



      So what's this all about? Unauthorized penetration testing? That would be the most-defensible (and least-illegal) reason. So giving Google the benefit of the doubt and assuming that that's what they're doing, what's the proper response?



      Other than when their bots hit HTTP honeypots, which could be dismissed as accidental, I block Google's IP's when they engage in what looks like mischief, just as I would block any other malicious IP. I didn't give them permission to do any of this; so as far as I'm concerned, they're no better than any other common hacker, cracker, or miscreant.







      google ftp hacking ssh






      share|improve this question















      share|improve this question













      share|improve this question




      share|improve this question








      edited 13 hours ago









      Stephen Ostermiller

      69.6k1396253




      69.6k1396253










      asked 15 hours ago









      GeekOnTheHillGeekOnTheHill

      1587




      1587




















          1 Answer
          1






          active

          oldest

          votes


















          3














          I think you’ll find that those are IP addresses for Google Cloud Platform, meaning that it’s not Google themselves but third parties running their own code on Google’s platform. So Google isn’t trying to hack you, it’s selling computing services to the public, some of whom are hackers.






          share|improve this answer























          • Okay, thanks. They resolve to *googleusercontent.com, so that would make sense. So temp-blocking them seems an appropriate response.

            – GeekOnTheHill
            15 hours ago











          Your Answer








          StackExchange.ready(function()
          var channelOptions =
          tags: "".split(" "),
          id: "45"
          ;
          initTagRenderer("".split(" "), "".split(" "), channelOptions);

          StackExchange.using("externalEditor", function()
          // Have to fire editor after snippets, if snippets enabled
          if (StackExchange.settings.snippets.snippetsEnabled)
          StackExchange.using("snippets", function()
          createEditor();
          );

          else
          createEditor();

          );

          function createEditor()
          StackExchange.prepareEditor(
          heartbeatType: 'answer',
          autoActivateHeartbeat: false,
          convertImagesToLinks: false,
          noModals: true,
          showLowRepImageUploadWarning: true,
          reputationToPostImages: null,
          bindNavPrevention: true,
          postfix: "",
          imageUploader:
          brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
          contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
          allowUrls: true
          ,
          onDemand: true,
          discardSelector: ".discard-answer"
          ,immediatelyShowMarkdownHelp:true
          );



          );













          draft saved

          draft discarded


















          StackExchange.ready(
          function ()
          StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fwebmasters.stackexchange.com%2fquestions%2f122111%2fwhy-are-hacking-attempts-coming-from-ip-addresses-owned-by-google%23new-answer', 'question_page');

          );

          Post as a guest















          Required, but never shown

























          1 Answer
          1






          active

          oldest

          votes








          1 Answer
          1






          active

          oldest

          votes









          active

          oldest

          votes






          active

          oldest

          votes









          3














          I think you’ll find that those are IP addresses for Google Cloud Platform, meaning that it’s not Google themselves but third parties running their own code on Google’s platform. So Google isn’t trying to hack you, it’s selling computing services to the public, some of whom are hackers.






          share|improve this answer























          • Okay, thanks. They resolve to *googleusercontent.com, so that would make sense. So temp-blocking them seems an appropriate response.

            – GeekOnTheHill
            15 hours ago















          3














          I think you’ll find that those are IP addresses for Google Cloud Platform, meaning that it’s not Google themselves but third parties running their own code on Google’s platform. So Google isn’t trying to hack you, it’s selling computing services to the public, some of whom are hackers.






          share|improve this answer























          • Okay, thanks. They resolve to *googleusercontent.com, so that would make sense. So temp-blocking them seems an appropriate response.

            – GeekOnTheHill
            15 hours ago













          3












          3








          3







          I think you’ll find that those are IP addresses for Google Cloud Platform, meaning that it’s not Google themselves but third parties running their own code on Google’s platform. So Google isn’t trying to hack you, it’s selling computing services to the public, some of whom are hackers.






          share|improve this answer













          I think you’ll find that those are IP addresses for Google Cloud Platform, meaning that it’s not Google themselves but third parties running their own code on Google’s platform. So Google isn’t trying to hack you, it’s selling computing services to the public, some of whom are hackers.







          share|improve this answer












          share|improve this answer



          share|improve this answer










          answered 15 hours ago









          Mike ScottMike Scott

          2,096118




          2,096118












          • Okay, thanks. They resolve to *googleusercontent.com, so that would make sense. So temp-blocking them seems an appropriate response.

            – GeekOnTheHill
            15 hours ago

















          • Okay, thanks. They resolve to *googleusercontent.com, so that would make sense. So temp-blocking them seems an appropriate response.

            – GeekOnTheHill
            15 hours ago
















          Okay, thanks. They resolve to *googleusercontent.com, so that would make sense. So temp-blocking them seems an appropriate response.

          – GeekOnTheHill
          15 hours ago





          Okay, thanks. They resolve to *googleusercontent.com, so that would make sense. So temp-blocking them seems an appropriate response.

          – GeekOnTheHill
          15 hours ago

















          draft saved

          draft discarded
















































          Thanks for contributing an answer to Webmasters Stack Exchange!


          • Please be sure to answer the question. Provide details and share your research!

          But avoid


          • Asking for help, clarification, or responding to other answers.

          • Making statements based on opinion; back them up with references or personal experience.

          To learn more, see our tips on writing great answers.




          draft saved


          draft discarded














          StackExchange.ready(
          function ()
          StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fwebmasters.stackexchange.com%2fquestions%2f122111%2fwhy-are-hacking-attempts-coming-from-ip-addresses-owned-by-google%23new-answer', 'question_page');

          );

          Post as a guest















          Required, but never shown





















































          Required, but never shown














          Required, but never shown












          Required, but never shown







          Required, but never shown

































          Required, but never shown














          Required, but never shown












          Required, but never shown







          Required, but never shown







          Popular posts from this blog

          Disable / Remove link to Product Items in Cart Planned maintenance scheduled April 23, 2019 at 23:30 UTC (7:30pm US/Eastern) Announcing the arrival of Valued Associate #679: Cesar Manara Unicorn Meta Zoo #1: Why another podcast?How can I limit products that can be bought / added to cart?Remove item from cartHide “Add to Cart” button if specific products are already in cart“Prettifying” the custom options in cart pageCreate link in cart sidebar to view all added items After limit reachedLink products together in checkout/cartHow to Get product from cart and add it againHide action-edit on cart page if simple productRemoving Cart items - ObserverRemove wishlist items when added to cart

          Helsingin valtaus Sisällysluettelo Taustaa | Yleistä sotatoimista | Osapuolet | Taistelut Helsingin ympäristössä | Punaisten antautumissuunnitelma | Taistelujen kulku Helsingissä | Valtauksen jälkeen | Tappiot | Muistaminen | Kirjallisuutta | Lähteet | Aiheesta muualla | NavigointivalikkoTeoksen verkkoversioTeoksen verkkoversioGoogle BooksSisällissota Helsingissä päättyi tasan 95 vuotta sittenSaksalaisten ylivoima jyräsi punaisen HelsinginSuomalaiset kuvaavat sotien jälkiä kaupungeissa – katso kuvat ja tarinat tutuilta kulmiltaHelsingin valtaus 90 vuotta sittenSaksalaiset valtasivat HelsinginHyökkäys HelsinkiinHelsingin valtaus 12.–13.4. 1918Saksalaiset käyttivät ihmiskilpiä Helsingin valtauksessa 1918Teoksen verkkoversioTeoksen verkkoversioSaksalaiset hyökkäävät Etelä-SuomeenTaistelut LeppävaarassaSotilaat ja taistelutLeppävaara 1918 huhtikuussa. KapinatarinaHelsingin taistelut 1918Saksalaisten voitonparaati HelsingissäHelsingin valtausta juhlittiinSaksalaisten Helsinki vuonna 1918Helsingin taistelussa kaatuneet valkokaartilaisetHelsinkiin haudatut taisteluissa kaatuneet punaiset12.4.1918 Helsingin valtauksessa saksalaiset apujoukot vapauttavat kaupunginVapaussodan muistomerkkejä Helsingissä ja pääkaupunkiseudullaCrescendo / Vuoden 1918 Kansalaissodan uhrien muistomerkkim

          Adjektiivitarina Tarinan tekeminen | Esimerkki: ennen | Esimerkki: jälkeen | Navigointivalikko