Brian F. Feldman wrote: >> There are other ways. For example, even if a user account is resource >> limited, root processes (such as sendmail, popper, identd, and so forth) >> are not. Attacks against these servers generally result in very high >> loads and sometimes make it difficult to login to fix the problem, but do >> not result in running out of swap.
It results sometimes in out of swap, too. > Inetd is rate-limited by default nowadays, so this really doesn't apply. It really does apply. Inetd limits incoming connections per minute, not per second. It is possible to use minute limit in a few seconds and cause a high load. Sendmail is worse than inetd; it cannot limit incoming rate on established connection. Butenko's (bute...@stalker.com) DoS attack to sendmail is to send thousands of letters to local user thru fast netork connection (i.e., Ethernet) thru one established TCP connection; the only barrier is testing of LA before sending '250 XXX message accepted to delivery' reply and fork-and-deliver-or-queue-and-exit decision, but attacker can send too many letters in few seconds; a hundreds of delivery processes locked on /usr/libexec/mail.local mailbox waiting. LA counts system state characteristics of last minute and thus is similar to average patients' temperature per hospital per last year. ;( I have seen a variant of this attack on my mail hosts, when host with 6000 letters in mail queue (mail2news server) sent all its mail to smarthost (uucp spool server); after ~500 letters, sendmail on smarthost closed port 25 on RefuseLA; it was saved from out-of-swap only because domain resolving spent some time. The only mechanism against such type of attack I can imagine is to sm_sleep(1) at "mail from:" smtp server code or before '250 Message accepted for delivery'. For inetd, we must limit connections per second, not per minute. -- Netch To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
