Best Practices
Location and Addressing
ARTEMIS is a locally deployed real-time BGP prefix hijacking monitoring, detection and mitigation tool. When the IP address of the server on which ARTEMIS is running is affected by a hijack (e.g., routing to blackholes, etc.), the connectivity with the external (publicly available) monitors such as RIPE RIS, RouteViews and CAIDA BMP feeders might be hindered, rendering ARTEMIS "blind". We recommend the following countermeasures against this scenario:
- Connect ARTEMIS also to a local monitor, using e.g., its exaBGP interface. This will ensure that even if the public monitors cannot be reached, information about BGP updates reaching your network will still reach ARTEMIS (for example, this might detect malicious BGP sub-prefix hijacks on the prefix where ARTEMIS itself is running).
- Deploy redundant instances of ARTEMIS running in at least two different (disjoint) prefixes, to lower the probability of such an event happening.
- Use private (or in general, internal) IPs for reaching ARTEMIS and connecting to a local monitor. The public-facing interfaces are primarily needed for communicating with external monitors, as well as serving the frontend content to ARTEMIS users.
- Protect your ARTEMIS server with appropriate firewall rules. We never expose to the Internet what does not need to be exposed; opening port 443 for incoming HTTPS is typically the only actual requirement for ARTEMIS.
Auto-cleaning
Use the DB_AUTOCLEAN
env variable to automatically clean up benign BGP updates more than e.g., 24 hours old (units: hours), see this page. This will also clean up unprocessed BGP updates that were generated from the monitor when the detector was OFF, or excess updates that arose during severe load periods and overwhelmed the detector.
Excess load: Use multiple microservices
See this page.
However, pay also attention to the RAM requirements of the extra microservices (essentially prefixtree
; see here)
Dormant hijacks
By default ARTEMIS will consider all unresolved/unignored/non-withdrawn/non-outdated hijacks as "ongoing". You can set the DB_HIJACK_DORMANT
flag; if an alert has not received BGP updates within the last DB_HIJACK_DORMANT
hours, it will consider it as "dormant" and will restore it to fully ongoing if this changes.
Custom logging
- You can set hijack logging filtering (depending on which communities are associated with the BGP hijack updates) using the
HIJACK_LOG_FILTER
env variable. For details, please check this page. - You can select which fields of a hijack to log using the
HIJACK_LOG_FIELDS
env variable. The default fields are:["prefix","hijack_as","type","time_started","time_last","peers_seen","configured_prefix","timestamp_of_config","asns_inf","time_detected","key","community_annotation","end_tag","hijack_url"]
. - You can select the frequency of the alerts to see in the logging system by proper selection of the mail or hijack log handlers. Please check this page.
Configuration
Please check this page.
Kubernetes
We support Kubernetes besides docker-compose! Please check this page.
Connecting ARTEMIS frontend to LDAP
Please check instructions here.