How do i connect to a server that uses sockets in postman? I can't understand where I should include the necessary data for the connection like the password, user, id and the port, I was able to connect to the server using a desktop application supplied with the server, by entering the previous data.
Related
I have an nodejs application where I connecto to devices via opcUA and send data via websocket to web page which works fine so far...but now I want to add a device where the server ip and the available endpoint is different.
The server ip is opc.tcp://192.168.5.65:4840 and the endpoint is opc.tcp://proto-01:4840.
I can connect to the server, read and console.log the available endpoint but when I try to create a session I get the error: endpoint opc.tcp://192.168.5.65:4840 does not exist.
I can connect to the device with UA-Expert without any problems but get the message that the naming was changed to proto-1.
Does anybody know how to convince node opcua to connect to endpoint? I haven't found anything related to such a problem.
I am using a mobile application that connects directly to the database instance (Postgres), as such, I have to keep the ports open for traffic that is generated from the internet (4G, mobile app).
This mobile app (QFIELD, mobile version of QGIS) has a direct connection to the database, this is the reason why the database is reachable from the internet on a public ip but this is a critical issue for the security of the data and the requests that can be sent to the database.
I would like to proxy the requests so that the database is only available to local machines and not open for connections directly.
The mobile appp would send the request to an HTTP url which would send the request to the local ip and port, this way I would avoid to have the database exposed on the internet.
Ideally, I would like to go from this app (which uses a postgres connection string to connect to the server) to an HTTP server that routes the request locally, as such:
APP connects to https://myproxy/postgres
Request is proxied to a local server
Can I do this with Apache2? Any ideas?
At the moment I cannot write a middleware that proxies requests from the APP to the local postgres.
If your application is expecting to connect directly to a PostgreSQL database and you don't want to change that then you need to connect to something that "speaks" PostgreSQL's client protocol.
You can place a proxy such as pgbouncer or pgpool in front of it, but they aren't a guarantee of greater security just by themselves. This is the same problem as with any proxy - it is just forwarding requests and responses to your actual server so any vulnerability is still exposed.
What you can do is:
restrict the number of connections at the proxy point
restrict which users can connect non-locally to your PostgreSQL cluster
restrict where they can connect from to just your proxy
restrict those users permissions within the database(s)
That last point is particularly important - assume any user account your application can be used maliciously. Restrict the account to prevent mass updating or deleting of data. Also take special care to restrict access to other users' data.
If I was forced to allow access like this, I would want one PostgreSQL user account per actual user at the very least. In practice I wouldn't get to this point with a production application.
We have a client/server based application that is developed internally. Clients and server communicate over a TCP/IP connection with an application-specific protocol. The clients run on Windows and the server runs on Linux. All machines are in the same Active Directory/Kerberos domain/realm.
Currently, the user enters a username and password when they start the application. The server checks the username and password (authentication). Based on the username, the server also determines access to resources (authorization).
We want to add Single Sign-On (SSO) capabilities to the application. That is, we do not want the user to enter a username and password but we want to automatically logon as the current Windows user.
Of course, determining the current Windows user has to be done securely.
I have come up with the following setup:
I use SSPI (Negotiate) on Windows and GSSAPI on Linux.
When the client connects to the server, it uses AcquireCredentialsHandle (Negotiate) to get the credentials of the current Windows user.
The client uses InitializeSecurityContext (Negotiate) to generate a token based on these credentials.
The client sends the token to the server.
The server uses gss_acquire_cred() to get the credentials of the service. These are stored in a .keytab file.
The server receives the token from the client.
The server uses gss_accept_sec_context() to process the token. This call also returns the "source name", that is the current Windows user of the client.
The server uses the "source name" as the username: the server performs no additional authentication. The server still performs authorization.
This works but I do have some questions:
Is this secure? It should not be possible for the client to specify any other username than the Windows user of the client process. If a user has the credentials to create a process as another user (either legally or illegally) than this is allowed.
Should I perform additional checks to verify the username?
Are there alternative ways to achieve SSO in this setup? What are their pros and cons?
What you've described here is the correct way to authenticate the user. You should not have to worry about the user specifying a different name; that's what Kerberos takes care of for you.
If the client is able to obtain a service ticket, then they must have been able to authenticate against the KDC (Active Directory). The KDC creates a service ticket that includes the user's name, and encrypts it with the service's secret key.
The client would not be able to create a ticket for the server with a fake name, because it doesn't have the necessary key to encrypt the ticket.
Of course, this all assumes that you've set everything up correctly; the client should not have access to the service's keytab file for example, and the service should not have any principals in its key tab except its own.
There's a pretty detailed explanation of how it works here.
I have server and client applications communicating over the TCP socket that is desktop applications. I have enabled Windows IP-sec between server and client machine so that my network traffic would be encrypted. During the login process client application send hash of the password to server and server validate it in the database after applying server side hash that is fine.
Now there is another scenario where client application request SQL server password from the server over TCP and server sends this password in plain text and then client application use this password to connect with SQL server, similarly to connect with other third party server, client application fetch password from server, server send it as plain over Ipsec. My question is does this safe to send password as plain over the ipsec enabled server and client? If not what else I have to do to make it secure?
IP-sec provides encryption, therefore it is in theory safe to send the password as plain-text over IP-sec connection.
However, it may be better practice to not send plain-text passwords if at all possible.
The method that comes to mind is using SSH keys. Client would generate key-pair and send public key to the server, which would forward it to the SQL/third-party server. In this scenario, the private key never has to leave the client. This is harder to set-up, but should be more secure in the long run.
PS: Also remember, that the password/key can be extracted from the client application, if the attacker has access to the client machine (directly or by malware on the computer). Therefore always assume that the user authenticated as client will have access to these keys and will be able to do everything these keys can be used to do, even if your client does not allow it.
I have the following setup with my GWT Client - Server application:
GWT Client -(RPC)- Server - MSSQL db.
The client is running on various platforms & devices (web application, mobile phones etc..). The java server (and web application files) are hosted on Jetty. MSSQL Database is running on a different server on a different domain.
I need to find a way for the user to authenticate on the domain of the MSSQL DB after which I can allow the client to access to rest of the servers services.
I can pass the username & password pair encrypted to the server but how do I continue from there on? I spent a lot of time figuring that out today, but I just got more and more confused. I did manage to check local authentication with Kerberos on the server, but I need to authenticate remotely to a different domain. Is it even possible without setting up service for that on the remote domain, which I'm trying to avoid?