DSL and Cable Modem Security
This is an ancient post with no relevance to modern systems.
This article is generally about using SCO OSR5 as your machine.
However, the concepts of using ssh to secure communications apply
to any OS.
Although high speed internet access may not have reached you
yet, it probably will soon. The advantages are obvious, but there's
a dark side: security. I'm not going to talk about the more general
aspects of securing your system here (I've done that in General Security), but only
specifically about the issue of clear text passwords with telnet,
pop, and ftp.
Out with the old, in with the new
Just because you have high speed access doesn't mean you
necessarily want to give up your present ISP. You may not want to
change your email address. You may have a web site that you need to
maintain with ftp. That's my situation: my ISP hosts my mail and my
web site, and I have no interest in changing that.
By the way, a few things you need to think about if you are
planning such a move:
- Does the DSL/Cable ISP have an SMTP server you can use for
outgoing mail? The answer is almost certainly yes, but it doesn't
hurt to ask. Ask if they have a back-up server in case that one has
problems. That was a very nice feature I had with my dial-up ISP-
it was rare for the primary to have any problem, but once every
year or so it would, and I' d just switch to the secondary.
- Do they have an NNTP (news) server? This may or may not be
important to you, but if it is important, you'll want to ask
questions about the groups they carry and the article retention
- Are you getting a fixed IP address or will it be DHCP? You may
have reason to need a static address, or you may not.
- Do they care if you are not running Windows? If so, find
- Do they care if you use NAT or a Proxy to allow machines on
your internal lan to access the net through this machine?
- Does their router/modem provide any security? If so, it's
important to understand what, both for its limitations and in case
it blocks something you need to provide. You can get some idea of
your security status by using an external scanning tool like those
available at http://www.grc.com/default.htm.
When I used that on my DSL line, I got informative messages on my
screen that someone might be trying to break in.
- If you are keeping your current ISP for mail, how are you going
to get it? Will your ISP allow remote POP/IMAP access or will you
In the clear
Pop, telnet, and ftp all use clear-text passwords- that is, the
passwords would be totally visible to someone snooping network
traffic. That's not necessarily a problem with a dial-up line (see
the General Security article) but it could be a problem with DSL
and it is definitely a concern with cable modems.
Fortunately, there's a solution: SSH. I'm not going to comment
very much here on how you get ssh or whether or not you need a
license. This is a very confused subject due to ridiculous U.S.
export restrictions (ssh comes from Sweden, but the U.S. government
says that if a U.S. citizen downloads it from Sweden or anywhere
else in the world, they can't then export it!) and the licensing is
confused just because ssh makes it confusing. The older versions
are definitely license-free for non-commercial use, but the
definition of non-commercial is confusing. So I'm going to neatly
bypass all of that and just assume you have ssh available and have
the right to use it.
Ssh replaces telnet. Of course that's not all that it does, but
for a beginning, that's how you'll want to test it. Naturally, your
ISP has to run the sshd daemon- fortunately mine does.
ssh -l username yourisp.com
will attempt to login to "yourisp.com" as "username". It will
ask you for your password, and from that point on it looks like a
telnet session (well, not really: telnet escape keys don't work,
for example). The entire session is encrypted, from the entry of
your password right up until you log out. Nothing you do while
logged in can be seen by someone sniffing the network.
You'd think that wouldn't help you with ftp, but ssh has more
tricks up its sleeves.
ssh -l username -L 1800:yourisp.com:21 yourisp.com
logs you in, just as before, but it also sets up a trap on port
1800, and that trap will just take anything that tries to use port
1800 on your local machine and forward it to port 21 (ftp) on
yourisp.com. You can see that it does that by opening a different
window on your home machine and trying:
telnet localhost 1800
(don't do this from the login you made using ssh above; that
won't get you anything useful)
The choice of 1800 is arbitrary and might not work if by chance
port 1800 is already in use. If that is the case, just try another
port. You can see ports in use with "netstat -a".
Yes, that's right: you telnetted to port 1800 on your
local machine, but you end up connected to the ftp server at
your ISP (type "quit" to exit). What's the point? The point is that
the connection is now encrypted because it goes through ssh. Note:
this obviously isn't usually important for anonymous ftp-
this is for sites that you must log in to as a real user, such as
your hosted web site, where you need to upload files. The point is
that you do not want anyone to be able to see your login and
If you have root access, you can set this up on port 21. You'll
need to comment out "ftpd" in /etc/inetd.conf, and send a "kill -1"
to the inetd daemon before you can do that, but then there wouldn't
be any need to use 1800 as a port number,
Unfortunately, that's not quite enough. You need an ftp client
that can be told to connect to port 1800 instead of the 21 it would
default to, and you also need an ftp client that can do "passive"
transfers. Why? Because your firewall should be set not to accept
incoming connections, and keep in mind that this is
important for both anonymous and authenticated ftp.
Ftp is a little different than most protocols. When you connect
to an ftp server, you connect on what's called the "Control" port
(that's port 21). When you want to transfer a file, the ftp server
opens a data connection back to you (using port 20). There's two
connections: one that you originated, and one that the server
opened for data. And there's the problem for most firewalls: they
block that data connection because it comes from outside.
Ian Peattie noted in a comp.unix.sco.misc posting that there is
another way to solve the FTP problem:
To get round this, you can use an FTP proxy.
Luckily, IPNAT comes with an FTP proxy built in to it. If you
change your IPNAT rules to:
map net1 172.16.1.0/24 -> 0.0.0.0/32 proxy port ftp ftp/tcp
map net1 172.16.1.0/24 -> 0.0.0.0/32
then IPNAT will watch for the connection coming
back from the remote server and will forward it on to the PC.
Passive ftp works by the client (that's you) telling the server
to use Passive mode-the client opens it's own data connection, and
the server uses that. The server is being "passive"- it isn't
actively opening connections. For your typical firewall, that's
much easier- the connection originates inside the firewall,
therefore it's OK (though the firewall does usually have to be told
that this is OK ahead of time).
An ftp client that answers both of these problems (and is more
than slick in other respects also) is "ncftp", which is freely
available on the web and from Skunkware. One caveat,
though, at least for the SCO Skunkware version I used while writing
this article: don't run ncftp as root. It's not that it won't work,
or that there's some awful security hole- the problem is just that
it's a little broken and doesn't properly create the bookmark and
preferences files for the root user. These are supposed to go into
$HOME/.ncftp, which is supposed to be created on first use of
ncftp, but it doesn't work for root. You shouldn't be using root
for ordinary work anyway.
Yet another way to have secure ftp is SecureFTP, which is a Java based
product for Unix or Windows.
Jean-Pierre Radley tells me that ncftp's "root" problem
can be fixed by adding "NCFTPDIR=/.ncftp" to root's
This is what an ncftp "bookmark" looks like:
Bookmark name: yourisp.com
Transfer type: Binary
Has SIZE command: Yes
Has MDTM command: Yes
Can use passive FTP: Yes
Operating System: UNIX
To create a new bookmark, type "hosts" at the ncftp prompt and
follow the directions. The only things you'll need to change are
the port (if you are not using port 21) and the "Can use Passive
FTP" (it's No by default). Make sure that the Hostname is
"localhost"- you can name the bookmark anything, but it's got to
connect to "localhost".
The other thing you need is to change your preferences so that
it will use passive ftp. Type "prefs"
Default open mode: anonymous
Anonymous password: [email protected]
Blank lines between cmds: Yes
Default FTP mode: Passive, but fall back to port if needed
(rest of preferences ommitted)
It's the "Default FTP mode" that you have to change to use
Passive. Once this is all configured as shown, an "ncftp
yourisp.com" (note that's the Bookmark name; it's really connecting
to localhost) will connect to your ISP and your control channel
(which is where your password would appear) is secure. Your data
channel is not, but that's unlikely to be a problem, and you could
always separately encrypt anything that was.
For pop, you probably want to use the actual pop port, because
many pop clients just assume 110 and can't be configured otherwise.
I had a pop client that I could configure, but for some reason that
still didn't work for me, and as my primary need (Netscape) insists
on using 110, that's what I did. That means taking POP3 out of
/etc/inetd.conf (and you wouldn't want to be running it there
anyway) and making a connection to your old ISP like this:
ssh -l username -L 110:yourisp.com:110 yourisp.com
Bruce Garlock pointed out that you can make Netscape use a
different port simply by entering (for example) localhost:1810 in
the Incoming Mail Server Name box. That does work, thanks
Note that there's no reason to make two connections if you also
want to use ftp:
ssh -l username -L 21:yourisp.com:21 -L 110:yourisp.com:110 yourisp.com
will take care of both forwardings at the same time.
Now all you have to do is tell your pop client (Netscape, etc.)
that you want it to use "localhost" instead of your ISP. That's all
it takes; the actual session will be forwarded to your ISP by ssh,
and it will be secure. Don't forget that you'll need to point your
SMTP at your new ISP's mail server and also News if you read news
See also Spamassassin (specifically
for Mac OS X, but would apply to any Unixy OS).
You can also use "scp" to copy files. Let's say I want to copy
"index.html" from my current directory to another machine. I might
scp index.html [email protected]:/www/newstuff/index.html
I'd be asked for my password, and then the file would be
Note: if this looks like it's going to work, but then says "scp
not found", it is the OTHER end that is missing (or lacks a PATH
to) scp. The other end could have sshd and not have scp.
Publish your articles, comments, book
reviews or opinions here!
© February 2000 A.P. Lawrence. All rights
If this page was useful to you, please help others find it:
More Articles by Tony Lawrence
- Find me on Google+
Have you tried Searching this site?
Unix/Linux/Mac OS X support by phone, email or on-site:
This is a Unix/Linux resource website. It contains technical articles about Unix, Linux and general computing related subjects, opinion, news, help files, how-to's, tutorials and more. We appreciate comments and article submissions.
Publishing your articles here
Jump to Comments
Many of the products and books I review are things I purchased for my own use. Some were given to me specifically for the purpose of reviewing them. I resell or can earn commissions from the sale of some of these items. Links within these pages may be affiliate links that pay me for referring you to them. That's mostly insignificant amounts of money; whenever it is not I have made my relationship plain. I also may own stock in companies mentioned here. If you have any question, please do feel free to contact me.
I am a Kerio reseller. Articles here related to Kerio products reflect my honest opinion, but I do have an obvious interest in selling those products also.
Specific links that take you to pages that allow you to purchase the item I reviewed are very likely to pay me a commission. Many of the books I review were given to me by the publishers specifically for the purpose of writing a review. These gifts and referral fees do not affect my opinions; I often give bad reviews anyway.
We use Google third-party advertising companies to serve ads when you visit our website. These companies may use information (not including your name, address, email address, or telephone number) about your visits to this and other websites in order to provide advertisements about goods and services of interest to you. If you would like more information about this practice and to know your choices about not having this information used by these companies, click here.