Implement "anti_slow_attack_timeout"

[ibc]

Requirements (given that security->anti_slow_attack_timeout value is set to 2 seconds):

• For incoming SIP TCP connections, once the TCP connection is established and, if there is no data received within 4 seconds, then close the connection.
• For incoming SIP TCP connections, once data is being received, if there is not a full SIP message within 4 seconds, then close the connection.
• For incoming SIP TLS connections, once the TLS connection is established and, if there is no data received within 4 seconds, then close the connection.
• For incoming SIP TLS connections, once TLS connection is established and data is being received, if there is not a full SIP message within 4 seconds, then close the connection.
• For incoming WS connections, once the TCP connection is established and, if there is no HTTP GET received within 1 second (hardcoded), then close the connection.
• For incoming WS connections, once WS frames are being received, if there is not a full WS message within 4 seconds, then close the connection.
• For incoming WSS connections, once the TLS connection is established and, if there is no HTTP GET received within 1 second (harcoded), then close the connection.
• For incoming WSS connections, once WS frames are being received, if there is not a full WS message within 4 seconds, then close the connection.
• For outgoing SIP TCP connections, once data is being received, if there is not a full SIP message received within 4 seconds, then close the connection.
• For outgoing SIP TLS connections, once TLS is established and data is being received, if there is not a full SIP message received within 4 seconds, then close the connection.
• For incoming SIP or WS TLS connections, if the TLS connection is not established within 4 seconds (harcoded), close connection (just applies when NOT using Stud TLS proxy).
• For outgoing SIP TLS connections, if the TLS connection is not established within 4 seconds (harcoded), close connection.

[ibc]

Some work done in b72f3e1 but still much more to do.

[saghul]

For incoming connections, isn't it not too abrupt to terminate connections because there is no traffic? I guess a SIP proxy could preemptively establish a TCP connection with you and send some data at a later time. Maybe this can be solved with TCP keepalives?

What happens if I establish 1000 connections to you, I send an OPTIONS and then stay idle forever? How is that different from not sending anything? Should this be handled at the application layer or wouldn't it better to let it to the TCP layer (in this particular case) ?

[ibc]

2012/10/23 Saúl Ibarra Corretgé [email protected]

For incoming connections, isn't it not too abrupt to terminate connections
because there is no traffic? I guess a SIP proxy could preemptively
establish a TCP connection with you and send some data at a later time.
Maybe this can be solved with TCP keepalives?

The TCP connection is not closed in case there has already been SIP
messages coming from the remote (well, OverSIP closes the connection after
300 seconds if NO TCP data has been received or sent over that connection.

NOTE: OverSIP sends TCP keepalives for TCP server connections (not for
connections initiated by OverSIP), but those TCP keepalives are TCP
messages with no data so they are not considered "data received or sent".

What happens if I establish 1000 connections to you, I send an OPTIONS and
then stay idle forever?

Connections will be closed after 300 seconds of no data sent/received. It's
not a big problem for OverSIP to keep lot of connections, but we must avoid
that an attacker sends slow headers/bodies since those consume memory in
buffers holding the received data.

How is that different from not sending anything? Should this be handled at
the application layer or wouldn't it better to let it to the TCP layer (in
this particular case) ?

We are the application and the TCP layer.

[saghul]

What do you mean by "TCP data" for closing the connection after 300 seconds, application level data or TCP keepalive data?

I think OverSIP should also have the ability to send keepalives for outgoing connections, it can help to detect and remove "dead connections" thus freeing resources. However, when there is a huge number of connections it's usually recommended to disable it because of the resources consumed by the server just to send those keepalives.

You didn't really answer my last question :-)

[ibc]

2012/10/23 Saúl Ibarra Corretgé [email protected]

What do you mean by "TCP data" for closing the connection after 300
seconds, application level data or TCP keepalive data?

There is no "TCP keepalive data" since such a keepalive mechanism means a
TCP package without data, so it does NOT arrive to the application (it's
"dropped" by the Kernel).

If OverSIP does not receive or send REAL TCP application data over a TCP
connection within 300 seconds then the connection is closed.

I think OverSIP should also have the ability to send keepalives for
outgoing connections, it can help to detect and remove "dead connections"
thus freeing resources.

Not possible. TCP keepalive mechanism requires root acccess but outgoing
TCP connections are created dynamically as "oversip" user (instead TCP
servers are created at start time by root and then owned by "oversip" user).

However, when there is a huge number of connections it's usually
recommended to disable it because of the resources consumed by the server
just to send those keepalives.

Well, what to do? I don't think there is a proper solution for this. We
could add a new security parameter "max_tcp_connections" and reject new TCP
connections, but that's not 100% possible with EventMachine (instead the
connection is automatically accepted and then you can decide to close it).

You didn't really answer my last question :-)

I want to provide some mechanism to avoid obvious attacks. If a TCP
connection is received and a SIP message or WS message inmediately
received, we can "expect" that it's "legitime". If no data is received, why
such a connection? SIP nodes don't establish connections for sending
nothing.