Red Hat NETSCAPE MANAGEMENT SYSTEM 6.2 - COMMAND-LINE Guida di Installazione Scaricare il pdf (Pagina 58)

USER PID ACCESS COMMAND

631/tcp root 1315 f.... cupsd

See the man pages for fuser and lsof command syntax.

Another place to look for where a service is started, is in the init.d directory, where the actual init scripts

live. Something like ls −l /etc/rc.d/init.d/, should give us a list of these. Often the script name

itself gives a hint as to which service(s) it starts, though it may not necessarily exactly match the "Program

Name" as provided by netstat. Or we can use grep to search inside files and match a search pattern. Need to

find where rpc.statd is being started, and we don't see a script by this name?

# grep rpc.statd /etc/init.d/*

/etc/init.d/nfslock: [ −x /sbin/rpc.statd ] || exit 0

/etc/init.d/nfslock: daemon rpc.statd

/etc/init.d/nfslock: killproc rpc.statd

/etc/init.d/nfslock: status rpc.statd

/etc/init.d/nfslock: /sbin/pidof rpc.statd >/dev/null 2>&1; STATD="$?"

We didn't really need all that information, but at least we see now exactly which script is starting it.

Remember too that not all services are started this way. Some may be started via inetd, or xinetd.

The /proc filesystem also keeps everything we want to know about processes that are running. We can

query this to find out more information about each process. Do you need to know the full path of the

command that started a process?

# ls −l /proc/1315/exe

lrwxrwxrwx 1 root root 0 July 4 19:41 /proc/1315/exe −> /usr/sbin/cupsd

Finally, we had a loose end or two in the UDP listening services. Remember we had a strange looking port

number 32768, that also had no service name associated with it:

# netstat −aup

Active Internet connections (servers and established)

Local Address Foreign Address State PID/Program name

*:32768 *:* 956/named

bigcat:domain *:* 956/named

*:631 *:* 1315/cupsd

Now by including the "PID/Program name" option with the −p flag, we see this also belongs to named, the

nameserver daemon. Recent versions of BIND use an unprivileged port for some types of traffic. In this case,

this is BIND 9.x. So no real alarms here either. The unprivileged port here is the one named uses to to talk to

other nameservers for name and address lookups, and should not be firewalled.

So we found no big surprises in this hypothetical situation.

Security Quick−Start HOWTO for Red Hat Linux

8.3.2. Port and Process Owners 55

1 2 ... 53 54 55 56 57 58 59 60 61 62 63 ... 81 82

Nessun commento

Red Hat NETSCAPE MANAGEMENT SYSTEM 6.2 - COMMAND-LINE Guida di Installazione Pagina 58