Jun 04

I. Installation:

Um auf Deinem Smartphone oder Tablet mit dem Android Betriebssystem die Avira Antivirus Pro zu installieren gibt es drei Möglichkeiten:

  • Avira Antivirus im Google Play Store suchen
  • Diesen Direkt-Link zur App im Google Play Store nutzen
  • Alternativ direkt über die Herstellerwebseite herrunterladen

II. Aktivierung:

  1. Öffne zur Aktivierung die APP Avira Antivirus und Du solltest folgendes Bild sehen:
Avira Android Willkommensbildschirm

2. Klicke auf Akzeptieren und Dir wird zunächst ein SmartScan Deines Android Gerätes vorgeschlagen:

Vorschlag Smart Scan durchzuführen

3. Klicke auf Smart Scan und anschließend wirst du gefragt ob Antivirus Security auf Fotos, Medien und Dateien auf deinem Gerät zugreifen darf. Bitte auf Zulassen drücken, damit die App auf Deine Dateien zugreifen darf, da ja ansonsten ein Virenscan nicht möglich ist:

Berechtigungsanfrage für Zugriff auf Ihre Fotos, Medien und Dateien

4. Jetzt einen Moment warten während Dein System überprüft wird und Du folgenden Bildschirm siehst:

Smart Scan Fortschrittsanzeige

5. Nach dem Smart Scan abgeschlossen wurde, wird Dir das Ergebnis angezeigt, bitte hier dann oben links auf den Pfeil <- links von Antivirus Security klicken.

Smart Scan Ergebniss Anzeige

6. Jetzt befindest Du Dich auf dem Startbildschirm von Avira. Am Namen oben ist erkennbar, das aktuell nur die Avira Free Security aktiv ist und auf der rechten Seite links vom Avira Logo ein gelb hinterlegtes Pro angezeigt wird. Um jetzt aus der Free Version die Pro Version zu machen, musst Du links oben auf das Profil Symbol vor dem Avira Free Security klicken:

Avira Free Security Startbildschirm

7. Auf der jetzt angezeigten Profil-Seite hast Du die Möglichkeit Deinen erworbenen Aktivierungscode einzugeben, durch klicken auf Aktivierungscode eingeben:

Avira Profil Anzeige

8. Nun gebe Deine eMail-Adresse und Deinen erworbenen Aktivierungscode ein und klicke anschließend auf den Button Entsperren

Eingabe des Aktivierungscode

9. Wenn alles passt, erhälst Du die Meldung „Ihre Lizenz ist jetzt aktiv“ und Du kannst mit „Erste Schritte“ klicken fortfahren

Ihre Lizenz ist jetzt aktiv

10. Wenn Du jetzt zurück auf dem Startbildschirm bist, steht oben Links neben dem Profil-Bild jetzt Avira Security Pro und die Aktivierung ist abgeschlossen. Leider lässt sich in der App nicht anzeigen, wie die Restlaufzeit deiner Avira Lizenz ist, dies geht nur über das Kundenkonto auf der Avira Webseite im Kundenkonto

Avira Security Pro Startbildschirm

Wichtiger Hinweis:

Wenn Du deine Lizenz im Avira Kundenkonto verwaltest, dann sei vorsichtig mit der Akvivierung des Abos, denn das bedeutet Du aktivierst die automatische Lizenzverlängerung direkt beim Hersteller Avira zum vollen Endkundenpreis und somit deutlich teurer als beim Avira-Händler deines Vertrauens oder Online auf www.asc-shop,de

Avira Abofalle Beispiel 1
Avira Abofalle Beispiel 2
Tagged with:
Apr 13

Heute hatten wir ein kurioses Problem mit einem Apache 2.2.22 Server.
Es ging um eine Domain, welche zwei Sub-Domains hat, wovon eine korrekt funktionierte und die andere nicht, sprich diese immer wieder zur Hauptdomain umleitete.

Der Aufbau der Verzeichnisstrucktur ist wie folgt:

/srv/www/webseite <- Hauptdomain www.muster.de
/srv/www/webseite/TEST <- Sub-Domain Nr. 1 test.muster.de
/srv/www/webseite/DEMO <- Sub-Domain Nr. 2 demo.muster.de

Der Nameserver ist korrekt konfiguriert:

muster.de. IN SOA ns1.nameserver.de. dns.ns.de. (
20170413
1800
3600
3600000
1800 )
muster.de. IN NS ns1.ns.de.
muster.de. IN NS ns2.ns.de.

muster.de. IN A 80.80.80.80
www IN A 80.80.80.80
demo IN A 80.80.80.80
test IN A 80.80.80.80
ftp IN CNAME ftp.ns.de.

mail IN CNAME mail.ns.de.
muster.de. IN MX 10 mx1.ns.de.
muster.de. IN MX 20 mx2.ns.de.

Und auch der Apache war korrekt konfiguriert:

<VirtualHost 80.80.80.80:80>

ServerName www.muster.de
ServerAlias muster.de
ServerAdmin webmaster@ns.de

DocumentRoot /srv/www/webseite
ScriptAlias /cgi-bin/ „/srv/www/cgi/“

CustomLog /var/logs/www/www.muster.de_combined_access.log combinedio
ErrorLog /var/logs/www/www.muster.de_error.log

</VirtualHost>

<VirtualHost 80.80.80.80:80>

ServerName demo.muster.de
ServerAdmin webmaster@ns.de

DocumentRoot /srv/www/webseite/DEMO
ScriptAlias /cgi-bin/ „/srv/www/cgi/“

CustomLog /var/logs/www/www.muster.de_combined_access.log combinedio
ErrorLog /var/logs/www/www.muster.de_error.log

</VirtualHost>

<VirtualHost 80.80.80.80:80>

ServerName test.muster.de
ServerAdmin webmaster@ns.de

DocumentRoot /srv/www/webseite/TEST
ScriptAlias /cgi-bin/ „/srv/www/cgi/“

CustomLog /var/logs/www/www.muster.de_combined_access.log combinedio
ErrorLog /var/logs/www/www.muster.de_error.log

</VirtualHost>

Zum Test lag in den beiden Unterverzeichnissen DEMO und TEST jeweils eine Datei test.html!

Der Aufruf test.muster.de/test.html erfolgte korrekt, sprich in der Webbrowser-Adress-Zeile stand dann auch noch test.muster.de/test.html und im Apache Log:
200.200.200.200 - - [13/Apr/2017:14:20:23 +0200] "GET /test.html HTTP/1.1" 200 24 "-" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Ubuntu Chromium/53.0.2785.143 Chrome/53.0.2785.143 Safari/537.36" 439 491

Im Gegensatz zum Aufruf demo.muster.de/test.html, denn hier erfolgte eine 301-Weiterleitung nach www.muster.de/DEMO/test.html, was dann auch in der Webbrowser-Adress-Zeile angezeigt wurde und im Apache Log folgendes stand:
200.200.200.200 - - [13/Apr/2017:15:09:07 +0200] "GET /test.html HTTP/1.1" 301 203 "-" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Ubuntu Chromium/53.0.2785.143 Chrome/53.0.2785.143 Safari/537.36" 421 658
200.200.200.200 - - [13/Apr/2017:15:09:07 +0200] "GET /DEMO/test.html HTTP/1.1" 200 24 "-" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Ubuntu Chromium/53.0.2785.143 Chrome/53.0.2785.143 Safari/537.36" 443 491

Leider konnte mir Google & Co. hier nichts wirklich weiterhelfen, so das ich begann, die beiden Verzeichnisse vom Inhalt her zu vergleichen.

Die Lösung lag in der fehlenden .htaccess Datei im Verzeichniss /srv/www/webseite/DEMO

Vom TEST-Verzeichniss die Datei .htaccess ins DEMO-Verzeichniss kopiert und es lief sofort. Warum ist mir zwar nicht ganz klar und für einen entsprechenden Kommentar wäre ich auch dankbar aber ich hoffe zumindest anderen mit dem gleichen Problem weiterhelfen zu können.

Tagged with:
Sep 09

Vorgabe:
Eine zusätzliche SSD mit kompletter Verschlüsselung als Laufwerk einbinden, wobei bei Booten keine zusätzliche Passwortabfrage erfolgen soll!

Lösung:

Die SDD ist in meinem Fall /dev/sdd und muß entsprechend eurer Konfiguration angepasst werden.

1. Primäre Partition mit voller Größe erstellen am einfachsten mittels
sudo cfdisk /dev/sdd
-> Erstellen -> volle Größe -> Schreiben -> Ende

2. Nach folgender Anleitung einrichten:

2.1. Anfang der zu verschlüsselnden Partition mit Zufallsbytes überschreiben:
sudo dd if=/dev/urandom bs=1M count=8 of=/dev/sdd1

2.2. Jetzt die Partition verschlüsseln:
sudo cryptsetup luksFormat -c aes-xts-plain64 -s 512 -h sha512 /dev/sdd1

2.3. Zuweisung der verschlüsselten Partition /dev/sdd1 dem virtuellem Gerät sdd1_crypt welches dann unter /dev/mapper/sdd1_crypt erreichbar ist:
sudo cryptsetup luksOpen /dev/sdd1 sdd1_crypt

2.4. Die Partition unter dem virtuellen Gerät /dev/mapper/sdd1_crypt kann jetzt mit dem gewünschtem Dateisystem beschrieben werden (in meinem Fall ext4):
sudo mkfs.ext4 /dev/mapper/sdd1_crypt

2.5. Nun kann die Partition gemountet werden:
sudo mount /dev/mapper/sdd1_crypt /data2

3. Da die Festplatte beim Systemstart automatisch und ohne Eingabe des Passwortes ins System eingebunden (gemountet) werden soll, ist dies recht elegant mit einem Keyfile möglich, wobei diese Lösung hier nur Sinn macht, wenn das System komplett ebenfalls verschlüsselt ist und somit das Keyfile im /root des verschlüsselten Systems liegt!
Als Vorlage habe ich hier folgenden Beitrag genommen.

3.1. Ein zufälliges Keyfile erzeugen
sudo dd if=/dev/urandom of=/root/keyfile_0x000c58a6 bs=1024 count=4

3.2. Nur root darf Zugriff auf dieses Keyfile haben!
sudo chmod 0400 /root/keyfile_0x000c58a6

3.3. Das Keyfile für die verschlüsselte Partition /dev/sdd1 hinzufügen
sudo cryptsetup luksAddKey /dev/sdd1 /root/keyfile_0x000c58a6

3.4. In der crypttab einen Eintrag hinzufügen um das Keyfile dem virtuellen Gerät /dev/mapper/sdd1_crypt zuzuordnen
sudo nano /etc/crypttab

sdd1_crypt UUID=53baf3bf-dd24-64fa-bbcf-b144870c09d3 /root/keyfile_0x000c58a6 luks,discard

3.5. In der fstab die Partition zum mounten eintragen
sudo nano /etc/fstab

/dev/mapper/sdd1_crypt /data2 ext4 defaults 0 2

4. Rechner neu starten und die neue SSD steht unter /data2 komplett verschlüsselt zur Verfügung! 🙂

Tagged with:
preload preload preload