This is a read-only archive. Find the latest Linux articles, documentation, and answers at the new Linux.com!

Linux.com

Feature: Security

Secure remote access to your desktop

By Federico Kereki on October 05, 2007 (9:00:00 AM)

Share    Print    Comments   

Accessing your home server safely can be problematic, especially if you don't have a fixed IP address, but with Linux, DynDNS, PAM, and NX Free you can create a safe remote access path to your machine.

A few months ago, I had to travel from my hometown of Montevideo, Uruguay, to New York. As I would be staying abroad a few weeks, I had to make sure I could access my home server safely. Despite Linux's stability, I had to allow for my family having problems back home, and I couldn't depend on giving instructions over the phone or by messaging.

I had to solve three problems to get everything running properly. First, I have an Asymmetric Digital Subscriber Line (ADSL) connection without a fixed IP address, which means my address can change, so I needed to be able to access my machine without knowing its address. Second, I can use SSH, but I know many people try attacks against machines that have the SSH port open, so I didn't want my box to become an open target. Finally, I had heard about NoMachine's NX Free Edition and wanted to try it out, but I had to make sure I did so safely.

Access a machine without a fixed IP

Not having a fixed IP address is a problem, but there's an easy solution: DynDNS from Dynamic Network Services. This free service allows anybody to have a subdomain pointing to a computer with a changing, variable IP address. You simply install a small update client that keeps the hostname up to date with the client's current IP address by notifying a central server each time the address changes. With many modern routers, you can even do without the client by configuring the router to do the notification by itself.

Go to the DynDNS site, sign up for a free account, and pick a domain (I picked remotekereki.homelinux.com). Finally, follow instructions to get the DDclient program, a short Perl script that keeps DynDNS up to date. Installing DDclient is easy: Just get the code, extract it to /usr/sbin (you'll have to work as root), and edit /etc/ddclient/ddclient.conf to provide details about the site:

pid=/var/run/ddclient.pid
daemon=600
protocol=dyndns2
use=web, web=support.easydns.com/utils/get_ip.php
server=members.dyndns.org
login=yourOwnUserAccount
password=yourOwnPassword
yourOwnDomainName

As root, I ran chkconfig ddclient on followed by /etc/init.d/ddclient start, and I was ready and on my way. To verify that everything was really working, I tried ping remotekereki.homelinux.com and got an answer, which meant my address was available from anywhere in the world. First problem solved!

Secure your SSH access

A pluggable authentication module (PAM) is the key to greater flexibility regarding security. It used to be that the only way to create authentication was to have a user enter a password, then check that it matched the official password stored in the /etc/passwd file. Now, many other methods have appeared, including replacements for the /etc/passwd file, smart cards, and other hardware devices. Instead of rewriting all the programs to support these methods, you can install a PAM, and the necessary checks will be performed transparently.

I wanted to add some restrictions to access, and that meant adding a line at the bottom of my /etc/pam.d/sshd file:

#%PAM-1.0
auth     include        common-auth
auth     required       pam_nologin.so
account  include        common-account
password include        common-password
session  include        common-session
account  required       pam_access.so

The pam_access module implements added security controls based on the /etc/security/access.conf file. I edited it in order to specify who could access my machine:

+ : ALL : 192.168.
+ : remote1776 : ALL
+ : nx : ALL
- : ALL : ALL

The first line means that anybody ("ALL") can log in to my machine from within the internal network at home. The second line allows the remote1776 user to access my machine from anywhere in the world, and the third line grants a similar right to the nx user that NX Free uses. The final line is a catch-all that disables access to anybody not specifically included in these lines.

That remote1776 user is an account with minimum rights that I created just to allow myself entry to the machine, so I could then execute su and work as myself or even root, if needed. If somebody guesses the correct password for remote1776, he'll still have to work at guessing the password for other, more useful, users; it's an extra barrier to pass before an intruder can do serious damage.

Now you need to configure SSH to use all of this. I edited /etc/ssh/sshd_config to include:

Port 16949
Protocol 2
PermitRootLogin no
MaxAuthTries 3
UsePAM yes

Note that these lines are all over the file; you'll have to look around for them. The first line changes the SSH standard, well-known port (22) to a different number, so it will be harder for potential intruders to guess. Take care not to pick an already used port. I also opened this port in my firewall.

The protocol 2 line avoids using a somewhat weaker protocol. The third line is almost self-explanatory: I didn't want anybody to be able to log in as root; let's make life harder for hackers! Allowing only three tries before a time-out throws a wrench in brute-force attacks. Finally, the last line makes SSH use the PAM configuration.

All of this meant I had to restart ssh with /etc/init.d/sshd restart, and could from now on run ssh remote1776@remotekereki.homelinux.com:9622 in order to access my machine; that's a long command!

Use NX Free

After having done all of this, getting NX Free to work with the added restraints was a breeze. NX Free implements its own security methods, but I added a couple of tweaks. First, I added the nx user to the list of allowed users. Second, when I defined the connection, I changed its standard port (22) to my new one (16949). That's all I had to do. Of course, you're taking advantage of all the installed infrastructure, but it's nice not having to do much extra work for added security, isn't it?

Learning how to do all this was a bit of work, but getting everything to work together was reasonably easy and efficient. I used my desktop machine from New York with no hassles, fixed a couple of problems that my family had, and survived all that time with my machine "in the open" with no intrusions.

Federico Kereki is an Uruguayan systems engineer with more than 20 years' experience developing systems, doing consulting work, and teaching at universities.

Share    Print    Comments   

Comments

on Secure remote access to your desktop

Note: Comments are owned by the poster. We are not responsible for their content.

Secure remote access to your desktop

Posted by: Anonymous [ip: 194.221.133.226] on October 05, 2007 09:30 AM

Sigh ... "security" by obscurity

Posted by: Anonymous [ip: 198.240.213.26] on October 05, 2007 12:28 PM

changes the SSH standard, well-known port (22) to a different number, harder for potential intruders to guess.


This is just plain stupid.


Intruders don't "guess", they probe all ports on the target.

#

Re: Sigh ... "security" by obscurity

Posted by: Anonymous [ip: 91.140.52.65] on October 05, 2007 01:32 PM
You are a bit stupid doncha? since you obviously don't work professionally with Unix machines let me tell you a "secret".
By changing the default SSH port you avoid 99% OF ALL ATTACKS!!!!!! Because 99% OF ALL ATTACKS ARE AUTOMATED BOTS THAT SEARCH ONLY FOR SSH ON PORT 22 and try to brute force it. But if you had ever taken look in a firewall log you would have known that.
How stupid do you look now hmm?

#

Re: Sigh ... "security" by obscurity

Posted by: Anonymous [ip: 24.248.89.66] on October 05, 2007 03:27 PM
keep in mind the most attacks scan all IPs for port 22. They don't bother searching all ports on all IPs

#

Re: Sigh ... "security" by obscurity

Posted by: Anonymous [ip: 190.64.4.34] on October 08, 2007 03:56 PM
You are mistaken here: by changing the port, a bot has to test tens of thousands of possible ports instead of just one, and it slows them down by several orders of magnitude, so they usually just check out port 22.

#

Re(1): Sigh ... "security" by obscurity

Posted by: Anonymous [ip: 203.2.120.16] on October 09, 2007 01:39 AM
You are all right. Switching the port breaks script kiddie attacks and that is reduction in your risk exposure to that particular threat but it does nothing to block a deliberate, targeted attack.
The deliberate targeted attack may be rarer but is far more insidious - the attacker will be more subtle, will build up a collection of information to use in an attack and will be highly motivated towards success. They will be targeting a valuable resource rather than miscellaneous booty or a new bot host. So, likelihood lower but certainly not zero (and completely dependent on your personal circumstance) but potential consequence much, much higher.
The "mystery port" trick is good to stop the teenagers jiggling doorhandles down your street but is useless for the guy who knows you own a flatscreen and wants it for himself.

#

Secure remote access to your desktop

Posted by: Anonymous [ip: 62.36.225.225] on October 05, 2007 01:25 PM
Too much hassle, why don't just use SSH? And what's the problem with having SSH open if it's the only thing open? Anyway, good tutorial on how to allow ssh to authenticate with pam.

#

Re: Secure remote access to your desktop

Posted by: Anonymous [ip: 91.140.52.65] on October 05, 2007 01:35 PM
SSH and NX are a bit different. NX is like VNC with ssh encryption only 100 times faster!!!! Which means that you connect remotely in a GUI manner. Yes with SSH you can do "ssh -X bob@machine" and forward X traffic to your machine, only that is dog slow compared with NX.
Try it

#

Re(1): Secure remote access to your desktop

Posted by: Anonymous [ip: 204.249.105.251] on October 08, 2007 02:39 PM
You can get very decent performance with VNC over ssh if you use compression. For example, you can use a line like this to connect you your computer:

ssh -C -L 5902:127.0.0.1:5901 -p 16949 remotekereki.homelinux.com -l remote1776

The -C parameter specifies to use compression. The 5902:127.0.0.1:5901 part maps your local host 127.0.0.1 port to your remote machine. The rest I think is obvious. Once that is done, all you have to do is run the tightvnc client poniting it to your local host's 02 port, like this:

127.0.0.1:2

That should give you a fast, encrypted connection to your remote machine using plain ssh and vnc. Try it.

#

Secure remote access to your desktop

Posted by: Anonymous [ip: 168.215.80.39] on October 05, 2007 01:31 PM
Thank you for sharing your experience with NoMachine NX Server Free Edition. NX Server is an incredible tool for securely accessing applications across any wide area network. NX also benefits local area networks by reducing the network traffic inherent in X-Windows. Besides accessing Linux system applications, NX's support for proxying foreign protocols like RDP and RFB make it useful for accessing applications and systems other than Linux. Enjoy!

#

Re: Secure remote access to your desktop

Posted by: Anonymous [ip: 12.169.163.241] on October 06, 2007 08:18 AM
Nice commercial. NoMachine is closed, proprietary software that require an antique version of libstdc++ that's so old it's not installed on most distros, so you have to hunt it down. The NX protocol a nice protocol, but I sure wouldn't trust closed code for secure remote access, and especially not antique closed code. It's too bad there isn't a Free client for FreeNX, though that's better only because it's GPL. It's not all that well-maintained either.

#

Sigh ... "security" by obscurity

Posted by: Anonymous [ip: 75.168.87.163] on October 05, 2007 01:33 PM
"security by obscurity" is a valid method, one that people too-often dismiss. Its not perfect or even great, but its valid and has its place. Is it the answer? No, no more than hiding a key under the rock out front of your apartment. It still happens and its still useful.

Most scans would be of well known ports, not high-numbered generally-unused ports. Unless you are a specific target, it is unlikely that the port would be scanned that high, and the attacker would move on.

#

Re: Sigh ... "security" by obscurity

Posted by: Anonymous [ip: 91.140.52.65] on October 05, 2007 01:39 PM
No the attacker wont move on if you change the SSH port, if it is YOU SPECIFICALLY that has gotten in his eye. But the automated BOTS that search only for SSH and try brute force mechanisms, are going to move on. That's possibly around 98% of all attacks you are going to have on your machine. So you are left with the remaining 2% to worry about ;)

#

Secure remote access to your desktop

Posted by: Anonymous [ip: 82.13.224.197] on October 05, 2007 01:53 PM
Interesting article and well worth doing. It seems a shame how the install and setup / tweaks performed on NX have been side stepped and not detailed in the same way though.

#

What do you do about NAT?

Posted by: Anonymous [ip: 68.153.29.4] on October 05, 2007 04:56 PM
You write: " + : ALL : 192.168.... The first line means that anybody ("ALL") can log in to my machine from within the internal network at home."

So you do have a multi-machine home network? The machine you're accessing remotely is one of several on a home network with a private address range 192.168.x.x and these 192.168 addresses can't be visible from the internet (because lots of other home networks are also using 192.168.) And the 192.168 machines are connected to a little router which might be 192.168.1.1, and this is connected to a DSL or cable modem that's maybe 192.168.1.254 on the side facing inward and has the changeable, ISP-provided IP address A.B.C.D on the side facing the internet?

If that's the picture then OK, I see how you're keeping track of the outside, ISP-provided address even if it changes. But once you get your packets from wherever in the world you are to your modem's outward-facing address A.B.C.D, which part of this setup routes them the last few feet to your PC? If you initiated a request from inside the home network going out, the NAT device would keep track of which PC the request came from and where to send the replies. But since you're now initiating the connection from outside, I don't see where or how this happens. Thanks very much!

#

Re: What do you do about NAT?

Posted by: Anonymous [ip: 204.174.12.18] on October 05, 2007 05:16 PM
the packets from outside would always have the outside address. they can't get address from the inside and that's why the arrive on a specific port (not the standard 22).

#

Re(1): What do you do about NAT?

Posted by: Anonymous [ip: 68.153.29.4] on October 05, 2007 05:34 PM
Oh, OK. And when you open the port on your firewall you forward it just to the PC you want to access remotely? Sorry to be so obtuse, I'm just a hobbyist and what you're discussing is right at the limit of what I understand about networking. Thanks again!

#

Re: What do you do about NAT?

Posted by: Anonymous [ip: 38.113.17.3] on October 05, 2007 05:41 PM
you do the same thing you do whenever you need a server inside the NAT to accept connections from the outside, you have your router forward incoming packets on a specific port (16949) to the right machine.

#

key vs pam

Posted by: Anonymous [ip: 204.174.12.18] on October 05, 2007 05:05 PM
what is the advantage of PAM vs KEY based authentication? The key also can have password and can be changed.

#

Re: key vs pam

Posted by: Anonymous [ip: 64.6.40.50] on October 05, 2007 07:07 PM
With key based authentication, you have to have a key on the machine you are trying to connect from which matches the key on the server you are trying to connect to. With PAM you can set up any one of several different authentication methods. Personally, when I set up SSH, I set it up to only accept a key since historically that has been less hackable. Also, the NX package the author was talking about uses a key to get through ssh. But that is where things get fun. Open SSH, by default uses SSH to change from the NX user to the user you are trying to sign in as. If you have disabled password authentication on SSH, then you must read through the FreeNX config file and disable SSH based user authentication and enable one of the other methods which FreeNX supports. The authors method of allowing password authentication from anything on the local network, and requiring keys from anything remote is an ingenious way to solve this situation.

#

Re: key vs pam

Posted by: Anonymous [ip: 139.142.219.253] on October 05, 2007 07:10 PM
Pubkey is better, in that you're restricting access further by requiring that someone have the key, not just a password which can be shoulder-surfed or keylogged.

#

Secure remote access to your desktop

Posted by: Anonymous [ip: 62.45.243.197] on October 08, 2007 03:07 PM
Just use SSH and strong passwords. Make sure they are really strong and not used anywhere else

#

Using NX

Posted by: Anonymous [ip: 67.122.246.158] on October 08, 2007 04:14 PM
Anybody know if NX's installation and configuration are reasonably simple these days? I have been trying to for the last couple of years, and its absurdly complicated installation and configuration keeps putting me off?

#

Secure remote access to your desktop

Posted by: Anonymous [ip: 10.2.115.107] on October 08, 2007 08:47 PM
Most port scans go through the first 0 - 1023 ports for vulnerability because it does not take long to scan and provide results. Anything beyond that will start to be time consuming which unless you ARE the target, the port scanner will keep moving until it finds another target with any open ports from 0 - 1023. I change my range for SSH to TCP 41022. From experience, I have port scanned 65554 ports and have taken about 16-20 hrs to complete. Again, unless you are the target, I don't think anyone will wait that long and move on to the one with open ports...there are tons out there.

#

Secure remote access to your desktop

Posted by: Anonymous [ip: 71.70.78.113] on October 09, 2007 03:56 PM
Great tutorial, but I'm confused about one thing. In sshd_config you have

Port 16949

but in your example invocation of ssh you have

ssh remote1776@remotekereki.homelinux.com:9622

Sorry to be obtuse, but wouldn't that amount to initiating the ssh connection on a port different than the one on which sshd is listening?

Thanks.

#

Secure remote access to your desktop

Posted by: Anonymous [ip: 10.2.115.107] on October 09, 2007 09:03 PM
9622 is the router port forwarding to 16949 on the ssh server. Basically, Any ssh incoming connections to remotekereki.homelinux.com on port 9622, send to internal 192.168.*.* with port 16949 open, authenticate with remote1776 and connect or remote1776@remotekereki.homelinux.com:9622 --> 192.168.100.1:16949 --> also known as NAT (Network Address Translation).

#

Re: Secure remote access to your desktop

Posted by: Anonymous [ip: 190.64.53.127] on December 01, 2007 02:48 PM
The command is wrong: it should be ssh -P 16949 .... though the setup is otherwise OK

#

Secure a bit more remote access to your desktop using knock.

Posted by: Anonymous [ip: 85.50.156.45] on December 01, 2007 04:01 AM
Why not to use knockd to open the desired port only after the correct knocking sequence and only for the correct knocking sequence + remote knocker IP.? See it at: http://www.zeroflux.org/cgi-bin/cvstrac.cgi/knock/wiki

#

This story has been archived. Comments can no longer be posted.



 
Tableless layout Validate XHTML 1.0 Strict Validate CSS Powered by Xaraya