Can I block this ip 34.101.115.42? (google) - ip

https://www.whois.com/whois/34.101.115.42
This ip is from google (cloud) and today I discovered it trying to access via ssh....
The instinct is to block it, but the doubt comes, won't it be used by the google spider as well?
Can it be blocked without risk?

Related

Google Cloud Armor not working until instance reset

I am trying to ban 1 IP address that someone is using to send malicious attacks every 3 seconds.
However, when I use Google Cloud armor, the IP/attacks aren't blocked until the application is reset. At which point, I see that the attacker set it up so that the IP address automatically changes and attacks from a different IP.
Am I always suppose to reset to make Cloud Armor work? Or is this happening because I'm using a load balancer?
Another possibility is that Cloud Armor never worked in the first place, but when the application was reset, the attacker's script changed the IP automatically.

What are the potential risks of not using a Web Application Firewall?

I develop and manage a small promotional/marketing website on Wordpress for a startup SaaS product. We're using Cloudflare for DNS and whatnot. Apparently the WAF has been turned on which uses a proxy and changes the user's IP address. i'm trying to use IP address to filter "internal" traffic for Google Analytics and the only way this works is with the WAF turned off. If not using the WAF is going to cause any sort of significant risk for my website, then obviously I'll need another way to do my analytics thing. Reading about what all it provides on their website doesn't make it all that clear to me how important it is for a website like this. If anyone who "gets it" had some insight to share, I'd be most appreciative. thx!
You should definitely use the WAF - it will protect your website from many malicious bots and attacks.
Wordpress sites are particularly juicy targets for attackers, for a number of reasons:
The security of a default Wordpress installation is not great.
Every Wordpress site shares common default features, such as the location of the admin login page, the admin username, and other exploitative resources.
Wordpress is extremely popular, and currently used by an estimated third of all websites on the internet.
Wordpress is used by many, many small businesses and hobbyists who do not how to secure their site properly.
Ergo, attackers can very easily scour the web for Wordpress websites that are easily hackable. Other nefarious activities are commonly carried out with ease on most Wordpress sites, such as comment spam or Denial of Service attacks.
What protection does the WAF offer?
Cloudflare and most other high quality WAFs can be configured to protect your site by automatically performing actions like:
Blocking known bad IP addresses.
Blocking bad bots which are automatically making requests to your site.
Limiting high numbers of requests from one source in a short amount of time (usually a sign of a DoS attack or scraping).
Blocking requests from particular countries or locations.
There is no reason why you wouldn't want to enable this protection if you have it available to you, and Cloudflare is the industry leader in this area.
Additionally, I would recommend you research how to better secure your Wordpress site in ways other than just the WAF - e.g. The Ultimate WordPress Security Guide
How to solve the IP address issue
Cloudflare is not changing the user's (the client) IP address, but rather acting as a proxy. As you have noticed, the IP address you're seeing is not the client's own, but one of Cloudflare's. This is crucial to how Cloudflare works to protect your site, but this is a common issue when using any kind of proxy.
To get the correct IP address when using a proxy, you need to check the X-FORWARDED-FOR header. You might see this as a string of comma-separated IP addresses, depending on how many proxies the user has gone through before reaching the site. The first one in the list is the original client IP.
e.g. Here 203.0.113.1 is the client's original IP address:
X-Forwarded-For: 203.0.113.1,198.51.100.101,198.51.100.102
Documentation: How does Cloudflare handle HTTP Request headers?
Anyway, it's good to use a function which can comprehensively check headers and give you the best match for the original client IP, regardless of whether the user is behind a proxy or not, so that you can guarantee it always works.
Here's a very popular StackOverflow question about this:
What is the most accurate way to retrieve a user's correct IP address in PHP?

What is the best solution to prevent malicious IPs from accessing my hosting server?

Just to explain my setup: I have a few websites hosted on a shared server (Lunarpages) and I use Google Apps (with modified MX records in Lunarpages) so the Google Apps emails work.
Now, I've noticed occationally that a mail script on one of my sites gets triggered without any content, though it includes IP information that the form collects. I looked up a couple of those IP address with AbuseIPDB, and they are known hacking IPs. So I want a good way to block all access to my server from known bad IPs.
I see in Cpanel in Lunarpages an option to turn on CloudFlare for security, and looking into them a little, it does appear that they block bad IPs. But I'm a little concerned about whether that would risk messing up how my site works or email works or how my analytics and email forms collect IP address information or if there would be anything different from me besides just turning it on and that the bad IPs would be blocked. I'm not looking to get myself in to a lot of troubleshooting.
Is CloudFlare a good solution, or are there other good alternatives?
Regarding the AbuseIPDB, they look like they have an API that I might be able to set up to block IPs, but if I understand right, I would have to modify all my sites and that still wouldn't block direct access to a lot of files. Unless I'm mistaken.
You can use ipset to block a list of IP addresses and you can set up ipset list of IP addresses from some spam DB.

Why does my website have referrals from http://1.1.1.3/fcgi/websAuth?

I just got an question from my Google Analytics expert that is identifying a lot of referrals from this IP
http://1.1.1.3/fcgi/websAuth
http://1.1.1.3/fcgi/websVlanAuth
i check all my server settings, i have anothers site in this server and i dont have this issue, also i check for virus and everything, but not idea why im having this referrals , also this is tracked as mobile traffic, i checked the ip with ip trace and it said is from google Australia
any clue of this and how to fix it ?
The referrer header sent with a HTTP request is completely unreliable. In your case, http://1.1.1.3/fcgi/websAuth might be a referring page on a private network, a deliberately spoofed referrer, or set by a misconfigured or buggy proxy server. There's probably nothing you can do about that.
Another big problem is referrer spam used to advertise certain websites. I typically create a segment that excludes all referrers that look fishy.

What IP will google analytics see for internally hosted site

One of our sites that we want to use google analytics on is hosted inside our network.
We would like to exclude the administrators own traffic from the reports, but I am wandering how analytics obtains the users IP address.
If it uses the address which the analytics script is requested from (the HTTP request for the js) then it will see one of our external ips and excluding that will get rid of all traffic.
If it obtains it in javascript once the ga.js is downloaded then it will see the internal 10.x.x.x addresses and filtering out the assigned addresses will have the desired result.
Essentially my question is, will filtering the internal address work or not.
I shall set up an experiment now, but obviously it will take 1 or 2 days before I can be sure about that outcome. If it doesn't work, then I will set custom vars and filter those instead
It will see the IP that requests the __utm.gif image, then the IP of your internet gateway(s)
You can define a filter to exclude each of your IPs, or your IP range

Resources