Create DoS binary to test load handling in eID-Service

BeID-lab / eIDClientCore

Präambel: Die Humboldt-Universität zu Berlin, Unter den Linden 6, 10099 Berlin, im Folgenden als Humboldt-Universität bezeichnet, stellt für die Anwendung im Zusammenhang mit deutschen hoheitlichen Dokumenten, wie beispielsweise den neuen Personalausweis und den elektronischen Aufenthaltstitel, eine clientseitige eID-Basis-Software zum Bereitstellen der sogenannten eID-Funktionalität, d.h. Ermöglichen eines elektronischen Identitätsnachweises, die sich an den Richtlinien des BSI TR-03110, TR-03112, TR-03130 orientiert, bereit, und zwar in dem Entwicklungszustand, in dem sie sich zum Zeitpunkt der Bereitstellung befindet. Diese Software, die im Folgenden als eIDClientCore bezeichnet wird, hat die Humboldt-Universität von der Bundesdruckerei GmbH, Oranienstraße 91, 10969 Berlin zur Verwendung in Lehre und Forschung sowie zur Bereitstellung an die Öffentlichkeit („Hosten“) für die allgemeine Prüfung und Verwendung durch jedermann erhalten.

15 stars 16 forks source link

Create DoS binary to test load handling in eID-Service #59

Open frankmorgner opened 8 years ago

frankmorgner commented 8 years ago

Does not require a real (or emulated) card. Simply fire enough PAOS requests pretending to have a card...

eriknellessen commented 8 years ago

Should be solved in #66

frankmorgner commented 8 years ago

Not yet soved:

the 2 second delay after each execution (I think this has once been added to not pollute the commandline too much in case of an error)
connections should be done in parallel, not sequentially

psytester commented 8 years ago

I agree. For me, the hard coded 2 seconds delay is just used, that eID service does not get too much stress load. BTW: A command line option for flexible value would be great. For a real DoS the client needs to setup parallel connections and as much as possible. But maybe a configurable maximum number of sockets would be usefull for some "moderate" DoS tests.

wolfmueller commented 8 years ago

Questions:

I think that the simplest way is to start one process for each PAOS-connection and setting the delay via a command line option. Is that sufficient for your purpose?
Or is needed one eIDCC-Test-Binary which opens multiple PAOS-connections? This solution has may be higher requirements with respect to tread safeness of our eIDCC-librariy and all libraries which are used by eIDCC.
Do you need e.g. multiple PAOS-connections through one SSL/TLS channel?

psytester commented 8 years ago

At the end I would need a way to open several parallel PAOS connections. One use case will be: The client keeps the connection simply open, until the server maybe will close it due to inactivity. Another use case is: The client closes the connection right after its establishment. Each PAOS connection gets its own TLS channel to be able to simulate a real scenario as I want to consume as much as possible TCP sockets. Optional: The number of parallel sockets sould be configurable, but at least 50 parallel sockets per client host are required.

With such simulation I was able in past to stress already some proccesses.

eriknellessen commented 8 years ago

"At the end I would need a way to open several parallel PAOS connections." What does "parallel" mean exactly? Does PAOS work like TCP connections, which are open until they are closed? "One use case will be: The client keeps the connection simply open, until the server maybe will close it due to inactivity." What does "keeping the connection open" mean? Do we have to send something to keep the connection open? Does the client have to save information about the connection? Can the client not just forget about the connection? "Another use case is: The client closes the connection right after its establishment." By "closing" you mean "tell the server, that this connection is closed"? "Each PAOS connection gets its own TLS channel to be able to simulate a real scenario as I want to consume as much as possible TCP sockets." Ok. We will have to find out, in which steps the eIDClientCore opens a new TLS channel.

psytester commented 8 years ago

1) Yes, it is based on a simple TCP connection, because "PAOS" is just a Special usage of HTTP layer to get the client side into the server mode and the real server will act as the Client. The eIDClientcore will open the TCP socket to establish the overlaying PAOS connection.

2) Keep open the TCP socket means, that the eIDClientcore client will noch send the TCP FIN or RST. We simply wait until the Server will maybe close the socket. No keep alaive is required here.

3) "Another use case is: The client closes the connection right after its establishment." By "closing" you mean "tell the server, that this connection is closed"? --> Yes, here the eIDClientcore will close the socket with a TCP FIN. On application Level it will be something like StopHttpConnection() from library eIDClientConnection

eriknellessen commented 8 years ago

If I understand the problem correctly:

The approach taken in #66 is in general correct.
You would like to have a new socket for every PAOS connection. I could not find a way to tell libcurl to open a new socket for every new connection. I could not find a way to get a guarantee from libcurl about opening or not opening new sockets for a connection to a host, to which we already have a connection. That means, that we can only be sure to get a new socket, if we create a new process.
You would like to open connections in parallel.
- We could do so by using threads. But then again, we do not have a guarantee from libcurl about opening new sockets. Besides, the eIDClientCore can not guarantee to be thread-safe without further work.
- We could also create parallel processes. This would solve both problems, but is not as efficient as using threads. Would using processes be efficient enough for your needs?
You would like to have a command line parameter for the time to wait between two runs. This should not be a problem.

One way to solve these problems would be to create a script, which starts multiple instances of the eIDClientCore. This could be a bash script or python etc. Would that be an acceptable solution for you?

psytester commented 8 years ago

Hello Erik,

yes that's it. Approach from #66 is correct. And if libcurl does not support it, don't make it too complicate and simply start several processes. Threads would be nice but the work and its effort is too bad. So again, single processes are enough. I can put a shell script around which starts me several processes.

eriknellessen commented 8 years ago

We implemented starting a configurable number of parallel processes in #80.