Citrix Receiver: self-signed SSL vertrauen unter Linux

Veröffentlicht am 20. Februar 20143. Mai 2020

Will man unter Linux den Citrix Receiver mit einem selbst ausgestellten SSL Zertifikat verwenden scheitert man meistens mit einer dieser Fehlermeldungen:

Linux Client Error: The security certificate could not be validated. SSL provider code: 20, SSL error 86
Linux Client Error: The security certificate could not be validated.
The security certificate “<Zertifikats-Name>” could not be validated. SSL provider code: 20, SSL error 86

Das liegt daran, dass der Receiver das Root-CA nicht in seinem Speicher hat.

Um nun dieses Zertifikat hinzuzufügen, oder anders gesagt ihm zu vertrauen, muss es einfach mit einem Browser heruntergeladen werden und dann in den ca-store kopiert werden. Dazu geht man vor wie folgt:

die entsprechende SSL ctx Seite aufrufen, zBsp: https://ctx.meine-firma.at/
der Browser zeit nun dieses Zertifikat als nicht vertrauenswürdig in der Adresszeile an
Klicken Sie auf das Schloss-Symbol im Dialog dann auf „Mehr Informationen“
Es sollte sich je nach Browser nun der SSL Informations Dialog öffnen, wenn nicht gibt es einen Button wie „Zertifikat anzeigen“ oder ähnliches
Im SSL Zertifikatsdialog wählen sie den zweiten Reiter „Details“, dort werden alle aktiven Zertifikate für diese Verbindung angezeigt
Wählen Sie das oberste Zertifikat aus, das sollte die CA sein, das brauchen wir. Das zweite ist das Zertifikat selbst, das ist nicht wichtig.
Klicken Sie nun bei der CA auf „Exportieren“
Speichern sie es lokal ab. Extention sollte sein .pem
Wenn Sie mehrere sehen und sich nicht sicher sind, können Sie auch einfach alle exporieren.
kopieren Sie als Root die Zertifikate in den ICA-Keystore.
Normalerweise ist der unter: /opt/Citrix/ICAClient/keystore/cacerts/ (Wobei /opt/Citrix/ICAClient/ die ICARoot ist)
Nun sollte der Citrix Receiver sich nicht mehr beklagen und die Session ganz normal starten.

OTRS wie kann ich einen Menüpunkt ausblenden

Veröffentlicht am 13. Februar 201417. Juni 2017

In einer Anfrage sollte konkret der Menüpunkt „Ansicht nach Eskalationen“ ausgeblendet/deaktiviert werden. Zusätzlich soll dabei auch das „!“ (Rufzeichen) in der Symbolleiste ausgeblendet werden, das zum gleichen Screen führt.

Lösung:

Admin / Sysconfig
Konfigurationseinstellungen bearbeiten in Ticket -> Frontend::Agent::ModuleRegistration
deaktivieren Sie „Frontend::Module###AgentTicketEscalationView“

Deaktivieren SIe hier den Menüpunkt für Eskalation.

In diesem Screenshot kann man auch gut erkennen, dass man den Menüpunkt verschiedenen Gruppen exclusiv zur Verfügung stellen kann, sofern er nur für bestimmte User ausgeblendet werden soll.

Ansicht nach der Umstellung: (Nun fehlt sowohl das Rufzeichen, als auch der Menüpunkt „Ansicht nach Eskalationen“)

Defacing von mehreren Kundenseiten, Feber 2014

Veröffentlicht am 11. Februar 20142. April 2022

In der Nacht von 10. auf 11. Februar wurden mehrere Kundenseiten auf einem unserer Server von einer Defacing-Attake des Hackers Iliya Norton heimgesucht.

Nahezu zeitgleich zeigten mehr als zehn Kundenseiten statt der gewohnten Startseite nur noch folgendes Bild:

Nach Warnungen von clean-mx.de und cert.at hat das graz4u-Team hat die betroffenen Seiten identifiziert und die Daten von der Sicherung restauriert. Die betroffenen Kunden wurden informiert.

Der Hacker gehört übrigens zur Kategorie „Friendly Hacker“ der mit seinem Defacement zwar für einige Aufregung gesorgt, jedoch im Grunde bewußt so wenig wie möglich zerstört hatte.
Diesmal konnte auch recht schnell geklärt werden über welche Schwachstellen der Hacker eindringen konnte. (Ein nicht auf den neuesten Stand gebrachtes Plugin des JCE-Editors in verschiedenen Joomla-Versionen)

Sucht man im Netz nach „Hacked by Iliya Norton“ findet man mittlerweile hunderte gehackte Seiten. Dabei beweißt der Hacker sehr viel Kreativität, denn das Bild das wir hier als Screenshot verewigt haben, variiert dabei sehr stark. Meist gibt es auch Musik (teilweise Technoklänge, teilweise Arabische Musik) – Iliya Norton, scheint jeder Seite seinen persönlichen Stempel auf zu drücken. Übrigens findet man auch recht schnell ein Google+ Konto mit diesem Namen, welches anscheinend wirklich von diesem Hacke betrieben wird…

Leider können wir nicht sicher sein, dass es bei allen Domains wirklich diese Schwachstelle war, über die der Hacker in das System eindringen konnte. Eine kurze Internetrecherche ergab jedoch wie schon bei unserem letzten Defacing-Fall im Jahr 2011, dass auch zahreiche andere Seiten mit verschiedensten CMS betroffen waren.
Wir raten einmal mehr allen Kunden auf die neuesten Versionen up zu daten – bzw, sich mit uns in Verbindung zu setzen, sofern Sie dabei Hilfe benötigen!