- 13 Sep 2024
- 4 Minutes to read
- Print
- DarkLight
- PDF
Firewall
- Updated on 13 Sep 2024
- 4 Minutes to read
- Print
- DarkLight
- PDF
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.