I've heard from more than one IT Manager that they don't allow users to user RDP to connect to their internal network from the outside, because it's not safe. They claim that if they'd allow their users to do so, then anyone from the outside will have access to their network as well.
I'm not getting it. In order to use RDP, you need a user name and password, and you can't get in without it. The same is for using Gmail, online banking, and any other web service.
So what do they use instead? LogMeIn. Or a VPN connection, and then use internal RDP. VPN also requires a user name and password.
If they're afraid of a brute-force attack, then someone can brute-force attack the VPN server or LogMeIn just the same. And if these other technologies have lockouts (after x number of failed attempts) then why can't the same be set up for RDP?
Similarly, people always say that VPN is very secure because it uses a "tunnel". I don't fully understand what that means, but regardless, why can't the username and password be cracked the same way any website or web service which uses a user name and password can be.
With proper configuration, RDP is capable of 128-bit RC4 encryption, virtually any port or set of port allocations, and has proven to be relatively bug-free, with only extremely minor flaws ever discovered.
On the other hand, the secure tunnel created in a VPN is far more secure than Remote Desktop. All your data is encrypted for safe transfer from one remote location to another.
Moreover, VPN only allows shared content to be accessed remotely to tighten the security. If your device falls in the wrong hands, they won’t be able to access and manipulate unshared data and resources.
The bottom line is that both RDP and VPN have their own advantages, however, with high security, better performance and manageability, VPN seems to be a clear winner in the competition of Remote Desktop VS VPN service.
Related
I have a simple app connected to a server via some sockets and the traffic is not yet encrypted users must log in or create accounts before using the app and afterwards traffic is shared between users and server. i want to know if i must encrypt all traffic or just the authentication and account creation?
Use https for all traffic (or an equivalent TLS-based protocol for non-HTTP traffic). Yes, encrypt and certificate-authenticate everything. For modern systems, there are vanishingly few cases where TLS is not the correct answer for network traffic. It is ubiquitously available across platforms, languages, and protocols.
On any modern network system you need an argument for why you wouldn't encrypt and authenticate the connection. It's not a matter of "must" you. It's a matter of "why wouldn't you?"
There are the following parameters:
I use the FirebirdSql.Data.FirebirdClient library in asp .net
Now, at the test level, I connect to the remote database using the line:
string workbase = "Server="public ip";Port="port";User=sysdba;Password=masterkey;Database=C:/path/db.FDB";
Further are connection methods, requests, transactions, commits, etc.
string sqlcardpin = $"SELECT.....";
var connection = new FbConnection(workbase);
Question: is it safe? Is traffic encrypted? where can I read about it? How should I connect?
From my modest brain efforts, the following goes: I need to have a service in a local network with a database, to which a secure connection goes, and this service has credentials for connecting to the database and performs operations with it, maybe I'm wrong, please correct me.
If 'public ip' is a publicly routed IP address, and port 3050 is open to the whole world, that is not safe. Don't expose your database server to the world, it will create a very wide attack surface to get at your data.
For example, Firebird 2.5 and earlier have a very weak authentication system (max 8 character passwords), and while Firebird 3 introduces a new, more secure authentication mechanism that allows much longer passwords, for various reasons, a lot of servers are still configured with the weak authentication (also) enabled. Also consider bugs that might allow people to circumvent authentication, or that could allow people to remotely crash your database server, etc.
As to encryption, Firebird 2.5 and earlier have no encryption of the connection. This was introduced in Firebird 3, and only for connections authenticating with the new SRP (Secure Remote Password) authentication mechanism, and only if the WireCrypt setting of the server is Required or Enabled and the client actually requests authentication. For C#, this requires Firebird ADO.net provider version 7.0.0.0 or higher. However, the wire protocol encryption offered in Firebird 3 is the relatively insecure RC4 encryption; Firebird 4 will introduce ChaCha-20 as an alternative wire protocol encryption.
So, your database should be on the same network as your application, preferably on an IP address that is not routable over the internet (ie in one of the private ranges), or at least shielded from the internet by a firewall. If for some reason you need to connect to a remote database over the internet, do not expose the database directly to the internet, but use a VPN solution, or maybe something like an SSH-based tunnel.
And as corradolab points out in their answer, don't use masterkey as a password for SYSDBA. In fact, don't use SYSDBA for your application to connect, but create a specific user and assign it the necessary but minimal rights for it to do its work.
You didn't say if the web server and the database server are on same or different site, but, anyhow,
do not expose a database server to the public Internet.
If web and database server are in different sites, consider using a firewall (on the database) to allow connection only from the web server address or a VPN between the two sites.
If they are in the same site, expose only the web server to the Internet (put it in DMZ) and keep the traffic to and from the database server on the private LAN.
BTW Having Firebird on the Internet using sysdba/masterkey is like going around with "kick me" written on your back. Don't be surprised if it hurts. :)
I'm working on an application that will be used from different locations so it has to be on a network, and since the distance from each workstation that will use the application is quite far, it will be on the internet. Definitely on a dedicated Windows Server.
I have security concerns because it is such an application that black-hat hackers and crackers will like to abuse to their own ends.
So I'm thinking, I can (since I am the I.T head of the company) procure a static IP address for all the workstations that will use the application, then I can compile a white list of IP addresses. If a request is not coming from an IP address in the white list, the request will be denied. Does this make sense?
I could also use more security tips on securing the server and the application.
It's an ASP.NET MVC application.
Does this make sense?
At a network level? Somewhat. At an application level? Probably not.
IP filtering is something that makes sense at the network level. So setting firewall rules to dictate which IPs are allowed to access certain ports on a server. That is both sensible and common.
Trying to do the same thing at the application layer is error prone and problematic. For instance, if your application is behind a load balancer, the IP address your application sees may well be the one belonging to the load balancer, not the client who originated the request.
As an additional note, just because a request is coming from a trusted IP, doesn't mean that you don't have to be careful. Your "trusted" client systems could be compromised or an attacker could be using a CSRF attack.
Am i correct that when using State Server traffic between my web site and the state server isn't encrypted? If it isn't, how can i secure it (SSL)?
The ASP.NET Session State server uses clear-text http-requests in a rest-like manner for communication. The actual protocol specification is publicly available at [MS-ASP]: ASP.NET State Server Protocol Specification.
I've never heard of anyone encrypting the state traffic, cant find any references for it, and nothing that states that it's even possible.
It's impossible for any of us to say whether the traffic between your web site and state server is encrypted or not.
At a high level, state server uses clear text for transferring the data. But this doesn't necessarily mean it's not encrypted.
However, depending on how your network is setup it might be encrypted at a lower layer by the operating system. Namely, if the machines are part of a domain the network administrator might have turned on the proper settings to force kerberos encryption between the machines.
Further, if you encrypt the data prior to putting it in "session" then it would obviously be encrypted.
If you are worried about internal threats then your network should be configured to encrypt all traffic between machines. (if you want to know how, go to serverfault.com).
The state server should be behind the firewall and not public, there should be no reason to encrypt the traffic. You would only want to make sure that the traffic is only able to go to and from the web tier to the state server via network layering.
We are in the process of building a new website which we want to lock down to specific computers to only allow access, then once the pc is authenticated we will do our in built user authentication.
Also, when a pc is known, we dont really want anything on the pc which can be easily transfered (by the client) onto another pc in order to gain access to the website.
Please can anyone give us an idea on the best way to achieve this 'lock down', we dont really want to go down the AD route and have loads of extra user data to maintain.
Thanks in advance.
Richard
IP and MAC addresses are trivial to spoof. Without Trusted Computing, there is nothing you can really trust to authenticate a PC. What you need to figure out is what can you do that gets you an acceptable level of trust. Here's what we have done with our "locked" tokens: They take some info from the PC and hash them and send that hash to the auth server. Any requests for an OTP then needs to be accompanied by that hash. It's not perfect, but it also handles mutual https authentication, so it thwarts network-based MITM attacks too. If the token is stolen, the attacker must also know what info to spoof and spoof it. Again, it's not perfect, but better than nothing given the current state of PC security. http://www.wikidsystems.com/downloads/token-clients and our sourceforge page: http://sourceforge.net/projects/wikid-twofactor/
specific computers on your network?
set some IP restrictions in IIS, this assumes your DHCP box is giving out static IPs.
The only way a user could "transfer" the authentication is to take their NIC with them, or clone its MAC address.
Install Helicon Ape free and put .htacces and .htpasswd files in the root of the site you are trying to protect.