Archiv

Archiv für die Kategorie ‘Security’

Vorsicht bei iPhone Unlock!

Diese Info heute grad via Newsletter eingetroffen. Nicht wirklich neues, aber schön formuliert und vielleicht für den ein oder anderen noch neu:

das iPhone wird von der Telekom (und neuerdings auch von Vodafone) zusammen mit einem Vertrag und einem Netlock verkauft, kann also nur im Mobilfunknetz des Anbieters benutzt werden. Dabei hängt der Preis des iPhones vom gewählten Tarif ab, die Kalkulation des Anbieters basiert auf dem geschätzten Umsatz, den der Anwender mit seinem iPhone im Netz des Anbieters generieren wird.

Diese Bindung ist allerdings häufig lästig. Wer etwa im Ausland mit seinem iPhone online gehen will, der muss entweder die horrenden Roaminggebühren zahlen – oder er knackt sein iPhone, um es mit einem günstigen Call-by-Call-Anbieter vor Ort zu benutzen.

Ein Unlock – also die Aufhebung der Bindung an ein bestimmtes Netzwerk – ist technisch nicht sonderlich kompliziert und in der Regel Sache weniger Mausklicks.  Doch so einfach ein Unlock auch ist, so problematisch kann er werden. Wer den Netlock des Anbieters  entfernt, der bricht den Vertrag, den er mit dem Kauf es iPhones abgeschlossen hat – und macht sich damit strafbar.

Nun gilt zwar der bekannte Spruch, dass wo kein Kläger auch kein Richter sei, doch das Risiko einer Anzeige besteht. Wer zwingend ein ungelocktes iPhone benötigt, der sollte sich lieber ein Gerät zulegen, das von Haus aus ohne Sperre ist.

Ihre iPhone daily Redaktion

Also Vorsicht :) Wer ein wirklich freies iPhone haben möchte, der sollte sich informieren, ob o2 das iPhone noch immer ohne Lock ausliefert, oder direkt im apple Store kaufen!

Zeitsynchronisation mit NTP Daemon für Debian und Ubuntu

Viele Webserver (oder Rootserver) sind auf eine genau laufende Uhrzeit angewiesen, um aussagefähige Logfiles (Beispielsweise Zugriffsstatistika der Webseiten oder Systemlogfiles für die Fehleranalyse) schreiben zu können. Leider laufen die Systemuhren (Hardwareclock) nicht sehr genau und haben bereits nach einigen Wochen relativ grosse Abweichungen zu verzeichnen. Vergisst man gelegentlich die Uhr zu stellen, kann man sich da schon einige Unschönheiten einfangen.

Die Rettung lautet NTP, das Network Time Protocol. Es dient, wie der Name schon sagt zur Zeitübertragung zwischen verschiedenen Rechnern über das Netzwerk. Das allein hilf natürlich noch nicht weiter… Aber es gibt relativ viele NTP Server im Internet, welche kostenlos mehr oder weniger aktuelle Uhrzeiten liefern, daruter auch Server, welche Ihre Uhrzeit direkt von Atomuhren beziehen! Über das NTP Protokoll kann man sich diese Server zu nutze machen, um automatisiert die uhrzeit auf dem einenem Rechner oder Server immer aktuell zu halten.

Unter Linux dient hierzu meist der NTP Client, welcher sich unter Debian Lenny sehr leicht mit der nachfolgenden Kommandozeile installieren lässt:

1
aptitude install ntp ntpdate

Konfiguriert wird der NTP Client über nur eine kleine Datei, die /etc/ntp.conf! Hier wird festgelegt, welche Zeitserver befragt werden können (nicht alle werden tatsächlich zeitserver für das System sein), ob und wie zeitdienste weitergegeben werden und wer den NTP Dienst noch konfigurieren darf.

/etc/ntp.conf

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
/etc/ntp.conf
# Pfad zum Driftfile
driftfile /var/lib/ntp/ntp.drift
 
statistics loopstats peerstats clockstats
filegen loopstats file loopstats type day enable
filegen peerstats file peerstats type day enable
filegen clockstats file clockstats type day enable
 
# Stratum 1 Server
server ntp1.ptb.de
server ntp2.ptb.de
 
# NTP Server aus dem Debian Pool (Defaultserver bei Lenny)
server 0.debian.pool.ntp.org iburst dynamic
server 1.debian.pool.ntp.org iburst dynamic
server 2.debian.pool.ntp.org iburst dynamic
server 3.debian.pool.ntp.org iburst dynamic
 
# By default, exchange time with everybody, but don't allow configuration.
restrict -4 default kod notrap nomodify nopeer noquery
restrict -6 default kod notrap nomodify nopeer noquery
 
# Local users may interrogate the ntp server more closely.
restrict 127.0.0.1
restrict ::1

Nachdem die Konfiguration in etwa wie im obigem Beispiel aussieht (Kommentarzeilen etc. habe ich der Übersichtlichkeit halber größtenteils entfernt), sollte man einmal von Hand die zeit auf dem System setzen. Das geht recht einfach mit dem oben schon mit installiertem ntpdate.

1
ntpdate ntp1.ptb.de

Nun ist die zeit auf dem System aktuell, sofern der Zeitserver auch erreichbar war! Ein funktionierendes Netzwerk mitsamt der dazugehörigen Namensauflösung (DNS Dienste) setze ich hier einfach mal vorraus! Wir können den NTP Client nun starten, bzw. neustarten

1
/etc/init.d/ntp start

oder

1
/etc/init.d/ntp restart

Überprüfung der Zeitsync:
Direkt nach dem Start:

ntpq -c peers
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 ptbtime1.ptb.de .PTB.            1 u    5   64    1   21.020   11.660   0.001
 ptbtime2.ptb.de .PTB.            1 u    4   64    1   20.856   11.789   0.001
 dnscache-frankf 192.53.103.104   2 u    1   64    1    6.087   12.967   0.891
 bind.ch         130.60.75.52     3 u    -   64    1    7.191   16.387   0.001
 phoenix.wzw.tum 192.53.103.108   2 u    1   64    1   22.817   18.651   0.001
 obelix.chown.dk 131.188.3.221    2 u    -   64    1    0.954   13.563   0.001

Nach einer Minute:

ntpq -c peers
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
*ptbtime1.ptb.de .PTB.            1 u   33   64   37   20.637   15.675   8.187
+ptbtime2.ptb.de .PTB.            1 u   32   64   37   20.806   24.409   8.137
+dnscache-frankf 192.53.103.104   2 u   28   64   37    4.869   16.740   6.471
-bind.ch         130.60.75.52     3 u   28   64   37    7.158   29.072   9.780
 phoenix.wzw.tum 192.53.103.108   2 u   23   64   37   21.779   19.059   8.523
+obelix.chown.dk 131.188.3.221    2 u   25   64   37    0.633   14.937   8.032

Erklärung relevanter Zeichen und Spalten:

* Der beste aller eingetragenen Server. Dieser Server wird als Referenz genommen.
+ akzeptable Qualität (sortiert nach absteigender Qualität)
# akzeptabler Zeitgeber, jedoch schlechter als mit “+”
- Schlechter Zeitgeber, meistens ausgenommen von der Zeitermittlung.
. Schlechter Zeitgeber, meistens ausgenommen von der Zeitermittlung.
x Server mit scheinbar falscher Zeit. Ausgenommen von der Zeitermittlung.

In der Spalte “st” steht der Stratum Wert, sprich wie viele Schritte der Server von der primären Zeitquelle (z.B. der Atomuhr) entfernt ist.

In der Spalte “when” steht wann der Zeitderver das letzte mal befragt wurde, analog dazu steht in der Spalte “poll” in welchem Zeitabstand der Server befragt wird.

Die Spalten “delay” “offset” und “jitter” stehen für die Netzlaufzeit, Abweichung und Streuung der Antworten des jeweiligen Servers in Millisekunden. Je weniger, desto besser natürlich.

Nach der Inbetriebnahme des NTP Dienstes, sollte man einige Stunden vergehen lassen, bevor man die Ergebnisse gegenprüft, da über das Driftfile ersteinmal eine gewisse Anzahl von Werten gesammelt werden müssen, bevor der NTP Dienst wirklich genau arbeiten kann.

Abschließend muss der NTP Dienst nur noch beim Systemstart gestartet werden. Dies erreicht man unter Debian wie folgt:

chkconfig --level 345 ntp on

Mit dieser Befehlszeile wird der NTP Dienst in den Runleveln 3,4 und 5 gestartet, was für 98% aller Systeme ausreichen sollte ;)!

P.S. Die Daten der ntp.conf gelten so für fast alle *nix Systeme, also auch HP UX, SUN Solaris sowie Linuxsysteme von SuSE und RedHat!

Weblinks zu Zeitserver Pools und Listen:

Cisco VPN mit Windows 7 64 Bit und Linux

28. Dezember 2009 1 Kommentar

[aartikel]B0028RBW1Y:left[/aartikel]Der Shrew VPN Client ist genau die Lösung die ich gestern gesucht habe. Mit einem leichtem Schock habe ich bemerkt, das ich mit meinem “altem” Cisco VPN Client und meinem Windows 7 64Bit keine VPN Verbindung aufbauen kann, Cisco unterstützt bei diesem VPN Client auch kein Windows 7 64Bit, nur die x32 Version.

Nach kurzer Suche im Web, ob es nicht evtl. doch eine andere Lösung gibt als ins Büro zu fahren, stieß ich auf den VPN Client von Shrew. Der VPN Client ist kostenlos, kann die Cisco VPN PCF Dateien importieren und funktioniert tadellos auf Windows 7 64Bit, Windows 7 32Bit, Windows XP sowie auf Ubuntu 8.04 LTS (soweit ich es getestet habe).

Shrew Soft VPN Client unter Windows 7

Shrew Soft VPN Client unter Windows 7

Unter Windows 7 64Bit habe ich über 8 Stunden eine durchgängige VPN Sitzung durchgeführt, ohne irgendein Problem. Eine echte Empfehlung!

Weblinks:

ohshit – iPhone Wurm ändert Root Kennwort

iWormDer “iPhone Wurm” ist in einer neuen Variante unterwegs!
Diese Variante verändert das Root Kennwort eures iPhones, sofern euer Gerät einem Jailbreak unterzogen wurde! Vor ein paar Tagen hatte ich noch gebloggt (hier) wie man die SSH Kennwörter ändert und wie das Kennwort in den default Einstellungen lautet.  Nun könnte es sich für jeden iPhone Nutzer mit jailbreak als extrem vorteilhaft gestalten diese Kennwörter durch eigene ausgetauscht zu haben.

Zuerst ging es nur darum das eigene iPhone zu sichern, nun muß man diese Sicherung tatsächlich vornehmen, bevor einem eine Schadsoftware wie dieser Wurm das iPhone völlig verkonfiguriert und man sich so eventuell sogar selbst aussperrt. An alle die ihre Kennwörter noch nicht geändert haben:

Schützt euch, eure Daten und euer iPhone! Ändert die SSH Kennwörter, installiert sbSettings mit dem “SSH Schalter”, stellt SSH nur an wenn ihr es wirklich braucht und stellt via BossPrefs SSH bei Start des iPhone auf “aus”!

Wenn euer iPhone per SSH nicht mehr mit dem default Kennwort “alpine” erreichbar ist (am besten per SSH garnicht zu erreichen), kann euch der Wurm wenig anhaben. So weit ich informiert bin, ist euer iPhone dann sogar immun gegen den iPhone Wurm – ebenso als hätte euer iPhone keinen Jailbreak!

Quelle:
Winfuture

Zitat frei nach granworld :
“Ist doch klar das der Wurm in den Apfel will. Kein Wurm der Welt fühlt sich woanders wohler als in einem Apfel. Vor allem wenn der dazu noch lecker angebissen ist…”

iPhone: Gefahr für jailbroken iPhones & ein Gegenmittel

Apple iPhoneiPhone Gefahr SSH
Fast alle iPhones mit jailbreak, also entsperrte oder jailbroken iPhones, sind in Gefahr, wie uns die Pressemeldungen der letzten Wochen recht gut verdeutlicht haben.

Nicht nur das viele iPhone nette Meldungen auf dem Display hatten, sondern auch durch die bereits existierende Virengefahr (z.B. der Wurm “privacy.A”)  ist es ratsam das iPhone ebenfalls effizient zu schützen. Hierbei geht es weniger um eine Software die man installieren muss (nein, wir sind ja nicht in der Fensterwelt), sondern vielmehr um Sicherungsmaßnahmen, die viele einfach nur nicht machen weil sie zu bequem sind!

Mit dem Jailbreak kommt meist auch der openSSH Server mit auf das iPhone, jedoch wird das Kennwort vom administrativem Benutzer Root nicht geändert. Das per default eingestellte Kennwort “alpine” kennt nun auch fast Jeder (spätestens jetzt  ;) ) und so ist es kein Wunder wenn sich alle Welt auf das iPhone einloggen kann. Mit dem benutzer Root haben diese “Fremden” dann obendrein Zugriff auf ALLE Teile von iPhne, es ist nichts mehr geschützt, bzw. verborgen! Das Kennwort vom Benutzer Root muss also dringend geändert werden! Mehr…