I am using Solr 4.8.X and need help getting around https://issues.apache.org/jira/browse/SOLR-4470
(Basic HTTP auth for SolrCloud nodes)
Is there a way to white-list certain ip addresses in Jetty 8/Solr so that they do not require basic http authentication? I have setup an auth-constraint under security-constraint in webdefault.xml, but that affects all users irregardless of IP address.
I would like to set it up so that the IP addresses of other Solr nodes do not have to go through basic http authentication while every other ip address does.
Thanks!
Related
I have read a lot on GCP's Firewall rules and even got help from a dev-ops person who could not understand why these rules block my home IP from my App Engine Standard F1 instance.
Priority T Action IP range
2000 Allow XX.X.XX.XXX
2001 Allow xxxx:xxxx:xxxx:xxx:xxxx:xxxx:xxxx:xxxx // my V6 IP
default Deny *
When adding the V6 IP
I am allowed access but with strange errors, eg. refreshing the page shows a path error: But browsing there (or to any path) loads just fine.
Error: Not Found
The requested URL /feed was not found on this server.
Without the V6 IP (and only the V4 IP allow rule) I cannot access the instance.
How can I whitelist my own IP for access?
As reviewed in the comments, from the test I've made, I can confirm that connections are preferred to be done over IPv6 rather than IPv4.
As pointed out by this answer:
The first thing that a client determines is which protocols are available. ...It will then do a DNS lookup for both the A (IPv4 address) and AAAA (IPv6 address) records. If only one type is returned then it will use that. If both IPv4 and IPv6 addresses are returned the default behaviour depends a bit on the client software. Usually RFC 3484 is used.
According to the official standards it should prefer IPv6...
You can confirm this behaviour by checking into the logs the IP address that reaches the service of which you are testing the firewall rules (eg. default service); service, using the Logs Viewer.
Look up for a Log entry that matches a request you made (eg. to the /
root directory).
To show the latest logs, click Jump to now.
Under httpRequest on the field remoteIp you could check the IP address that your machine is using to access App Engine.
In order to do this, delete the rules you've created and change the default rule to Allow.
Below is my scenario:
I am calling API Management from Logic APP.
I want to restrict IP Address so that only Logic App can call the API Management.
I am using the IP Filter as shown below for the IP Address mentioned here
<ip-filter action="allow | forbid">
<address>40.112.243.160</address>
<address>address</address>
</ip-filter>
But I am not able to figure out the IP Address that's coming in to API Management. Its different than the list of IP Address provided in this link. It starts with 10...*.
Am I missing anything here?
As far as I know, there is a list of outbound IP addresses for Azure Logic App per region. For more details, you can refer to the doc. If you want to avoid other users with the Logic App in the same region to have access to your resource or get a static single IP address, you can further use Azure API Management to act as a reverse proxy for the Logic App. And then use the policy in the APIM as below:
<ip-filter action="allow | forbid">
<address>address</address>
<address-range from="address" to="address" />
</ip-filter>
All logic apps in a region use the same ranges of IP addresses. To support the calls that logic apps directly make with HTTP, HTTP + Swagger, and other HTTP requests, set up your firewall configurations in your APIM so they include these outbound addresses, based on where your logic apps exist:
Here is the list of IP address of Logic App based on the region.
You could use the ip-filter policy filters (allows/denies) calls from specific IP addresses and/or address ranges in your APIM.
Policy statement
<ip-filter action="allow | forbid">
<address>address</address>
<address-range from="address" to="address" />
</ip-filter>
You could get your logic app ip address from this link. Then you could set APIM like:
<ip-filter action="allow">
<address>address1</address>
<address>address2</address>
<address>address3</address>
</ip-filter>
Update:
But I am not able to figure out the IP Address that's coming in to API Management. Its different than the list of IP Address provided in this link.
When you use logic app to call APIM, you could see the X-Forwarded-For attribute in output which is a common method for identifying the originating IP address of a client connecting to a web server through an HTTP proxy or load balancer.
Here is my test snapshot. My logic app location is eastasia and my IP address is 13.75.94.173 which is inside the East Asia Outbound IP of Logic App.
I'm using Nginx as a proxy to filter requests for my AppEngine Java application. GAE's location services (X-AppEngine-country header) works great without the proxy, but now GAE is using the proxy server's IP as client IP, and the X-AppEngine-country header is quite useless - it returns "ZZ" as the country code.
I know that the header is determined by the client IP, as mentioned here:
"X-AppEngine-Country -
Country from which the request originated, as an ISO 3166-1 alpha-2 country code. App Engine determines this code from the client's IP address. "
The problem is that I don't know from what data this header is derived. I used Nginx modules to set the client IP in X-Forwarded-For, Remote_Addr and Http_Client_IP headers, but apparently the X-AppEngine-country header is derived from somewhere else.
How can I provide GAE the client IP so it can retrieve the correct country code from the original IP?
You already provided all the info needed for the answer: "..App Engine determines this code from the client's IP address". So they actually look at an IP from where the connection was made.
Since your proxy sits between the client and AppEngine, AppEngine sees connections coming from proxy IP. No way around it.
I'm working with a third party webservice who requires that all calls to their service are made from whitelisted IP addresses. That is, I must give them IP addresses from which I will be making calls to their service.
Problem is I'm using Google Appengine. Is there any way to get a static IP address when making outgoing http requests from Appengine? Failing that - is there a block of IP addresses that all requests will come from? I could get the entire bloc whitelisted. If this exists, how likely is it to change?
I know I could setup a simple Amazon EC2 instance to use as a proxy (will ask another question for how to do this specifically) but just wanted to make sure there was no other way.
I had the same problem a couple of weeks ago connecting via Urlfetch from Google App Engine to the Stack Exchange API (The team has promptly fixed the problem whitelisting all the GAE IPs).
The range of IP addresses that urlfetch connections may come from, can be found by performing the following DNS lookup:
dig -t TXT _netblocks.google.com #ns1.google.com
Last I checked this wasn't possible. You can get the current IP address dynamically, but it isn't predictable.
Please note: _netblocks.google.com is apparently not accurate. Currently I have noticed that GAE connects from addresses not listed when you dig _netblocks, for example from 8.35.201.166.
This range is not listed in _netblocks, _netblocks2 or _netblocks3.
Current dig output:
ip4:216.239.32.0/19
ip4:64.233.160.0/19
ip4:66.249.80.0/20
ip4:72.14.192.0/18
ip4:209.85.128.0/17
ip4:66.102.0.0/20
ip4:74.125.0.0/16
ip4:64.18.0.0/20
ip4:207.126.144.0/20
ip4:173.194.0.0/16
I am using Nokogiri to screen scrape a few websites.
My website is hosted on US servers, and so when it fetches the website, the website responses as if the user was a US user. I need the website to responds as if I was an Australian user, even though the server is located in the US.
When running locally it works fine because locally it responds as if it was Australian.
How can I read the site using Nokogiri as if I was from another country?
You have to run your requests through a proxy in Australia.
This doesn't have anything to do with Nokogiri - it applies no matter how you're trying to scrape a page. HTTP travels over TCP, which is a bi-directional protocol so you can't spoof its IP address. If you tried to spoof the IP address of a TCP packet, you would never get your response back.
You can configure Tor to always use exit nodes from a specific country. Please, however, do not use this method if this will put the Tor network under some serious strain (i.e. fetching the pages continually); in this case please consider buying an (Austrlia-based) annonimizing service (or simply a proxy).