Unable to hard reject the Bot caller about drachtio-srf HOT 5 OPEN

There is a sort of workaround to let the app determine what is spam.

First, employ fail2ban with the drachtio filter as described above.

Second, create some drachtio middleware that rejects suspected spam calls with 603 or whatever you want, and include a custom header that will trigger the drachtio fail2ban filter.

The middleware would look like this (in this example, I am determining that all calls other than sip over wss are spam, but obviously the logic is up to you):

function spamCheck() {
  return (req, res, next) => {
    const via = req.getParsedHeader('Via');

    // allow sip over wss only
    if (req.protocol === 'tcp' && 'wss' === via[0].protocol.toLowerCase()) return next();

    res.send(603, {
      headers: {
        'X-Reason': `detected potential spammer from ${req.source_address}:${req.source_port}`
      }
    });
  };
}

Note: make the header value of your custom header (you can choose any header name) exactly as shown above, since that is what fail2ban is filitering for.

install the middleware as per usual in your app.js

// middleware first
srf.use(spamCheck);

// then routes
srf.invite((req, res) => ...
srf.register((req, res) => ...

I do like the idea of not retransmitting, and not waiting for an ACK that will never come. I have to look further into how to trick the stack into doing that though...

from drachtio-srf.

could you expand on this please?

from drachtio-srf.

Hi Dave,

I am using Drachtio-srf module in a SIP_gateway. But the app is being attacked by the bots.

In response to the invite, I am sending the message 503, Forbidden. I have also tried 404, Not Found and 603, Decline.

But Drachtio keeps sending these response messages and waits for the ACK to arrive to end the call as shown in the tcpdump below.

11:33:10.397204 IP 216.244.65.98.5076 > 10.233.123.28.5060: SIP: INVITE sip:[email protected] SIP/2.0
11:33:10.397488 IP 10.233.123.28.5060 > 216.244.65.98.5076: SIP: SIP/2.0 603 Decline
11:33:10.898453 IP 10.233.123.28.5060 > 216.244.65.98.5076: SIP: SIP/2.0 603 Decline
11:33:11.899568 IP 10.233.123.28.5060 > 216.244.65.98.5076: SIP: SIP/2.0 603 Decline
11:33:13.899569 IP 10.233.123.28.5060 > 216.244.65.98.5076: SIP: SIP/2.0 603 Decline
11:33:17.899568 IP 10.233.123.28.5060 > 216.244.65.98.5076: SIP: SIP/2.0 603 Decline
11:33:21.899569 IP 10.233.123.28.5060 > 216.244.65.98.5076: SIP: SIP/2.0 603 Decline
11:33:25.899570 IP 10.233.123.28.5060 > 216.244.65.98.5076: SIP: SIP/2.0 603 Decline
11:33:29.899570 IP 10.233.123.28.5060 > 216.244.65.98.5076: SIP: SIP/2.0 603 Decline

This blocks Drachtio to forward other SIP calls to the SIP Gateway.

So, my question is, can we do the hard reject of bot calls without waiting for the ACK from the spammer's end.

Thanks.

from drachtio-srf.

Could you share a full INVITE that you are seeing? The reason is that the drachtio server tries to weed out some spam traffic that should never reach your app (based on well-known user agent strings, etc), yet it seems this traffic is reaching your app. So I would like to see an example INVITE, so I can figure out if the drachtio server needs to be updated.

Beyond that, if you can't use iptables to lock down where traffic is coming from (ie if you need only to take traffic from known sip trunks, then use iptables to lock down traffic on 5060/udp to only those addresses), then I would suggest using suggest installing fail2ban, and then adding configuration for drachtio.

I have an ansible role that you can use to install the drachtio specific config once you have installed fail2ban.

If you don't use ansible and don't wish to figure out how to run it, you can look at the main ansible task file and work out how to make the changes manually.

Beyond all of this, I have been thinking about whether to make a change to how drachtio server responds to identified spam traffic -- ie either not retransmit at all, not respond at all, or send a bogus 200 OK (as some people have recommended). Interested in your thoughts on this

from drachtio-srf.

Thanks for the quick response.

I think another approach could be letting the app decide which caller is spam and who is legit.

If the app rejects the caller due to its own criteria, we can implement a method for the srf class to hard-reject* the caller. This method will be able to free the app and let the drachtio know that the app is now available to take another call.

In my app, I reject all those callers whose number is not of a certain type.

*: hard reject can be done either by ignoring the caller or once we send them 603 Decline, we should not continuously look for their ACK and release the app for the next caller.

PS: I am collecting a tcpdump of all the spam numbers and will share it with you soon.

from drachtio-srf.