[141] in linux-security and linux-alert archive
rsh et al.: Linux's ipfw seems to solve the practical problem.
daemon@ATHENA.MIT.EDU (Andrew Cromarty)
Mon Mar 13 07:38:32 1995
Date: Mon, 13 Mar 95 01:51 PST
From: andy@distrib.com (Andrew Cromarty)
To: linux-security@tarsier.cv.nrao.edu
CC: panzer@dhp.com
Reply-To: linux-security@tarsier.cv.nrao.edu
Matt (panzer@dhp.com) wrote:
> : rlogin tells the other side "this user is called wolff, can you let him
> : in". If you allow rlogind to accept this from any port, any user could
> : write a new rlogin program that pretends to be anyone
> The whole "r" program problem is always a pain. If you have a local
> cluster of machines you run, you want people to be able to rsh back and
> forth around them and not worry about having to type their passwords
> again. Though you want to prevent any attempt at doing this from the
> outside including if these users have + + in their .rhosts file due to
> some "mistake".
It seems most of us run Linux either as a standalone system
(e.g. using SLIP/PPP) or on an Internet-connected LAN. I agree
there's a gravitic effect to rsh and company, i.e. most legitimate
rsh/rlogin/...'s are between local (e.g. LAN-connected) machines, not
across the Internet router. That actually helps: at least for the LAN
case, it appears that Linux's ipfw (IP Firewall, now in the kernel)
solves this problem. Here's how:
1. You configure your Internet router to know that (say) your Class C addrs
are all on the LAN side of the router, and all other addrs are on the WAN
side. This should prevent IP address spoofing from Internet hosts,
since spoof packets get dropped on the floor.
2. You then compile your Linux kernel with firewall enabled, and then
on each of your LAN nodes (e.g. in rc.local) you say:
ipfw add blocking deny tcp from 0/0 to $MYLAN exec
ipfw add blocking deny tcp from 0/0 to $MYLAN login
ipfw add blocking deny tcp from 0/0 to $MYLAN shell
ipfw add blocking accept all from $MYLAN to 0/0
where MYLAN is set to your Class C network's IP address in a.b.c.0/24
format. This prevents both FQDN spoofing and password cracking attacks,
since all Internet packets for rexec, rcp, rsh, and rlogin packets services
are never seen on your LAN, but it gives your LAN machines complete r-command
access to each other. ("exec", "login", and "shell" are the service names
appearing in your /etc/services file, in case yours differ; the port
numbers work here too.)
I tested it, and it seemed to work for me. Obviously it should apply
to other services (lpd, finger, etc.) as well. It took me an hour or
two of wading through the ipfw source to work it out (see p.s. below),
but it should take only 3 minutes to implement using the above commands
as a guide. It doesn't assume you have a "real" firewall (bastion
host, proxy server, etc.); every machine can be Internet-connected, as
long as they all execute these ipfw commands.
I'd appreciate feedback, especially from others who try this out.
asc
p.s. Warning: the ipfw docs are quite weak and sometimes wrong, and my mind
threw up a couple times while reading the ipfw.c source, which is
1300 lines of C parser and 100 lines of real work. I have added
"Never write a recursive descent parser in C" to my Book of Life
Heuristics---those 25 pages of parser would have been three pages
of LISP or 10 lines of SNOBOL or Icon. So we're still bleeding-edge
when using ipfw for now, I think.
