Questions on secure remote access to Fedora Core 2 - Security

This is a discussion on Questions on secure remote access to Fedora Core 2 - Security ; 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. I am setting up a server with Fedora Core 2 (there are specific reasons ...

+ Reply to Thread
Results 1 to 12 of 12

Thread: Questions on secure remote access to Fedora Core 2

  1. Questions on secure remote access to Fedora Core 2


    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.

    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 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 in.

    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.

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

    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 server.

    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?

    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.

    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.

    Thanks.... CJ


  2. Re: Questions on secure remote access to Fedora Core 2

    C. J. Clegg wrote:

    > Anyway I am unclear on just what it is that makes ssh more secure than,
    > say, telnet.


    Telnet sends passwords and data in clear text, so anyone that can see the
    packets (using a sniffer) as they are transmitted over the network, can get
    the password and the data. With ssh, both the password and the data are
    encrypted, so neither can be read using a sniffer. If you do nothing else,
    switching from telnet to ssh, ssh will secure your data and password as
    they transverse an insecure net. That said, there is, as you say below,
    other issues...

    > 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.


    Unless you use "keys" with passphrases.

    http://www.securityfocus.com/infocus/1810


  3. Re: Questions on secure remote access to Fedora Core 2

    On 2006-10-26, C. J. Clegg wrote:
    >
    > 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 server.


    That's not really true. You can use openvpn to link up a remote client
    to a server on site pretty easily. IIRC they have docs on this
    configuration (it's not trivial).

    > 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?
    >
    > 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.


    With telnet it's easy to sniff passwords because it's unencrypted. With
    ssh it's not easy to sniff passwords because it's encrypted. The
    encryption is not impossible to crack, but it's not at all easy.

    If all your users need is command-line access, ssh, scp, and sftp will
    be plenty secure unless you're incredibly paranoid. You can provide
    https access, as well, for encrypted web applications. The only hitch
    is email, which doesn't really support encryption directly, but if
    that's an issue you can have your users use an MUA that can use PGP or
    gpg, and they can use that for encrypting the body of their email.

    --keith

    --
    kkeller-usenet@wombat.san-francisco.ca.us
    (try just my userid to email me)
    AOLSFAQ=http://www.therockgarden.ca/aolsfaq.txt
    see X- headers for PGP signature information


  4. Re: Questions on secure remote access to Fedora Core 2


    Keith and left_coast;

    Thanks much for your help. I am most of the way to where I need to be
    thanks to you.

    One other question... If I try to upgrade this server to Fedora Core 5,
    I'm going to be in for a very big fight (don't ask ).

    I don't mind fighting the fight if it will be truly worth it, so my
    question is ... is there any aspect of FC2 that is inherently dangerous
    and insecure that got fixed by the time FC5 came out?


  5. 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
    > in.
    >
    > 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
    beginner.


    > 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
    > server.


    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.


    Regards,
    E.S.



    References:
    [1] http://rsync.samba.org/
    [2] http://nbd.sourceforge.net/
    [3] http://openvpn.net/

  6. Re: Questions on secure remote access to Fedora Core 2

    On 2006-10-26, C. J. Clegg wrote:
    >
    > One other question... If I try to upgrade this server to Fedora Core 5,
    > I'm going to be in for a very big fight (don't ask ).
    >
    > I don't mind fighting the fight if it will be truly worth it, so my
    > question is ... is there any aspect of FC2 that is inherently dangerous
    > and insecure that got fixed by the time FC5 came out?


    Seems unlikely, but if this machine is supposed to be a server-class
    machine, you might consider using something more along the lines of
    CentOS. Fedora is intended to be more bleeding-edge, and so may not be
    quite as stable and well-tested as CentOS (well, tested by proxy,
    anyway, through RHEL). You could probably get away with minor
    patches to FC2, but I would not take my word for it, as I'm not a Fedora
    user.

    --keith


    --
    kkeller-usenet@wombat.san-francisco.ca.us
    (try just my userid to email me)
    AOLSFAQ=http://www.therockgarden.ca/aolsfaq.txt
    see X- headers for PGP signature information


  7. Re: Questions on secure remote access to Fedora Core 2


    On Fri, 27 Oct 2006 01:42:21 +0200, Ertugrul Soeylemez wrote:

    > 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.


    Good evening, E.S.

    I don't know if I'd say "everything works", exactly :-) ... It's getting
    there, actually getting there faster than I thought it would (thanks
    mostly to you guys), but it still has a ways to go.

    As for misconception ... uh huh, lots and lots of that :-). Again, thanks
    to you guys, it's being chipped away bit by bit.

    > 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.


    Right, I actually learned this the hard way not so very long ago. :-\

    I'm using host-based filtering only as one (minor) tool in the toolbox
    among some more powerful ones. As you say, it adds a bit of security, and
    every little bit helps these days.

    > If you really need a live connection to the server (which I can't
    > imagine), then SFTP is probably a good idea.


    Yeah, we do need that. We need to store things on a secure FTP server,
    and also are using Subversion for document revision control. So far I
    have SFTP working, and svn+ssh is sort of working. Haven't figured out
    how to generate and apply keys yet, but that's next.

    > 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.


    That's the first I've heard of Network Block Devices. I'll study up on
    that. It sounds like a useful tool.

    However ... if I'm using only SSH-based connections (SSH, SFTP, svn+ssh),
    don't they also prevent a single plain-text byte from entering the wire?

    > 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.


    Would a cryptographic VPN be "better" than SSH and friends, assuming I get
    the SSH keys set up correctly?

    I think that what I would like to do is finish up a correct and secure
    implementation of SSH and friends, since that's sort of "almost" working,
    and then once that is up and running, I can start studying up on OpenVPN.
    Does that sound like a reasonable approach?



  8. Re: Questions on secure remote access to Fedora Core 2

    On Thu, 26 Oct 2006 17:14:42 -0700, Keith Keller wrote:

    > Seems unlikely, but if this machine is supposed to be a server-class
    > machine, you might consider using something more along the lines of
    > CentOS.


    Hmmm ... CentOS ... that's another new one on me.

    Anyway, though, for all practical purposes we're stuck with FC2 ...
    changing to anything else (CentOS or FC5/6 or ??) would be an unreasonably
    large issue to resolve, as I said I'd rather not fight that fight unless
    it's really of clear benefit security-wise.

    We've been running a high-traffic web site on that FC2 machine for a
    couple of years and it has been rock-solid (that's why I need to allow
    open HTTP access on this machine and restrict access to everything else).
    There are also some local users that do various things on that machine
    that depend on FC2, and that's why it would be such a fight to change.

    Yeah, I know ... we should use separate servers for the secure remote
    access stuff and the open HTTP / local use stuff. Unfortunately it ain't
    gonna happen, so we play the cards we are dealt.



  9. Re: Questions on secure remote access to Fedora Core 2

    "C. J. Clegg" (06-10-26 20:44:50):

    > > If you really need a live connection to the server (which I can't
    > > imagine), then SFTP is probably a good idea.

    >
    > Yeah, we do need that. We need to store things on a secure FTP
    > server, and also are using Subversion for document revision control.
    > So far I have SFTP working, and svn+ssh is sort of working. Haven't
    > figured out how to generate and apply keys yet, but that's next.


    By a "live connection", I mean such things as streaming media or mail
    reading via IMAP, or even chat systems. Subversion only needs a
    connection when committing something or checking something out (of
    course a few other things, too). One idea of CVS and Subversion is to
    eliminate the need for a live connection.


    > > 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.

    >
    > That's the first I've heard of Network Block Devices. I'll study up
    > on that. It sounds like a useful tool.


    They won't be much useful in your case. I thought of a file server,
    where each user gets reserved a certain amount of hard disk space, which
    he can use as he likes (and thus also encrypt it).


    > However ... if I'm using only SSH-based connections (SSH, SFTP,
    > svn+ssh), don't they also prevent a single plain-text byte from
    > entering the wire?


    They should, but you won't do everything via SSH or SSL. There are a
    number of things, which always remain plain-text, like DNS queries,
    pings, etc. Some of them can be configured to use cryptographic
    techniques, too (like DNS), but soon you'll get frustrated, if you're
    going to fill every tiny gap by hand ...


    > > 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.

    >
    > Would a cryptographic VPN be "better" than SSH and friends, assuming I
    > get the SSH keys set up correctly?


    .... and that is where a secure VPN is better. As said: No single bit
    of plain-text information ever leaves any of the hosts. A VPN is also
    virtual in that it's independent of the host network. You can create a
    VPN over a serial cable or through your toaster (possibly including your
    toaster as a host). This means, you can also stretch a VPN over the
    entire internet.

    An important fact is that you can only communicate with the participants
    securely. All others get plain-text from you (unless you use something
    like SSH, of course). In Linux, you can also prohibit routing to hosts
    outside the VPN. That's useful, if the VPN is inside a LAN, and there
    is no or limited interest in accessing the internet.


    > I think that what I would like to do is finish up a correct and secure
    > implementation of SSH and friends, since that's sort of "almost"
    > working, and then once that is up and running, I can start studying up
    > on OpenVPN. Does that sound like a reasonable approach?


    Yes, you can convert your normal network into a VPN almost without
    changes. Just create the VPN interface and change routing information
    accordingly.


    Regards,
    E.S.

  10. Re: Questions on secure remote access to Fedora Core 2


    Heartfelt thanks to all of y'all who gave me so much help on the security
    questions, and everyone else who replied to the "Disabling telnet on
    Linux" thread.

    After most of a day of research on iptables, and a bunch of trial and
    error, I came up with the following /etc/sysconfig/iptables file (I hope
    the formatting doesn't get screwed too badly):

    :INPUT ACCEPT [0:0]
    :FORWARD ACCEPT [0:0]
    :OUTPUT ACCEPT [0:0]
    :RH-Firewall-1-INPUT - [0:0]
    #
    -A INPUT -j RH-Firewall-1-INPUT
    #
    -A FORWARD -j RH-Firewall-1-INPUT
    #
    -A OUTPUT -o lo -p tcp --dport 143 -j RETURN
    -A OUTPUT -o lo -p tcp --sport 143 -j RETURN
    -A OUTPUT -m state --state NEW -m tcp -p tcp --dport 21 -j DROP
    -A OUTPUT -m state --state NEW -m tcp -p tcp --dport 23 -j DROP
    -A OUTPUT -m tcp -p tcp -d aaa.bbb.0.0/16 --sport 22 -j RETURN
    -A OUTPUT -m tcp -p tcp -d ccc.ddd.0.0/16 --sport 22 -j RETURN
    -A OUTPUT -m tcp -p tcp -d eee.fff.ggg.0/24 --sport 22 -j RETURN
    -A OUTPUT -m tcp -p tcp --sport 25 -j RETURN
    -A OUTPUT -m tcp -p tcp --dport 25 -j RETURN
    -A OUTPUT -m tcp -p tcp --sport 80 -j RETURN
    -A OUTPUT -p icmp --icmp-type any -j RETURN
    -A OUTPUT -p udp --dport 53 -j RETURN
    -A OUTPUT -j LOG
    #
    -A RH-Firewall-1-INPUT -i lo -j ACCEPT
    -A RH-Firewall-1-INPUT -p icmp --icmp-type any -j ACCEPT
    -A RH-Firewall-1-INPUT -p 50 -j ACCEPT
    -A RH-Firewall-1-INPUT -p 51 -j ACCEPT
    -A RH-Firewall-1-INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
    -A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 80 -j ACCEPT
    -A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 443 -j ACCEPT
    -A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 21 -j ACCEPT
    -A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 22 -j ACCEPT
    -A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 25 -j ACCEPT
    -A RH-Firewall-1-INPUT -j DROP
    COMMIT

    Objectives:

    1. Keep HTTP and HTTPS open for everybody

    2. Open inbound SSH, FTP, and mail for everybody ... but, they are
    severely restricted in /etc/hosts.allow, and the few allowed FTP users are
    kept in chroot jails. FTP is really just needed for three individual
    users who for whatever reason can't use SFTP.

    3. Disable outgoing telnet and FTP

    4. Log all other outbound activity EXCEPT: SSH going to three trusted
    networks; any SMTP, HTTP, DNS activity; any pings; any IMAP activity on
    the localhost.

    I used DROP rather than REJECT because I don't want messages going out
    explaining why the connection is being rejected.

    Look reasonable?


  11. Re: Questions on secure remote access to Fedora Core 2

    On Sun, 29 Oct 2006, in the Usenet newsgroup comp.os.linux.security, in article
    , C. J. Clegg wrote:

    >3. Disable outgoing telnet and FTP


    All you are doing is blocking access to those well known ports. That doesn't
    stop anyone from using telnet or ftp to access remote servers on non-standard
    ports.

    >4. Log all other outbound activity EXCEPT: SSH going to three trusted
    >networks; any SMTP, HTTP, DNS activity; any pings; any IMAP activity on
    >the localhost.


    This statement is ambiguous.

    >I used DROP rather than REJECT because I don't want messages going out
    >explaining why the connection is being rejected.


    Care to expand on this?

    Old guy

  12. Re: Questions on secure remote access to Fedora Core 2

    C. J. Clegg wrote:

    >
    > Heartfelt thanks to all of y'all who gave me so much help on the security
    > questions, and everyone else who replied to the "Disabling telnet on
    > Linux" thread.
    >
    > After most of a day of research on iptables, and a bunch of trial and
    > error, I came up with the following /etc/sysconfig/iptables file (I hope
    > the formatting doesn't get screwed too badly):


    [...]

    Hey C. J., Glad you feel better. Actually iptables, a good interface for
    netfilter, a good firewall, makes me "crazy" to read. I won't expand on
    that or complain for the good tools that have been given to us freely.

    What you see with # iptables --list is not what you put in with # iptables
    .... commands. What you define for commands makes several orders of
    magnitude more sense if one knows the precise topology and traffic
    requirements, and other contexts. I can't read or decipher it, even if it
    weren't (evilly?) reformatted by the Usenet softwarez

    When you have your systems running as you think you would like them, nmap
    them from inside and scan them from outside to test them. Other people
    may have fancier (more effective, more elegant) approaches, and they might
    write to say what they are. I suggest you go to grc.com (Gibson Research)
    and go to the "shieldsup" page, clicking through cookies and proceeds and
    all (many clicks). He gives you the options to scan your interface many
    ways and report the results to you.

    If you have no better, more expensive, more proprietary, more private way
    of testing your systems' external appearance, then click away to your
    hearts' content, and see what your systems look like to someone else on
    the outside trying to scan you or trying to crack you. It is pedestrian,
    for sure. But it works.

    There are always commercial pen-test services available if judged to be
    necessary or desirable. Ask and you will receive. If the powers that be
    insist on running FC2 on their server, they probably don't want to know,
    anyway.

    And OK, so I'm not really a full newbie anymore and have a tendency to be
    less insecure and perhaps even slightly complacent. Even experts get
    cracked. But I wouldn't ever even be posting my firewall rules on usenet.
    Don't worry about it; - if the rules are good, they will hold regardless.

    > COMMIT
    >
    > Objectives:
    >
    > 1. Keep HTTP and HTTPS open for everybody
    >
    > 2. Open inbound SSH, FTP, and mail for everybody ... but, they are
    > severely restricted in /etc/hosts.allow, and the few allowed FTP users are
    > kept in chroot jails. FTP is really just needed for three individual
    > users who for whatever reason can't use SFTP.
    >
    > 3. Disable outgoing telnet and FTP
    >
    > 4. Log all other outbound activity EXCEPT: SSH going to three trusted
    > networks; any SMTP, HTTP, DNS activity; any pings; any IMAP activity on
    > the localhost.
    >
    > I used DROP rather than REJECT because I don't want messages going out
    > explaining why the connection is being rejected.
    >
    > Look reasonable?


    I would tell you if I knew. Best wishes.

+ Reply to Thread