I have created pfSense(version: 21.05.1) firewall on Azure VM. In the LAN section, I have made a rule to deny any traffic, so all the traffic to the internet is blocked. Also, I have created an alias that contains the URL www.google.com. However, even after making a firewall rule to allow traffic to this alias, I cannot send traffic to www.google.com.
Can anyone please help me understand how to set up the firewall to allow a specific domain(www.google.com) and block all other domains?
[N.B.: I understand one way of achieving this is by finding out all the I.P. address(es) related to the domain and adding them to alias, but it is common for websites to use CDN services that don’t use anycast routing. In this case, the dns resolver can provide an I.P. address that is not present in the list, and this may block the traffic, even if the domain is allowed]
You can create alias with host type and under the hosts, you can add the FQDN such as www.google.com
Now, you can use this alias to create rule to allow traffic to this alias.
Reference : Firewall — Aliases | pfSense Documentation (netgate.com)
Related
i have windows server 2019 with iis 10 installed, ip and domain restriction enabled ip range 10.0.0.1=>10.0.0.240 - domain name : lo-server.com
the problem that am facing is : when adding a local ip address / Same ip with server / same network / example 10.0.0.66 to deny list it works perfectly it deny the access
but when i add an ip address outside the network / 192.168.20.10 / which is connected to a firewall ( FortiGate ) 10.0.0.200 the restriction doesn't work i need to add the firewall ip to deny it which i don't want to do it because i'll block all the ranges that are connected to the firewall.
how can i deny access to another network without adding the firewall
Microsoft considered the simplest case for you and implemented the so called Proxy mode, which you might try out,
https://learn.microsoft.com/en-us/iis/get-started/whats-new-in-iis-8/iis-80-dynamic-ip-address-restrictions#configuring-iis-for-proxy-mode
Deep down inside it checks x-forwarded-for header to see whether the incoming HTTP requests are through a proxy (the firewall in your case) and then apply the rules to decide whether to deny any request.
However, a real world proxy can manipulate the incoming requests in too many ways, so the proxy mode might fail you and you will have to switch to something like URL Rewrite module and write a more complicated rule to abort the desired requests.
You can use the IP Address and Domain Restrictions feature page to define and manage rules that allow or deny access to content for a specific IP address, a range of IP addresses, or a domain name or names.
Opens the Add Deny Restriction Rule dialog box from which you can define rules that allow access to content for a specific IP address, a range of IP addresses, or a DNS domain name.
More information you can refer to this link: IP Address and Domain Restrictions.
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 need to prevent users from accessing the site through the External IP Address on Compute Engine, they should can access site only via domain name (www.some-domain.com), not the IP Address itself.
Let says the instance's IP Address of the Compute Engine is A.A.A.A. I am using Load Balancer to redirect it to secure connection, with these settings:
Frontend
HTTP : B.B.B.B:80
HTTPS : B.B.B.B:443
Backend
Redirected to the active instance
And I pointing the DNS (A) to B.B.B.B.
Now, I am able to access https://www.some-domain.com. But the problem is, I still can access the site with A.A.A.A and B.B.B.B.
This is my current firewall configuration:
How to prevent this? Thanks.
Well, there are a couple of things you can do:
1- Remove External IP from VM instance
2-Create specific firewall rule to only allow access to an specific subnet range
Let me elaborate:
For 1:
Using web console, You only need to edit the VM details, go to network interfaces settings and choose none over External IP drop menu, save the new configuration. All of this can be done without stop the VM instance.
For 2:
Create a couple of firewall rules with the same configuration from default-allow-http and default-allow-https, but at "Filter" you need to specify the "public" subnet range you want to allow (your data center range for example). These new firewall rules must have a lower value at priority to have more preference over the existing ones. Once you validate is working properly you can delete the old ones Video GCP Firewall.
I hope that helps, if you need more assistance just write me a comment
Your problem is very similar to configuring the Google Identity Aware Proxy, which is part of the Google Beyond Corp architecture and, providing your users have Google IDs is very effective.
The docs explain the process for setting up the IAP but it also helps explain how to configure the moving parts. You need to:
Set your A record on your DNS to the public front-end of your load balancer
Configure your firewall rule on your GCE instance to not permit any traffic from the Internet, but only allow from the load balancer. The load balancer has a helpful graphic to show the rules.
Configure your load balancer back end to direct traffic from your front-end to the GCE instance. I have TLS over the internet to the LB and then HTTP from the LB to my instance but you don't have to
Your load balancer will then take the HTTP/S traffic and forward to the back end using the forwarding rule that you set up when configuring it. If you try to go to the instance IP directly then the firewall will block you, for testing you can enable an allow from your client IP and then you will see that you don't get the headers
here's how I fixed this issue:
In your GCP Account.
Go to VPC Networks then to Firewall rules
You need to create 2 Firewall rules:
1) Allow all traffic coming from google health checks and your own load balancer.
Priority: 500
Direction: Ingress
Action on match: Allow
Target tags:if you want to apply this rule only to 1 instance, then, open the VM Instance, edit it, create the specific network target tag, save it and then, add it here.
IP ranges: 35.191.0.0/16 and 130.211.0.0/22 https://cloud.google.com/load-balancing/docs/https#source_ip_addresses
2) Deny all traffic.
Priority: 900
Direction: Ingress
Action on match: Deny
Target tags: put here the same network target tag(s).
IP ranges: 0.0.0.0/0
That's it. If you put the IP of the VM Instance in the your browser, it will fail. The access will be forced through the Load Balancer.
In the GCP project menu
We are planning to use cloudfront distribution for our main domain and the setup will be as follows.
Cloudfront Origin - route.domain.com -> Remote Server IP address(xx.xx.xx.xx)
www.domain.com, domain.com -> d123.cloudfront.com
As we know, we can setup CNAME for www.domain.com to point to cloudfront distribution(d123.cloudfront.net). However, for domain.com we should point A record to IP address and its not possible to setup CNAME record.
In route53, there is an option called Alias which can be used to point the domain to Cloudfront. But, our domain.com nameserver uses different provider and we would like to stick with current nameserver.
Any help would be appreciated.
Since this is a limitation in DNS itself, there is no way to accomplish this without a DNS hosting provider that supports an alias-like feature, sometimes called an "ANAME" or "flattened CNAME". Route 53 is of course the canonical example. CloudFlare and DNS Made Easy are others.
Or use a service like this one¹ to redirect your naked domain name to the www address, which would be your "real" site. They give you a single IP address for your A record. Note that your current DNS provider may have a "redirection" option that does this. It is not properly a part of DNS, but some providers allow you to configure domain redirections in their DNS portal.
Or migrate your DNS hosting to Route 53, keeping your DNS registration with your current vendor. In my mind, there is really no compelling reason not to use Route 53. See Making Route 53 the DNS Service for a Domain That's in Use for migrating to Route 53 without disruption, noting that the final step -- Transfer Domain Registration to Amazon Route 53 -- is entirely optional, as mentioned in the docs.
¹ this one is not a service I am affiliated with or have ever used in production, because I built my own service for that purpose using EC2, which is another option but outside the scope of this answer. This is intended as an example, not an endorsement.
My client have a dedicated server on liquedweb cloud service and we my web app is hosted on that server. We want our users to map their domain to our server. So they can enjoy our web app by using their domain name. What information I need to provide to my user so he can map domain and what information I need from them?
I don't know much(in fact anything) about domain mapping
thanks
It depends if the server has a dedicated IP address or is natted.
If the server has a dedicated IP address you can ask your clients to point their entire domain to you server by adding the following A records:
Host TTL Protocol Type IP Address
# 300 IN A 1.1.1.1
www 300 IN A 1.1.1.1
Not all domain hosts ask for TTL,if not dont worry about it.
If you want just their subdomain to point to your server (subdomain.website.com)
subdomain IN A 0.0.0.1
TTL is optional in some systems, in this case the default will be used.
Generally it is recommended that you use an IP for the Apex record and not a domain name. EG: example.com is the apex, www.example.com is the www subdomain.
A typical configuration would be below:
Host TTL Protocol Type Result
# 300 IN A 1.1.1.1
www 300 IN CNAME example.com
This is the same config as the top example but using CNAME example.com. It is the same as using A 1.1.1.1, it just means you only need to change one record.
If your server details are a hostname and not an IP address, most systems will not let you use the hostname for the apex so you will need to find out the IP address. (A simple method is to use the nslookup command or dig command).
TTL is how long in seconds a record last before it expires. If you are unsure what you are doing I recommend lowering this so you can correct mistakes more quickly.
Different methods for the different servers. For most of the servers, you have to change the nameservers of your domain.
This mostly needs when your domain registrar and hosting provider both are different.
First Login into your hosting account, navigate to the account details,
then copy the nameservers from there...which would be like :- dns1.hostingprovider.com
dns2.hostingprovider.com
After that, Go to control panel of your domain. Navigate to the nameservers
You will see the link:- dns1.domainregistrar.com
dns2.domainregistrar.com
Paste the above links at the place of below links.
They need the IP address (and possibly instructions on how to configure their DNS servers (which means a variety of different sets of instructions for different servers and control panels)).
You need the domain name.