Traefik ECS provider is not forwarding client IP with AWS ALB - traefik

I'm trying to fix this issue for the past 2 days but I don't know how to resolve it. I wanted to capture the client IP on the application with traefik proxy.
Setup:
R53 --> ALB --> (Traefik proxy --> applocation) ECS
I'm running my application on ECS and leveraging ECS provider.
What I have tried :
Adding the below labels to the traefik as per the documents:
--entrypoints.http.forwardedheaders.trustedips=0.0.0.0/0
--entrypoints.https.forwardedheaders.trustedips=0.0.0.0/0
--entrypoints.http.forwardedheaders.insecure=true
--entrypoints.https.forwardedheaders.insecure=true
Tried all of them together and individually also but every time I add these configurations traefik stopped working without any useful logs.
What I observed:
Without adding any of these configurations if I hit the trafik IP directly by skipping the Loadbalancer I can see My IP (client-IP). does it mean i need to make changes in the AWS-ALB ?
Through LB:
Upgrade-Insecure-Requests: 1
X-Amzn-Trace-Id: Root=1-620e68b5-121181407c9ceadf6c8f0a25
X-Forwarded-For: 172.31.22.81
X-Forwarded-Host: infra.**********.nl
X-Forwarded-Port: 80
X-Forwarded-Proto: http
X-Forwarded-Server: ip-172-31-8-140.eu-central-1.compute.internal
X-Real-Ip: 172.31.22.81
Directly IP HIT:
Accept-Language: en-GB,en-US;q=0.9,en;q=0.8
Upgrade-Insecure-Requests: 1
X-Forwarded-For: 80.***.***.61
X-Forwarded-Host: 3.71.93.123
X-Forwarded-Port: 80
X-Forwarded-Proto: http
X-Forwarded-Server: ip-172-31-8-140.eu-central-1.compute.internal
X-Real-Ip: 80.***.***.61

Finally, I have found a way to do achieve this after reading tons of documents and testing.
This is for ECS provider:
Task definitions :
Traefik
"traefik",
"--providers.ecs.clusters=application",
"--log.level=DEBUG",
"--providers.ecs.region=us-west-2",
"--api.insecure",
"--entryPoints.web.address=:80",
"--entryPoints.web.proxyProtocol.trustedIPs=127.0.0.1/32,<VPC-CIDR>",
"--entryPoints.web.forwardedHeaders.trustedIPs=127.0.0.1/32,<VPC-CIDR>",
application:
"traefik.http.routers.app.rule": "pathprefix(`/`)",
"traefik.enable": "true",
"traefik.http.services.service-app-app.loadbalancer.healthcheck.timeout": "10",
"traefik.http.services.service-app-app.loadbalancer.sticky.cookie": "true",
"traefik.http.services.service-app-app.loadbalancer.healthcheck.port": "8080",
"traefik.http.services.service-app-app.loadbalancer.healthcheck.interval": "30",
"traefik.http.services.service-app-app.loadbalancer.healthcheck.path": "/ping",
"traefik.http.services.service-app-app.loadbalancer.sticky.cookie.name": "app-cookie"
With Who-ami container:
Hostname: ip-172-31-29-79.us-east-2.compute.internal
IP: 127.0.0.1
GET / HTTP/1.1
Accept-Encoding: gzip, deflate
Accept-Language: en-GB,en-US;q=0.9,en;q=0.8
Upgrade-Insecure-Requests: 1
X-Amzn-Trace-Id: Root=1-623af218-525fa18d4d17e1ef431bb2b9
X-Forwarded-For: 8*******5, 172.31.12.125
X-Forwarded-Host: ecs-*****.us-east-2.elb.amazonaws.com
X-Forwarded-Port: 80
X-Forwarded-Proto: http
X-Forwarded-Server: ip-172-31-15-101.us-east-2.compute.internal
X-Real-Ip: <loadbalancer-IP>
This PR gives a good overview of how the forward header works
https://github.com/traefik/traefik/pull/7875/files
How it works:
X-Forwarded-For: <client_ip>, <alb_ip>
X-Real-Ip: <alb_ip>

Related

Postman connect ECONNREFUSED 127.0.0.1:8080

Trying to test an API endpoint and got this error. Could it be my request body? Or is it a network issue? Maybe something I need to change in my proxy settings?
POST http://localhost:8080/v1/collections
Error: connect ECONNREFUSED 127.0.0.1:8080
Proxy
authenticate: false
disabled: false
host: "127.0.0.1"
id: "smth"
match: {…}
port: 8080
tunnel: false
Request Headers
Test: check-headers
x-ads-token-data: {stuff}
x-ads-gateway-secret: test1
Content-Type: application/json
User-Agent: PostmanRuntime/7.26.5
Accept: */*
Postman-Token: xxxx
Host: localhost:8080
Accept-Encoding: gzip, deflate, br
Connection: keep-alive
econnrefused means most probably you have not started your server on port 8080.
Take a look at the nodejs documentation here
ECONNREFUSED (Connection refused): No connection could be made because the target machine actively refused it. This usually results from trying to connect to a service that is inactive on the foreign host.
I am new to doing REST API and was trying to do Post request. I got this error when I was using Postman and c#
POST https://localhost:44310/api/Books
Error: connect ECONNREFUSED 127.0.0.1:44310
Request Headers
Content-Type: application/json
User-Agent: PostmanRuntime/7.28.4
Accept: */*
Host: localhost:44310
Accept-Encoding: gzip, deflate, br
Connection: keep-alive
Request Body
{
"Id": 1,
"Title": "Harry Potter",
"Author": "J.K. Rowling",
"Pages": 500
}
what happened was that the program was not running in visual studio but after executing it, the error did not appear again.
Hope my response will be useful.
I got the same issue and looks like clearing the breakpoints and setting the same again fixed the issue.
I was also suffering from the same problem. At that point in time, my local server was not published.
So I simply ran my backend server on IntelliJ IDEA.
Then try to post the request.
It works for me.
So, according to my experience, I would like to suggest that,
Before posting or getting any request you have to confirm that your local server is running properly.
I had the same problem and solved it by defining the "Edit / run configuration dialog" in IntelliJ

Tomcat 9 with Apache 2.4 Proxy: 408 after correct login

I'm running Apache 2.4 as Reverse Proxy in front of Tomcat 9 on Ubuntu 18.04.
The Tomcat application is deployed in /apachetest and is using form-based authentification.
When calling "http://10.10.50.20/apachetest" (without proxy)
the login-page is comming up
I put in the credentials
and than "index.html" is delivered
So far ...
On Apache I have configured a virtual host for ssl:
ProxyPass / http://localhost:8087/apachetest/
ProxyPassReverse / http://localhost:8087/apachetest/
ProxyPassReverseCookiePath / /apachetest
when calling https://apachetest.localdomain/
- the login-page is comming up
- I put in the credentials
- and than I receive "HTTP Status 408 – Request Timeout" from Tomcat
By using the developer tools of Chrome I can see the following header for request "j_security_check"
General:
- Request URL: https://apachetest.localdomain/j_security_check
- Request Method: POST
- Status Code: 408
- Remote Address: 10.10.50.20:443
- Referrer Policy: no-referrer-when-downgrade
Response Header
Connection: close
- Content-Language: de
- Content-Length: 1239
- Content-Type: text/html;charset=utf-8
- Date: Mon, 09 Dec 2019 10:36:28 GMT
- Server: Apache/2.4.29 (Ubuntu)
- X-Content-Type-Options: nosniff
- X-Frame-Options: DENY
Request Header:
-Accept:text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,/;q=0.8,application/signed-exchange;v=b3
- Accept-Encoding: gzip, deflate, br
- Accept-Language: de-DE,de;q=0.9,en-US;q=0.8,en;q=0.7
- Cache-Control: max-age=0
- Connection: keep-alive
- Content-Length: 43
- Content-Type: application/x-www-form-urlencoded
- Cookie: JSESSIONID=B859EE1F208D4D1C26C7B5714A41B03D
- Host: apachetest.localdomain
- Origin: https://apachetest.localdomain
- Referer: https://apachetest.localdomain/
- Sec-Fetch-Mode: navigate
- Sec-Fetch-Site: same-origin
- Upgrade-Insecure-Requests: 1
- User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/78.0.3904.108 Safari/537.36
Thank you for your interest in my question.
ok, I will try again.
I'm looking for a configuration to have a Tomcat Web-Application running behind an Apache Reverse Proxy.
The Tomcat Web-Application have a form-based authentification implemented.
By calling the Tomcat Web-Application, through proxy, I get the expected login-page.
But after putting in the right credentials and submit, I receive the following message:
"HTTP Status 408 – Request Timeout".
The expected site "index.html" is not provided.

aws api gateway client certificate: certificate is empty

We are using aws api gateway to call our backend api. We used aws generated client cert to call end point (.net web api).
But each time the request comes in, I did not see any cert in the raw data. below is the raw data:
GET /rest/test
x-amzn-apigateway-api-id: xxxxxxxx
x-api-key: xxxxxxx
User-Agent: curl/7.53.1
X-Forwarded-Proto: https
X-Forwarded-For: 24.16.156.224
X-Forwarded-Port: 443
X-Amzn-Trace-Id: Root=1-5a6a4c29-07091e853bae0bbd7f7db3b3
accept: */*
Host: 185b5418.ngrok.io
X-Forwarded-Proto: https
X-Forwarded-For: 52.42.18.220

getting wss working with stunnel & ratchet

Running Apache v2.4, PHP v5.6 w/ php-fpm, on CentOS 7
So I'm trying to get wss working with stunnel & Ratchet. I've got Ratchet's Hello World (http://socketo.me/docs/hello-world) working successfully with the test code on non-ssl at port 8080. I can telnet from the same machine, as well as telnet from a a different machine.
Through reading, I know that ratchet doesn't support ssl connections, but does by wrapping the communications with stunnel, so I setup stunnel with an appropriate cert listening on port 8443, which appears to be working (as evidenced by the log file).
When I try to make a connection using wss from Firefox's scratchpad, I get the following error: Firefox can't establish a connection to the server at wss://testserver.testdomain.com:8443 I can see the connection being created through the various log files, however somewhere along the line communications is failing since I can't create a solid wss connection. Any ideas on what I'm missing or where I'm screwing up? Log/code below
Scratchpad Code
var conn = new WebSocket('wss://testserver.testdomain.com:8443');
conn.onopen = function(e) {
console.log("Connection established!");
};
conn.onmessage = function(e) {
console.log(e.data);
};
Stunnel config:
cert = /etc/httpd/ssl/ov_wildcard.pem
[hublistener]
accept = 8443
connect = 8080
Stunnel log:
2016.05.11 14:43:28 LOG5[38759:140614807435328]: stunnel 4.56 on x86_64-redhat-linux-gnu platform
2016.05.11 14:43:28 LOG5[38759:140614807435328]: Compiled/running with OpenSSL 1.0.1e-fips 11 Feb 2013
2016.05.11 14:43:28 LOG5[38759:140614807435328]: Threading:PTHREAD Sockets:POLL,IPv6 SSL:ENGINE,OCSP,FIPS Auth:LIBWRAP
2016.05.11 14:43:28 LOG5[38759:140614807435328]: Reading configuration from file /etc/stunnel/stunnel.conf
2016.05.11 14:43:28 LOG5[38759:140614807435328]: FIPS mode is enabled
2016.05.11 14:43:28 LOG4[38759:140614807435328]: Insecure file permissions on /etc/httpd/ssl/cert.pem
2016.05.11 14:43:28 LOG5[38759:140614807435328]: Configuration successful
2016.05.11 14:45:59 LOG5[38765:140614807430912]: Service [hublistener] accepted connection from ***.***.***.***:39124
2016.05.11 14:45:59 LOG5[38765:140614807430912]: connect_blocking: connected 127.0.0.1:8080
2016.05.11 14:45:59 LOG5[38765:140614807430912]: Service [hublistener] connected remote server from 127.0.0.1:59795
Ratchet sample output:
[zxurian#ariel dev-hub]$ php module/HubListener/websocket.php
New Connection! (307)
New Connection! (317)
Connection 317 sending message "second window line 1
" to 1 other connection
Connection 317 sending message "second window line 2
" to 1 other connection
New Connection! (318)
Connection 318 sending message "GET / HTTP/1.1
Host: testserver.testdomain.com:8443
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:46.0) Gecko/20100101 Firefox/46.0 FirePHP/0.7.4
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
Sec-WebSocket-Version: 13
Origin: https://testserver.testdomain.com
Sec-WebSocket-Extensions: permessage-deflate
Sec-WebSocket-Key: PrWlBjR2q6a0syT4oplnAQ==
Cookie: PHPSESSID=ci7102qouvqprhdpk483hv6ar3; exclusive_offers_popup=1; __utma=213556497.27501638.1462814210.1462827970.1462831402.3; __utmc=213556497; __utmz=213556497.1462814210.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none); __utmv=213556497.|1=l=%2F=1
x-insight: activate
Connection: keep-alive, Upgrade
Pragma: no-cache
Cache-Control: no-cache
Upgrade: websocket
" to 2 other connections
Telnet Connection 1
[zxurian#ariel ~]$ telnet 127.0.0.1 8080
Trying 127.0.0.1...
Connected to 127.0.0.1.
Escape character is '^]'.
second window line 1
second window line 2
GET / HTTP/1.1
Host: testserver.testdomain.com:8443
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:46.0) Gecko/20100101 Firefox/46.0 FirePHP/0.7.4
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
Sec-WebSocket-Version: 13
Origin: https://testserver.testdomain.com
Sec-WebSocket-Extensions: permessage-deflate
Sec-WebSocket-Key: PrWlBjR2q6a0syT4oplnAQ==
Cookie: PHPSESSID=ci7102qouvqprhdpk483hv6ar3; exclusive_offers_popup=1; __utma=213556497.27501638.1462814210.1462827970.1462831402.3; __utmc=213556497; __utmz=213556497.1462814210.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none); __utmv=213556497.|1=l=%2F=1
x-insight: activate
Connection: keep-alive, Upgrade
Pragma: no-cache
Cache-Control: no-cache
Upgrade: websocket
I have a Ratchet WebSocket running on my own machine and am also using Apache2.4
To make it work over SSL I did:
Proxy pass the socket
inside (/etc/apache2/)apache2.conf I added
//added for the websocket over SSL
ProxyPass /wss/ ws://alpha.example.com:8080/
this passes my websocket running on port 8080 to wss://alpha.example.com/wss/
to make sure your stunnel config is correct, this is what I did
inside of (/etc/stunnel/)stunnel.conf
cert = /etc/letsencrypt/live/www.example.com/cert.pem
key = /etc/letsencrypt/live/www.example.com/privkey.pem
[wss]
accept = 8082
connect = 8080
REMINDER: change the paths to the keys I used to thee paths your keys are using.
inside the PHP file that starts my server I user port 8080 as in the ratchet example
$webSock->listen(8080, '0.0.0.0'); // Binding to 0.0.0.0 means remotes can connect

Configuring Burp Suite to intercept data between web browser and proxy server

I need to configure Burp Suite to intercept data between web browser and proxy server. The proxy server requires a basic authentication (Username & Password) while connecting for the first time in each session. I have tried the 'Redirect to host' option in Burp Suite(Entered the proxy server address and port in the fields):
Proxy >> Options >> Proxy Listeners >> Request Handling
But I can't see an option to use the authentication that is required while connecting to this proxy server.
While accessing google.com, the request headers are:
GET / HTTP/1.1
Host: google.com
User-Agent: Mozilla/5.0 (X11; Linux i686) KHTML/4.13.3 (like Gecko) Konqueror/4.13
Accept: text/html, text/*;q=0.9, image/jpeg;q=0.9, image/png;q=0.9, image/*;q=0.9, */*;q=0.8
Accept-Encoding: gzip, deflate, x-gzip, x-deflate
Accept-Charset: utf-8,*;q=0.5
Accept-Language: en-US,en;q=0.9
Connection: close
And the response is:
HTTP/1.1 400 Bad Request
Server: squid/3.3.8
Mime-Version: 1.0
Date: Thu, 10 Mar 2016 15:14:12 GMT
Content-Type: text/html
Content-Length: 3163
X-Squid-Error: ERR_INVALID_URL 0
Vary: Accept-Language
Content-Language: en
X-Cache: MISS from proxy.abc.in
X-Cache-Lookup: NONE from proxy.abc.in:3343
Via: 1.1 proxy.abc.in (squid/3.3.8)
Connection: close
you were on the right track, just at the wrong place. You need to setup an upstream proxy at:
Options>>Connections>>Upstream proxy
There you can also setup the authentication
Options>>Connections>>Platform authentication
Here you can create different auth configurations, which will be done if the server requests it.