Kontaktinformationen
Bei technischen Problemen, die mit den CenturionNet-Webservern zusammenhängen, senden Sie bitte eine Anfrage an webmaster@coresecret.eu. Wenn Sie eine verschlüsselte und | oder signierte E-Mail-Kommunikation bevorzugen, verwenden Sie bitte unsere S/MIME- oder PGP-Schlüssel.
Erreichbarkeit und Sicherheit der Server
Alle Server im CenturionNet lassen sich mit DANE/TLSA Resource Records validieren. Selbstverständlich werden die TLSA Resource Records mittels DNSSEC kryptographisch signiert ausgeliefert.
DANE/TLSA (DNS-Based Authentication of Named Entities / TLSA Records):
- DANE ist eine Technologie, die es ermöglicht, TLS-Zertifikate (Transport Layer Security) über DNS (Domain Name System) zu validieren.
- TLSA Records enthalten Informationen über das TLS-Zertifikat eines Servers und werden in DNS-Zonen veröffentlicht, um die Authentizität von TLS-Verbindungen sicherzustellen.
DNSSEC (Domain Name System Security Extensions):
- DNSSEC ist eine Erweiterung des DNS-Protokolls, die durch kryptografische Signaturen die Integrität und Authentizität der DNS-Daten sicherstellt.
- Mit DNSSEC signierte DNS-Daten schützen vor Manipulation und Angriffen wie DNS-Spoofing.
HTTP-Security-Header
Der Zugriff auf unsere Webserver wird durch moderne HTTP-Security-Header geschützt. Diese Header verbessern die Sicherheit der Webanwendungen, indem sie verschiedene Sicherheitsmechanismen aktivieren.
Content-Security-Policy (CSP)
Die Content-Security-Policy (CSP) ist eine Sicherheitsmaßnahme, die Cross-Site Scripting (XSS) und andere Code-Injektionsangriffe verhindert.
Beispiel für eine sehr strikte CSP:
add_header Content-Security-Policy "default-src 'self'; script-src 'self'; object-src 'none'; style-src 'self'; img-src 'self'; frame-ancestors 'none';";Nginx- default-src ’self‘: Erlaubt Ressourcen nur von derselben Origin.
- script-src ’self‘: Erlaubt das Ausführen von Skripten nur von derselben Origin.
- object-src ’none‘: Verhindert die Einbettung von Objekten wie Flash oder Java.
- style-src ’self‘: Erlaubt das Laden von Stylesheets nur von derselben Origin.
- img-src ’self‘: Erlaubt das Laden von Bildern nur von derselben Origin.
- frame-ancestors ’none‘: Verhindert das Einbetten der Seite in Frames oder iFrames.
Unsere Konfiguration
| Domain | CSP |
|---|---|
| coresecret.eu | default-src 'none'; |
Cross-Origin Header
Die Klasse der Cross-Origin-Header
Access-Control-Allow-OriginCross-Origin-Embedder-PolicyCross-Origin-Opener-PolicyCross-Origin-Resource-Policy
zielen darauf ab, die Sicherheit und Integrität von Webanwendungen zu gewährleisten, indem sie kontrollieren, wie Ressourcen zwischen verschiedenen Ursprüngen (Domains) geladen und eingebettet werden. Sie verhindern Cross-Origin-Angriffe, wie Cross-Site Scripting (XSS) und Cross-Site Request Forgery (CSRF), indem sie den Zugriff auf und die Interaktion mit Ressourcen auf eine sichere und kontrollierte Weise regeln.
Access-Control-Allow-Origin
Der Access-Control-Allow-Origin-Header gibt an, welche Ursprünge auf Ressourcen eines Servers zugreifen dürfen. Dieser Header ist Teil des Cross-Origin Resource Sharing (CORS) Mechanismus und wird verwendet, um Webanwendungen auf verschiedenen Domains sicher miteinander kommunizieren zu lassen.
Beispiel:
add_header Access-Control-Allow-Origin "https://coresecret.eu/";NginxDieser Header erlaubt es nur Ressourcen von https://coresecret.eu, auf die Inhalte des Servers zuzugreifen. Dadurch wird verhindert, dass andere Ursprünge (Domains) auf die Ressourcen zugreifen können.
Cross-Origin-Embedder-Policy (COEP)
Der Cross-Origin-Embedder-Policy-Header kontrolliert, welche Ressourcen in eine Webseite eingebettet werden dürfen. Er trägt dazu bei, das Risiko von Cross-Site-Scripting (XSS) und anderen Angriffen zu verringern, indem er den Zugriff auf Ressourcen einschränkt.
Beispiel:
add_header Cross-Origin-Embedder-Policy "require-corp";NginxDieser Header legt fest, dass nur Ressourcen eingebettet werden dürfen, die entweder auf derselben Origin liegen oder über Cross-Origin-Resource-Policy oder CORS explizit freigegeben sind.
Cross-Origin-Opener-Policy (COOP)
Der Cross-Origin-Opener-Policy-Header legt fest, wie eine Webseite mit Dokumenten und Skripten interagiert, die in anderen Browser-Kontexten geladen werden. Dies hilft, verschiedene Cross-Origin-Angriffe zu verhindern, indem es sicherstellt, dass eine Webseite isoliert bleibt.
Beispiel:
add_header Cross-Origin-Opener-Policy "same-origin";NginxDieser Header sorgt dafür, dass Dokumente nur in demselben Origin geöffnet werden können. Dadurch wird verhindert, dass bösartige Seiten Informationen über die aufgerufene Seite erhalten oder damit interagieren.
Cross-Origin-Resource-Policy (CORP)
Der Cross-Origin-Resource-Policy-Header bestimmt, welche Ressourcen von anderen Ursprüngen geladen werden dürfen. Er ergänzt die Sicherheitsmechanismen, die durch die anderen Cross-Origin-Header bereitgestellt werden.
Beispiel:
add_header Cross-Origin-Resource-Policy "same-origin";NginxDieser Header bedeutet, dass nur Ressourcen aus demselben Origin geladen werden dürfen. Ressourcen aus anderen Ursprüngen werden blockiert, was das Risiko von Datenlecks und Angriffen reduziert.
Unsere Konfiguration
Angenommen, die Webseite unter https://coresecret.eu möchte sicherstellen, dass nur Inhalte von dieser Domain geladen und eingebettet werden können und dass die Interaktion mit anderen Ursprüngen streng kontrolliert wird, dann könnte der Header folgendermaßen lauten:
add_header Access-Control-Allow-Origin "https://coresecret.eu";
add_header Cross-Origin-Embedder-Policy "require-corp";
add_header Cross-Origin-Opener-Policy "same-origin";
add_header Cross-Origin-Resource-Policy "same-origin";Nginx- Nur Anfragen von
https://coresecret.eudürfen auf die Ressourcen zugreifen. - Nur Ressourcen von der eigenen Origin oder freigegebenen Ressource können eingebettet werden.
- Dokumente können nur in demselben Origin geöffnet werden, um Isolation sicherzustellen.
- Nur Ressourcen aus derselben Origin dürfen geladen werden.
Strict-Transport-Security (HSTS)
Der HTTP Strict-Transport-Security (HSTS) Header weist Browser an, nur noch über HTTPS mit der Webseite zu kommunizieren, was Man-in-the-Middle-Angriffe verhindert und sicherstellt, dass alle Verbindungen verschlüsselt sind.
Beispiel:
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload";Nginx- max-age=31536000: Die Zeitspanne (in Sekunden), während der der Browser nur HTTPS-Verbindungen zulässt (hier ein Jahr).
- includeSubDomains: Gilt auch für alle Subdomains der Webseite.
- preload: Fordert Browser auf, die Domain in ihre HSTS-Preload-Listen aufzunehmen.
Unsere Konfiguration
| Domain | HSTS Preload Status |
|---|---|
| coresecret.eu | Status: coresecret.eu is currently preloaded. |
| cendev.eu | Status: cendev.eu is currently preloaded. |
X-Content-Type-Options
Der X-Content-Type-Options Header verhindert, dass Browser MIME-Typen „sniffen“ und ermöglicht es, das MIME-Typen genau überprüft werden. Dies hilft, bestimmte Arten von Angriffen zu verhindern.
Beispiel:
add_header X-Content-Type-Options "nosniff";Nginx- nosniff: Weist den Browser an, den deklarierten Content-Type strikt zu beachten und nicht zu erraten.
X-Frame-Options
Der X-Frame-Options Header schützt vor Clickjacking-Angriffen, indem er verhindert, dass die Webseite in einem Frame oder iFrame eingebettet wird.
Beispiel:
add_header X-Frame-Options "deny";Nginx- DENY: Verhindert jegliche Einbettung der Seite.
- SAMEORIGIN: Erlaubt die Einbettung nur von derselben Origin.
Unsere Konfiguration
| Domain | X-Frame-Options |
|---|---|
| coresecret.eu | deny |
| coresecret.dev | deny |
Referrer-Policy
Der Referrer-Policy Header kontrolliert, welche Informationen im Referrer-Header bei Anfragen an andere Seiten gesendet werden. Dies hilft, die Privatsphäre zu wahren und sensible Informationen zu schützen.
Beispiel:
add_header Referrer-Policy "no-referrer" always;NginxReferrer-Policy: no-referrer
- no-referrer: Sendet keinen Referrer-Header.
- no-referrer-when-downgrade: Sendet den Referrer-Header nur, wenn die Zielseite über HTTPS erreichbar ist.
- origin: Sendet nur die Origin, nicht die vollständige URL.
- same-origin: Sendet den Referrer nur für Anfragen mit gleichem Ursprung.
- strict-origin-when-cross-origin: Sendet die Origin bei Cross-Origin-Anfragen, aber die vollständige URL bei gleichen Origin-Anfragen.
Unsere Konfiguration
| Domain | Referrer-Policy |
|---|---|
| coresecret.eu | same-origin |
| coresecret.dev | same-origin |
Verschlüsselte DNS-Resolver
Unsere DNS-Resolver sind über verschiedene verschlüsselte Protokolle erreichbar:
- DNS-over-HTTPS (DoH): Verschlüsselt DNS-Anfragen über das HTTPS-Protokoll, bietet Privatsphäre und Schutz vor Abhören und Manipulation.
- DNS-over-QUIC (DoQ): Eine neuere Technologie, die DNS-Anfragen über das QUIC-Protokoll verschlüsselt, welches eine schnelle und sichere Datenübertragung ermöglicht.
- DNS-over-TLS (DoT): Verschlüsselt DNS-Anfragen mittels TLS-Protokoll, was die Integrität und Vertraulichkeit der Anfragen sicherstellt.
- DNSCrypt: Ein Protokoll, das DNS-Anfragen und -Antworten verschlüsselt und authentifiziert, um Sicherheit und Datenschutz zu gewährleisten.
Sicherheitsüberwachung mit SIEM
Alle Server im CenturionNet werden im Rahmen eines Security Information and Event Management (SIEM) Systems überwacht, in unserem Beispiel: Wazuh.
SIEM (Security Information and Event Management):
- Ein SIEM-System sammelt und analysiert sicherheitsrelevante Daten aus verschiedenen Quellen in Echtzeit.
- Wazuh, unser gewähltes SIEM-Tool, bietet umfassende Überwachungs-, Erkennungs- und Reaktionsfunktionen für sicherheitsrelevante Ereignisse.
Serverhärtung
Unsere Server sind gehärtet und erreichen einen Lynis Score von über 94 %. Lynis ist ein Sicherheitstool, das Systeme auf Schwachstellen und Sicherheitslücken überprüft. Ein Score von über 94 % zeigt ein hohes Maß an Sicherheit und eine starke Härtung gegen potenzielle Angriffe.
Besondere .txt Dateien
mta-sts.txt: SMTP MTA Strict Transport Security RFC 8461
Finden Sie hier unsere aktuelle mta-sts.txt gem. RFC-8461:
version: STSv1
mode: enforce
mx: mail.ed448.eu
max_age: 604800Plaintextrobots.txt: Robots Exclusion Protocol RFC 9309
Finden Sie hier unsere aktuelle robots.txt gem. RFC-9309:
# .__________________________.
# | .___________________. |==|
# | | ................. | | |
# | | ::[ Dear robot ]: | | |
# | | ::::[ be nice ]:: | | |
# | | ::::::::::::::::: | | |
# | | ::::::::::::::::: | | |
# | | ::::::::::::::::: | | |
# | | ::::::::::::::::: | | ,|
# | !___________________! |(c|
# !_______________________!__!
# / \
# / [][][][][][][][][][][][][] \
# / [][][][][][][][][][][][][][] \
#( [][][][][____________][][][][] )
# \ ------------------------------ /
# \______________________________/
#
# https://robotstxt.com/ai
#
User-agent: *
Disallow: /
User-agent: AI2Bot
User-agent: AI2Bot-Dolma
User-agent: aiHitBot
User-agent: Amazonbot
User-agent: anthropic-ai
User-agent: Applebot
User-agent: Applebot-Extended
User-agent: AwarioBot
User-agent: AwarioRssBot
User-agent: AwarioSmartBot
User-agent: Bingbot
User-agent: Bytespider
User-agent: CCBot
User-agent: ChatGPT-User
User-agent: Claude-SearchBot
User-agent: Claude-User
User-agent: claude-web
User-agent: Claude-Web
User-agent: ClaudeBot
User-agent: cohere-ai
User-agent: cohere-training-data-crawler
User-agent: Cotoyogi
User-agent: DataForSeoBot
User-agent: diffbot
User-agent: DuckAssistBot
User-agent: DuckDuckBot
User-agent: Facebookbot
User-agent: facebookexternalhit
User-agent: Factset_spyderbot
User-agent: FirecrawlAgent
User-agent: Gemini-Deep-Research
User-agent: Google-CloudVertexBot
User-agent: Google-Extended
User-agent: Googlebot
User-agent: Googlebot-Image
User-agent: Googlebot-News
User-agent: Googlebot-Video
User-agent: GoogleOther
User-agent: GPTBot
User-agent: Grok
User-agent: Grok-DeepSearch
User-agent: GrokBot
User-agent: ICC-Crawler
User-agent: ImagesiftBot
User-agent: img2dataset
User-agent: Kangaroo Bot
User-agent: Manus-User
User-agent: Mediapartners-Google
User-agent: Meltwater
User-agent: meta-externalagent
User-agent: Meta-ExternalAgent
User-agent: meta-externalfetcher
User-agent: Meta-ExternalFetcher
User-agent: MistralAI-User
User-agent: OAI-SearchBot
User-agent: Omgili
User-agent: Omgilibot
User-agent: PanguBot
User-agent: peer39_crawler
User-agent: Perplexity-User
User-agent: PerplexityBot
User-agent: Petalbot
User-agent: Scrapy
User-agent: Seekr
User-agent: SemrushBot-OCOB
User-agent: Sentibot
User-agent: TikTokSpider
User-agent: Timpibot
User-agent: TurnitinBot
User-agent: Twitterbot
User-agent: VelenPublicWebCrawler
User-agent: webzio-extended
User-agent: xAI-Bot
User-agent: xai-grok
User-agent: xAI-Grok
User-agent: xAI-Web-Crawler
User-agent: Youbot
Allow: /
Disallow: /wp-admin/
Allow: /wp-admin/admin-ajax.php
Disallow: /wp-includes/
Disallow: /wp-content/plugins/
Sitemap: https://coresecret.eu/wp-sitemap.xml
# ________
# __,_, | |
# [_|_/ | OK |
# // |________|
# _// __ /
#(_|) |@@|
# \ \__ \--/ __
# \o__|----| | __
# \ }{ /\ )_ / _\
# /\__/\ \__O (__
# (--/\--) \__/
# _)( )(_
# `---''---`Plaintextsecurity.txt: Security Vulnerability Disclosure RFC 9116
Finden Sie hier unsere aktuelle robots.txt gem. RFC-9116:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
# For Coordinated Vulnerability Disclosure
Contact: mailto:security@coresecret.eu
Contact: https://coresecret.eu/contact
# Our RSA4096 OpenPGP key for vulnerability disclosure
Encryption: https://keys.openpgp.org/vks/v1/by-fingerprint/2D9807F410301776597EBDC99F54885335A3C9AD
Encryption: https://coresecret.eu/repository
# Our coordniated vulnerability disclosure policy
Policy: https://coresecret.eu/security-policy
# Our security acknowledgments page (Hall of fame)
Acknowledgments: https://coresecret.eu/security-policy/acknowledgments
# Further information according to RFC 9116
Expires: 2026-07-01T00:00:00.000Z
Preferred-Languages: de, en, fr, pt
Canonical: https://coresecret.eu/.well-known/security.txt
# Interested to join ous?
Hiring: https://coresecret.eu/career
# CSAF: not supported yet
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCAAdFiEELZgH9BAwF3ZZfr3Jn1SIUzWjya0FAmfutXEACgkQn1SIUzWj
ya1oQxAAtlz6pFoehooH0+LPKi8SSkRin1pt0dAvmMwIJw6SIzjP4p65g4UPCrfk
gRgRZLfBUJHRzQeTVCOjFG3FWusW7O8ajPyzDH0j8tprcuoMEGPT8FfDhYaquy4L
wu8IncX5GcntjqifSmryLtyaJJuuhxaLppAWQcbTDW7tYL+sOYqbUMTvjQopgIUH
K/mhRBhXL4LEfe0wWcesYc4tp8mx1hVlmYww8IzLApkjMA/f5dU6KZkfN7KoSkuM
myvbjsLmORSVZb3oTeVLEfY38X0PbRCbsQ5SmBFbPWU7BVQ60HE5SATTa7MVbnzW
1bUv9FsB71HDd4SWIrK42Im4nGuVaVCOd/G1fpoqY2ij8gQjF44qK+5znlrwRjbc
XMitU+wFpXZU0qIcE5BWOIxs44yRgVfNz0TOrvp/EN6HdjiLjIWseZD/I/ikgw7B
ezzAbrPqnz6vDm/tRMT7Q2WTa95csKB9fyZUvUShV7CWMVYK+vTeRTbhco/2xJz3
opGDdJiNc3U+Unq4edjvAlxDa9xiCfVYFrcG+pNcFeAT3chgTr2Dyas99GZdKMn3
iKBsqxAfwZEQBnyhMlIQqcIsAWwcOPaTc7TD2kI78qdljeke/zmGrOmbDkE4A16G
2ZR0UtBbHQRjp+82Fd04Wj9L5SCv+hYyr1sUt/stQ7I/Ui1QUZ4=
=0R7I
-----END PGP SIGNATURE-----Plaintext