I think that Cloudflare bypass my custom htaccess rules.
Is it true?
I had some IP restrictions in htaccess but they are bypassed.
Plus, my Expired Rules (for caching) I think that they aren't working.
I am trying to check that from redbot.org that tell me that: "Pragma: no-cache is a request directive, not a response directive."
Thanks
Cloudflare will request resources (such as web pages) from your server using its IP, not the client's IP. So, if you have some IP restrictions which you expect to work based on the client IP, then instead your .htaccess will be seeing Cloudflare's IP, not the client IP.
Cloudlfare have posted some answers on how to modify certain web servers so that the original client IP is again the IP you get, rather than Cloudflare's IP. See https://support.cloudflare.com/hc/en-us/sections/200038166-How-do-I-restore-original-visitor-IP-to-my-server-logs- for more information.
Related
I am getting a bit into protecting my website but someone keeps posting the origin-ip of my website. I've found out that this website is exposing it: http://www.crimeflare.org:82/cfs.html
after some extra research I found that this site has been online for a couple years but no info on how it is made or what technique it uses. Does anyone have a clue how this website gets the direct-connection IP address? Thanks in advance.
I can answer this question. It's really all due to domain history in a nutshell. In order to avoid domain history fetching websites, so-called CloudFlare resolvers and Crimeflare, you need to change your origin IP while under the banner of CloudFlare. Then to stay hidden you MUST not use the email services from your domain otherwise a simple MX record lookup will expose your origin IP. So this means you now need to use third-party email services. If you are using a VPS or bare metal you need to setup IPtables so that ALL IPs are blocked and just allow CloudFlare's IPs. This way IP scanners like Censys can't find your origin IP either since all IPs would be blocked except CloudFlare's forcing all connections to go through CloudFlare. Thankfully CloudFlare IPs don't change that often and they do publish the IP list at their website.
If you are using a shared account you'll want to make sure your shared account uses a shared IP and not a unique IP. With a shared IP your website is mixed with others and these CloudFlare resolver websites can't distinguish between who's who to get your origin IP.
There are some other very minor trivial things to also consider. One trivial possible vector for origin IP exposure is allowing remote content to be published via the website. Be it a remote avatar or file. The link used from this remote content has the possibility of resolving your origin IP behind CloudFlare.
If you are using a shared account you can help block direct IP connections and keep all connections going through CloudFlare in one of two ways. In an Apache or Litespeed SAPI, add the following to your htaccess file:
RewriteCond %{HTTP:CF-IPCountry} ^$
RewriteRule ^ - [F,L]
What that code does is check for the CloudFlare Geo location header in the request from CloudFlare and if not present the user gets a 403. Thus all connections must go through CloudFlare. In order for this to work, the IP Geo Location option has to be turned on in your CloudFlare dashboard under Network.
The other really unique and awesome way of doing this is by using CloudFlare Workers. You can read about that here: https://community.cloudflare.com/t/stop-cloudflare-bypassing-on-shared-hosting/91203
I use all of these methods myself with my websites minus the fact of not using a VPS. So far my origin IP is not shown in Crimeflare or other websites.
Best of luck.
They very much explain it on that very site:
There are sites on the web that specialize in collecting registration and nameserver data. [..] CloudFlare maintains around 391 nameservers, and customers must change the nameservers on their registration in order to use most services. Each customer's domain is assigned two nameservers. This makes it easier to verify which domains depend on CloudFlare, and helps us keep our domain lists relatively current.
In other words, they look at public nameserver data and filter out the domains that have their nameservers pointed at one of CloudFlare's nameservers.
i know you can't redirect the path portion of a URL with DNS only
But is this possible with DNS only?
app1.domain.com --> domain.com:4993
app2.domain.com --> domain.com:4994
(both are https only)
which DNS records do i need to add?
It's not possible with pure DNS. The DNS does not care about the port, but only about the domain. To achieve this check if your DNS provider offers Web Redirecting or Web Forwarding. It's not DNS only, but depending on the reason why you want it to be DNS only this might work for you.
My company changed names recently, so along with that came a new domain. Both the old site and the new site are HTTPS and are on the same server using separate DNS entries.
I setup a 301 redirect which works great if people go to oldsite.com, but if they go to https://oldsite.com they get an SSL error.
Is there any way around this? Hopefully through DNS, server config, or htaccess file.
With TLS/SSL, only one certificate can be presented by the server per IP address. So if oldsite.com is using the same IP as newsite.com, the certificate for https://newsite.com will be the one sent to the client, which will (by definition) raise an SSL error for https://oldsite.com.
To have both oldsite.com and newsite.com both active, you'll have to have separate IPs for each. These can reside on the same server, with some (possibly complicated) routing configuration depending on your server's OS, to ensure requests to each IP are replied to from the same IP. However, even with DNS entries for both, you cannot share an IP address with multiple HTTPS domains.
Edit: You could also use virtual domains (exact config dependent on which web server you're running) to present the certificate for oldsite.com, then send the redirect after the TLS session is in place. I'd have to know which web server you're using (Apache, Nginx, Lighttpd, etc) to give a config example, though.
I have a subdomain (mail.mywebsite.com) that points to the login page that I've set up for Google apps (per their instructions). I'm currently using a CNAME record to point users to the page.
However, I'd like to restrict access to this subdomain on an IP basis (effectively create a whitelist).
Not sure if modifiying .htaccess on my server is an option, as the domain is configured in the registrar to forward to Google, not content on my server.
Any suggestions for how I could accomplish this? Thanks in advance!
If you've done this using a DNS CNAME, you have no control over who can access mail.mywebsite.com since it's not even your server that's accepting requests (it's Google's server).
Unless there's some way to setup access restrictions on Google, there's not going to be anything that you can do.
Alternatively, you can change the CNAME to point to your server, then use a reverse proxy to proxy the requests to Google. You can then use access controls to setup what IPs will be proxied and all the rest will just get 403'ed. Can't setup ProxyPass in htaccess file though, need to do it in server/vhost config, but you can use the P flag in mod_rewrite to reverse proxy for you.
Can anybody explain why I see another web site at my http secure address. I don't have a certificate. I can manage files from folder httpsdocs but cannot access them from web. Also httpsdocs is empty. https://innovacube.com/
And base of my problem is Google indexes my https domain but I cannot denny Google Bot.
You're sharing IP addresses with another site - you'll see that both www.innovacube.com and www.cokyader.com resolve to 92.199.202.62. HTTP/1.1 allows this because you also send a host header
GET / HTTP/1.1
Host: www.innovacube.com
so the web server knows which site to serve for a given connection.
It isn't, however, possible to do this for HTTPS. The problem is that the certificate negotiation happens before the server gets to HTTP so you can't switch depending on the site that the browser really means. Therefore you can only host one HTTPS site per IP and this IP is hosting cokyader.com. (There are proposed extensions to help fix this but I've never seen any progress on this.)
If you want your own separate HTTPS site then your host will have to allocate you your own separate IP address.
Because you are using shared hosting, and it has been configured with a default SSL site that isn't yours (but presumably belongs to someone who has paid for SSL support and has their site hosted on the same server).