inetd_flags in rc.conf

2011-08-15 Thread David Walker
Hey folks.

I installed a snapshot from a day or so ago:
OpenBSD 5.0 GENERIC#39

So things change but this doesn't seem to work any more for inetd ...
http://www.openbsd.org/cgi-bin/cvsweb/src/etc/rc.conf.diff?r1=1.141;r2=1.142
This doesn't look right:

# set these to NO to turn them off.  otherwise, they're used as flags
inetd_flags=  # for normal use: 

inetd is definitely running on this machine with that flag set NO.

Sad to say I don't understand the new rc.conf well enough to figure
this out on my own.
I'm sure I could add inetd_flags=NO to my rc.conf.local and everything
would work ...
Yep that works.

BTW, maybe it could be:
# Set these to NO to turn them off. Otherwise they're used as flags.

Best wishes.



Re: inetd_flags in rc.conf

2011-08-15 Thread Alexander Hall

On 08/15/11 19:58, David Walker wrote:

Hey folks.

I installed a snapshot from a day or so ago:
OpenBSD 5.0 GENERIC#39

So things change but this doesn't seem to work any more for inetd ...
http://www.openbsd.org/cgi-bin/cvsweb/src/etc/rc.conf.diff?r1=1.141;r2=1.142
This doesn't look right:

# set these to NO to turn them off.  otherwise, they're used as flags
inetd_flags=# for normal use: 

inetd is definitely running on this machine with that flag set NO.

Sad to say I don't understand the new rc.conf well enough to figure
this out on my own.
I'm sure I could add inetd_flags=NO to my rc.conf.local and everything
would work ...
Yep that works.


Hm so where did you think it was set to NO before that?

Oh, ah! You modified rc.conf? Think again. inetd_flags are a bit 
'special' in that they are handling the legacy inetd=YES.


Short answer: Don't edit rc.conf.

(if you didn't edit rc.conf, I'm short of ideas unless you start sharing 
your /etc/rc* contents)


/Alexander


BTW, maybe it could be:
# Set these to NO to turn them off. Otherwise they're used as flags.

Best wishes.




Re: inetd_flags in rc.conf

2011-08-15 Thread Kevin Chadwick
On Tue, 16 Aug 2011 03:28:53 +0930
David Walker davidianwal...@gmail.com wrote:

 inetd is definitely running on this machine with that flag set NO.

Why turn it off, Just hash everything in inetd.conf and your nmap
fingerprint will be lower than without inetd running.



Re: inetd_flags in rc.conf

2011-08-15 Thread David Walker
Hi Kevin.

Kevin Chadwick ma1l1ists () yahoo ! co ! uk
 Why turn it off, Just hash everything in inetd.conf and your nmap
 fingerprint will be lower than without inetd running.

I used to hash the file back in the day until it became clear I was
never using it.
The few machines I run serve very few services and I'm happy for them
to be running 24x7 - although I'm in an opposite situation this still
seems apposite ...

FTPD(8):
This has lower overhead than starting ftpd from
 inetd(8) and is thus useful on busy servers to reduce load.

POPA3D(8):
This has lower overhead than starting popa3d
 from inetd(8) and is thus useful on busy servers to reduce load.

In this mode popa3d also does quite a few checks to significantly
 reduce the impact of connection flood attacks.

... and so on.
Yes, I also see this:

INETD(8):
Essentially, inetd allows running one daemon
 to invoke several others, reducing load on the system.

In my situation after many releases of hashing inetd.conf I decided to
stop playing chinese whispers.
As far as nmap goes, sure, but I don't care about port scans.
As a matter of principle I think knowledge of running services should
never be an issue.
If there's a failure there, it's either a flaw in the software which
I'd like to know about, or I've made an administration error. Right?
Frankly I'm happy to have people trying to break into these machines,
if only there was more of it ...
If I needed to do something a little more critical I would re-think my
service choices and probably still not care about port scans.
As it stands though I'm okay for these machines to be cracked wide
open and be off the air for a day or so if I can help squash a bug or
learn something.
The only associated issue that concerns me at all there is DoS and I
think other methods are more appropriate there (such as picking up the
phone).

The only thing I can think of off the top of my head is port scanning
and getting meaningful results through inetd is slower right?
If you could provide some reading material on that I'd probably read it.

Best wishes.