Are the following open ports a danger?

[Graeme Nichols]

Hello Folks, I have just become aware of a utility, nmap, to discover
open ports on my system. The output of the run is as follows:-

[graeme at barney graeme]$ sudo nmap -sS -O barney
 
Starting nmap 3.50 ( http://www.insecure.org/nmap/ ) at 2004-08-09 13:07
EST
Interesting ports on barney.localdomain (192.168.1.1):
(The 1637 ports scanned but not shown below are in state: closed)
PORT      STATE SERVICE
1/tcp     open  tcpmux
11/tcp    open  systat
15/tcp    open  netstat
22/tcp    open  ssh
111/tcp   open  rpcbind
143/tcp   open  imap
540/tcp   open  uucp
635/tcp   open  unknown
1024/tcp  open  kdm
1080/tcp  open  socks
1524/tcp  open  ingreslock
2000/tcp  open  callbook
6667/tcp  open  irc
10000/tcp open  snet-sensor-mgmt
12345/tcp open  NetBus
12346/tcp open  NetBus
31337/tcp open  Elite
32771/tcp open  sometimes-rpc5
32772/tcp open  sometimes-rpc7
32773/tcp open  sometimes-rpc9
32774/tcp open  sometimes-rpc11
54320/tcp open  bo2k
Device type: general purpose
Running: Linux 2.4.X|2.5.X
OS details: Linux 2.5.25 - 2.5.70 or Gentoo 1.2 Linux 2.4.19 rc1-rc7)
Uptime 0.056 days (since Mon Aug  9 11:47:15 2004)
 
Nmap run completed -- 1 IP address (1 host up) scanned in 6.560 seconds

Are any of the above open ports posing a danger that I should close?

My apologies for a dumb question but iptables is not my forte I'm
afraid. BTW, nmap got my system wrong, its FC2 on kernel 2.6.6
--
----------------------------------------------------------------------
Kind regards, Graeme Nichols.
----------------------------------------------------------------------
My own business always bores me to death; I prefer other people's. --
Oscar Wilde
----------------------------------------------------------------------
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/redhat-install-list/attachments/20040809/69a6d58f/attachment.sig>