Who rated this article

Question

Do you know about Embedded Login Firewall of Bosch IP cameras?

Answer

Embedded Login Firewall | Intelligent Device Access Protection

Introduction

As IP video devices have become more connected and exposed to global networks, so too has their exposure to the threat from cyber-attacks. Attacks can range from simple attempted log-in using a dictionary attack to more sophisticated attacks such as cross-site scripting.
Since most cyber-attacks are based on unauthorized access and control of devices, our first line of defense is credential check and how log-in attempts are treated.
There are many methods in which credential checks can be implemented, and these can vary from vendor to vendor.
Many vendors simply increase the lock-out period with every wrong attempt, like e. g. a standard Linux system does.
While this could provide a reasonable obstacle for an attacker it also has some drawbacks for clients with a wrong or incomplete configuration, and for installers working to set up a system.
The disadvantage of this approach is that, for example, if the user has a typo in his password he may be locked out for a few minutes before he can try again.
In case this happens to an installer, it means non-productive but valuable time and money for him and his customer.
Some vendors even lock out a user completely after a certain number of wrong attempts. For an installer, this means he has to factory default a device, not only dismissing the passwords but also all previous configuration settings that need to be done again.
We don’t want to lock out our own configuration tools and clients nor to place obstacles for our installers, so we implemented a more intelligent solution.

Embedded Login Firewall

The Embedded Login Firewall of all Bosch IP cameras, introduced with firmware version 6.30, consists of a two-level system which makes use of two integrated functional modules.

The logging module

The logging module observes clients’ log-in attempts and gathers information about these clients and their behavior:

► What server or service is targeted with the attempted log-in (RCP, HTTP, Terminal, Web service, iSCSI, FTP, SNMP)?
► Is at least one of the log-in credentials correct in the log-in attempt to any of these servers?
► Are there repeated log-in attempts and failures?

The module logs and memorizes up to the last 32 attempted logins to include client IP addresses, client actions and last access time.

The firewall module

The firewall module blocks access and data traffic from clients which are rated ‘suspicious’ by the logging module.
► TCP-Connections are blocked before they get connected.
► UDP Unicast and Broadcast packets are discarded before being processed by the application.
By blocking access and data traffic on socket level already, the Embedded Login Firewall requires only insignificant computational power to handle unauthorized access and is thus less prone to denial-of-service (DoS) attacks.

The benefits

The Embedded Login Firewall does not require any configuration. It automatically selects the appropriate level of protection to provide full transparency to positively acknowledged clients while blocking unauthorized log-in attempts.
The 20 seconds period is derived from user tests and balanced against probability. On one side, it is short enough that a human user would not experience any blocking while he tries to log in. On the other side, it is long enough to make any attack, and the results of it, unattractive to an attacker. Running a password hacking sequence would extend towards months, if not years, given the password being reasonably strong.
For Configuration Manager, a blocking due to misconfiguration of the password for device access would automatically disappear after 20 seconds once the password had been corrected. Same is valid for any other misconfigured client.
While the Embedded Login Firewall provides reliable access protection in case of an attack, it is quickly „self-healing“ once a password misconfiguration has been corrected, allowing all the “good guys” to seamlessly continue their work.

The decision tree

The intelligence in the Embedded Login Firewall is based on behavioral analysis. If there are 3 or fewer failed log-in attempts to a single server within 20 seconds, the system only observes.
For a human user, this period is typically too short to enter 4 wrong attempts triggering the firewall. Hence, the typical user will have the chance to continuously try to get his password correct without being blocked.
An automated system, like a configuration tool, e. g. Configuration Manager, or an attacking botnet, will try to get access to a device repeatedly and much faster.
Depending on the number of connected or connecting clients the system choses between two modes:

► Blacklist mode
If all recently active clients can be stored in the history (32 IP addresses), the Embedded Login Firewall uses the “Blacklist” mode:
IP addresses which have been successfully logged in are put on an “authenticated” list and kept there for 15 minutes. During this period, an accidental wrong authentication is ignored.
IP addresses which have never been successfully logged in and had more than 3 failed log-in attempts during the last 20 seconds are blocked.
This ensures that allowed clients are not blocked also while a fast attack is running.

► Whitelist mode
When the number of recently active clients exceeds the capacity of the history buffer, in other words, when the number of clients exceeds 32, the Embedded Login Firewall uses the “Whitelist” mode.
Then, only IP addresses, which were registered with at least one successful login to any server on the device within the last 24 hours are allowed to access. Access from a maximum of 32 clients which have been considered “good guys” is possible in this mode.
All other clients, most probably including all the “bad guys”, are blocked until the number of failed log-in attempts drops below the alarm threshold of 4 wrong attempts within 20 seconds, and another client expires from the list of 32.

Event logging and history

Each login attempt is logged in the camera’s event logging, both successful and unsuccessful.
The camera provides an internal history buffer for short-term lookups.
When a longer history is required, external logging to a syslog server is advised.
Refer to our tech note about Log Management.

Attack and Anomaly Detection

The Embedded Login Firewall has the possibility to actively inform a monitoring system about anomalies in system access or an active attack.

RCP message registration

A monitoring system that integrates our RCP+ protocol can register on the message
CONF_LOGIN_LIMITER_MESSAGE to receive a trigger on a relevant change.

Refer to the RCP+ documentation that is published with every firmware release via our product catalog.

Messages are sent:
► With every first successful login
► From the third failed login onwards, but only up to 10 messages to avoid denial-of-service (DoS) situations.

Messages contain only entries for the recent events, like they are also stored in the event log, and not a whole list.
Content of the message in a tagged list format includes status, server name, remote address and user name fields.

SNMP trap

Whenever a RCP+ message is created, the camera checks if a SNMP trap shall be sent.
The SNMP trap contains the same message structure.
Refer to our tech note about SNMP setup and usage.

The win on security

An Anomaly Detection system can analyze the status, repetition, burstiness and content of the messages or traps to protect the installation and help keep the system healthy.
With an installation perfectly optimized, meaning camera access is under control and no camera is loaded with too many access attempts during regular system operation, an attack can be detected easily and very fast due to an immediate report of irregular access patterns, allowing a quick attack response.

Glossary