Datenhaufen zu IT und Elektronik.

Autor: kernel-error (Seite 16 von 48)

Die Jungs vom BSI und Nextcloud: Zusammenarbeit für mehr Sicherheit

Nextcloud hat sie die Mühe gemacht und mal nach owncloud und nextcloud Installationen gesucht. Dabei haben sie direkt mal geprüft wie sicher oder unsicher die wohl sind. Das hat seinen Weg zum BSI gefunden und die haben dann die abuse Adressen aller Netzbetreiber „gefüttert“.

Erstmal keine schlechte Idee. Natürlich will nextcloud was damit erreichen, das BSI macht auch brav mit super… Solange wir alle IPv4 machen läuft diese Version auch!

Oh ja, die abuse Mail:

Sehr geehrte Damen und Herren,
 
 ownCloud und Nextcloud sind Software-Lsungen zum Betrieb selbst
 gehosteter Cloud-Instanzen zur Synchronisation und zum Austausch
 von Daten.
 
 Das Unternehmen Nextcloud GmbH hat offen aus dem Internet
 erreichbare Installationen von ownCloud und Nextcloud geprft.
 Dabei wurden zahlreiche Cloud-Instanzen identifiziert, die mit
 veralteten Software-Versionen laufen, welche verschiedene
 Sicherheitslcken aufweisen.
 
 Angreifer knnen diese Schwachstellen ausnutzen, um unter anderem
 unberechtigt auf die in der Cloud gespeicherten Daten zuzugreifen.
 Dabei knnen die Angreifer ggf. sensible Informationen wie z.B.
 persnliche Dokumente, Fotos oder Kundendaten von Unternehmen
 aussphen und diese anschlieend im Internet verffentlichen oder
 fr kriminelle Zwecke wie Erpressungen nutzen.
 Andere Schwachstellen ermglichen Angreifern die Ausfhrung
 beliebigen Programmcodes auf dem Cloud-Server. Dies kann ggf.
 zu einer vollstndigen Kompromittierung des Systems und dessen
 Missbrauch fr weitere kriminelle Aktivitten fhren.
 
 Die Nextcloud GmbH hat CERT-Bund ihre Ergebnisse der Prfungen
 zur Untersttzung bei der Benachrichtigung betroffener Server-
 Betreiber bereitgestellt.
 
 Nachfolgend senden wir Ihnen eine Liste betroffener Systeme in
 Ihrem Netzbereich. Der Zeitstempel (Zeitzone UTC) gibt an, wann
 die verwundbare Cloud-Installation identifiziert wurde.
 Weiterhin sind fr jedes System eine Risikoeinstufung sowie eine
 eindeutige ID (UUID) angegeben.
 
 Die Nextcloud GmbH stellt unter folgender URL detaillierte
 Informationen zu den bei der jeweiligen Cloud-Instanz erkannten
 Schwachstellen und deren Behebung zur Verfgung:
 https://scan.nextcloud.com/results/[UUID]
 
 Der Parameter [UUID] muss dabei durch die zu der jeweiligen Instanz
 angegebene UUID ersetzt werden. Beispiel:
 https://scan.nextcloud.com/results/12345678-1234-1234-1234-12345678
 
 Wir mchten Sie bitten, den Sachverhalt zu prfen und Manahmen zur
 Aktualisierung der Cloud-Installationen auf den betroffenen Systemen
 zu ergreifen bzw. Ihre Kunden entsprechend zu informieren. Fr alle
 auf den betroffenen Systemen identifizierten Schwachstellen stehen
 entsprechende Sicherheitsupdates der Hersteller zur Verfgung.
 
 Bei Rckfragen zu den durchgefhrten Prfungen der Cloud-Instanzen
 wenden Sie sich bitte direkt an die Nextcloud GmbH unter
 <cloud-security-scan@nextcloud.com>.
 
 
 Diese E-Mail ist mittels PGP digital signiert.
 Informationen zu dem verwendeten Schlssel finden Sie unter
 <https://reports.cert-bund.de>.
 
 Bitte beachten Sie:
 Dies ist eine automatisch generierte Nachricht.
 An die Absenderadresse kann nicht geantwortet werden.
 Bei Rckfragen zu dieser Benachrichtigung wenden Sie sich bitte
 unter Beibehaltung der Ticketnummer in der Betreffzeile an
 <certbund@bsi.bund.de>.
 
 ======================================================================
 
 Betroffene Systeme in Ihrem Netzbereich:
 
 Format: ASN | IP | Timestamp (UTC) | UUID | Severity | Port | Hostname
  12345 | 1.2.3.4    | 2017-02-06 19:53:17 | 1ae3f7da-3367-4012-9382-7912dd4bd163 | high       | 80     | cloud.domain.de
  12345 | 1.2.3.5    | 2017-02-06 19:53:17 | 2e0a45fa-1568-458f-898e-2a888b44c9c6 | medium     | 80     | cloud.wurst.com
  12345 | 1.2.3.6    | 2017-02-06 19:53:17 | 32288a95-d396-4c9b-8998-d1968dc30ad7 | low        | 80     | cloud.alalaa.de 
  12345 | 1.2.3.7    | 2017-02-06 19:53:17 | ecfd4e62-b1b5-4c7d-b888-3f19ca3ca7ff | high       | 443    | cloud.butani.cn
  12345 | 1.2.3.8    | 2017-02-06 19:53:17 | 52ff7f71-c004-4a36-9975-2b5a99f280d6 | high       | 80     | cloud.bima.org
  12345 | 1.2.3.9    | 2017-02-06 19:53:17 | e388d8c5-4124-4af3-b052-57f77469783a | high       | 80     | cloud.2083a.net
  12345 | 1.2.3.10   | 2017-02-06 19:53:17 | 5cad0785-a6eb-47ca-aeec-6c4252928d13 | low        | 443    | cloud.lutzola.nl
  12345 | 1.2.3.11   | 2017-02-06 19:53:17 | 7da5d2dc-8556-4699-9ea4-7814c6afb8c0 | high       | 80     | cloud.weglaa.wu
  12345 | 1.2.3.12   | 2017-02-06 19:53:17 | adac575f-6a42-487d-a8c3-1b789ebafe39 | medium     | 80     | cloud.breck.aa
  [.....]

 
 Mit freundlichen Gren / Kind regards
 Team CERT-Bund
 
 Bundesamt fr Sicherheit in der Informationstechnik (BSI)
 Federal Office for Information Security
 Referat CK22 - CERT-Bund
 Godesberger Allee 185-189, D-53175 Bonn, Germany

LG G2 (d802) LinageOS und TWRP

Auf meinem Smartphone werkelt inzwischen LinageOS. Funktioniert auch ganz prima 🙂 Heute am Morgen kommt die Meldung hoch: „Es gibt ein Update“. Ich drück natürlich auf: „Gib ihm!“

Das Gerät macht irgendwas und startet dann im TWRP neu. An der Stelle hätte ich nun damit gerechnet, dass es beginnt das Update zu installieren. Tut er aber leider nicht :-/ Ich starte also neu, wieder kommt er im TWRP hoch. Egal was ich mache, bleibt so.

Nicht falsch verstehen, ich beschwere mich nicht darüber. Ich habe mich ja dafür entschieden ein solch instabiles System zu nutzen. 😀

Wie auch immer. Folgendes hat mir geholfen.

Im TWRP den Terminal Emulator starten und folgende Befehl absetzten:

dd if=/dev/zero of=/dev/block/platform/msm_sdcc.1/by-name/fota
dd if=/dev/zero of=/dev/block/platform/msm_sdcc.1/by-name/misc

Reboot und gut!

Anruf bei der G Data Hotline: Ein Erfahrungsbericht

Ich: tuuuuut…… tuuuuuut
Hotline: Bla gdata Hotline bla
Ich: Pffffhhhh
Hotline: *laala* (mucke)
Ich: Pffffhhhh
Hotline: Willkommen an der Hotline, mein Name ist Mann, was kann ich für sie tun?
Ich: Sie brauchen sicher meinen Benutzernamen, oder?

Das scheint da so etwas wie die Kundennummer in anderen Unternehmen zu sein….

Hotline: Oh ja, den nehme ich gerne.
Ich: Konrad-5-Julius-Heinrich-97- [Hotlinemann unterbricht mich]
Hotline: Konrad ausgeschrieben?
Ich: Öhm ähh ne also öh der Buchstabe?!?
Hotline: OK
Ich: Kundenummer…
Hotline: und was kann ich nun für sie tun?
Ich: Wir testen gerade die Amavis Integration eurer G DATA Business Lösung und das läuft nicht ganz rund.
Hotline: uhhaaa ohh
Ich: Warum uhaaa ohh?
Hotline: Öhm (hehe) also ähh, da bekommen wir eher weniger Anfragen. Wird nicht so oft benutzt.
Ich: Na aber ihr verkauft das ja.
Hotline: Ja aber ähh gut.


Dann wurden Version und OS abgefragt und ein Ticket angelegt. Ich sollte mal Auszüge aus dem Maillog senden O_o irgendwie habe ich das Gefühl als wenn das gerade nix wird 😀

Für Spaß auch mal die Logfiles:

Feb  7 08:27:54 mx amavis[27217]: (21323-04-4) (!)run_command: child process [27217]: Insecure dependency in exec while running with -T switch at /usr/sbin/amavisd-new line 4743.
Feb  7 08:27:54 mx amavis[21323]: (21323-04-4) (!!)collect_results from [27217] (/usr/bin/gdmailscannerc): exit 3 Feb  7 08:27:54 mx amavis[21323]: (21323-04-4) (!)checking with spam scanner GDATA_SPAM_SCANNER failed: GdataSpamScanner: Failed processing request; illegal response(%d) at /usr/local/lib/site_perl/Amavis/SpamControl/GdataSpamScanner.pm line 158.
Feb  7 08:27:54 mx amavis[21323]: (21323-04-4) (!!)TROUBLE in check_mail: spam_scan FAILED: GDATA_SPAM_SCANNER failed: GdataSpamScanner: Failed processing request; illegal response(%d) at /usr/local/lib/site_perl/Amavis/SpamControl/GdataSpamScanner.pm line 158. at (eval 98) line 159.
Feb  7 08:27:54 mx amavis[21323]: (21323-04-4) (!)PRESERVING EVIDENCE in /var/lib/amavis/tmp/amavis-20170207T082744-21323-gFK_Ofar
Feb  7 08:27:54 mx postfix/smtp[27003]: EFA15C0A13: to=<type@domain.de>, relay=127.0.0.1[127.0.0.1]:10024, conn_use=4, delay=85234, delays=85181/42/0/10, dsn=4.5.0, status=deferred (host 127.0.0.1[127.0.0.1] said: 451 4.5.0 Error in processing, id=21323-04-4, spam_scan FAILED: GDATA_SPAM_SCANNER failed: GdataSpamScanner: Failed processing request; illegal response(%d) at /usr/local/lib/site_perl/Amavis/SpamControl/GdataSpamScanner.pm line 158. at (eval 98) line 159. (in reply to end of DATA command)) Feb  7 08:27:54 mx amavis[27219]: (21323-04-5) (!)run_command: child process [27219]: Insecure dependency in exec while running with -T switch at /usr/sbin/amavisd-new line 4743.
Feb  7 08:27:54 mx amavis[21323]: (21323-04-5) (!)run_av (GDAVCLIENTC SCANNER.) FAILED - unexpected , output=""
Feb  7 08:27:54 mx amavis[21323]: (21323-04-5) (!)GDAVCLIENTC SCANNER. av-scanner FAILED: CODE(0x2cc4260) unexpected , output="" at (eval 97) line 905.
Feb  7 08:27:54 mx amavis[21323]: (21323-04-5) (!)WARN: all primary virus scanners failed, considering backups Feb  7 08:27:54 mx amavis[27221]: (20783-09-4) (!)run_command: child process [27221]: Insecure dependency in exec while running with -T switch at /usr/sbin/amavisd-new line 4743.
Feb  7 08:27:54 mx amavis[20783]: (20783-09-4) (!!)collect_results from [27221] (/usr/bin/gdmailscannerc): exit 3 Feb  7 08:27:54 mx amavis[20783]: (20783-09-4) (!)checking with spam scanner GDATA_SPAM_SCANNER failed: GdataSpamScanner: Failed processing request; illegal response(%d) at /usr/local/lib/site_perl/Amavis/SpamControl/GdataSpamScanner.pm line 158.
Feb  7 08:27:54 mx amavis[20783]: (20783-09-4) (!!)TROUBLE in check_mail: spam_scan FAILED: GDATA_SPAM_SCANNER failed: GdataSpamScanner: Failed processing request; illegal response(%d) at /usr/local/lib/site_perl/Amavis/SpamControl/GdataSpamScanner.pm line 158. at (eval 98) line 159.
Feb  7 08:27:54 mx amavis[20783]: (20783-09-4) (!)PRESERVING EVIDENCE in /var/lib/amavis/tmp/amavis-20170207T082744-20783-75UHo67I
Feb  7 08:27:54 mx postfix/smtp[27159]: D74F7C00F4: to=<type@domain.de>, relay=127.0.0.1[127.0.0.1]:10024, conn_use=4, delay=342238, delays=342185/42/0/10, dsn=4.5.0, status=deferred (host 127.0.0.1[127.0.0.1] said: 451 4.5.0 Error in processing, id=20783-09-4, spam_scan FAILED: GDATA_SPAM_SCANNER failed: GdataSpamScanner: Failed processing request; illegal response(%d) at /usr/local/lib/site_perl/Amavis/SpamControl/GdataSpamScanner.pm line 158. at (eval 98) line 159. (in reply to end of DATA command)) Feb  7 08:27:55 mx amavis[20783]: (20783-09-5) Passed CLEAN {RelayedInbound}, SPAM_DISC [1.2.3.4]:44419 [1.2.3.4] <type@domain.de> -> <type@domain.de>, Queue-ID: 6D65CC0A33, Message-ID: <62734015.3835.1486452455492.JavaMail@domain.de>, mail_id: lsOZOYNAIa3o, Hits: 0, size: 44774, queued_as: 57B04C0A40, 471 ms

Feb  7 09:55:25 mx amavis[22893]: (22893-07) Passed CLEAN {RelayedInbound}, SPAM_DISC [1.2.32.4]:36945 [1.5.7.98] <type@domain.de> -> <type@domain.de>, Queue-ID: E7592C0071, Message-ID: <20170207085513.B8A52340881@domain.de>, mail_id: 3lhpfBFnyuAI, Hits: 0, size: 4172, queued_as: 1F499C00F7, 10166 ms Feb  7 09:55:25 mx amavis[20843]: (20843-14) (!)run_av (GDAVCLIENTC SCANNER.) FAILED - unexpected , output="SKIP"
Feb  7 09:55:25 mx amavis[20843]: (20843-14) (!)GDAVCLIENTC SCANNER. av-scanner FAILED: CODE(0x2cc4260) unexpected , output="SKIP" at (eval 97) line 905.
Feb  7 09:55:25 mx amavis[20843]: (20843-14) (!)WARN: all primary virus scanners failed, considering backups

Eigenes DNSRBL, RHSBL und RBL für Postfix einrichten

Hallo zusammen,

ich habe meine DNSRBL RHSBL RBL für Postfix angefasst. Wer sie also zum Test abfragen möchte (/etc/postfix/main.cf)):

# RECIPIENT restrictions:
smtpd_recipient_restrictions =
   permit_mynetworks,
   permit_sasl_authenticated,
   check_recipient_access hash:/etc/postfix/recipient-access,
   check_sender_access hash:/etc/postfix/sender-access,
   reject_unverified_recipient,
   reject_unauth_pipelining,
   reject_non_fqdn_recipient,
   reject_unknown_recipient_domain,
   reject_unauth_destination,
   reject_rbl_client imap.bl.blocklist.de,
   reject_rbl_client mail.bl.blocklist.de,
   reject_rbl_client b.barracudacentral.org,
   reject_rbl_client zen.spamhaus.org,
   reject_rbl_client bl.spamcop.net,
   reject_rbl_client cbl.abuseat.org,
   reject_rbl_client ix.dnsbl.manitu.net,
   reject_rbl_client virbl.dnsbl.bit.nl,
   reject_rbl_client abuse.rhsbl.kernel-error.de,
   reject_rbl_client postmaster.rhsbl.kernel-error.de,
   reject_rbl_client spam.rhsbl.kernel-error.de,
   reject_rbl_client spam.rbl.kernel-error.de,
   reject_unknown_recipient_domain,
   permit

B.t.w.: Ihr solltet das natürlich niemals produktiv einsetzten und macht es vollständig auf eure Verantwortung, denn ich würfle das nach meine ganz privaten Meinung 🙂

Ich fülle die Liste zum Teil von Hand, wenn ich irgendwas von einem System bekomme was ich nicht haben wollte landet es dort. Ebenfalls füllt es sich automatisch durch ein Postfach das „Werbung“ sammelt. Ich lasse Adressen/Systeme dort in der Regel für min. 6 Monate liegen. Es sei denn da ist was schief gelaufen, ich habe doch das Bedürfnis mit diesem System E-Mails zu tauschen oder sonst was.

Es bleibt aber dabei, es ist meine ganz private Liste damit nicht jedes meiner Mailsysteme einzeln lernen muss welche E-Mails ich nicht haben will. Wenn ihr es produktiv einsetzt wird es Probleme geben 😀

So long..

DNSSEC IPv6 DENIC und ein DNS in Japan

Ich brauche mal eure Hilfe…

Zum Spaß habe ich mir einen VPS Server in Japan geklickt. Was nun damit tun? Einfach mal ein weiteren DNS Server nutzen \o/ Gute Idee? Nein… Warum nicht? Weil der Server in Japan steht, höhere Antwortzeiten hat und der meist zufällig entscheidet, welcher DNS Server nun gefragt wird. Ich habe somit also sporadisch DEUTLICH langsamere DNS Antworten. Für meinen Spieltrieb aber gerade OK .-P

Ist also nun ein FreeBSD 10 mit einem Bind9.11 als slave für drei Spielzonen (kernel-error.org, kernel-error.com, kernel-error.de). FreeBSD ans Ende gepatcht, aktuellen Bind drauf, getestet ob die Kiste sauber signierte Zonen abfragen und prüfen kann (TCP/UDP und größer 512) alles gut. Dann als slave eingebunden wieder getestet und dann in die Zone darüber eintragen lassen. Die Zonen org. sowie com. haben den DNS-Server einfach gefressen. die Zone de. meckert aber! DNS timeout bei IPv6 O_o Öhm, ok… dig und drill sagen das geht aber. Bind ist auch fest ein und ausgehend an die IPv6 Adresse gebunden. Als „Firewall“ rennt PF, das mal deaktiviert ändert aber nichts. Vielleicht filter der Provider? Nope nur switch, iptables und ebtables öhm, das klingt sehr spartanisch.

Hat das Problem nur denic? Nö, DNSViz scheint es auch nicht zu können: http://dnsviz.net/d/kernel-error.com/dnssec/

Wie gesagt NUR bei IPv6! Jetzt habe ich mir alle Mühe gegeben diesen Timeout selbst mal zu produzieren, klappt aber nicht. Bei mir geht es einfach IMMER egal was für Optionen ich dig mitgebe.

# dig @2001:310:6000:f::1fc7:1 +edns +multi +norec +bufsize=4096 kernel-error.com IN MX +short
10 smtp.kernel-error.de.
# dig @2001:310:6000:f::1fc7:1 +tcp +edns +multi +norec +bufsize=4096 kernel-error.com IN MX +short
10 smtp.kernel-error.de.

Ich verstehe das nicht! Ich mache am bind keine Unterscheidung zwischen IPv4 und IPv6, für mich geht alles. Alle Antworten und Fragen in alle Richtungen laufen ohne jedes Problem. Nur DNSViz und denic scheinen ein „Problem“ zu haben. Mal sehen ob jemand von der denic mit einen sinnvollen Tipp geben kann. Mir würde ja schon der dig Aufruf reichen der zu einem timeout führt :-/ Dann hätte ich etwas zum Testen.

Oh ja, ich habe natürlich auch ganz brav mal tcpdump laufen lassen. Leider sieht es hier ebenfalls einfach funktionstüchtig aus 🙁

https://www.kernel-error.de/download/dns.tar.gz

Hat von euch irgendjemand eine Idee?


*U-P-D-A-T-E*

Die interne Fehlermeldung der API DENIC:

ERROR: 223 Timeout after switching from UDP to TCP – switch to TCP due to timeout (target) (ns3.kernel-error.com./2001:310:6000:f:0:0:1fc7:1:53)


*U-P-D-A-T-E*

Mal querry log eingeschaltet:

30-Jan-2017 18:30:04.669 client @0x802e62600 2a02:568:201:214::1:15#38145 (ns3.kernel-error.com): query: ns3.kernel-error.com IN A -E(0)DC (2001:310:6000:f::1fc7:1)
30-Jan-2017 18:30:04.670 client @0x802e62600 2a02:568:201:214::1:15#41589 (ns3.kernel-error.com): query: ns3.kernel-error.com IN AAAA -E(0)DC (2001:310:6000:f::1fc7:1)
30-Jan-2017 18:30:04.938 client @0x802e62600 2a02:568:201:214::1:15#20703 (kernel-error.de): query: kernel-error.de IN SOA - (2001:310:6000:f::1fc7:1)
30-Jan-2017 18:30:05.510 client @0x802e6f800 2a02:568:201:214::1:15#58465 (kernel-error.de): query: kernel-error.de IN NS -T (2001:310:6000:f::1fc7:1)
30-Jan-2017 18:30:05.889 client @0x802e62600 2a02:568:201:214::1:15#47548 (kernel-error.de): query: kernel-error.de IN SOA -E(0)D (2001:310:6000:f::1fc7:1)
30-Jan-2017 18:30:05.896 client @0x802e62600 2a02:568:201:214::1:15#55493 (kernel-error.de): query: kernel-error.de IN DNSKEY -E(0)D (2001:310:6000:f::1fc7:1)
30-Jan-2017 18:30:06.416 client @0x802e70c00 2a02:568:201:214::1:15#37170 (kernel-error.de): query: kernel-error.de IN DNSKEY -E(0)TD (2001:310:6000:f::1fc7:1)

*U-P-D-A-T-E*

Ich glaube es nicht… Ich teste hier gerade rum, will einem Kollegen zeigen das es nicht geht und das Update läuft bei DENIC einfach durch und OK Ö_ö ich verstehe das nicht, wirklich nicht. Absolut 0,0 warum geht das jetzt und warum meint DNSViz das es dennoch nicht geht? Was passiert hier?


*U-P-D-A-T-E*

Bleibt nur noch meine Vermutung, dass es wirklich um die Antwortzeit des Servers geht… Die liegt so zwischen 200 und 300ms. Das ist echt lange aber auch nicht SOOOOOOO lange :-/ Mal sehen ob von denic irgendwas kommt?!?!


*U-P-D-A-T-E*

Da fliegt mir doch gerade folgende Info rein:

die DENIC meinte dazu:

    unsere Kollegen können derzeit nicht genau sagen woran es hängt. Jedoch sind unsere Verbindungen nach Korea zeitweise leicht beeinträchtigt, evtl. wurde dir Nast Prüfung genau in dem Moment durchgeführt.


Es scheint als bekommen wir das nicht geklärt. Aber schön, wenn das
Update nun durch ist.

PS: Ein leicht ungutes Gefühl bleibt ...

Neues Zertifikat für die Homepage von Let’s Encrypt

Tach zusammen,

StartSSL ist ja aktuell einfach tot 🙁 Eine für mich sinnvolle Alternative konnte ich aber nicht finden. Eine Wildcard Zertifikat für meine Domains und dann einfach überall das gleiche *grusel* aber 10000 € ausgeben um sonst meine Wünsche zu erfüllen macht auch keinen Sinn. Tja bleibt Let’s Encrypt…. Gott, ich will nicht alle drei Monate neue Zertifikate bauen. Das ist Käse, vor allem mit TLSA/DANE, HPKP usw. *brech*

Für jetzt bin ich dennoch dazu gezwungen auf Let’s Encrypt zu wechseln. Es wird also ein solches Zertifikat hier geben. Ich hoffe nun einfach darauf, dass StartSSL wieder in die Browser kommt. 01.06.2017 soll es da wohl weiter gehen, hm?

https://bugzilla.mozilla.org/show_bug.cgi?id=1311832

https://startssl.com/NewsDetails?date=20160919

Klar ist jetzt dieser China CA zu vertrauen? Nö… Nur bis zu einem gewissen Punkt und ab dann halt HPKP, TLSA/DANE, DNS CAA. Was mir so gut gefällt ist die Möglichkeit für einen vertretbaren Preis so viele unterschiedliche Zertifikate raus zu hauen, wie ich es für richtig halte.

Also kommt nun Let’s Encrypt als „hoffentlich Übergang“ und dann wieder StartSSL oder jemand von euch hat eine gute Idee für mich?

So long…

Telekom SmartHome

Das Zeug funktioniert ja zu 85% super… Aber hin und wieder könnte ich das Zeug einfach aus dem Haus treten :-/

Es ist ein Problem aufgetreten (500)

Die gewünschte Seite ist zurzeit nicht erreichbar.

Laden Sie die Seite zunächst bitte neu. Erhalten Sie wiederholt diese Meldung, versuchen Sie es zu einem späteren Zeitpunkt wieder, da evtl. Wartungsarbeiten durchgeführt werden.

Im Falle einer Meldung an den QIVICON Support stets angeben:
Fehlercode 586b87c131d73:0

Es ist ein Problem aufgetreten (500) Die gewünschte Seite ist zurzeit nicht erreichbar. Laden Sie die Seite zunächst bitte neu. Erhalten Sie wiederholt diese Meldung, versuchen Sie es zu einem späteren Zeitpunkt wieder, da evtl. Wartungsarbeiten durchgeführt werden. Im Falle einer Meldung an den QIVICON Support stets angeben: Fehlercode 586b87c131d73:0
QIVICON Telekom SmartHome Error Fehler

« Ältere Beiträge Neuere Beiträge »

© 2025 -=Kernel-Error=-

Theme von Anders NorénHoch ↑