🚀 go-pugleaf

Paul Richards <pauldoo@dunvegan1.demon.co.uk> wrote:
> OK here goes:
> tcp        0      0 *:4666                  *:*                     LISTEN
> tcp        0      0 *:1239                  *:*                     LISTEN
> tcp        0      0 *:1177                  *:*                     LISTEN
> tcp        0      0 *:1176                  *:*                     LISTEN
> tcp        0      0 *:1175                  *:*                     LISTEN
> tcp        0      0 *:1174                  *:*                     LISTEN
> tcp        0      0 *:1173                  *:*                     LISTEN
> tcp        0      0 *:1172                  *:*                     LISTEN
> tcp        0      0 *:1171                  *:*                     LISTEN
> tcp        0      0 *:1164                  *:*                     LISTEN
> tcp        0      0 *:6000                  *:*                     LISTEN

6000 is X, IIRC. X does its own access control .

> tcp        0      0 *:4383                  *:*                     LISTEN
> No idea what those were

Me neither :-(

> tcp        0      0 *:nntp                  *:*                     LISTEN
> My NTP server???

NNTP -- you seem to running a news server. INN or Cnews probably, or maybe
leafnode (does anyone know if the latter has an NNTP interface?). You ought
to make sure that no unauthorised bods can post through it; you probably
don't want anyone reading from it either over a dial-up link, however public
spirited you are. I regularly see people probing my news server, presumably
look for an open one to spam Usenet through.

> tcp        0      0 *:ftp                   *:*                    LISTEN
> I need this

Fair enough :-) Just make sure there aren't any known exploits in the ftpd
you're running. If you've got anonymous ftp enabled, make sure there's nothing
in ~ftp you don't want people to see.

> tcp        0      0 *:www                   *:*                    LISTEN
> And this

AFAIK, the biggest security problems with web servers are any CGI scripts that
might be available, so check those out.

> tcp        0      0 *:5865                  *:*                     LISTEN
> tcp        0      0 *:55556                 *:*                     LISTEN
> tcp        0      0 *:5556                  *:*                     LISTEN
> tcp        0      0 *:omniorb               *:*                     LISTEN
> tcp        0      0 *:9111                  *:*                     LISTEN
> tcp        0      0 *:803                   *:*                     LISTEN
> No idea

omniorb is presumably an CORBA ORB. I think Gnome may use it. I /assume/
it has sane access control, but I don't use it and know nothing about it.
This is the sort of thing for which you could safely reject connections
coming over your PPP interface. As others have suggested, it's probably
best to set up your firewalling rules (ipmasqadm/ipfwadm/ipchains) to disallow
all incoming connects except the ones you know you want open (ftp, www).

> tcp        0      0 *:printer               *:*                    LISTEN
> Do I need this?  lpr does the printing AFAIK

Only if you want to print remotely - I don't know much about this, I'm
afriad.

> tcp        0      0 *:socks                 *:*                    LISTEN
> No idea

A SOCKS proxy. It's worth figuring out what package this is, and making sure
it will reject connections from the internet. Actually, you don't need it
all if you haven't got a LAN. The risk is people could use it to connect to
arbitrary machines on the internet and perform mischief, and it would look
like it was coming from you.

> tcp        0      0 *:auth                  *:*                    LISTEN
> Am I a PAP server or something stupid?

Nope, PAP is auth protocol involved in PPP. This is identd, and /fairly/
harmless; people can connect to it and give it a a port number, and it returns
the user name of the person who owns the corresponding socket. It's only use
is AFAICT for remote sys admins to log; if they spot any abuse coming from
a multiuser system they can forward the info to the other system's admin
to aid LARTing. You could kill it if you want to, or use an identd which
returns random info, or similar. I believe some IRC networks insist on being
about to identd you before letting you on.

> tcp        0      0 *:vboxd                 *:*                    LISTEN
> tcp        0      0 *:saft                  *:*                    LISTEN
> No idea

Me neither. See if there's anything useful mentioned in /etc/services for
these.

> tcp        0      0 *:finger                *:*                    LISTEN
> I know this one, but DoS attacks can come from this right?

Erm, pass. If it's a bog standard finger daemon it should be OK; you might
want to look at the information it provides and see if you really want to
make it available.

> tcp        0      0 *:smtp                  *:*                    LISTEN
> tcp        0      0 *:pop3                  *:*                    LISTEN
> I need those two, but perhaps I could place IP restrictions...  ?

You can probably restrict access to the SMTP server to Demon's mail subnet
(which I can't remember off hand, it must be documented somewhere) and any
where you might want to send mail from (probably just your local address).
For the pop3 server, anywhere you want to pick mail up from (again,
probably just your local address).

> tcp        0      0 *:telnet                *:*                    LISTEN
> Need this

Better to use ssh if you can; unless you're using something fancy like IPsec,
your passwords as well as your session data will go across the internet in
the clear with regular telnet.

> tcp        0      0 *:time                  *:*                    LISTEN
> Or is this my NTP server???

No, this is just a very simple time protocol - splits out 4 bytes giving
the seconds since the epoch. I can't see any harm in that, but then, no
obvious uses spring to mind either.

> tcp        0      0 *:daytime               *:*                    LISTEN
> tcp        0      0 *:discard               *:*                    LISTEN

daytime just spits out the current date and time in human readable format.
discard justs read characters and throws them away, mainly used for debugging
networks. Again, no harm but no use either; though in theory I think there's
an RFC that makes the discard service mandatory, I don't believe many people
honour that bit of it any more.

> tcp        0      0 *:sunrpc                *:*                    LISTEN
> No idea what those were

That's for all the rpc-based services, you need to use rpcinfo(8) to find
out what services are running.

> OK chaps, enlighten me.

There's an awful lot of stuff running there -- what distro are you using?
I'm wondering if inetd(8) is listening to many ports for which the associated
programs aren't installed. It would certainly be worth reading about inetd
and inetd.conf, and then having a rummage around in the latter file. Also
read about tcpd and hosts_access for setting IP restrictions on services.

Also, I didn't see any *udp* listeners in there, which seems odd. netstat
-ul will show those.

-- 
"If you wish to insult me my consulting rates are available by return of
email." -- Alan Cox