Public Firewall Rules

This document outlines the public firewall rules. To protect against targeted Distributed Denial of Service (DDoS) attacks, we do not disclose the additional dynamic rules that are part of our AWS DDoS Protection. These dynamic rules are crucial for enhancing security and are adjusted automatically based on real-time threat detection. By withholding this information, we aim to minimize vulnerabilities and ensure the ongoing security and integrity of our infrastructure while maintaining transparency about the core elements of our public firewall setup.

Visma Connect’s own IP Addresses

The Connect Identity Provider IP Addresses for our domain connect.visma.com are changed frequently by the hosting provider and are not fixed, so we cannot give you a list to add to your Firewall.

IP blacklisting

What is it and how it works

In order to prevent various DDOS events that can happen both intentionally and unintentionally, we have implemented multiple automatic firewall strategies that could affect traffic even from trusted sources if something is detected as violating one of the rules.

We can classify malicious traffic in the following way:

• Intentional → done by bad actors that have the sole purpose of putting a strain on the system or even taking it down completely

• Unintentional → a bad implementation by an integration. An example, with all the redirections between systems that happen during an OIDC flow, users could possibly end-up in an infinite redirect loop thus causing an unwanted DDOS event towards our system, or even both systems.

We have multiple rules that are evaluated in a specific order, each dealing with a different threat or use-case.

Rules

The order in which these rules are evaluated is the order in which they are described below.

General blacklist

• Returned status code → 403 Forbidden

• Duration →permanent

• Who controls it → Visma Connect

General blacklist controlled by our team. This list is managed manually by us and we can do changes to it if requested via a support ticket describing the IP and the customer’s needs and usage for it.

Visma blacklist

• Returned status code → 403 Forbidden

• Duration →permanent

• Who controls it → Visma Security

General blacklist controlled by the Visma Security team. This contains a list of malicious IPs gathered though different intelligence methods from both the clearnet and dark web.

Changing something in the list can be requested via a support ticket describing the IP and the customer’s needs and usage for it.

AWS IP reputation list

• Returned status code → 403 Forbidden

• Duration →permanent

• Who controls it →

Similar to the Visma blacklist, but it’s controlled by AWS itself. Mostly concerns bots, darknet and similar networks. Cannot be edited for individual IPs.

User-Agent regex pattern filter

• Returned status code → 403 Forbidden

• Duration →permanent

• Who controls it → Visma Connect

Blocks all requests with a User-Agent header (UA) that matches the following regex: ^[a-z0-9]{12}$. This regex pattern is usually used by various botnets when performing scans on public domains. Does not affect customers that have no UA present or that have any type of common UA specified, such as a browser or device.

Error-based blocklist

• Returned status code → 403 Forbidden

• Duration →permanent

• Who controls it → Visma Connect

Whenever we detect an IP addressed that generates more than 6500 bad requests / 5 min, that end-up with our system returning any status code from the 4xx range, that IP is permanently blocked by our system.

Changing something in the list can be requested via a support ticket after the customer has identified and fixed the source of the errors.

Request flood rate limiting

• Returned status code → 429 Too Many Requests

• Duration →5 min

• Who controls it → AWS & Visma Connect

Temporary rate-limiting when a single IP is detected to perform more than 10k requests / 5 min.

This list is managed by AWS and lasts for 5 mins after the rule violation has ended. While the rule is still being triggered by the IP, the duration will not start counting down from the initial 5 minutes.

There is no way to reset this rule, the only solution is to stop the request flood and wait the allocated leeway of 5 minutes for that IP address.

IP whitelisting

We also offer a solution for whitelisting IP addresses.

We have 2 whitelists that have a higher priority than all of the blacklists in the previous section, so any IP added in these lists will never be able to be blocked by the automatic blocking rules of our firewall.

The order in which these rules are evaluated is the order in which they are described below.

Rules

General whitelist

• Who controls it → Visma Connect

General blacklist controlled by our team. This list is managed manually by us and meant to be used mostly for internal resources within Visma.

Application whitelist

• Who controls it → Integrating applications & Visma Connect

Whitelist where integrations (teams in Developer Portal) can add well-known IPs from their systems. These can be managed within Developer Portal.

Integrations often use these lists to circumvent the Request flood rate limiting blacklist rule when they know there is usually going to be high traffic from a certain access point (i.e. a public school where an exam takes place).

IPs added to this list are usually applied instantly, with the exception of addresses that are found in certain blocklists. When this happens, those IPs will need to be approved by the Visma Connect team before being applied.