Responsive Firewall

The Responsive Firewall is an additional element of the core System Firewall, that continually monitors signalling requests for the selected services, allows legitimate attempts, and blocks attacks.

Open

What is a Signalling Request?

This is a SIP or IAX packet that asks the server to do something, such as 'Make a Call', or 'Authorize Me'. 

How does it work?

When Responsive is enabled, any signalling packet that comes from a host that the server doesn't know about, and that would normally be rejected, is instead tentatively allowed through the firewall.  If, after a small number of packets, the machine that is sending the signalling packets has not registered successfully, all signalling traffic from that client is DROP'ed for a short period of time (60 seconds). 

If the remote CONTINUES to send traffic without successfully registering, that IP address is blocked for at least 24 hours, and the block isn't dropped until the remote machine has not sent any packets for 24 hours.

When enabling Responsive Firewall for a protocol, all non-Local permissions are removed from that protocol. This is expected. Responsive Firewall only manages packets that would normally be rejected, so when you browse to the 'Services' page, 'Services' tab, you will see this for signalling protocols that are being managed by Responsive:

Open

Note that by default, traffic in the Local zone is allowed without Responsive enabled, and any traffic the Trusted Zone is always ignored by Firewall, so hosts registering from these zones will not be seen in Status.

Does this mean a 'Slow' attack will still work?

No. The most authentication attempts an attacker can try is 49, and that will have to be spread out over a 24 hour period. After the 50th attempt they will be blocked, any further attempts will simply extend their ban time, without informing the attacker.

What are the attack trigger thresholds?

The attack thresholds have been set after exhaustive testing with various endpoints and offer a reasonable amount of fault tolerance in case of a firewall monitoring failure. These are not configurable.

First (temporary) Block

This allows 10 signalling packets to be sent to the server before traffic from this client is dropped. 10 was chosen because it allows a phone to register, request MWI status, and then establish and terminate a call, and then establish a second call.  Various real-world log investigation shows that this covers 99.995% of attempts – out of over 30,000 registration and call logs investigated, only one call would have potentially failed to hang up. 

Second (defensive) Block

This is triggered when 50 or more unsuccessful registration or call attempts have been made within a 24 hour period. All traffic from that IP address to the attacked protocol is DROPPED.  Note that this is the only time that the firewall DROPs packets. This is to encourage automated attack systems to move on to a different target. Any attacker that has triggered this defensive block is only released by not sending any further attacking packets for 24 hours.

Both triggers only block the attacked port. This is because a common mis-configuration is for a PJSIP configured endpoint to attempt to connect to chan_sip, or vice versa. 

Alternative (defensive) Block

Many attack tools, when probing a system, send a large number of SIP packets in a short period of time as part of probe of the system. The firewall detects this, and explicitly marks a client as an attacker when it sends 50 or more packets in under 10 seconds, blocking them for a 24 hour period.

This is in addition to the first block, so only 10 of those packets would have been acknowledged - a legitimate client would be incapable of flooding the server like that.

Can I blacklist known bad networks?

Yes. This is the only place that a Blacklist is useful, as this firewall is Deny by Default.  More information is on the Blacklist page.

Why am I not seeing a client in Status that should be there?

If a device is already registered, then it is already a trusted entity, and won't traverse the Responsive firewall.  This, however, means that if you restart iptables (or, the entries expire, which they can do after more than 4000 OTHER hosts try to probe your machine), they won't be visible in the status tab. If you want to see that phone in the Status tab, simply turn it off until it deregisters, and then turn it back on.  Note that the Status is a descriptive only page, and has no relevance to the permissions granted to the device.