Re: Questions on secure remote access to Fedora Core 2

"C. J. Clegg" <> (06-10-26 01:27:01):

I am somewhat new to Internet security solutions in general and Linux
security in particular, though I have a fair amount of experience with
Linux generally.

Now that you say that everything works, I'd like to clear a few things
up, as it seems that there is a lot of misconception.

I am setting up a server with Fedora Core 2 (there are specific
reasons why this server needs to run FC2 and not something newer like
FC5/6). I want HTTP to be open to everyone. Everything else needs to
be open only to certain trusted individuals via certain trusted hosts
and needs to be locked up tight to everyone else. Right now, this is
all controlled by hosts.allow and hosts.deny (hosts.deny contains ALL:
ALL, hosts.allow enables access to ALL from four trusted hosts, and
all servers are turned off except httpd, sshd, and ftpd).

The first thing is: host-based filtering is bad -- really bad! It's
not secure at all, because hostnames (e.g. IP addresses) can be forged.
It's not trivial, but it's also not too difficult. Base authentication
on something else.

The problem is that those certain trusted individuals all have DSL
with dynamic IP addressing and so I would have to open up a whole
netblock from their ISPs (Comcast) in order to be sure to allow them

Also, these people travel from time to time, and they need access from
"wherever" while they're traveling. That's not currently available
with the current setup.

Whether that is a problem is a matter of view. This forces you to use
secure authentication mechanisms. You can still restrict the range of
permitted source hostnames, which adds a bit of security, but not much.

What is the most secure method I can use to give these individuals
access from wherever they are, while minimizing risk from intruders?

The users should generate themselves key pairs for SSH access. My
concept would be to use rsync [1] to retrieve a local copy of the data
on the server, work on it, and then send it back. As rsync reduces
bandwidth by only sending the differences (as far as possible), this
also reduces network traffic greatly.

If you really need a live connection to the server (which I can't
imagine), then SFTP is probably a good idea. If all machines are
Linux-based, then Network Block Devices [2] are a good idea, too. They
can be encrypted/decrypted locally, such that no single plain-text byte
ever enters the wire. But I think, that would go too far for a

I've been reading up on Virtual Private Networks (VPN) over the last
couple of days but it seems that they are mostly intended to link up
two private LANs, not provide secure access to a publicly-visible

Cryptographic VPNs are also a very good idea to protect not only file
data, but any data that is passed through the network. VPNs can be used
to create a virtual network inside of an existing one. To the user it
appears just like any other network, but everything in it is encrypted
and authenticated.

I have been told that I can enable only ssh (and not telnet or rlogin
or ftp or etc.) and that trusted users can tunnel other protocols
(e.g. ftp) under ssh. That sounds interesting but is that really the
most secure way?

There is no "most secure way". There are several concepts to achieve
the same goal. In your case, I would clearly recommend a secure VPN.
As always, I recommend the OpenVPN [3] package for this. However, it
might be not trivial to set up for a beginner. First you should get
some basic understanding of cryptography, how you can use it, and what
it's good for (it's not only good to scramble data, you can do a lot of
useful things with it).

Anyway I am unclear on just what it is that makes ssh more secure
than, say, telnet. If I set up sshd and someone has an ssh client on
their computer, and they know a valid userID and password on my
machine, then they're in just as easily with ssh as with telnet, near
as I can see.

Like others have already stated, Telnet is totally in plain-text. You
certainly know that networks can be intercepted easily, don't you? SSH
works around this, but the problem is only solved, when you set it up
properly. You should use key-based authentication in both directions
(not only should the server authenticate the client, but the client
should also make sure he is talking to the right server).

As you can see I'm pretty short on clues when it comes to this
security stuff, so if anyone can (a) suggest the most secure way to
allow remote access and (b) point to a website or tutorial or two that
I can study that tells all about (a), that would be a very big help
and much appreciated.

Again: There is no most secure or most suitable way. It depends on the
environment, the network model, as well as a bit on personal taste.
Read some general introduction into cryptography and why you can't live
without it.



Relevant Pages

  • Re: 2003 Security -- IIS w/ incoming VPN connections
    ... Then buy a NetScreen Neoteris device from Juniper Networks which can provide a secure access point to your internal we server and allow access to no other boxes on your network. ... I've got to relocate a 2003 IIS box from my LAN to a direct Internet ...
  • Questions on secure remote access to Fedora Core 2
    ... I am somewhat new to Internet security solutions in general and Linux ... I am setting up a server with Fedora Core 2 (there are specific reasons ... What is the most secure method I can use to give these individuals access ... under ssh. ...
  • Public Authentication Problem on Batch Job using SCP2 when SSH Client Reboot
    ... to a SSH server, HOST2. ... for secure ftp login. ... The login ID is a local user account ... we found that scp2 run failed every time the SSH client ...
  • Re: FreeBSD 8.0 - network stack crashes?
    ... If memory serves me right, sometime around 10:52am, Weldon S Godfrey 3 told me: ... Something happens to the stack that causes processes accessing the network to just hang. ... Always, you can't ssh or telnet out, and nothing can access the NFS shares on the server. ...
  • Re: outstanding challenge
    ... >> down the network is not ours to break. ... >> SYSDOOR will not take legal action against anyone trying to log in to this ... They claim it's secure, the actual OS, the kernel, etc. Hmmmmm. ... Server admin, support & programing for shared & dedicated web servers ...