I'm trying to get a deeper understanding of the architecture and design of Openstack noVNC security. I found this document. It makes sense but missing details. Can somebody confirm my understanding is right, or correct me if I'm wrong.
0) noVNC allows VNC clients in web browsers, good for clients without java or vnc client installed.
1) VNC server is provided by the hypervisor, Every VM has its own VNC server, at port 59xx, not accessible from outside.
2) Websocket proxy bridges to VNC server and provide service for noVNC client (javascript in browser), say at port 6080.
3) Simple security: Security could alternatively be guaranteed by VNC password, but it's not convenient to type every time and not easy to change. Every VM on the same hypervisor has to share the same password. Different compute nodes may use different VNC passwords.
4) To provide better access control, consoleauth is introduced. We can now use Openstack authentication for VNC. When a new request for remote console comes, a dynamic access URL (with a token) is generated, cached/registered, and sent back to client. Later, only previously registered connections are accepted.
I would like to know more about whether/how dynamic firewall rules are created, and whether/when the tokens are invalidated. I know the best way is to read the source code, but a high level description is also valuable. Thanks.
Related
This has taken me about a year to understand and get to, but I am the limit of my capability so reaching out to a StackOverflow guru please...
I would like to, if possible, secure my network model. The model is as shown in the diagram. To explain:-
All the aspects I have control of, is within the green shaded area. I cannot change anything outside this.
I run a simple application web server which is the VPN IPsec/L2tpd client. Static IP.
My router is ISP provided. It receives a DHCP Dynamic IP from the ISP.
My Digital Ocean Virtual Private Server has a static IP. It runs an NGINX reverse proxy that channels traffic through the VPN tunnel. It also runs the IPsec/L2tpd server.
A IPsec/L2TPD VPN tunnel is established and working.
A working VPN tunnel.
A cellphone that runs an app that communicates with my application server app. My cellphone receives a dynamic IP from my Network Operator.
I have three IP camera feeds served by my application server. Not a great speed but watchable in real-time.
I cannot change my ISP, or bandwidth/download/upload speed.
I cannot install VPN clients on the cellphone and I may want to access my app server through another cellphone provided by work so cannot install apps on it but does have unfettered web access through a browser.
Everything is now working, can't believe I've done it !
Anyway, my question is:-
Is there any way to secure the network so that only traffic from my mobile reaches - or rather is accepted - by my application server.
I accept IPsec/L2tpd is not great, but it is fast and I use this because I have tried OpenVPN, SoftEther and key based OpenSwan. These are waaaay to slow. The camera feeds are unwatchable and update one frame about every 5 seconds.
So with the limitations above, what can I do, what is possible? Please may I respectfully ask that you refrain from suggestions and concerns requiring a change to that which I cannot control, i accept all critique but that is not what I need here. I am asking for advice on how to secure , that which I can influence. Thank you
I cannot install VPN clients on the cellphone and I may want to access
my app server through another cellphone provided by work so cannot
install apps on it but does have unfettered web access through a
browser.
Due to the limitation that at the end, even a phone where you are not allowed to change anything but use the web, i suggest to configure proxy authentication on the nginx reverse proxy. I don't have experience with setting this up with nginx in particular but that's what should do the trick according to the network architecture and description you provided.
An example configuration on how to configure nginx for basic / client certificate auth can be found at: https://www.cloudsavvyit.com/1355/how-to-setup-basic-http-authentication-on-nginx/
I need informations about security risks and proof of concepts to work with an local client.
In my option, a user will install two components:
The game client
The client launcher
The launcher is running as an background process all the time. The launcher provides an WebSocket server.
The user will open my website to start the game (with game-server lists and other settings). The Website connects to the game launcher to handle all actions (change configuration, start the game executable)..
Problem:
How realize the communication with the website and the game launcher? Okay, Websockets, yes. But browsers forbid to connect to localhost/127.0.0.1 by security reason.
An fake-pointer as DNS or hosts-file to an subdomain like local.game.tld is bad, because SSL-Certificates can be revoked here as bad usage.
Another idea was to provide an NPAPI-Plugin for the browser. But it seems, that the NPAPI is deprecated and useless for the future.
Whats the best practice to communicate between webpages and local installed software?
But browsers forbid to connect to localhost/127.0.0.1 by security reason
This isn't true. Browsers allow you to connect to localhost / 127.0.0.1. I do it all the time on my machine.
The issue is that TLS (wss://localhost, not ws://localhost) requires a certificate and browsers forbid mixed content (you can't have an https website load non-encrypted resources).
fake-pointer as DNS or hosts-file to an subdomain like local.game.tld is bad, because SSL-Certificates can be revoked here as bad usage.
As part of your game installer you could create a hosts file entry with a certificate for mygame.localhost (possibly using a local script) and then ask the player to authorize the installation of the certificate using their password. This way your certificate won't be revoked... but you are right that this his suboptimal.
EDIT: also, please note that the domain name must be at the end, not at the beginning (i.e., game.localhost and not localhost.game).
Whats the best practice to communicate between webpages and local installed software?
Generally speaking, if your game is installed on the local machine, there's no need to encrypt the communication between the local browser and the local machine.
You can easily write your local server to accept only connections from the local machine (or, at worst, if need be, accept connections from the local area network - though this adds security risks).
Your webpage and WebSocket data can be sent "in the clear" (ws:// and http://) between the local server and the browser since they are both on the same machine - this way you don't need a browser. The local server would initiate (as a client) any encrypted connection it needs when communicating with an external service (was:// / https://).
EDIT (from the comments):
There are the only 2 solutions I know of:
Installing a self-signed certificate; or
Using http instead of https and having the server handle outside traffic as if it were a client (so all traffic going outside is encrypted).
I've build a Web-App that is displayed in an Electron-App with Nativefier. That already works great, but now i need to send requests from the website to the local network to talk with some local devices which are (with it's ip-address) configured in the Web-App.
I had the idea to use the Electron-App as a "proxy" to the local network by using a javascript callback from the Website to the Electron-App (don't know if this is possible, just an idea), which then makes the local request because it's running on a computer in the same network.
The reason for this post is that i need ideas/tips to secure this and prevent allowing to talk to other than the desired Web-App (available under a certain domain) by developing something protective like checking or validating the Server, validating the request by sending it's hash back to the server or other methods.
So my questions are: is it generally a good idea to do something like this or is this a huge security problem and have anyone any tips to secure the communication and only allowing the communication to in the web-app configured devices in the local network?
A beginner question, but I've looked through many questions on this site and haven't found a simple, straightforward answer:
I'm setting up a Linux server running Ubuntu to store a MySQL database.
It's important this server is secure as possible, as far as I'm aware my main concerns should be incoming DoS/DDoS attacks and unauthorized access to the server itself.
The database server only receives incoming data from one specific IP (101.432.XX.XX), on port 3000. I only want this server to be able to receive incoming requests from this IP, as well as prevent the server from making any outgoing requests.
I'd like to know:
What is the best way to prevent my database server from making outgoing requests and receiving incoming requests solely from 101.432.XX.XX? Would closing all ports ex. 3000 be helpful in achieving this?
Are there any other additions to the linux environment that can boost security?
I've taken very basic steps to secure my phpmyadmin portal (linked to the MySQL database), such as restricting access to solely my personal IP address.
To access the database server requires the SSH key (which itself is password protected).
A famous man once said "security is a process, not a product."
So you have a db server that should ONLY listen to one other server for db connections and you have the specific IP for that one other server. There are several layers of restriction you can put in place to accomplish this
1) Firewall
If your MySQL server is fortunate enough to be behind a firewall, you should be able to block out all connections by default and allow only certain connections on certain ports. I'm not sure how you've set up your db server, or whether the other server that wants to access it is on the same LAN or not or whether both machines are just virtual machines. It all depends on where your server is running and what kind of firewall you have, if any.
I often set up servers on Amazon Web Services. They offer security groups that allow you to block all ports by default and then allow access on specific ports from specific IP blocks using CIDR notation. I.e., you grant access in port/IP combination pairs. To let your one server get through, you might allow access on port 3000 to IP address 101.432.xx.xx.
The details will vary depending on your architecture and service provider.
2) IPTables
Linux machines can run a local firewall (i.e., a process that runs on each of your servers itself) called iptables. This is some powerful stuff and it's easy to lock yourself out. There's a brief post here on SO but you have to be careful. It's easy to lock yourself out of your server using IPtables.Keep in mind that you need to permit access on port 22 for all of your servers so that you can login to them. If you can't connect on port 22, you'll never be able to login using ssh again. I always try to take a snapshot of a machine before tinkering with iptables lest I permanently lock myself out.
There is a bit of info here about iptables and MySQL also.
3) MySQL cnf file
MySQL has some configuration options that can limit any db connections to localhost only - i.e., you can prevent any remote machines from connecting. I don't know offhand if any of these options can limit the remote machines by IP address, but it's worth a look.
4) MySQL access control via GRANT, etc.
MySQL allows you very fine-grained control over who can access what in your system. Ideally, you would grant access to information or functions only on a need-to-know basis. In practice, this can be a hassle, but if security is what you want, you'll go the extra mile.
To answer your questions:
1) YES, you should definitely try and limit access to your DB server's MySQL port 3000 -- and also port 22 which is what you use to connect via SSH.
2) Aside from ones mentioned above, your limiting of PHPMyAdmin to only your IP address sounds really smart -- but make sure you don't lock yourself out accidentally. I would also strongly suggest that you disable password access for ssh connections, forcing the use of key-pairs instead.You can find lots of examples on google.
What is the best way to prevent my database server from making outgoing requests and receiving incoming requests solely from 101.432.XX.XX? Would closing all ports ex. 3000 be helpful in achieving this?
If you don't have access to a separate firewall, I would use ip tables. There are a number of managers available for you on this. So yes. Remember that if you are using IPtables, make sure you have a way of accessing the server via OOB (short for out of band, which means accessing it in such a way that if you make a mistake in IP tables, you can still access it via console/remote hands/IPMI, etc)
Next up, when creating users, you should only allow that subnet range plus user/pass authentication.
Are there any other additions to the linux environment that can boost security? I've taken very basic steps to secure my phpmyadmin portal (linked to the MySQL database), such as restricting access to solely my personal IP address.
Ubuntu ships with something called AppArmor. I would investigate that. That can be helpful to prevent some shenanigans. An alternative is SELinux.
Further, take more steps with phpmyadmin. That is your weakest link in the security tool chain we are building.
To access the database server requires the SSH key (which itself is password protected).
If security is a concern, I would NOT use SSH key style access. Instead, I would use MySQLs native support for SSL certificate authentication. Here is now to configure it with phpmyadmin.
I have a 'native' program (in Java) which would like to communicate with a Google Chrome/Chromium extension. The communication contains sensitive informations, and should not be accessible by anybody else than the user running them (and the root of course).
What technology should I choose for this communication channel? Is there even a solution?
EDIT:
Of course I could open a TCP/IP port on the local host, but wouldn't it be accessible by other users having an account on the same host? Is there a technic to avoid that side effect?
Could we access unix domain sockets from Google Chrome extensions?
Assuming you are already familiar with TCP, if you use localhost / 127.0.0.1 for the communication it would not be visible/available for other machines.
You could solve this at the higher level with a secured SSL communication with certificates etc... IF someone does not have the certificate, then the connection is killed. Moreover, you would benefit from encryption.
The solution that I chose is to have an server socket listening on the loopback interface (/ 127.0.0.1) with a shared secret used as an api key.
The reason is that I didn't realize that in my case each app which connect to my node had to be authenticated .. because each app is treated in a different way, with different access permissions.