Very Computer

You've closed off incoming packets with the SYN bit set. Since the
client initiates a telnet session I believe the first packet has to have
the SYN bit set to open the session. If in doubt do a "tail -f
/var/log/messages" while you try to start a telnet session from the
outside. You'll see whatever is being rejected. (assuming your rules log
denied packets)

Quote:> Questions:

> 1)  What's wrong with the above rules?
> 2)  Is this a _really_ bad idea or just not a good one?

In answer to question #2 my vote is *REALLY* bad, no offense intended.
Even if you restrict it to a *very* few addresses, the clients will be
transmitting their passwords to the entire world in clear text. Any
half-brain with a sniffer will have valid logins and passwords to your
boxes in no time. If you *really must* do this, look into SSH. At least
it encrypts the sessions.

just one guys $.02 worth

bryan
--
================================================================
Before you criticize someone, walk a mile in his shoes.
That way, if he gets angry, he'll be a mile away and barefoot.
================================================================

I have a RH6.1 system running with IP-Masq and IPChains running.  Everything
seems to work fine.  I got the firewall script from some web site and it
works well (grc.com) said everything was locked down.

I have a database on the box which everyone in our local network can access
via telnet.  What I'd like to do is allow a few clients to access the
application from the web.

When I shut down the firewall I can test access by dialing a separate ISP
and accessing the database via telnet ok.  However, when I restart the
firewall I get nothing.  I tried the following and still cannot gain access
to the database using telnet:

#
# TELNET server (23)
# ------------------
/sbin/ipchains -A output -i $EXTERNAL_INTERFACE -p tcp  \
               --source-port $UNPRIVPORTS \
               -d $IPADDR 23 -j ACCEPT

/sbin/ipchains -A input  -i $EXTERNAL_INTERFACE -p tcp ! -y \
               -s $IPADDR 23 \
               --destination-port $UNPRIVPORTS -j ACCEPT

#=======================================================================#
#
# TELNET client (23)
# ------------------
/sbin/ipchains -A output -i $EXTERNAL_INTERFACE -p tcp  \
               -s $IPADDR $UNPRIVPORTS \
               --destination-port 23 -j ACCEPT

/sbin/ipchains -A input -i $EXTERNAL_INTERFACE -p tcp ! -y \
               --source-port 23 \
               -d $ANYWHERE $UNPRIVPORTS -j ACCEPT

I know I'm opening up my site by allowing telnet access but I was thinking I
should be able to restrict access to selected IP addresses (or ranges if
some clients get dynamic IP addresses from their ISP).

Questions:

1)  What's wrong with the above rules?
2)  Is this a _really_ bad idea or just not a good one?

Thanks in advance.

Bill

Quote:> I have a RH6.1 system running with IP-Masq and IPChains running.
Everything
> seems to work fine.  I got the firewall script from some web site and it
> works well (grc.com) said everything was locked down.

> I have a database on the box which everyone in our local network can
access
> via telnet.  What I'd like to do is allow a few clients to access the
> application from the web.

> When I shut down the firewall I can test access by dialing a separate ISP
> and accessing the database via telnet ok.  However, when I restart the
> firewall I get nothing.  I tried the following and still cannot gain
access
> to the database using telnet:

> #
> # TELNET server (23)
> # ------------------
> /sbin/ipchains -A output -i $EXTERNAL_INTERFACE -p tcp  \
>                --source-port $UNPRIVPORTS \
>                -d $IPADDR 23 -j ACCEPT

> /sbin/ipchains -A input  -i $EXTERNAL_INTERFACE -p tcp ! -y \
>                -s $IPADDR 23 \
>                --destination-port $UNPRIVPORTS -j ACCEPT

> #=======================================================================#
> #
> # TELNET client (23)
> # ------------------
> /sbin/ipchains -A output -i $EXTERNAL_INTERFACE -p tcp  \
>                -s $IPADDR $UNPRIVPORTS \
>                --destination-port 23 -j ACCEPT

> /sbin/ipchains -A input -i $EXTERNAL_INTERFACE -p tcp ! -y \
>                --source-port 23 \
>                -d $ANYWHERE $UNPRIVPORTS -j ACCEPT

> I know I'm opening up my site by allowing telnet access but I was thinking
I
> should be able to restrict access to selected IP addresses (or ranges if
> some clients get dynamic IP addresses from their ISP).

> Questions:

> 1)  What's wrong with the above rules?
> 2)  Is this a _really_ bad idea or just not a good one?

> Thanks in advance.

> Bill

A cursory glance at the rules show that they  _appear_ to be correct
(although I've been at my keyboard for about 10 hours now, and my eyes are
tired).

** Added after I really looked at the rules:
It looks like you're not accepting the SYN packet necessary to open the
telnet session in the first place. For a telnet server, the option in the
rules should be
'-y' and not '! -y'
'! -y ' means: this packet is OK if it's not a packet with just SYN set (TCP
established session).

That being said, however, IMHO telnet is jst _bad_, and should die right
now. SSH or OpenSSH (my preference) is dead easy to set up, and even out of
the box allowing simple encrypted password auth (as opposed to the slightly
more secure RSA-only authentication method) is 1000% more secure than plain
telnet. SSH clients for encrypted-password auth are a dime a dozen, and some
of them are open sourced even for certain * closed-source dirty OS's
that shall remain nameless.

Just my $0.20 (adjusted for inflation and experience ;)   ).

WG

Quote:> I know I'm opening up my site by allowing telnet access but I was thinking
I
> should be able to restrict access to selected IP addresses (or ranges if
> some clients get dynamic IP addresses from their ISP).

> 2)  Is this a _really_ bad idea or just not a good one?

Both. :-). It's a bad idea because telnet still sends
login/password information in-the-clear, even if
you do restrict what IP addresses can use telnet.
Packet sniffers.....

Restricting what services you allow to certain
IP's is a step in the right direction though. I tend to
frown on a Pakistan IP address trying to access
anything on my system, for example.

Use ssh2 and restrict the IP address that can access
your ssh server/daemon. You'll be better off.

Actually, secure Telnet options are available, like SRP Telnet
(http://www.veryComputer.com/), that provide even better password
security than either UserAuthentication or RSAAuthentication in ssh,
so I'd consider those first.  You get secure authentication and
session encryption, and it's backward-compatible with standard Telnet,
so nobody has to remember any new commands or options.

Quote:> the box allowing simple encrypted password auth (as opposed to the slightly
> more secure RSA-only authentication method) is 1000% more secure than plain
> telnet. SSH clients for encrypted-password auth are a dime a dozen, and some
> of them are open sourced even for certain * closed-source dirty OS's
> that shall remain nameless.

SRP is 100% Open Source, and clients/servers are available for most
platforms, including the ones just mentioned.
--


  Phone: (650) 723-1565              exchange for security deserve neither."
   http://www.veryComputer.com/~tjw/   http://www.veryComputer.com/

Sounds interesting. Is the entire session encrypted or just the
authentication process. I took a quick peek at the link above, but I
couldn't really tell if it did or not.

Also any ideas where a person might find a windoze client?

Bryan Packer

--
================================================================
Before you criticize someone, walk a mile in his shoes.
That way, if he gets angry, he'll be a mile away and barefoot.
================================================================

The entire session is encrypted, and the login process is protected
from both active and passive network attack.

Quote:> Also any ideas where a person might find a windoze client?

Both Kermit95 and NetTerm, for starters, support SRP authentication
with full session encryption.

Quote:> Bryan Packer

> --
> ================================================================
> Before you criticize someone, walk a mile in his shoes.
> That way, if he gets angry, he'll be a mile away and barefoot.
> ================================================================

--


  Phone: (650) 723-1565              exchange for security deserve neither."
   http://www-cs-students.stanford.edu/~tjw/   http://srp.stanford.edu/srp/