[hunchentoot-devel] Hunchentoot effective DOS-attack

Mon Jul 6 07:22:45 UTC 2009

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello Hans!

I have confirmed the problem both when running on localhost and with
seperate machines for client and server. Siege does not act the same way
that nmap -sT does. The problem is noticable with nmap because it
performs a connect without sending any additional data from the nmap man
page I extracted this not so flattery nugget:

> Many services on your average Unix system will add a note to 
> syslog, and sometimes a cryptic error message, when Nmap 
> connects and then closes the connection without sending data.
> Truly pathetic services crash when this happens, though that
> is uncommon.

I noticed myself that I was unable to provoke the uncaught exception
when using a lower number of iterations but it always does this for an
iteration count of 20 on my machines. I'm expecting this could vary a
little so maybe you could raise the number of iterations slightly to
provoke one?

I also did as you suggested and set *break-on-signals*. The trace looks
like this:

Socket error in "getpeername": ENOTCONN (Transport endpoint is not
connected)
BREAK was entered because of *BREAK-ON-SIGNALS* (now rebound to NIL).
   [Condition of type SIMPLE-CONDITION]

Restarts:
 0: [CONTINUE] Return from BREAK.
 1: [REASSIGN] Return from BREAK and assign a new value to
*BREAK-ON-SIGNALS*.
 2: [TERMINATE-THREAD] Terminate this thread (#<THREAD "Hunchentoot
listener (*:8000)" RUNNING {AAA8B51}>)

Backtrace:
  0: (BREAK "~A~%BREAK was entered because of *BREAK-ON-SIGNALS* ~\n
                (now rebound to NIL)."
#<SB-BSD-SOCKETS:NOT-CONNECTED-ERROR {AE7FCA9}>)
  1: (SIGNAL #<SB-BSD-SOCKETS:NOT-CONNECTED-ERROR {AE7FCA9}>)[:EXTERNAL]
  2: (ERROR SB-BSD-SOCKETS:NOT-CONNECTED-ERROR)[:EXTERNAL]
  3: (SB-BSD-SOCKETS:SOCKET-ERROR "getpeername")
  4: (SB-BSD-SOCKETS:SOCKET-ERROR "getpeername")[:EXTERNAL]
  5: ((SB-PCL::FAST-METHOD SB-BSD-SOCKETS:SOCKET-PEERNAME
(SB-BSD-SOCKETS:SOCKET)) #<unavailable argument> #<unavailable argument>
#<SB-BSD-SOCKETS:INET-SOCKET descriptor 6 {AE7F971}>)
  6: ((SB-PCL::FAST-METHOD USOCKET:GET-PEER-ADDRESS
(USOCKET:STREAM-USOCKET)) #<unavailable argument> #<unavailable
argument> #<USOCKET:STREAM-USOCKET {AE7FBD1}>)
  7: (HUNCHENTOOT::CLIENT-AS-STRING #<USOCKET:STREAM-USOCKET {AE7FBD1}>)
  8: ((SB-PCL::FAST-METHOD HUNCHENTOOT:HANDLE-INCOMING-CONNECTION
(HUNCHENTOOT:ONE-THREAD-PER-CONNECTION-TASKMASTER T)) ..)
  9: ((SB-PCL::FAST-METHOD HUNCHENTOOT:ACCEPT-CONNECTIONS
(HUNCHENTOOT:ACCEPTOR)) #<unavailable argument> #<unavailable argument>
#<HUNCHENTOOT:ACCEPTOR (host *, port 8000)>)
 10: ((FLET SB-THREAD::WITH-MUTEX-THUNK))
 11: ((FLET #:WITHOUT-INTERRUPTS-BODY-[CALL-WITH-MUTEX]477))
 12: (SB-THREAD::CALL-WITH-MUTEX ..)
 13: ((LAMBDA ()))
 14: ("foreign function: #x806480C")
 15: ("foreign function: #x8052C21")
 16: ("foreign function: #x805BD9D")
 17: ("foreign function: #xB7FB84C0")

I had a quick peek at client-as-string and it does indeed not handle the
sb-bsd-sockets:not-connected-error and if I put a handler-case around
body of client-as-string returning nil when the exception appears I can
not reproduce my problem anymore.

This wouldn't provide a portable solution though :-P

/Peter

Hans Hübner wrote:
> Peter,
> 
> I am not able to reproduce the problem using the nmap command line
> that you provided.  I also ran siege against Hunchentoot:
> 
> Transactions:                   1205 hits
> Availability:                 100.00 %
> Elapsed time:                  14.40 secs
> Data transferred:               3.03 MB
> Response time:                  0.11 secs
> Transaction rate:              83.69 trans/sec
> Throughput:                     0.21 MB/sec
> Concurrency:                    9.30
> Successful transactions:        1205
> Failed transactions:               0
> Longest transaction:            6.29
> Shortest transaction:           0.01
> 
> Can you reproduce the problem with siege?  What platform are you
> running on?  Can you reproduce the problem when the client is on the
> same machine as the server?
> 
> It'd be interested to learn where the
> SB-BSD-SOCKETS:NOT-CONNECTED-ERROR is actually signalled from.  To
> debug, you might set *BREAK-ON-SIGNALS* to
> 'SB-BSD-SOCKETS:NOT-CONNECTED-ERROR and post the backtrace.
> 
> -Hans
> 
> 2009/7/3 Peter Stiernström <peter.stiernstrom at blixtvik.se>:
> I don't know if this have come up earlier or if it is a known problem.
> If so I am sorry for bringing it up again. A quick look through the
> archives turned up a non-caught sbcl socket timeout error with the
> obvious fix of adding an error translation to the usocket sbcl backend
> error map. I expect this to be somewhat similar.
> 
> When stressing hunchentoot with a number of connection like so:
> 
> for i in $(seq 1 20); do nmap -sT -p 80 <hostname> ;done
> 
> Hunchentoot (last 1.0 release) stops responding after not having caught
> a SB-BSD-SOCKETS:NOT-CONNECTED-ERROR thus being easily DOSed.
> 
> I was hoping that there would be an obvious similar mapping missing but
> I don't know my way around hunchentoot to figure out what to map
> SB-BSD-SOCKETS:NOT-CONNECTED-ERROR to.
> 
> I am seeing this problem on a regular basis and for now it always
> prompts a full restart.
> 
> I am using usocket 0.4.1 with hunchentoot 1.0.0.
> 
> /Peter
>>
_______________________________________________
tbnl-devel site list
tbnl-devel at common-lisp.net
http://common-lisp.net/mailman/listinfo/tbnl-devel
>>

> _______________________________________________
> tbnl-devel site list
> tbnl-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/tbnl-devel

- --
Med vänlig hälsning,

Peter Stiernström
0708-810932
Blixtvik AB
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkpRpkUACgkQ0brSZD05ZzDADQCdHqzYZg8+Aza0hVvP+gT/3Oa3
PS0AoLv8ni4rQ5IF5qSUEXzqK4Rfu/7y
=vZYn
-----END PGP SIGNATURE-----