I'm in an awkward position where I need all outbound requests from applications running in IIS that are connecting to 1.1.1.1 to be redirected to request from 2.2.2.2 instead.
I can't change the connections strings in the application themselves so it will need to be some rule added to IIS or the windows environment itself, is this possible?
Related
I have a handler deployed on IIS which proxies communication to specific URLs. I need to specify IP address for outbound communication called from this handler different than IP address for general communication from server.
I can isolate those handler to different IIS site if needed.
Currently, I'm redirecting requests for this handler to different server via ARR and URLRewrite, but I'd like to avoid this.
On linux, there is solution to use SRC-NAT rule for specific user, if process was owned by this user (https://serverfault.com/questions/236721/bind-process-or-user-to-specific-ip-linux).
EDIT: If handler was isolated to different site, this site also can be run in different application pool and/or different identity.
Thanks for any advice.
I am trying to see if it's possible to route user requests to serverA or serverB based on their IP address or Host Name.
Currently users are accessing an application via URL, https://thisismyprodserver:9999
let's call this serverA and now the business want to set up a serverB and deploy the new code here. They then want to filter some of the users to use serverB for testing but without them knowing any difference as they are still access their application using the same URL. The don't want the user to see any difference on the front end. Once a small number of users have tested the updated application on serverB they will then route all remaining users over to serverB which will now become production.
I was hoping the Datapower could step in and route the request to either serverA or serverB based on the incoming users IP address.
The current flow is USER Request <->WebServer <->AppServer
I was wondering if the Datapower could step in and change the flow to
USER Request ->WebServer -> IDG -> ServerA
-> ServerB
Application is running in WAS v9 and the Webserver is Apache 2.4
I am also looking to see if this can be done via the WebServer but would like to integrate the IDG into the application.
Your question is a bit unclear but the best option is of course to do this in a load-balancer using a pool with rules to direct different IP's to different endpoints.
If you have the TLS/SSL certificate on the instance they "hit" you can't "forward" the connection in anyway so in that case your only option is to either use the second instance as a "back-end" service and the first as "proxy" or to use a url-open to grab data from the second and return to the first.
You can also return a 301 redirect but there are a lot of services/software that doesn't like that in an API/Service implementation.
Neither of these two options does what you strive for though as there is no clear path into the final migration to the second box as you seek.
A better approach for it is to add a "proxy service", e.g. a MPGW, which routes to the service either on 127.0.0.1:xxxx or to the other box depending on the request source IP.
That way you can have identical services on both boxes and the request always hits the same "proxy" service. This is also know as "chained services" in DataPower lingo...
I made a proxy server in python 3. It listens on the port 4444. It basically receives the request from clients and sends it to the server. I want to use it as a firewall to my Dvwa server. So added another functionality to the proxy. What it does is, before sending the request to the DVWA server, it validates the input.
But the problem is, the clients have to configure their proxy settings in the browser to use my proxy server. Is there any way to access the proxy without configuring the browser settings. Basically I want to host the proxy server instead of the original web server. So that all the traffic goes through the proxy before going to the webserver.
Thanks in advance...
You don't say whether your Python3 proxy is hosted on the same machine as the DVWA.
Assuming it is, the solution is simple: a reverse-proxy configuration. Your proxy transparently accepts and forwards requests to your server who then processes them and sends them back via the proxy to the client.
Have your proxy listen on port 80
Have the DVWA listen on a port other than 80 so it's not clashing (e.g. 8080)
Your proxy, which is now receiving requests for the IP/hostname which would otherwise go to the DVWA, then forwards them as usual.
The client/web browser is none the wiser that anything has changed. No settings need changing.
That's the best case scenario, given the information provided in your question. Unfortunately, I can't give any alternative solutions without knowing the network layout, where the machines reside, and the intent of the project. Some things to consider:
do you have a proper separation of concerns for this middleware you're building?
what is the purpose of the proxy?
is it for debugging/observing traffic?
are you actually trying to build a Web Application Firewall?
In our application's Production environment, when we call the Navigate operation on our C# WebBrowser control, we POST the authentication details and a redirect URL first to an authentication server. This server authenticates and sends back a HTTP 302 response which prompts the WebBrowser control to redirect to another server. Because of a change in the IP address by the time the redirect is performed, a fingerprint monitor masking the target url sends us a challenge. We then forward the cookies and what not that we received from the authentication server.
Now, the problem is, when we debug this in our non-prod environment, because the client IP remains unchanged, there is no challenge issued by the monitor and we are not able to test out our changes which ensure all the right authenticatoin information is forwarded from the earlier Authentication Server's response.
Is it possible to do this sort of client ip address spoofing in between redirects in order to allow us to test our code? I was using Fiddler for this and as far as I can see, there are no properties which can be modified. the Session variable "x-clientip" is a readonly variable.
How does your server determine the IP address of the client? If it looks at, for instance, an X-Forwarded-For request header, Fiddler can easily change that.
If not, no, Fiddler does not itself have some magical way to make traffic originate from a different IP address. If your machine has multiple NICs, Fiddler can direct the second request to egress via a specific IP address using the X-EgreesIP. Or you can have Fiddler direct a given request through a different proxy (say, another Fiddler instance) running on a different machine that has a different IP address; use the X-OverrideGateway flag to do that.
I have a Play! Application which needs to use HTTP and HTTPS. The application is running behind a proxy server (using Apache) that forwards web requests to the play application.
The proxy is using one port for HTTP requests, and another port that is intended for HTTPs requests. Note that the ports on the proxy are not the same ports as the ones used by the Play application (this is due to provider restrictions!).
The Play application is using the "standard" ports 9000 for HTTP and 9443 for HTTPs. The proxy receives HTTP requests on Port 8080 and forwards them to Play's port 9000. The proxy receives HTTPs requests on Port 8090 and forwards them to Play's port 9443.
My problem is that when I use the secure() method of making pages appear in Play, Play's logic causes the app to attempt to use 9443 as the port for HTTPs. This causes the request to be lost because the proxy is using a different port.
The same appears to happen when I want to switch from HTTPs to HTTP. I cannot seem to make the system go to the port used by the proxy.
Somehow I need to make the system go to the ports known to the proxy server, without screwing up my routes. Is there some way to do this?
Thanks in advance for any help/insights.
I have found my own "answer", though it is somewhat of a cludge.
It turns out that, based on what I can ascertain from the documentation, there really is no way to tell Play to switch between ports when a Play application is behind a proxy. This is because while Play does recognize the port that a request comes in on, it has no way of telling what proxy port it should use when going between secure and unsecure ports. It knows, for example, that an HTTP request comes through a proxy port 8080, and it knows that subsequent requests to its port 9000 will come from that proxy port. What it does not know to do is to switch to another proxy port when someone attempts to use https to access its port 9443. Consequently, if you have a page like
http://toproxy:8080/links that has one or more links that use the secure() method to activate https, then Play will resolve the link to be https://toproxy:8080 -- despite the fact that the proxy server may want to use port 8090 for HTTPS requests. Because proxy port 8080 is redirected to Play's port 9000, use of that port for HTTPS requests always fails. This is true in Play 2.0 as well as Play 1.X.
I believe that Play needs some standard configuration parameter that can tell it to map proxy ports to its HTTP and HTTPS ports. That way, when it is behind a proxy server a developer can use the secure() method and Play will be able to resolve the URL to the correct proxy port. This capability should be available in 1.X as well as Version 2.
Until someone actually implements this (I might if I ever get the time, but with all that I am committed to do people shouldn't hold their breath), my cludge is to simply use the rediirect() method to switch between HTTP and HTTPS proxy ports. The redirect() method apparently allows us to enter full URLs, so I simply call the full URL of the page that I switch requests on.
For example: in the aforementioned page http://toproxy:8080/links, I may have a link to a login page that I want to protect using HTTPS. To do this I create two actions: one for the redirect to the proxy HTTPS port (for this example, call it gotoLogin()) and another for actually rendering the login page (for this example, call it loginPage() and give it a route of /loginpage).
In gotoLogin() I redirect to loginPage in the following manner:
redirect("https://toproxy:8090/loginpage");
This makes Play come in on proxy port 8090, which is redirected to Play's port 9443.
When the user properly logs in, my authentication action simply uses another redirect() call:
redirect("http://toproxy:8080/destination_page");
This causes Play to go back to the proper proxy port for unsecured requests.
This is not the best solution for this problem. There is a possibility that the proxy server can be somehow configured to make the proper switch between HTTP and HTTPS ports, but investigating this may take some time for someone not an expert in proxy server configuration (which describes me!). Of course, the best solution would be to implement in Play the kind of proxy port handling that I have previously described.
But this solution works and can be adapted to many different situations. Unless someone comes up with another better solution, this solution is the one I am using.
Play should recognise the port the request is coming from, and use that port. It is possible your apache config is not set up correctly.
Have you put the following line in your apache config?
ProxyPreserveHost on
You may also need XForwardedSupport=127.0.0.1 depending on your server configuration.