Howdy -
Sorry for the delay in responding.
The portmapper is responsible for converting (mapping) network connections
(i.e. bindings to a network port) to Remote Procedure Call
(RPC) processes. The portmapper grabs inbound network connections and
redirects them to the internal service components of NFS and NIS. It is
part of the network redirector, and has historically been the target of
lots of buffer overrun attacks.
Unless you are running NIS or NFS and you want hosts on the Internet to
use these services (very dangerous), it is a good idea to turn off these
services. Disable portmap, nfs, and nfslock (on some Red Hat distros).
Just Thomas's opinion:
Relying on tcp_wrappers (hosts.allow and hosts.deny) is not that great an
idea, at least not on tcp_wrappers alone. If you read inetd.conf, you'll
note that tcpd is spawned upon a request to a service. tcpd then reads
hosts.deny and hosts.allow to determine if the service is permitted for
the requsting host.
The problem here is that tcpd is a daemon - an application. It reads data
from the network. There is a greater potential for exploits against an
app/daemon than against ipchains.
I use the ipchains rules below for every computer I have which may be
connected to the Internet. It allows all client activities (like ftp,
telnet, web browsing, etc.), but restricts all priviledged access to my
host. Since it works at a lower layer than tcpd, it is not *as*
suseptible to attack. Before the data in the packet is passed to the
application layer, the packet is discarded.
So, if these rules are helpful, use them. Being a belt and suspenders
type, I use these rules as well as tcp_wrappers.
---- cut here ----
#!/bin/bash
# fw.sh - script to turn on a personal firewall
# Flush any previous rules, and set the defaults back to, well,
# default. :)
ipchains -F
ipchains -P input ACCEPT
ipchains -P forward ACCEPT
ipchains -P outpur ACCEPT
# Set the default policy for EVERYTHING incoming to deny -
# this drops incoming packets, so the sender does not get ANY response
# back. This is better than the sender getting an error.
ipchains -P input DENY
# Next, allow ping (ICMP) to work. You may or may not want this,
# depending on your level of paranoia.
ipchains -A input -p icmp -j ACCEPT
# We need loopback to work!
ipchains -A input -d 127.0.0.1 -j ACCEPT
# Now, allow client connections to work - those connections on
# ports 1024-5999. Must allow tcp and udp. 6000-6009 are excluded
# because X uses them for network connections, and X is not the most
# secure thing in the world.
ipchains -A input -p tcp -d [your.ip.address.here] 1024:5999 -j ACCEPT
ipchains -A input -p udp -d [your.ip.address.here] 1024:5999 -j ACCEPT
ipchains -A input -p tcp -d [your.ip.address.here] 6010: -j ACCEPT
ipchains -A input -p udp -d [your.ip.address.here] 6010: -j ACCEPT
---- cut here ----
This is not intended to be the be-all end-all firewall. But, it keeps the
bad guys out of your private ports while still allowing you to make client
connections. There is one gotcha - the ssh client uses low ports. I
usually alias ssh to ssh -P, which forces ssh to use high ports on the
client side.
Regards,
Thomas Cameron
***************************************************************
Red Hat Certified Engineer TurboLinux Certified Trainer
Certified NetWare Engineer Microsoft Certified Trainer
***************************************************************
On Tue, 15 Aug 2000, Nolan Darilek wrote:
> Thanks to everyone who answered my last Paranoid Security
> Rambling(tm). Here's another one. :)
>
> Ok, I've been pondering this for ages. WTF is portmap, and why
> do/don't I need it? It was installed when I set up this Debian box 2
> years back, so I thought that it might be useful. (Then again, telnetd
> and lots of other braindead stuff was also installed, so now I'm
> wondering. :)
>
> Anyhow, I'm checking logcheck reports, and I'm seeing the following
> alert (repeated 3-4 times, though it hasn't happened in a few days):
>
> Aug 13 22:20:31 ethereal portmap[30435]: connect from 195.74.211.71 to dump():
>request from unauthorized host
>
> Should this concern me? I really don't know much about RPC and what it
> is, so I'm honestly not sure.
>
> I have the following in my /etc/hosts.deny:
>
> portmap: ALL EXCEPT 127.0.0.1
>
> so I'm thinking that if portmap is important, I can still access it
> locally while nobody else can, and I'm wondering if that is why
> 195.74.211.71 was rejected. But, I might not even have this configured
> correctly, according to the following snippet from my /etc/hosts.deny:
>
> # If you're going to protect the portmapper use the name "portmap" for the
> # daemon name. Remember that you can only use the keyword "ALL" and IP
> # addresses (NOT host or domain names) for the portmapper.
>
> So, I'm not sure if EXCEPT is valid there.
>
> Anyhow, is portmap pointless? If so, can I just disable it in
> inetd.conf and save myself the headaches, lost sleep, etc.? :)
>
> Thanks a bunch in advance.
> ---------------------------------------------------------------------------
> Send administrative requests to [EMAIL PROTECTED]
>
---------------------------------------------------------------------------
Send administrative requests to [EMAIL PROTECTED]
