Autor: kernel-error (Seite 25 von 48)

Auf meinem Sabayon System findet mein Rigo leider keinen owncloud-client. Glücklicherweise baut sich dieser fast von alleine 😀

Ich lade mir also einfach die beiden Quellpakete qtkeychain-master.zip und mirall-1.6.1rc1.tar.bz2 herunter. Entpacke sie qtkeychain-master in qtkeychain-master und mirall-1.6.1rc1 in mirall. Dann beginne ich mit dem bauen, dabei lege ich den späteren Installationsprefix auf /usr fest damit es am Ende nicht alles unter /usr/local… liegt. Dieses aber, wie so oft, selbst denkend nachmachen, es wird schnell unordentlich.

$ mkdir qtkeychain-build
$ cd qtkeychain-build
$ cmake -DCMAKE_BUILD_TYPE="Debug" cmake -DCMAKE_INSTALL_PREFIX:PATH=/usr ../qtkeychain-master
$ make
$ sudo make install

Jetzt noch der eigentliche owncloud-client.

$ mkdir mirall-build
$ cd mirall-build
$ cmake -DCMAKE_BUILD_TYPE="Debug" cmake -DCMAKE_INSTALL_PREFIX:PATH=/usr ../mirall
$ make
$ sudo make install

Schon lässt sich alles aufrufen und wie gewünscht nutzen. Ach ja, sollten noch Abhängigkeiten fehlen, finden sich diese aktuell alle mit Rigo! Sauberer wäre es ebenfalls direkt Pakete zu erstellen, dann könnte man sie sauberer ersetzten, löschen usw.. Ist mir gerade für diese Nummer zu aufwendig.

Viel Spaß!

Da bekomme ich gerade so ein neues Samsung Ultrabook in die Hand und schaue mir beim Auspacken den Karton an….. Da steht da etwas von Komputer Laptop? Also Komputer mit K?!?
Muss das so? Kenne ich da gerade etwas nicht?

Spannende Sache… Kennt da jemand eine Geschichte zu?

Möchte man unter seinem Java AES mit 256 Bit nutzen, muss man die JCE Unlimited Strength Jurisdiction Policy Files von Hand installieren.

Ja, man fühlt sich schnell einige Jahre zurück versetzt, als man noch aus den USA keine große Krypto exportieren durfte/darf. Daher war es ja lange nicht möglich große Krypto in Browsern einzusetzen. Das Java Thema ist sehr ähnlich!

Die Installation ist recht einfach.

Zuerst einmal die neuen Policy Files herunterladen (für Java 7):

http://www.oracle.com/technetwork/java/javase/downloads/jce-7-download-432124.html  

Im heruntergeladenen ZIP-File finden sich zwei jar Dateien. Diese müssen nun gegen die….  na, sagen wir mal beschränkten, ausgewechselt werden. Auf einem Debian finden sich diese hier:

/usr/lib/jvm/java-7-oracle/jre/lib/security
/usr/lib/jvm/jdk1.7.0_51/jre/lib/security

Nachdem beiden Dateien getauscht wurden, sind sie auch schon aktiv für jeden neuen Java Prozess. Ich will damit sagen, wenn es für den Openfire genutzt werden soll, diesen bitte einmal durchstarten.

Clientreport:

https://xmpp.net/result.php?id=42150

Serverreport:

https://xmpp.net/result.php?id=42151

Noch Fragen? Na dann fragen 🙂

Etwas hilflos stand ich heute vor der Meldung von Openfire, welche mit mitteilte, dass mein Zertifikat von StartSSL nicht importiert werden konnte.

Über folgenden Weg habe ich es denn noch in meinen Openfire gießen können.

1. OpenFire beenden.

2. Das Root-Zertifikat von StartSSL sowie das Class1 Zertifikat für Server ist bereits im Java Truststore von Openfire enthalten. Da ich ein Class2 Zertifikat erstellt habe, muss ich das Intermedia Zertifikat noch aufnehmen. Sonst lässt sich ja kaum eine Kette bilden.

In meiner Installation liegt mein Openfire unter /etc/. Dort findet sich auch der Trust- sowie der Keystore. Die nächsten Schritte finden also am besten direkt dort statt. Damit ich am Ende direkt mein Zertifikat und das Intermediate Zertifikat in einem Rutsch importieren kann. Werfe ich direkt beide zusammen. Domain.tld.cert ist dabei der öffentliche Teil meines Zertifikates.

$ cd /etc/openfire/security
$ wget http://www.startssl.com/certs/sub.class2.server.ca.crt
$ cat sub.class2.server.ca.crt domain.tld.cert > domain.tld.cert.tmp

3. Das eigentliche Zertifikat muss ins pkcs12 Format konvertiert werden, domain.tld.key ist dabei der private Teil meines Zertifikates. Bei dieser Aktion muss ein Kennwort erstellt werden. Das Standardkennwort des Keystores ist: „changeit“. Ich nutze dieses hier ebenfalls.

$ openssl pkcs12 -export -in domain.tld.cert.tmp -inkey domain.tld.key -out domain.tld.pkcs12 -name domain.tld

4. Als letzten Schritt kann ich nun das Zertifikat in den Keystore meines Openfires aufnehmen:

$ keytool -importkeystore -deststorepass changeit -destkeypass changeit -destkeystore /etc/openfire/security/keystore -srckeystore domain.tld.pkcs12 -srcstoretype PKCS12 -srcstorepass changeit -alias domain.tld

5. Openfire wieder starten.

Nun lässt sich bereits im Webinterface das neue Zertifikat sehen und ist nutzbar.

Noch Fragen?

Da fummle ich gerade mit dem Jabber / XMPP Server Openfire herum und stoße auf einen etwas nervigen Bug. Das Teil hat nämlich ein kleines Problem, wenn man als Nameserver in seinem System den localhost als IPv6 Adresse eingetragen hat.

Zur besseren Identifikation, im ErrorLog (/var/log/openfire/error.log)von Openfire finden sich dann Meldungen wie diese:

2014.06.15 22:48:35 org.jivesoftware.openfire.session.LocalOutgoingServerSession - Error authenticating domain with remote server: jabber.ccc.de
java.lang.NumberFormatException: For input string: ":1"
        at java.lang.NumberFormatException.forInputString(NumberFormatException.java:65)
        at java.lang.Integer.parseInt(Integer.java:492)
        at java.lang.Integer.parseInt(Integer.java:527)
        at com.sun.jndi.dns.DnsClient.<init>(DnsClient.java:125)
        at com.sun.jndi.dns.Resolver.<init>(Resolver.java:61)
        at com.sun.jndi.dns.DnsContext.getResolver(DnsContext.java:570)
        at com.sun.jndi.dns.DnsContext.c_getAttributes(DnsContext.java:430)
        at com.sun.jndi.toolkit.ctx.ComponentDirContext.p_getAttributes(ComponentDirContext.java:231)
        at com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.getAttributes(PartialCompositeDirContext.java:139)
        at com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.getAttributes(PartialCompositeDirContext.java:127)
        at javax.naming.directory.InitialDirContext.getAttributes(InitialDirContext.java:142)
        at org.jivesoftware.openfire.net.DNSUtil.srvLookup(DNSUtil.java:192)
        at org.jivesoftware.openfire.net.DNSUtil.resolveXMPPDomain(DNSUtil.java:124)
        at org.jivesoftware.openfire.session.LocalOutgoingServerSession.createOutgoingSession(LocalOutgoingServerSession.java:270)
        at org.jivesoftware.openfire.session.LocalOutgoingServerSession.authenticateDomain(LocalOutgoingServerSession.java:167)
        at org.jivesoftware.openfire.server.OutgoingSessionPromise$PacketsProcessor.sendPacket(OutgoingSessionPromise.java:261)
        at org.jivesoftware.openfire.server.OutgoingSessionPromise$PacketsProcessor.run(OutgoingSessionPromise.java:238)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
        at java.lang.Thread.run(Thread.java:745)

Zum lösen muss also nur in die /etc/resolf.conf der Nameserver von ::1 auf 127.0.0.1 umgestellt werden.

Immer diese Kackbugs hinsichtlich IPv6. Hoffentlich arbeiten so langsam mal mehr mit IPv6, damit die Fehler schneller gefunden und gefixt werden. Ich hasse es an so etwas hängen zu bleiben, da ich es so unnötig finde!

Fertig…

Habe ich ganz aktuell gesehen dass sich über die Webseite ssl-tools.net nun ebenfalls die DANE RECORDS testen lassen. Also einmal ob sie vorhanden sind und natürlich auch die Gültigkeit des RECORDS. Zu dem Thema bin ich ja bereits ein paar mal gefragt worden, da „einfache“ Test Tools noch rar waren. Was sich ja inzwischen endlich zu ändern scheint 🙂

KLICK: https://de.ssl-tools.net/mailservers/kernel-error.de

WOOOOHOOOOO… Ich habe auch mal so eine E-Mail bekommen 🙂

CERT-Bund Reports <noreply@reports.certbund.net> schrieb am 27.05.2014 11:31:10:

Von: CERT-Bund Reports <noreply@reports.certbund.net>
An: registry@domain.tld
Datum: 27.05.2014 11:31
Betreff: [CERT-Bund#2014052612345678] Gestohlene FTP-Zugangsdaten

Sehr geehrte Damen und Herren,

CERT-Bund hat von einer vertrauenswürdigen externen Quelle eine Liste
gestohlener FTP-Zugangsdaten für in Deutschland gehostete Server erhalten.
Die Zugangsdaten wurden im Rahmen der Analyse eines Botnetzes gefunden
und werden offenbar dazu verwendet, um in mit dem FTP-Account
verbundene Webseiten schädlichen Code einzuschleusen, welcher auf
Drive-by-Exploits verweist. Es liegen leider keine Informationen vor,
wann und wie die Zugangsdaten ausgespäht wurden.

Nachfolgend senden wir Ihnen eine Liste der Zugangsdaten für Server in
Ihrem Netzbereich. Die Passwörter wurden sanitarisiert.

Format: ASN | IP-Adresse | FTP-Login

Wir möchten Sie bitten, den Sachverhalt zu prüfen und Ihre Kunden
entsprechend zu informieren.

Bitte bestätigen Sie den Eingang dieser Benachrichtigung und
informieren Sie uns über die von Ihnen getroffenen Maßnahmen.

Liste der Zugangsdaten für Server in Ihrem Netzbereich:

 12345 | 123.123.123.123  | benutzername:IG******@ftp21.domain.tld

Mit freundlichen Grüßen
Team CERT-Bund

Bundesamt für Sicherheit in der Informationstechnik (BSI) Referat C21 –
CERT-Bund Godesberger Allee 185-189
D-53175 Bonn

————————————————————————
Dies ist eine automatisch generierte Nachricht.
Bitte beachten Sie beim Antworten die Reply-To Adresse.

Achtung, böser YouTube-Link!

Ich habe vor einiger Zeit ein „Will haben Gerät!“ gesehen… Bzw. den Prototyp eines solchen Gerätes. Zu dem Zeitpunkt wurde noch Geld für das Projekt gesammelt. Inzwischen ist die nötige Summe mehr als vorhanden und es geht seinen Weg… 

Das Teil nennt sich Pockethernet, ein Video gibt es unten und einen Link zum Projekt gibt es hier: http://pockethernet.com/

Klar wird es kaum mit einem guten Fluke Gerät mithalten können… Für viele kleine Tests scheint es aber mehr als ausreichend zu sein. Schaut einfach mal ins Video! Wer will es noch?