Continually receive bootpd message in syslog

[Robert Milne]

Hi all,

I often receive the message:
bootpd[3470]: Option 43: Client specified unacceptable opt
ion length (92 octets)
in the syslog, whilst it's not a problem, it's annoying and fills the syslog. Obviously some device on the network is continually sending out bootpd requests, but we don't use it and have no reason to booy anything by this request. How can I stop or remove this from the server, we do not need this service I believe.

All the best,

Rob.

[A. Clay Stephenson · Accepted solution]

Edit /etc/inetd.conf and comment out the bootp line; you then tell inetd to re-read the configuration file by sending a SIGHUP to the daemon. HP-UX makes this easy so all you need to do to send this signal is "inetd -c".

[Robert Milne]

Hi Clay,

Thanks, fast response too !
Just one question before I do, if I run the inetd -c command, this will not have any impact on current running sessions/services such as telnet ? Is it safe ? This is on a production server with a number of users running live and I just didn't want to kill or disrupt any of their sessions. I assume that a inetd -k would probably do this, but just wanted to be sure.

All the best,

Rob.

[A. Clay Stephenson]

It's "inetd -c" and no that will not disrupt established sessions. "Inetd -c" is a safe command to issue anytime. You could do exactly the same thing by determining the PID of the inetd daemon and then doing a "kill -1 PID". That will send a SIGHUP to inetd and the signal handler says reread the configuration file and reconfigure yourself. The only possible impact would be missing a connection at the exact moment inetd was doing reconfiguration --- whichs is completed within a few tens of milliseconds. Because almost all protocols automatically retry, even this low-probability event would have no impact.

Bear in mind the the inetd daemon (yes, that's redundant) does very little itself. It simply listens for connections and then forks and execs a new process (e.g telnetd, ftpd) so that the kills that you send to inetd aren't even directed at established connections.

[A. Clay Stephenson]

This actually reminds of an incident last year on a Sun box in which I almost gave the local expert Solaris sysadmin a heart attack by issueing a "kill -1 inetd's_PID" (Sun like most UNIX flavors doesn't have the -c inetd option). He was convinced that chaos was going to result on his production machine and clients were going to be disconnected. He "knew" he was supposed to reboot any time inetd's configuration file was changed (I was actually doing some security hardening for them); he also "knew" that kill always kills -- except when it doesn't which was why some of his kill -9's didn't work. He was absolutely amazed when my kill didn't seem to do anything to inetd.

I then had him read inetd's man page and pay attention to signal handling. It's always a good idea for a sysadmin to know some C/C++ so that deep, down he understands just what a kill actually does.

[Robert Milne]

Clay,

Thanks, done that, looks good. I noticed the following entry in syslog:

Jun 28 16:38:39 krone inetd[724]: Rereading configuration
Jun 28 16:38:39 krone inetd[724]: bootps/udp: Deleted service
Jun 28 16:38:39 krone inetd[724]: Thru with configuration
Jun 28 16:38:39 krone inetd[724]: Configuration complete

So I'm convinced.
Lastly to "harden" security for use (or rather misuse) of services like ftp and tftp is this the best way to turn these off, by disabling in inetd.conf and running inetd -c as we did here. Then if required as a temporary or one off to do a file transfer or whatever, renabling and disabling when complete ?

Thanks again,

Rob.

[A. Clay Stephenson]

Yes, that is one approach although ftp can generally be sufficiently hardened via the ftpaccess and ftpusers file. You should also note that a box can still serve as an ftp client even if the ftpd daemon is disabled. You should (at a minimum) also permanently disable the finger, daytime, time, echo, discard and chargen services.

[Robert Milne]

Clay,

Thanks, yes already do use the ftpaccess and ftpusers files.
Thanks again for all and now I leave the feedback !

Rob.