Is allowing syn packets on port 22 (ssh) a problem? - Security

This is a discussion on Is allowing syn packets on port 22 (ssh) a problem? - Security ; Hi All, I have a customer that just installed "no machine" ( http://www.nomachine.com/ ) on one of his Linux firewall/servers. (It is a cross between x terminal server and Citrix for windows.) Clients contact this server over ssh (port 22). ...

+ Reply to Thread
Results 1 to 2 of 2

Thread: Is allowing syn packets on port 22 (ssh) a problem?

  1. Is allowing syn packets on port 22 (ssh) a problem?

    Hi All,

    I have a customer that just installed "no machine"
    (http://www.nomachine.com/) on one of his Linux
    firewall/servers. (It is a cross between x terminal server
    and Citrix for windows.) Clients contact this server
    over ssh (port 22).

    I was about to do the following on a customer's
    iptables firewall

    $tbls -A dsl-in -i eth1 -p tcp --syn -s $ANY_IP \
    --sport $allports -d $eth1_addr --dport ssh -m state \
    --state NEW -j ACCEPT

    $tbls -A dsl-in -i eth1 -p tcp ! --syn -s $ANY_IP \
    --sport $allports -d $eth1_addr --dport ssh -m state \
    --state ESTABLISHED -j ACCEPT

    but, thought I'd better ask if allowing syn packets (--syn)
    open to port probes was a problem. Seems to me that somewhere
    I vaguely remember the occasional security problems with ssh that
    might allow a port prober to take over a machine.

    Any words of wisdom?

    Many thanks,
    -T

  2. Re: Is allowing syn packets on port 22 (ssh) a problem?

    On Sat, 05 Apr 2008, in the Usenet newsgroup comp.os.linux.security, in article
    , ToddAndMargo wrote:

    > I have a customer that just installed "no machine"
    >(http://www.nomachine.com/) on one of his Linux
    >firewall/servers. (It is a cross between x terminal server
    >and Citrix for windows.) Clients contact this server
    >over ssh (port 22).


    What a wonderful idea - having client services on a firewall box. If
    the users can kick over one of the clients, they can also 0wn the
    firewall.

    > I was about to do the following on a customer's
    >iptables firewall
    >
    > $tbls -A dsl-in -i eth1 -p tcp --syn -s $ANY_IP \
    > --sport $allports -d $eth1_addr --dport ssh -m state \
    > --state NEW -j ACCEPT
    >
    > $tbls -A dsl-in -i eth1 -p tcp ! --syn -s $ANY_IP \
    > --sport $allports -d $eth1_addr --dport ssh -m state \
    > --state ESTABLISHED -j ACCEPT


    That will allow anyone to connect to the SSH port on the 'eth1' side of
    the box. If they also have an account/authentication, they will be able
    to log in. Is that the intent? (Comment: We have no idea what eth1
    may be connected to - inside, outside, the world...) The --syn and NEW
    relate to establishing a TCP connection. The second rule allows them
    for established connections (there should be no case for SYN flags on
    an ESTABLISHED connection - SYN is used to start a new connection).

    >but, thought I'd better ask if allowing syn packets (--syn)
    >open to port probes was a problem. Seems to me that somewhere
    >I vaguely remember the occasional security problems with ssh that
    >might allow a port prober to take over a machine.


    Is the intent to allow anyone to connect? From where? At work, I'll
    only state that the connections are restricted. At home, the SSH
    server is accessible from a /22 and two /24s "outside" because I can't
    see any reason to allow connections from you or anyone else that I
    haven't approved in advance, and I really don't expect authorized users
    to be connecting from Korea, Kenya, Kuwait or Kazakhstan or a lot of
    other places either.

    If you haven't been studying the HOWTOs from
    http://www.netfilter.org/documentation/HOWTO/ you probably should. As
    for the flags, if you haven't had time to read W. Richard Stevens book
    "TCP/IP Illustrated Volume 1" (ISBN 0-201-63346-9, 1994, 1996, 576 pgs,
    $EXPENSIVE), use a packet sniffer to observe the start of a connection,
    or google for 'three-way handshake'.

    Old guy

+ Reply to Thread