Re: cvs commit: src/usr.sbin/inetd builtins.c inetd.h

[Jeroen Ruigrok/Asmodai]

* David Malone (dwmal...@maths.tcd.ie) [990723 18:41]:
> if ((bi->bi_socktype == sep->se_socktype &&
> strcmp(bi->bi_service, sep->se_service) == 0) ||
> matchservent(bi->bi_service, sep->se_service,
> sep->se_proto))
> 
> It should probably say:
> 
> if (bi->bi_socktype == sep->se_socktype &&
> ((strcmp(bi->bi_service, sep->se_service) == 0) ||
> matchservent(bi->bi_service, sep->se_service,
> sep->se_proto)))

Holymoley,

detect the braces-quiz. Those braces which changed are hard to spot, but
prolly mean the world in this case

-- 
Jeroen Ruigrok van der Werven  asmodai(at)wxs.nl
The BSD Programmer's Documentation Project 
Network/Security SpecialistBSD: Technical excellence at its best
Cum angelis et pueris, fideles inveniamur. Quis est iste Rex gloriae...?


To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message

Re: cvs commit: src/usr.sbin/inetd builtins.c inetd.h

[Jeroen Ruigrok/Asmodai]

* David Malone ([EMAIL PROTECTED]) [990723 18:41]:
> if ((bi->bi_socktype == sep->se_socktype &&
> strcmp(bi->bi_service, sep->se_service) == 0) ||
> matchservent(bi->bi_service, sep->se_service,
> sep->se_proto))
> 
> It should probably say:
> 
> if (bi->bi_socktype == sep->se_socktype &&
> ((strcmp(bi->bi_service, sep->se_service) == 0) ||
> matchservent(bi->bi_service, sep->se_service,
> sep->se_proto)))

Holymoley,

detect the braces-quiz. Those braces which changed are hard to spot, but
prolly mean the world in this case

-- 
Jeroen Ruigrok van der Werven  asmodai(at)wxs.nl
The BSD Programmer's Documentation Project 
Network/Security SpecialistBSD: Technical excellence at its best
Cum angelis et pueris, fideles inveniamur. Quis est iste Rex gloriae...?


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: cvs commit: src/usr.sbin/inetd builtins.c inetd.h

[David Malone]

I've found the problem - it looks like a bug in the code for matching
internal service names to /etc/service names. The code says:

if ((bi->bi_socktype == sep->se_socktype &&
strcmp(bi->bi_service, sep->se_service) == 0) ||
matchservent(bi->bi_service, sep->se_service,
sep->se_proto))

It should probably say:

if (bi->bi_socktype == sep->se_socktype &&
((strcmp(bi->bi_service, sep->se_service) == 0) ||
matchservent(bi->bi_service, sep->se_service,
sep->se_proto)))

It was running the tcp service instead of the udp service.

David.


To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message

Re: cvs commit: src/usr.sbin/inetd builtins.c inetd.h

[David Malone]

I've found the problem - it looks like a bug in the code for matching
internal service names to /etc/service names. The code says:

if ((bi->bi_socktype == sep->se_socktype &&
strcmp(bi->bi_service, sep->se_service) == 0) ||
matchservent(bi->bi_service, sep->se_service,
sep->se_proto))

It should probably say:

if (bi->bi_socktype == sep->se_socktype &&
((strcmp(bi->bi_service, sep->se_service) == 0) ||
matchservent(bi->bi_service, sep->se_service,
sep->se_proto)))

It was running the tcp service instead of the udp service.

David.


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: cvs commit: src/usr.sbin/inetd builtins.c inetd.h

[Dag-Erling Smorgrav]

Andre Albsmeier  writes:
> Just to overcome speculations :-) I just tested it on another machine
> with the same result. If have tested it now between all 3 machines in
> each direction. Same result.

Weird. I'm unable to reproduce it; my test box responds to UDP queries
but does not log them (though it logs TCP queries). I'll update to the
latest inetd and try again.

DES
-- 
Dag-Erling Smorgrav - d...@flood.ping.uio.no


To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message

Re: cvs commit: src/usr.sbin/inetd builtins.c inetd.h

[Andre Albsmeier]

On Fri, 23-Jul-1999 at 15:35:48 +0200, Dag-Erling Smorgrav wrote:
> Andre Albsmeier  writes:
> > Comes in private email. It's about 130KB after which tcpdump crashed with:
> > 
> > zsh: 5741 segmentation fault tcpdump -i fxp0 150 udp or icmp
> 
> Weird. Very weird.

Just to overcome speculations :-) I just tested it on another machine
with the same result. If have tested it now between all 3 machines in
each direction. Same result. It should be reproducible very easily by
running "nmap -sU target_machine" where target_machine has the internal
inetd services enabled. I attach my inetd.conf in case it might be
interesting (nothing special in it):

#   $Id: inetd.conf,v 1.33.2.1 1999/07/21 19:28:25 sheldonh Exp $
#
# Internet server configuration database
#
#   @(#)inetd.conf  5.4 (Berkeley) 6/30/90
#
ftp stream  tcp nowait  root/usr/libexec/ftpd   ftpd
telnet  stream  tcp nowait  root/usr/libexec/telnetdtelnetd
shell   stream  tcp nowait  root/usr/libexec/rshd   rshd
login   stream  tcp nowait  root/usr/libexec/rlogindrlogind
finger  stream  tcp nowait/3/10 nobody /usr/libexec/fingerd fingerd
#exec   stream  tcp nowait  root/usr/libexec/rexecd rexecd
#uucpd  stream  tcp nowait  root/usr/libexec/uucpd  uucpd
#nntp   stream  tcp nowait  usenet  /usr/libexec/nntpd  nntpd
# run comsat as root to be able to print partial mailbox contents w/ biff,
# or use the safer tty:tty to just print that new mail has been received.
#comsat dgram   udp waittty:tty /usr/libexec/comsat comsat
ntalk   dgram   udp waittty:tty /usr/libexec/ntalkd ntalkd
#tftp   dgram   udp waitnobody  /usr/libexec/tftpd  tftpd /tftpboot
#bootps dgram   udp waitroot/usr/libexec/bootpd bootpd
#
# "Small servers" -- used to be standard on, but we're more conservative
# about things due to Internet security concerns.  Only turn on what you
# need.
#
daytime stream  tcp nowait  rootinternal
daytime dgram   udp waitrootinternal
timestream  tcp nowait  rootinternal
time dgram  udp waitrootinternal
echostream  tcp nowait  rootinternal
echodgram   udp waitrootinternal
discard stream  tcp nowait  rootinternal
discard dgram   udp waitrootinternal
chargen stream  tcp nowait  rootinternal
chargen dgram   udp waitrootinternal
#
# Kerberos authenticated services
#
#klogin stream  tcp nowait  root/usr/libexec/rlogindrlogind -k
#eklogin stream tcp nowait  root/usr/libexec/rlogindrlogind -k -x
#kshell stream  tcp nowait  root/usr/libexec/rshd   rshd -k
#kipstream  tcp nowait  root/usr/libexec/kipd   kipd
#
# CVS servers - for master CVS repositories only!
#
#cvspserver stream  tcp nowait  root/usr/bin/cvscvs pserver
#cvsstream  tcp nowait  root/usr/bin/cvscvs kserver
#
# RPC based services (you MUST have portmapper running to use these)
#
rstatd/1-3  dgram rpc/udp wait root /usr/libexec/rpc.rstatd  rpc.rstatd
rusersd/1-2 dgram rpc/udp wait root /usr/libexec/rpc.rusersd rpc.rusersd
walld/1 dgram rpc/udp wait root /usr/libexec/rpc.rwalld  rpc.rwalld
#pcnfsd/1-2 dgram rpc/udp wait root /usr/libexec/rpc.pcnfsd  rpc.pcnfsd 
#rquotad/1  dgram rpc/udp wait root /usr/libexec/rpc.rquotad rpc.rquotad
sprayd/1dgram rpc/udp wait root /usr/libexec/rpc.sprayd  rpc.sprayd
#
# example entry for the optional pop3 server
#
#pop3   stream  tcp nowait  root/usr/local/libexec/popper   popper
#
# example entry for the optional imap4 server
#
#imap4  stream  tcp nowait  root/usr/local/libexec/imapdimapd
#
# Return error for all "ident" requests
#
#auth   stream  tcp nowait  rootinternal
#
# example entry for the optional ident server
#
authstream  tcp waitkmem:kmem   /usr/local/sbin/identd  identd 
-w -t120
#
# example entry for the optional qmail MTA
#
#smtp   stream  tcp nowait  qmaild  /var/qmail/bin/tcp-env  tcp-env 
/var/qmail/bin/qmail-smtpd
#
# Enable the following two entries to enable samba startup from inetd
# (from the Samba documentation).
#
#netbios-ssn stream tcp nowait root /usr/local/sbin/smbd smbd 
#netbios-ns dgram udp wait root /usr/local/sbin/nmbd nmbd 


To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message

Re: cvs commit: src/usr.sbin/inetd builtins.c inetd.h

[Dag-Erling Smorgrav]

Andre Albsmeier  writes:
> Comes in private email. It's about 130KB after which tcpdump crashed with:
> 
> zsh: 5741 segmentation fault tcpdump -i fxp0 150 udp or icmp

Weird. Very weird.

DES
-- 
Dag-Erling Smorgrav - d...@flood.ping.uio.no


To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message

Re: cvs commit: src/usr.sbin/inetd builtins.c inetd.h

[Andre Albsmeier]

On Fri, 23-Jul-1999 at 15:16:14 +0200, Dag-Erling Smorgrav wrote:
> Sheldon Hearn  writes:
> > I know exactly why you see what you see when you do what you do. All I
> > can say is "don't do that", because I can't think of a why to cater for
> > what you're doing in a sensible fashion.
> 
> I think you're jumping to conclusions. What I'd like to see is a
> tcpdump log of the UDP scan ('tcpdump -i ed0 udp or icmp'). Yes, I
> know it's going to be huge.

Comes in private email. It's about 130KB after which tcpdump crashed with:

zsh: 5741 segmentation fault tcpdump -i fxp0 150 udp or icmp

But when I restart tcpdump again (while inetd still is going wild)
it is quiet.

-Andre


To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message

Re: cvs commit: src/usr.sbin/inetd builtins.c inetd.h

[Andre Albsmeier]

On Fri, 23-Jul-1999 at 15:09:12 +0200, Sheldon Hearn wrote:
> 
> 
> On Fri, 23 Jul 1999 15:06:02 +0200, Andre Albsmeier wrote:
> 
> > But when inetd is run without -l it get 100%.
> 
> Are you avoiding my question on purpose? :-)

Sorry. The machine wasn't stressed by other programs so
it was "the only significant user of CPU and so showed up at
close to 100% CPU usage". But when I logged into it to kill
and restart inetd the machine was responding very slow.

> > On Fri, 23-Jul-1999 at 14:29:19 +0200, Sheldon Hearn wrote:
> >
> > > What does "sucking all the CPU time" mean? Does it mean that other
> > > programs were suffering, or does it mean that it was the only
> > > significant user of CPU and so showed up at close to 100% CPU usage?
> 
> I don't care how the usage is split over syslog and inetd. What I want
> to know is whether their combined usage of the CPU causes a serious
> problem for other CPU-bound processes.

Yes.

> 
> After all, you _have_ asked the inetd+syslog pair to do a lot of work.

Why? I start nmap, it scans the ports and inetd has for sure a lot of
logging work to do. But at some time, the scan is finished but inetd
continues to consume CPU time endlessly. 

Maybe I am just confused and this behaviour is normal ...

-Andre


To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message

Re: cvs commit: src/usr.sbin/inetd builtins.c inetd.h

[Dag-Erling Smorgrav]

Sheldon Hearn  writes:
> I know exactly why you see what you see when you do what you do. All I
> can say is "don't do that", because I can't think of a why to cater for
> what you're doing in a sensible fashion.

I think you're jumping to conclusions. What I'd like to see is a
tcpdump log of the UDP scan ('tcpdump -i ed0 udp or icmp'). Yes, I
know it's going to be huge.

DES
-- 
Dag-Erling Smorgrav - d...@flood.ping.uio.no


To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message

Re: cvs commit: src/usr.sbin/inetd builtins.c inetd.h

[Sheldon Hearn]

On Fri, 23 Jul 1999 15:06:02 +0200, Andre Albsmeier wrote:

> But when inetd is run without -l it get 100%.

Are you avoiding my question on purpose? :-)

> On Fri, 23-Jul-1999 at 14:29:19 +0200, Sheldon Hearn wrote:
>
> > What does "sucking all the CPU time" mean? Does it mean that other
> > programs were suffering, or does it mean that it was the only
> > significant user of CPU and so showed up at close to 100% CPU usage?

I don't care how the usage is split over syslog and inetd. What I want
to know is whether their combined usage of the CPU causes a serious
problem for other CPU-bound processes.

After all, you _have_ asked the inetd+syslog pair to do a lot of work.

Ciao,
Sheldon.


To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message

Re: cvs commit: src/usr.sbin/inetd builtins.c inetd.h

[Dag-Erling Smorgrav]

Andre Albsmeier <[EMAIL PROTECTED]> writes:
> Just to overcome speculations :-) I just tested it on another machine
> with the same result. If have tested it now between all 3 machines in
> each direction. Same result.

Weird. I'm unable to reproduce it; my test box responds to UDP queries
but does not log them (though it logs TCP queries). I'll update to the
latest inetd and try again.

DES
-- 
Dag-Erling Smorgrav - [EMAIL PROTECTED]


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: cvs commit: src/usr.sbin/inetd builtins.c inetd.h

[Andre Albsmeier]

On Fri, 23-Jul-1999 at 14:29:19 +0200, Sheldon Hearn wrote:
> 
> [Hijacked from cvs-committers and cvs-all]
> 
> On Fri, 23 Jul 1999 11:28:12 +0200, Andre Albsmeier wrote:
> 
> > I observed some kind of denial of service on -STABLE: I was
> > playing with the new nmap and did a 'nmap -sU printfix'.
> > inetd was running as "inetd -l" and started sucking all the
> > CPU time even the nmap had been terminated long ago.
> 
> What does "sucking all the CPU time" mean? Does it mean that other
> programs were suffering, or does it mean that it was the only
> significant user of CPU and so showed up at close to 100% CPU usage?
>
> I suspect that the latter is true.

It's only nearly 50% because syslogd gets most of the other half :-)

But when inetd is run without -l it get 100%.


> > /var/log/messages file showed zillions of the following lines
> > being added continously:
> 
> Well, you did ask for them (inetd -l). :-)
>
> > Jul 23 11:21:28  printfix inetd[1743]: time from [...]
> > Jul 23 11:21:28  printfix inetd[1743]: daytime from [...]
> 
> Usually syslog will give you "last message repeated X times".
> Unfortunately, the alternation of the messages makes this impossible.
> 
> David Malone had a few ideas on "clever" handling of UDP. While what
> he suggests might help reduce the number of messages you receive under
> legitimate use, it won't help against DoS, since the sender of packets
> can simply randomize the origin addresses.
> 
> > Maybe you got an idea...
> 
> I know exactly why you see what you see when you do what you do. All I
> can say is "don't do that", because I can't think of a why to cater for
> what you're doing in a sensible fashion.


I think, I didn't describe the problem clearly so I will try again :-)

1. I run 'nmap -sU printfix' on the 192.168.17.100 machine.
2. After nmap has finished it shows me the open ports.
3. We wait , e.g. 1 minute
4. inetd, which runs with -l, continues logging to syslogd and 
   never stops. Here is a top snapshot taken one minute later:

last pid:  4040;  load averages:  0.96,  0.56,  0.29   up 0+06:19:27  14:56:00
36 processes:  2 running, 34 sleeping
CPU states: 54.3% user,  0.0% nice, 41.9% system,  3.9% interrupt,  0.0% idle
Mem: 8500K Active, 37M Inact, 12M Wired, 3428K Cache, 7592K Buf, 532K Free
Swap: 49M Total, 49M Free
 
  PID USERNAME PRI NICE  SIZERES STATETIME   WCPUCPU COMMAND
 3748 root  58   0   956K   704K RUN  0:20 44.97% 44.97% inetd
  122 root   2   0   848K   576K select   3:10 36.47% 36.47% syslogd
  127 root   2   0  1588K  1228K select   0:05  0.00%  0.00% named
  200 root   2   0   876K   524K select   0:02  0.00%  0.00% lpd
  132 root   2 -52  1236K   732K select   0:02  0.00%  0.00% xntpd


In case we start inetd without -l, it doesn't log to syslogd anymore
and therefore consumes all the CPU for itself:

last pid:  4397;  load averages:  1.59,  1.10,  0.55up 0+06:22:14  14:58:47
111 processes: 2 running, 109 sleeping
CPU states: 61.2% user,  0.0% nice, 38.0% system,  0.8% interrupt,  0.0% idle
Mem: 10M Active, 30M Inact, 14M Wired, 3776K Cache, 7592K Buf, 3688K Free
Swap: 49M Total, 49M Free

  PID USERNAME PRI NICE  SIZERES STATETIME   WCPUCPU COMMAND
 4043 root 104   0   956K   740K RUN  1:33 97.66% 97.61% inetd
  122 root   2   0   848K   576K select   3:16  0.00%  0.00% syslogd
  127 root   2   0  1588K  1228K select   0:05  0.00%  0.00% named


Remember that nmap has finished already a long time ago. I think, inetd
is stuck in some loop which can be terminated only by killing and
restarting it.

-Andre


To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message

Re: cvs commit: src/usr.sbin/inetd builtins.c inetd.h

[Andre Albsmeier]

On Fri, 23-Jul-1999 at 15:35:48 +0200, Dag-Erling Smorgrav wrote:
> Andre Albsmeier <[EMAIL PROTECTED]> writes:
> > Comes in private email. It's about 130KB after which tcpdump crashed with:
> > 
> > zsh: 5741 segmentation fault tcpdump -i fxp0 150 udp or icmp
> 
> Weird. Very weird.

Just to overcome speculations :-) I just tested it on another machine
with the same result. If have tested it now between all 3 machines in
each direction. Same result. It should be reproducible very easily by
running "nmap -sU target_machine" where target_machine has the internal
inetd services enabled. I attach my inetd.conf in case it might be
interesting (nothing special in it):

#   $Id: inetd.conf,v 1.33.2.1 1999/07/21 19:28:25 sheldonh Exp $
#
# Internet server configuration database
#
#   @(#)inetd.conf  5.4 (Berkeley) 6/30/90
#
ftp stream  tcp nowait  root/usr/libexec/ftpd   ftpd
telnet  stream  tcp nowait  root/usr/libexec/telnetdtelnetd
shell   stream  tcp nowait  root/usr/libexec/rshd   rshd
login   stream  tcp nowait  root/usr/libexec/rlogindrlogind
finger  stream  tcp nowait/3/10 nobody /usr/libexec/fingerd fingerd
#exec   stream  tcp nowait  root/usr/libexec/rexecd rexecd
#uucpd  stream  tcp nowait  root/usr/libexec/uucpd  uucpd
#nntp   stream  tcp nowait  usenet  /usr/libexec/nntpd  nntpd
# run comsat as root to be able to print partial mailbox contents w/ biff,
# or use the safer tty:tty to just print that new mail has been received.
#comsat dgram   udp waittty:tty /usr/libexec/comsat comsat
ntalk   dgram   udp waittty:tty /usr/libexec/ntalkd ntalkd
#tftp   dgram   udp waitnobody  /usr/libexec/tftpd  tftpd /tftpboot
#bootps dgram   udp waitroot/usr/libexec/bootpd bootpd
#
# "Small servers" -- used to be standard on, but we're more conservative
# about things due to Internet security concerns.  Only turn on what you
# need.
#
daytime stream  tcp nowait  rootinternal
daytime dgram   udp waitrootinternal
timestream  tcp nowait  rootinternal
time dgram  udp waitrootinternal
echostream  tcp nowait  rootinternal
echodgram   udp waitrootinternal
discard stream  tcp nowait  rootinternal
discard dgram   udp waitrootinternal
chargen stream  tcp nowait  rootinternal
chargen dgram   udp waitrootinternal
#
# Kerberos authenticated services
#
#klogin stream  tcp nowait  root/usr/libexec/rlogindrlogind -k
#eklogin stream tcp nowait  root/usr/libexec/rlogindrlogind -k -x
#kshell stream  tcp nowait  root/usr/libexec/rshd   rshd -k
#kipstream  tcp nowait  root/usr/libexec/kipd   kipd
#
# CVS servers - for master CVS repositories only!
#
#cvspserver stream  tcp nowait  root/usr/bin/cvscvs pserver
#cvsstream  tcp nowait  root/usr/bin/cvscvs kserver
#
# RPC based services (you MUST have portmapper running to use these)
#
rstatd/1-3  dgram rpc/udp wait root /usr/libexec/rpc.rstatd  rpc.rstatd
rusersd/1-2 dgram rpc/udp wait root /usr/libexec/rpc.rusersd rpc.rusersd
walld/1 dgram rpc/udp wait root /usr/libexec/rpc.rwalld  rpc.rwalld
#pcnfsd/1-2 dgram rpc/udp wait root /usr/libexec/rpc.pcnfsd  rpc.pcnfsd 
#rquotad/1  dgram rpc/udp wait root /usr/libexec/rpc.rquotad rpc.rquotad
sprayd/1dgram rpc/udp wait root /usr/libexec/rpc.sprayd  rpc.sprayd
#
# example entry for the optional pop3 server
#
#pop3   stream  tcp nowait  root/usr/local/libexec/popper   popper
#
# example entry for the optional imap4 server
#
#imap4  stream  tcp nowait  root/usr/local/libexec/imapdimapd
#
# Return error for all "ident" requests
#
#auth   stream  tcp nowait  rootinternal
#
# example entry for the optional ident server
#
authstream  tcp waitkmem:kmem   /usr/local/sbin/identd  identd -w -t120
#
# example entry for the optional qmail MTA
#
#smtp   stream  tcp nowait  qmaild  /var/qmail/bin/tcp-env  tcp-env 
/var/qmail/bin/qmail-smtpd
#
# Enable the following two entries to enable samba startup from inetd
# (from the Samba documentation).
#
#netbios-ssn stream tcp nowait root /usr/local/sbin/smbd smbd 
#netbios-ns dgram udp wait root /usr/local/sbin/nmbd nmbd 


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: cvs commit: src/usr.sbin/inetd builtins.c inetd.h

[Dag-Erling Smorgrav]

Andre Albsmeier <[EMAIL PROTECTED]> writes:
> Comes in private email. It's about 130KB after which tcpdump crashed with:
> 
> zsh: 5741 segmentation fault tcpdump -i fxp0 150 udp or icmp

Weird. Very weird.

DES
-- 
Dag-Erling Smorgrav - [EMAIL PROTECTED]


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: cvs commit: src/usr.sbin/inetd builtins.c inetd.h

[Andre Albsmeier]

On Fri, 23-Jul-1999 at 15:16:14 +0200, Dag-Erling Smorgrav wrote:
> Sheldon Hearn <[EMAIL PROTECTED]> writes:
> > I know exactly why you see what you see when you do what you do. All I
> > can say is "don't do that", because I can't think of a why to cater for
> > what you're doing in a sensible fashion.
> 
> I think you're jumping to conclusions. What I'd like to see is a
> tcpdump log of the UDP scan ('tcpdump -i ed0 udp or icmp'). Yes, I
> know it's going to be huge.

Comes in private email. It's about 130KB after which tcpdump crashed with:

zsh: 5741 segmentation fault tcpdump -i fxp0 150 udp or icmp

But when I restart tcpdump again (while inetd still is going wild)
it is quiet.

-Andre


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: cvs commit: src/usr.sbin/inetd builtins.c inetd.h

[Andre Albsmeier]

On Fri, 23-Jul-1999 at 15:09:12 +0200, Sheldon Hearn wrote:
> 
> 
> On Fri, 23 Jul 1999 15:06:02 +0200, Andre Albsmeier wrote:
> 
> > But when inetd is run without -l it get 100%.
> 
> Are you avoiding my question on purpose? :-)

Sorry. The machine wasn't stressed by other programs so
it was "the only significant user of CPU and so showed up at
close to 100% CPU usage". But when I logged into it to kill
and restart inetd the machine was responding very slow.

> > On Fri, 23-Jul-1999 at 14:29:19 +0200, Sheldon Hearn wrote:
> >
> > > What does "sucking all the CPU time" mean? Does it mean that other
> > > programs were suffering, or does it mean that it was the only
> > > significant user of CPU and so showed up at close to 100% CPU usage?
> 
> I don't care how the usage is split over syslog and inetd. What I want
> to know is whether their combined usage of the CPU causes a serious
> problem for other CPU-bound processes.

Yes.

> 
> After all, you _have_ asked the inetd+syslog pair to do a lot of work.

Why? I start nmap, it scans the ports and inetd has for sure a lot of
logging work to do. But at some time, the scan is finished but inetd
continues to consume CPU time endlessly. 

Maybe I am just confused and this behaviour is normal ...

-Andre


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: cvs commit: src/usr.sbin/inetd builtins.c inetd.h

[Sheldon Hearn]

[Hijacked from cvs-committers and cvs-all]

On Fri, 23 Jul 1999 11:28:12 +0200, Andre Albsmeier wrote:

> I observed some kind of denial of service on -STABLE: I was
> playing with the new nmap and did a 'nmap -sU printfix'.
> inetd was running as "inetd -l" and started sucking all the
> CPU time even the nmap had been terminated long ago.

What does "sucking all the CPU time" mean? Does it mean that other
programs were suffering, or does it mean that it was the only
significant user of CPU and so showed up at close to 100% CPU usage?

I suspect that the latter is true.

> /var/log/messages file showed zillions of the following lines
> being added continously:

Well, you did ask for them (inetd -l). :-)

> Jul 23 11:21:28  printfix inetd[1743]: time from [...]
> Jul 23 11:21:28  printfix inetd[1743]: daytime from [...]

Usually syslog will give you "last message repeated X times".
Unfortunately, the alternation of the messages makes this impossible.

David Malone had a few ideas on "clever" handling of UDP. While what
he suggests might help reduce the number of messages you receive under
legitimate use, it won't help against DoS, since the sender of packets
can simply randomize the origin addresses.

> Maybe you got an idea...

I know exactly why you see what you see when you do what you do. All I
can say is "don't do that", because I can't think of a why to cater for
what you're doing in a sensible fashion.

Ciao,
Sheldon.


To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message

Re: cvs commit: src/usr.sbin/inetd builtins.c inetd.h

[Dag-Erling Smorgrav]

Sheldon Hearn <[EMAIL PROTECTED]> writes:
> I know exactly why you see what you see when you do what you do. All I
> can say is "don't do that", because I can't think of a why to cater for
> what you're doing in a sensible fashion.

I think you're jumping to conclusions. What I'd like to see is a
tcpdump log of the UDP scan ('tcpdump -i ed0 udp or icmp'). Yes, I
know it's going to be huge.

DES
-- 
Dag-Erling Smorgrav - [EMAIL PROTECTED]


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: cvs commit: src/usr.sbin/inetd builtins.c inetd.h

[Sheldon Hearn]

On Fri, 23 Jul 1999 15:06:02 +0200, Andre Albsmeier wrote:

> But when inetd is run without -l it get 100%.

Are you avoiding my question on purpose? :-)

> On Fri, 23-Jul-1999 at 14:29:19 +0200, Sheldon Hearn wrote:
>
> > What does "sucking all the CPU time" mean? Does it mean that other
> > programs were suffering, or does it mean that it was the only
> > significant user of CPU and so showed up at close to 100% CPU usage?

I don't care how the usage is split over syslog and inetd. What I want
to know is whether their combined usage of the CPU causes a serious
problem for other CPU-bound processes.

After all, you _have_ asked the inetd+syslog pair to do a lot of work.

Ciao,
Sheldon.


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: cvs commit: src/usr.sbin/inetd builtins.c inetd.h

[Andre Albsmeier]

On Fri, 23-Jul-1999 at 14:29:19 +0200, Sheldon Hearn wrote:
> 
> [Hijacked from cvs-committers and cvs-all]
> 
> On Fri, 23 Jul 1999 11:28:12 +0200, Andre Albsmeier wrote:
> 
> > I observed some kind of denial of service on -STABLE: I was
> > playing with the new nmap and did a 'nmap -sU printfix'.
> > inetd was running as "inetd -l" and started sucking all the
> > CPU time even the nmap had been terminated long ago.
> 
> What does "sucking all the CPU time" mean? Does it mean that other
> programs were suffering, or does it mean that it was the only
> significant user of CPU and so showed up at close to 100% CPU usage?
>
> I suspect that the latter is true.

It's only nearly 50% because syslogd gets most of the other half :-)

But when inetd is run without -l it get 100%.


> > /var/log/messages file showed zillions of the following lines
> > being added continously:
> 
> Well, you did ask for them (inetd -l). :-)
>
> > Jul 23 11:21:28  printfix inetd[1743]: time from [...]
> > Jul 23 11:21:28  printfix inetd[1743]: daytime from [...]
> 
> Usually syslog will give you "last message repeated X times".
> Unfortunately, the alternation of the messages makes this impossible.
> 
> David Malone had a few ideas on "clever" handling of UDP. While what
> he suggests might help reduce the number of messages you receive under
> legitimate use, it won't help against DoS, since the sender of packets
> can simply randomize the origin addresses.
> 
> > Maybe you got an idea...
> 
> I know exactly why you see what you see when you do what you do. All I
> can say is "don't do that", because I can't think of a why to cater for
> what you're doing in a sensible fashion.


I think, I didn't describe the problem clearly so I will try again :-)

1. I run 'nmap -sU printfix' on the 192.168.17.100 machine.
2. After nmap has finished it shows me the open ports.
3. We wait , e.g. 1 minute
4. inetd, which runs with -l, continues logging to syslogd and 
   never stops. Here is a top snapshot taken one minute later:

last pid:  4040;  load averages:  0.96,  0.56,  0.29   up 0+06:19:27  14:56:00
36 processes:  2 running, 34 sleeping
CPU states: 54.3% user,  0.0% nice, 41.9% system,  3.9% interrupt,  0.0% idle
Mem: 8500K Active, 37M Inact, 12M Wired, 3428K Cache, 7592K Buf, 532K Free
Swap: 49M Total, 49M Free
 
  PID USERNAME PRI NICE  SIZERES STATETIME   WCPUCPU COMMAND
 3748 root  58   0   956K   704K RUN  0:20 44.97% 44.97% inetd
  122 root   2   0   848K   576K select   3:10 36.47% 36.47% syslogd
  127 root   2   0  1588K  1228K select   0:05  0.00%  0.00% named
  200 root   2   0   876K   524K select   0:02  0.00%  0.00% lpd
  132 root   2 -52  1236K   732K select   0:02  0.00%  0.00% xntpd


In case we start inetd without -l, it doesn't log to syslogd anymore
and therefore consumes all the CPU for itself:

last pid:  4397;  load averages:  1.59,  1.10,  0.55up 0+06:22:14  14:58:47
111 processes: 2 running, 109 sleeping
CPU states: 61.2% user,  0.0% nice, 38.0% system,  0.8% interrupt,  0.0% idle
Mem: 10M Active, 30M Inact, 14M Wired, 3776K Cache, 7592K Buf, 3688K Free
Swap: 49M Total, 49M Free

  PID USERNAME PRI NICE  SIZERES STATETIME   WCPUCPU COMMAND
 4043 root 104   0   956K   740K RUN  1:33 97.66% 97.61% inetd
  122 root   2   0   848K   576K select   3:16  0.00%  0.00% syslogd
  127 root   2   0  1588K  1228K select   0:05  0.00%  0.00% named


Remember that nmap has finished already a long time ago. I think, inetd
is stuck in some loop which can be terminated only by killing and
restarting it.

-Andre


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: cvs commit: src/usr.sbin/inetd builtins.c inetd.h

[Sheldon Hearn]

[Hijacked from cvs-committers and cvs-all]

On Fri, 23 Jul 1999 11:28:12 +0200, Andre Albsmeier wrote:

> I observed some kind of denial of service on -STABLE: I was
> playing with the new nmap and did a 'nmap -sU printfix'.
> inetd was running as "inetd -l" and started sucking all the
> CPU time even the nmap had been terminated long ago.

What does "sucking all the CPU time" mean? Does it mean that other
programs were suffering, or does it mean that it was the only
significant user of CPU and so showed up at close to 100% CPU usage?

I suspect that the latter is true.

> /var/log/messages file showed zillions of the following lines
> being added continously:

Well, you did ask for them (inetd -l). :-)

> Jul 23 11:21:28  printfix inetd[1743]: time from [...]
> Jul 23 11:21:28  printfix inetd[1743]: daytime from [...]

Usually syslog will give you "last message repeated X times".
Unfortunately, the alternation of the messages makes this impossible.

David Malone had a few ideas on "clever" handling of UDP. While what
he suggests might help reduce the number of messages you receive under
legitimate use, it won't help against DoS, since the sender of packets
can simply randomize the origin addresses.

> Maybe you got an idea...

I know exactly why you see what you see when you do what you do. All I
can say is "don't do that", because I can't think of a why to cater for
what you're doing in a sensible fashion.

Ciao,
Sheldon.


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message