Let's assume I use IAP TCP forwarding for port 8080, which forwards port 8080 to my local workstation from the GCE VM. And let's assume that port is used for an HTTP connection.
Two questions:
will this setup suffer from the TCP meltdown?
I'm going back and forth on this one, so having a definitive answer from a GCP specialist would be great.
is the connection between IAP and VM encrypted in this specific case?
note that I'm not asking if the connection between my workstation and IAP is encrypted, I know it's, I'm asking about the "final" hop between the IAP and my VM.
at least based on the diagrams and documentation it should be automatically encrypted by GCP network BUT no "user" encryption (since HTTP)
related: would SSH (assuming OpenSSH) port forwarding of port 8080 over IAP SSH forwarding suffer from the TCP meltdown?
will this setup suffer from the TCP meltdown
IAP TCP forwarding doesn't use TCP-over-TCP. Instead, IAP TCP forwarding works on the application layer and encapsulates the HTTP/SSH/RDP/... data stream and forwards it over a WebSocket connection.
In your example, the protocol layers would be HTTP > IAP > WebSocket > HTTP > TLS > TCP > IP
is the connection between IAP and VM encrypted in this specific case?
See Encryption in Transit by Default: GFE to VM traffic is protected by Google Cloud's virtual network encryption.
Related
I have an app which uses a backend (REST webservice) on a public server. Currently I am using 8080 as the incoming port and asked myself if this is correct. In theory I could choose almost any port. Theoretically... But it is advisable to use a non-reserved port.
I once heard that calling a web service with an "exotic" port could be blocked in a public WLAN. Due to firewall/proxy rules. Could that really happen?
Would it make sense to use port 443 for the web service? (I use a SSL certificate on my backend)
This concept is pretty difficult to tackle, there are a lot of options when considering networked services. I'd advise against using a well known port for your web service in general, although in the case of REST there is a case to be made.
As you mentioned, obscure port numbers can be blocked inside certain networks by strict sys admins. Operating your service over TLS on port 443 is a secure and reliable way to access your api from within a network.
Being that REST is an http(s) api, and being that port 443 is designated for https traffic, using 443 for https-REST api seems appropriate.
TLDR; It's okay to use the well known http(s) ports, 80 and 443, for your REST api
I want to expose port 8888 on my AWS EC2 free-tier micro instance. Right now, my security group for the instance has this in bound protocol:
Custom TCP Rule TCP 8888 0.0.0.0/0 Jupyter Notebook
Once I set this up, if I go to the https://INSTANCE_PUBLIC_IP:8888/ I see a warning screen with
Your connection is not private
Attackers might be trying to steal your information from
INSTANCE_PUBLIC_IP (for example, passwords, messages, or credit cards).
Learn more
NET::ERR_CERT_AUTHORITY_INVALID
I click on advanced and then I can finally access the port. But my question is, how can I over come this so I don't ever see this screen (how do I get my SSL approved?). And I've also seen some folks expose a port (ex. 8888) and access it via http://INSTANCE_PUBLIC_IP:8888/ (note the http instead of https). How is this possible?
There's nothing wrong with your setup. SSL can be used in any port, so port 8888 isn't the problem. The problem is that your SSL Certificate is self-signed (not created by a Certificate Authority).
Companies like Let's Encrypt offer free SSL Certificates. It's worth having a look.
I am relatively new to AWS and I've been looking at quite a few tutorials for the past couple of days trying to figure out how to make my AWS ubuntu instance accessible from the browser.
What I've done:
1st: I configured security groups to accept all traffic for ssh, http, https just to see if the public DNS listed in the instance is accessible.
2nd: I changed the IP of my instance to an elastic IP
3rd: I wrote a simple node.js file that listens on port: 9000 and console.logs 'hello world'
For some reason ssh works, and I can run my node.js file, but agina I cannot access the remote instance from the browser.
Any help would be greatly appreciated since I've been on this for a couple of days
Thanks!
Thank you everyone for the quick responses!
My issue was I did not include a TCP rule to my specific port. Now I am able to access that port via ec2-DNSNAME:9123.
And, just to clarify, if I want to host that DNS for all traffic I should specify 'anywhere' for the TCP rule, correct?
I configured security groups to accept all traffic for ssh, http, https
In security groups, "HTTP" does not mean "HTTP on any port"... it means "any traffic on TCP port 80" -- 80 being the standard IANA assigned port for HTTP.
Security groups are not aware of the type of traffic you are passing, only the IP protocol (e.g. TCP, UDP, ICMP, GRE, etc.) and port number (for protocols that use port numbers) and any protocol specific information (ICMP message types).
You need a rule allowing traffic to port 9000.
Firstly go to your EC2 and see if curl http://localhost works..
Also, if you are exposing your nodejs on port 9000 ; did u open 9000 also on security groups or not ?
Few things to check:
Security groups
Subnet NACLS (these can function as a subnet level
firewall, but unless you've messed with these they should allow all
traffic.)
On the server if you run netstat -na | grep <PORT> do you see your
application listening on the correct ports?
You may also check your system for a firewalls that could be short circuiting the requests.
If the above doesn't point you towards where your issue is you can grab tcpdump and filter it just for requests coming from your web browser (e.g after installing tcpdump -vvn host 10.20.30.40 port 8000 Substitute your ip and port). This will let you know if you're running into a network issue (Packets aren't reaching the server) or if its something with the app.
I'd also recommend using IP addresses while doing your initial troubleshooting. That way we can establish it is not network/server configuration before going into DNS.
I'm not sure why my browser is timing out when I try to connect to my AWS Ubuntu Instance squid proxy
I want to have my AWS Ubuntu instance act as a proxy for my python requests. The requests I make in my program will hit my AWS proxy and my proxy will return to me the webpage. The proxy is acting as a middleman. I am running squid in this Ubuntu instance. This instance is also within a VPC.
The VPC security group inbound traffic is currently set to
HTTP, TCP, 80, 0.0.0.0/0
SSH, TCP, 22, 0.0.0.0/0
RDP, TCP, 3389, 0.0.0.0/0
HTTPS, TCP, 443, 0.0.0.0/0
and outbound traffic is open to all traffic
This is my current squid configuration is the default squid.conf except that I changed one line to
http_access allow all meaning traffic is open to all.
However when I changed my mozilla browser to use the Ubuntu instance's Public IP and squid.conf default port of 3128, I cannot see any traffic going through my proxy using this command on the ubuntu instance
tail -f /var/log/squid/access.log
My browser actually times out when I try to connect to a website such as google.com. I am following this tutorial but I cannot get the traffic logs that his person is getting.
HTTP/S as shown in security group settings actually has nothing whatsoever to do with HTTP/S.
Many port numbers have assigned names. When you see "HTTP," here, it's only an alias that means "whatever stuff happens on TCP port 80." The list of values only inludes common services and the names aren't always precise compared the official port names, but the whole point is to give neophytes a word that nakes sense.
What should I change? I always thought I should be leaving HTTP/S ports to their default values.
That is not at all what this does. As already inferable from above, changing an "HTTP" rule from port 80 to something else does not change the value for the HTTP port on instances behind it. Changing the port value makes the rule no longer be an "HTTP" rule, since HTTP is just a friendly label which means "this rule is for TCP port 80."
You need a custom TCP rule allowing port 3128 from your IP, and that's it.
You need to add 3128 as custom TCP in your SG. This will allow Squid to send/ receive traffic.
Also as a best practice, make SSH accessible from your own IP rather than public.
I looking for add support to a VPN for my software,
I known PPTP and OpenVPN , the two makes a system-wide binding, installing a TAP driver so all applications route their traffic to then.
How could i implement a VPN support for just my application ? There´s any library, example, hint or way to do it ?
My software is actually made in C++ /MFC. Using the standard CAsyncSocket.
Forwading incoming connections to your application is relatively easy:
stunnel allows you to forward traffic to specific ports through an an SSL tunnel. It requires that you run it on both ends, though.
Most decent SSH clients, such as OpenSSH or PuTTY also support port forwarding, with the added advantage that any remote SSH server can usually act as the other end of the tunnel without any modifications.
You can also use OpenVPN and other VPN solutions, but this requires specific forwarding rules to be added to the remote server.
Forwarding outgoing connections, though, is trickier without modifying your application. The proper way to do it is to implement the SOCKS protocol, preferrably SOCKS5. Alternatively, you can use an external application, such as FreeCap, to redirect any connections from your application.
After you do that, you can forward your connections to any SOCKS server. Most SSH clients, for example, allow you to use the SOCKS protocol to route outgoing connections through the remote server.
As a sidenote, OpenVPN servers do not necessarily become the default gateway for all your traffic. Some do push such a route table entry to the clients, but it can be changed. In my own OpenVPN setup I only use the VPN to access the private network and do not route everything through it.
If you can force your application to bind all outgoing sockets to one or more specific ports, you could use IP filtering rules on your system to route any connections from those ports through the VPN.
EDIT:
Tunneling UDP packets is somewhat more difficult. Typically you need a proxy process on both the remote server and the local client that will tunnel incoming and outgoing connections through a persistent TCP connection.
Your best bet would be a full SOCKS5 client implementation in your application, including the UDP-ASSOCIATE command for UDP packets. Then you will have to find a SOCKS5 proxy that supports tunnelling.
I have occasionally used Delegate which seems to be the Swiss pocket-knife of proxies. As far as I know, it supports the UDP-ASSOCIATE command in its SOCKS5 implementation and it also supports connecting two Delegate processes through a TCP connection. It is also available for both Linux and Windows. I don't remember if it can also encrypt that TCP connection, but you could always tunnel that one through stunnel or SSH if you need to.
If you have system administrator rights on a remote VPN server, however, you could probably have a simpler set-up:
Have your P2P application bind it's outgoing UDP sockets to the client VPN interface. You many need to setup a secondary default route for that interface. This way your application's outgoing packets will go through the remote server.
Have the remote server forward incoming UDP packets to specific ports through the VPN connection back to you.
This should be a simpler set-up, although if you really care about anonymity you might be interested in ensuring your P2P application does not leak DNS or other requests that can be tracked.
Put SSH connectivity in your app or use SSL. You'll have to use a protocol/service instead of VPN technology. Good luck!
I think you simply need SSL: http://www.openssl.org/
OpenVPN is based on SSL - but it is a full vpn.
The question is what do you need? If you need encryption (application private connection) - and not a vpn (virtual private network) go for ssl.
Hints can be found here:
Adding SSL support to existing TCP & UDP code?
http://sctp.fh-muenster.de/dtls-samples.html
http://fixunix.com/openssl/152877-ssl-udp-traffic.html