Previous Next Contents


5 PPP-Verbindung zu Windows NT mit PAP-Authentifizierung

Bei dieser Variante kann das der Linux Distribution beiliegende Standard 'pppd'-Paket verwendet werden; d.h. es brauchen keinerlei Veraenderungen am standardmaessig installieten Linux-System gemacht werden !

5.1 'pppd'-Anwahlscript

Fuer den Anwahlvorgang wird ein einfaches Script verwendet, das den 'pppd'-Prozess startet.


#!/bin/sh
# Aufbau einer PPP Verbindung zu einem Windows NT Server
/usr/sbin/pppd 38400 connect '/usr/sbin/chat -v -f $HOME/win_nt.chat' lock

Datei: dial_win_nt


Parameterbeschreibung Datei dial_win_nt :

38400                   : setzt die zu verwendende Portgeschwindigkeit
connect '...'           : Herstellung der Modemverbindung und Einloggen 
                          ueber das Programm 'chat', wobei die zum Verbindungs-
                          aufbau notwendigen Informationen aus der ueber den 
                          Parameter -f angegebenen Datei entnommen werden. 
                          Der 'chat'-Parameter -v bewirkt eine Protokollierung 
                          des Verbindungsaufbaus ueber 'syslogd' 
                          (Datei /var/log/messages)
lock                    : Verwendung einer "UUCP-konformen" Lockdatei 
                          (unter /var/lock/LCK..ttyS0)

Die Parameter fuer das 'chat'-Programm sind in einer eigenen Datei hinterlegt:


TIMEOUT  60
ABORT "NO CARRIER"
ABORT BUSY
ABORT "NO DIALTONE"
ABORT ERROR
"" +++ATZ 
OK ATE1Q0&C1&S0DT555222
CONNECT ""

Datei: win_nt.chat

Auffallend an dieser Datei ist das Fehlen des ueblichen "Login:/Password:"-Schemas, das von Windows NT nicht verwendet wird. Ein Warten auf die 'Login:'-Aufforderung nach der 'CONNECT'-Meldung ist sinnlos !!

Es wird stattdessen einfach auf eine 'CONNECT'-Meldung gewartet und die Steuerung an den 'pppd' uebergeben.

5.2 Konfiguration Datei /etc/ppp/pap-secrets

Um eine Verbindung mit Windows NT herzustellen muss das PAP-Authentifizierungsschema verwendet werden. Die dazu benoetigten Parameter und Kennungen erwartet der 'pppd' in der Datei /etc/ppp/pap-secrets:


# Secrets for authentication using PAP
# client        server     secret      IP addresses
my_login        win_nt     my_passw

Datei: /etc/ppp/pap-secrets

Typischerweise sollte diese Datei fuer eine PPP-Verbindung eine Zeile (ohne fuehrende Blanks) enthalten, obwohl fast immer erwaehnt wird, dass fuer eine PPP-Verbindung zwei Eintraege (mit gespiegelten 'server'/'client' Parametern) notwendig sind.

Wie es sich jedoch herausstellt, genuegt bei einer Windows NT-Verbindung ein Parametersatz (Authentifizierung von Linux an Windows NT Server), da eine Authentifizierung des Windows NT Rechners nicht stattfindet, bzw. eine Aufforderung dazu mit 'Authentication refused' durch Windows NT abgelehnt wird.

Als 'server' wird der Windows NT Rechner bezeichnet, bei dem angerufen wird; das 'secret' enthaelt das der unter 'client' eingetragenen Windows NT-Userkennung zugeordnete Passwort im Klartext. Unter 'client' ist bezeichnenderweise nicht der lokale Rechnername, sondern die Userkennung anzugeben.

Um die Kombination PAP/PPP in Verbindung mit Windows NT zu nutzen, ist dem 'pppd' ueber die Option 'remotename' der Systemname des betreffenden Windows NT Servers mitzuteilen, damit der entsprechende pap-secrets-Eintrag verwendet werden kann. Microsoft NT Systeme senden beim Aufbau der PPP/PAP-Verbindung ihren Systemnamen leider nicht; deshalb muss dieser per Option definiert werden.

Als lokaler Systemname ('pppd'-Option name) wird die Windows NT-Userkennung vereinbart.

5.3 Konfiguration Datei /etc/ppp/options

Der verwendete 'pppd'-Optionssatz besteht aus folgenden Parametern und liegt in der Datei /etc/ppp/options.


/dev/ttyS0
crtscts
152.3.60.1:152.3.60.2
defaultroute
debug
modem
name my_login
remotename win_nt

Datei: /etc/ppp/options


Parameterbeschreibung Datei /etc/ppp/options :

/dev/ttyS0              : Port an dem das Modem angeschlossen ist 
                          ( ttyS0 = COM1 )
crtscts                 : Verwendung der Hardwareflusskontrolle (RTS/CTS) 
                          um den Datenverkehr am seriellen Port zu 
                          kontrollieren
152.3.60.1:152.3.60.2   : Definition der zu verwendenden IP-Adressen in der 
                          Form <local_ip_addr>:<remote_ip_addr> 
defaultroute            : Verwendung des Remotehosts als Standardroute-
                          verbindung:
                          die PPP-Verbindung wird als Default in die
                          Routingtabelle des Kernels eingetragen
debug                   : aktiviert den Debugmodus; die anfallenden 
                          Informationen werden in die Datei /var/log/messages 
                          geschrieben
modem                   : gibt an, dass es sich um eine Modemverbindung
                          handelt
name <username>         : setzt laut man-Page den lokalen Systemnamen fuer
                          Authentifizierungszwecke; 
                          es wird aber die zu verwendende Windows NT-User- 
                          kennung angegeben !!!
remotename <systemname> : setzt den Systemnamen des angewaehlten Windows NT
                          Servers fuer Authentifizierungszwecke

Die bis hier erfolgten Definitionen sollten ausreichen, die erstmalige Verbindungsaufnahme mit dem Windows NT Server zu wagen.

5.4 Protokoll PPP/PAP-Verbindung

Die Transaktionen des 'chat'- als auch des 'pppd'-Programmes koennen durch

      tail -f /var/log/messages

beim Verbindungsaufbau am Bildschirm mitprotokolliert werden.

Ein -unkommentiertes- Protokoll einer erfolgreichen PPP-Verbindungsaufnahme via PAP-Authentifizierung sieht folgendermassen aus:


 kernel: PPP: version 2.2.0 (dynamic channel allocation)
 kernel: PPP Dynamic channel allocation code copyright 1995 Caldera, Inc.
 kernel: PPP line discipline registered.
 kernel: registered device ppp0
 pppd: pppd 2.2.0 started by root, uid 0
 chat: timeout set to 60 seconds
 chat: abort on (NO CARRIER) 
 chat: abort on (BUSY) 
 chat: abort on (NO DIALTONE) 
 chat: abort on (ERROR) 
 chat: send (+++ATZ^M) 
 chat: expect (OK) 
 chat: +++ATZ^M^M 
 chat: OK -- got it 
 chat: send (ATE1Q0&C1&S0S0=0DT555222^M) 
 chat: expect (CONNECT) 
 chat: ^M 
 chat: ATE1Q0&C1&S0S0=0DT555222^M^M 
 chat: CONNECT -- got it 
 chat: send (^M) 
 pppd: Serial connection established.
 pppd: Using interface ppp0
 pppd: Connect: ppp0 <--> /dev/ttyS0
 pppd: sent [LCP ConfReq id=0x1 <mru 1500> <magic 0x9df1a72> <pcomp> <accomp>]
 pppd: sent [LCP ConfReq id=0x1 <mru 1500> <magic 0x9df1a72> <pcomp> <accomp>]
 pppd: rcvd [LCP ConfReq id=0x0 <asyncmap 0x0> <auth chap msoft>              \
       <magic 0x3e6f> <pcomp> <accomp>] 
 pppd: sent [LCP ConfNak id=0x0 <auth chap md5>]
 pppd: rcvd [LCP ConfAck id=0x1 <mru 1500> <magic 0x9df1a72> <pcomp> <accomp>]
 pppd: rcvd [LCP ConfReq id=0x1 <asyncmap 0x0> <auth 0xc027 01 00 00 01>      \
       <magic 0x3e6f> <pcomp> <accomp>]
 pppd: sent [LCP ConfNak id=0x1 <auth chap md5>]
 pppd: rcvd [LCP ConfReq id=0x2 <asyncmap 0x0> <auth 0xc123 01 00 00 01>      \
       <magic 0x3e6f> <pcomp> <accomp>]
 pppd: sent [LCP ConfNak id=0x2 <auth chap md5>]
 pppd: rcvd [LCP ConfReq id=0x3 <asyncmap 0x0> <auth pap> <magic 0x3e6f>      \
       <pcomp> <accomp>]
 pppd: sent [LCP ConfAck id=0x3 <asyncmap 0x0> <auth pap> <magic 0x3e6f>      \
       <pcomp> <accomp>]
 pppd: sent [PAP AuthReq id=0x1 user="my_login" password="my_passw"]
 pppd: rcvd [PAP AuthAck id=0x1msg=""]
 pppd: Remote message: 
 pppd: sent [IPCP ConfReq id=0x1 <addr 152.3.60.1> <compress VJ 0f 01>]
 pppd: rcvd [CCP ConfReq id=0x4 < 12 06 00 00 00 01>]
 pppd: sent [CCP ConfReq id=0x1]
 pppd: sent [CCP ConfRej id=0x4 < 12 06 00 00 00 01>]
 pppd: rcvd [proto=0x803f] 01 06 00 17 03 05 00 05 01 02 0e 00 01 00 01      \
       00 00 52 32 30 30 32 00
 pppd: Unknown protocol (0x803f) received
 pppd: sent [LCP ProtRej id=0x2 80 3f 01 06 00 17 03 05 00 05 01 02 0e       \
       00 01 00 01 00 00 52 32 30 30 32 00]
 pppd: rcvd [IPCP ConfAck id=0x1 <addr 152.3.60.1> <compress VJ 0f 01>]
 pppd: rcvd [CCP ConfAck id=0x1 < fe 02>]
 pppd: rcvd [CCP TermReq id=0x7 00 00 02 dc]
 pppd: sent [CCP TermAck id=0x7]
 pppd: sent [IPCP ConfAck id=0xd <compress VJ 0f 01>]
 pppd: local  IP address 152.3.60.1
 pppd: remote IP address 152.3.60.2
 pppd: sent [CCP ConfReq id=0x1]
 pppd: rcvd [CCP TermAck id=0x1]
 pppd: sent [CCP TermReq id=0x2]
 pppd: rcvd [CCP TermAck id=0x2]
 ... 
 ...   Beginn der Verbindung
 ...   Warten auf Verbindungsende
 ...
 pppd: Terminating on signal 2.
 pppd: sent [LCP TermReq id=0x3]
 pppd: rcvd [LCP TermAck id=0x3]
 pppd: Connection terminated.
 pppd: Exit.
 kernel: PPP: ppp line discipline successfully unregistered

Auszug Protokoll /var/log/messages : Aufbau einer PAP/PPP-Verbindung

Interessant ist hierbei die Reaktion des Clients auf den Request der PAP-Authentisierung

 pppd: rcvd [ LCP ConfReq  ...  <auth pap> ... ]

Dieser Request wird prompt beantwortet mit

 pppd: sent [LCP ConfAck ... <auth pap> ... ] 
 pppd: sent [PAP AuthReq  user="my_login" password="my_passw"]

Dies fuehrt schliesslich zum erfolgreichen Verbindungsaufbau.

Wie aus dem Protokoll ersichtlich ist, wird beim PAP-Authentifizierungsschema neben der Userkennung auch das Passwort im Klartext uebertragen, was unter Umstaenden als Sicherheitsrisiko angesehen werden kann. Um den Sicherheitsstandard zu heben, wird zusaeztlich zumindest eine Verschluesselung des Passwortes gefordert.

6 PPP-Verbindung zu Windows NT mit CHAP-Authentifizierung

Hierzu wird das CHAP-Authentisierungsverfahren verwendet: Ein Hauptunterschied zu PAP liegt unter anderem in der kodierten Uebertragung des Passwortes.

'pppd' handelt dies ueber das /etc/ppp/chap-secrets-File, das im Prinzip den gleichen Aufbau der pap-secrets-Datei hat (pap-secrets kann nach chap-secrets kopiert werden).

Die Anwahl des Windows NT Servers erfolgt nach dem vorausgegangenen Schema.

Es wird die oben erwaehnte gepatchte 'pppd'-Version eingesetzt.

6.1 Protokoll PPP/CHAP-Verbindung

Ein -unkommentiertes- Protokoll einer erfolgreichen PPP-Verbindungsaufnahme via CHAP-Authentifizierung sieht folgendermassen aus (der 'chat'-Verbindungsaufbau und der 'pppd'-Verbindungsabbau sind nicht mehr aufgefuehrt):


 pppd: Using interface ppp0
 pppd: Connect: ppp0 <--> /dev/ttyS0
 pppd: sent [LCP ConfReq id=0x1 <mru 1500> <magic 0xb77347c8> <pcomp> <accomp>]
 pppd: sent [LCP ConfReq id=0x1 <mru 1500> <magic 0xb77347c8> <pcomp> <accomp>]
 pppd: rcvd [LCP ConfReq id=0x0 <asyncmap 0x0> <auth chap msoft>               \
       <magic 0x4d9b> <pcomp> <accomp>]
 pppd: sent [LCP ConfAck id=0x0 <asyncmap 0x0> <auth chap msoft>               \
       <magic 0x4d9b> <pcomp> <accomp>]
 pppd: rcvd [LCP ConfAck id=0x1 <mru 1500> <magic 0xb77347c8> <pcomp> <accomp>]
 pppd: cbcp_lowerup
 pppd: want: 2
 pppd: phone no: (null)
 pppd: rcvd [CHAP Challenge id=0x2e <f7d486a3df030b71>, name = ""]
 pppd: sent [CHAP Response id=0x2e <0000000000000000000000000000000000000      \
       00000000000ee0cecf8c969e78c01e80aa8f28dcd0aa5a835287d0fa32d01>,         \
       name = "my_login"]
 pppd: rcvd [CHAP Success id=0x2e ""]
 pppd: sent [IPCP ConfReq id=0x1 <addr 152.3.60.1> <compress VJ 0f 01>]
 pppd: rcvd [CCP ConfReq id=0x1 < 12 06 00 00 00 01>]
 pppd: sent [CCP ConfReq id=0x1]
 pppd: rcvd [proto=0x803f] 01 03 00 17 03 05 00 05 01 02 0e 00 01 00 01        \
       00 00 52 32 30 30 32 00
 pppd: Unknown protocol (0x803f) received
 pppd: sent [LCP ProtRej id=0x2 80 3f 01 03 00 17 03 05 00 05 01 02 0e         \
       00 01 00 01 00 00 52 32 30 30 32 00]
 pppd: rcvd [IPCP ConfAck id=0x1 <addr 152.3.60.1> <compress VJ 0f 01>]
 pppd: rcvd [CCP ConfAck id=0x1 < fe 02>]
 pppd: rcvd [CCP TermReq id=0x4 00 00 02 dc]
 pppd: sent [CCP TermAck id=0x4]
 pppd: sent [IPCP ConfAck id=0xa <compress VJ 0f 01>]
 pppd: local  IP address 152.3.60.1
 pppd: remote IP address 152.3.60.2
 pppd: sent [CCP ConfReq id=0x1]
 pppd: rcvd [CCP TermAck id=0x1]
 pppd: sent [CCP TermReq id=0x2]
 pppd: rcvd [CCP TermAck id=0x2]

Auszug Protokoll /var/log/messages : Aufbau einer CHAP/PPP-Verbindung

Interessant ist hierbei die Reaktion des Clients auf den Request der CHAP-Authentisierung

 pppd: rcvd [LCP ConfReq ... <auth chap msoft> ... ]

Dieser Request wird prompt beantwortet mit

 pppd: sent [LCP ConfAck ... <auth chap msoft> ... ]   

Die nachfolgende "CHAP Challenge"-Forderung wird mit dem verschluesselten Passwort und der Login-Kennung in Klartext beantwortet

 pppd: rcvd [CHAP Challenge ... <f7d486a3df030b71>, name = ""]
 pppd: sent [CHAP Response  ... <0000000000000000000000000000000000000      \
       00000000000ee0cecf8c969e78c01e80aa8f28dcd0aa5a835287d0fa32d01>,      \
       name = "my_login"]
 pppd: rcvd [CHAP Success ... ]

Dies fuehrt schliesslich zum erfolgreichen Verbindungsaufbau.

Wie aus dem Protokoll ersichtlich ist, wird beim CHAP-Authentifizierungsschema neben der Userkennung das Passwort nicht mehr im Klartext uebertragen, was als positiver Sicherheitsaspekt anzusehen ist. Um den Sicherheitsstandard weiter zu heben, wird nun zu saeztlich noch die Moeglichkeit eines automatischen Rueckrufes durch den Windows NT Server gefordert.

7 PPP-Verbindung mit CHAP/ 'Callback'-Authentifizierung

Es wird die oben erwaehnte gepatchte 'pppd'-Version eingesetzt und zusaetzlich das Callback-Feature verwendet.

Die Anwahl des Windows NT Servers erfolgt nach dem vorausgegangenen Schema.

7.1 'pppd'-Anwahlscript

Um den automatischen Rueckruf zu aktivieren, muss dem 'pppd' die -variable- benutzerdefinierte Telefonnummer unter der Windows NT zurueckruft mitgeteilt werden; dies erfolgt mit der Option "cb", die in das Anwahlscript eingebaut wird:


#!/bin/sh
# Aufbau einer PPP Verbindung
# zu einem Windows NT Server unter Verwendung des CALLBACK-Modus
phone="cb 555111"
/usr/sbin/pppd 38400 connect '/usr/sbin/chat -v -f $HOME/win_nt.chat' \
    lock $phone

Datei: dial_win_nt.callback

7.2 'mgetty'-Konfiguration

Um den eingehenden Rueckruf korrekt zu uebernehmen, muss hierzu ein entsprechender 'mgetty'-Prozess fuer die Schnittstelle durch Eintrag in die Datei /etc/inittab definiert werden. Dieser 'mgetty'-Prozess wird beim naechsten Systemstart automatisch aktiviert und uebernimmt bei einer ankommenden PPP-Verbindung den Aufruf des 'pppd'-Programmes.


mo:23:respawn:/usr/sbin/mgetty -x 6 -s 38400 ttyS0

Auszug Datei /etc/inittab


Parameterbeschreibung Auszug Datei /etc/inittab :

-s  <speed>          :   setzt die zu verwendende Portgeschwindigkeit 
                         z.B.: 38400 Baud
ttyS0                :   definiert die anzusprechende Schnittstelle
                         ( ttyS0 = COM1 ) 
-x 6                 :   setzt den debug-Modus; die debug-Informationen werden
                         in der Datei /tmp/log.mg.<device> abgelegt
                         (/tmp/log.mg.ttyS0)

In der 'mgetty'-Konfigurationsdatei /etc/mgetty+sendfax/mgetty.config wird unter anderem festgelegt, bei einer ankommenden Verbindung nur den Modem-Modus zu verwenden:


# ----- port specific section -----
# Here you can put things that are valid only for one line, not the others
# USR Sportster Vi 28.8, connected to ttyS0: don't do fax
port ttyS0
data-only y
rings 2

Auszug Datei /etc/mgetty+sendfax/mgetty.config


Parameterbeschreibung Auszug Datei /etc/mgetty+sendfax/mgetty.config :

 port ttyS0           : Schnittstellenspezifische Definitionen fuer
                        Port ttyS0 ( = COM1 )
 data-only y          : spezifiziert die Klasse des am angegebenen Port
                        angeschlossenen Modems:  
                        keine Verwendung des FAX-Modus, nur Daten-Modus
 rings <n>            : definiert die Anzahl der RING-Meldungen die
                        abgewartet werden bis 'mgetty' ueber das Modem abhebt

Schliesslich ist dem 'mgetty'-Prozess in der Datei /etc/mgetty+sendfax/login.config noch mitzuteilen, bei einer erkannten PPP-Anforderung automatisch den 'pppd'-Prozess zu starten:


# Automatic PPP startup on receipt of LCP configure request.
#  mgetty has to be compiled with "-DAUTO_PPP" for this to work.
#  Warning: Case is significant, AUTOPPP or autoppp won't work!
/AutoPPP/ -     ppp     /usr/sbin/pppd 38400  

Auszug Datei /etc/mgetty+sendfax/login.config


Parameterbeschreibung Auszug Datei /etc/mgetty+sendfax/mgetty.config :

38400                   : setzt die zu verwendende Portgeschwindigkeit
                          (38400 Baud)

Dieses Verfahren birgt aber bei gleichzeitiger Verwendung des Modems am Telefonhauptanschluss die Gefahr, dass 'mgetty' bei jedem eingehenden Telefonanruf abhebt. Diese Funktion ist aber nicht erwuenscht, denn wer unterhaelt sich schon gerne mit einem Modem.

'mgetty' bietet hierfuer eine Loesung, 'login'-Prozesse zeitweise zu sperren. Durch Anlegen einer Datei namens /etc/nologin.<device> (hier /etc/nologin/ttyS0) wird 'mgetty' gehindert, einem eingehenden Anruf selbststaendig zu antworten.

Diese Funktion muss natuerlich in den entsprechenden Anwahl-/Abwahlscripts, beim Verbindungsende/-abbruch ('pppd'-Option 'disconnect') bzw. beim Hochlauf des Systemes als Standardeinstellung (in der Datei /sbin/init.d/serial) definiert werden.

Die 'login'-Sperre wird realisiert durch ein simples

     touch /etc/nologin.ttyS0; chmod 666 /etc/nologin.ttyS0

Die 'login'-Sperre kann wieder aufgehoben werden durch

     rm -f /etc/nologin.ttyS0

7.3 Protokoll PPP/CHAP-Verbindung mit 'User-Defined Callback'-Funktion

Ein -unkommentiertes- Protokoll einer erfolgreichen PPP-Verbindungsaufnahme via CHAP-Authentifizierung mit Rueckruf ("User-Defined") durch den Windows NT Server sieht folgendermassen aus (der 'chat'-Verbindungsaufbau ist nicht mehr aufgefuehrt):


 pppd: Using interface ppp0
 pppd: Connect: ppp0 <--> /dev/ttyS0
 pppd: sent [LCP ConfReq id=0x1 <mru 1500> <callback 0x605>                   \
       06 6c ce 1f 62 07 02 08 02 00]
 pppd: sent [LCP ConfReq id=0x1 <mru 1500> <callback 0x605>                   \
       06 6c ce 1f 62 07 02 08 02 00]
 pppd: rcvd [LCP ConfReq id=0x0 <asyncmap 0x0> <auth chap msoft>              \
       <magic 0x6b35> <pcomp> <accomp>]
 pppd: sent [LCP ConfAck id=0x0 <asyncmap 0x0> <auth chap msoft>              \ 
       <magic 0x6b35> <pcomp> <accomp>]
 pppd: rcvd [LCP ConfAck id=0x1 <mru 1500> <callback 0x605>                   \
       06 6c ce 1f 62 07 02 08 02 07]
 pppd: cbcp_lowerup
 pppd: want: 6
 pppd: rcvd [CHAP Challenge id=0x10 <349d61d2af2f5f75>, name = ""]
 pppd: sent [CHAP Response id=0x10 <0000000000000000000000000000000           \
       000000000000000004ee80271f4ad6170bfb6ffa5a866883f5bdf739e596162db01>,  \
       name = "my_login"]
 pppd: rcvd [CHAP Success id=0x10 ""]
 pppd: cbcp_open
 pppd: rcvd [CBCP Request id=0x1 < NoCallback> 02 05 00 01 00]
 pppd: length: 7
 pppd: no callback allowed
 pppd: length: 5
 pppd: user callback allowed
 pppd: cbcp_resp cb_type=6
 pppd: cbcp_resp CONF_USER
 pppd: sent [CBCP Response id=0x1 < UserDefined delay = 5 number = 555111>]   \
       35 35 35 31 31 31
 pppd: rcvd [CBCP Ack id=0x1 < UserDefined delay = 5 number =  555111>]       \
       35 35 35 31 31 31
 pppd: peer will call: 555111
 pppd: sent [LCP TermReq id=0x2]
 pppd: rcvd [LCP TermAck id=0x2]
 pppd: Connection terminated.
 pppd: Exit.

Auszug Protokoll /var/log/messages : Aufbau einer CHAP/PPP-Verbindung mit Rueckruf ("User-Defined")

Interessant ist hierbei die Reaktion des Clients noch vor dem Request der CHAP-Authentisierung durch Senden eines "Callback-Requests"

 pppd: sent [LCP ConfReq ... <callback 0x605> ... ]

Dieser Request wird prompt beantwortet mit

 pppd: rcvd [LCP ConfAck ... <callback 0x605> ... ]

um spaeter nach der CHAP-Authentifizierung dem Windows NT Server die Telefonnummer mitzuteilen

 pppd: sent [CBCP Response ...  number = 555111>]   ...

Diese Mitteilung wird vom Windows NT Server angenommen

 pppd: rcvd [CBCP Ack      ...  number =  555111>]  ...

Die bestehende Verbindung wird nun vom Client unterbrochen und auf den Rueckruf gewartet. Erfolgt der Rueckruf, wird ueber den 'mgetty'-Prozess das 'pppd'-Modul erneut aufgerufen, wobei nun keine Telefonnummer mitgegeben werden darf. Der CHAP/PPP-Verbindungsaufbau erfolgt analog dem weiter oben schon gezeigten Schema (Abschnitt 6.1).

Mit dieser Verfahrensweise sind die anfangs erwaehnten Sicherheitsaspekte (MS-CHAP-Authentifizierung und "Callback"-Schema) erfuellt.

Um den unsicheren PAP/PPP-Zugang wieder zu unterbinden, kann nun auf dem Windows NT Server im Windows NT-Remote Access Service unter 'Network Configuration' bei den 'Encryption settings' der Punkt 'Require Microsoft encrypted authentication' aktiviert werden, der nur noch CHAP/PPP-Verbindungen via MS-CHAP-Authentifizierung zulaesst.

7.4 Protokoll PPP/CHAP-Verbindung mit 'Admin-Defined Callback'-Funktion

Um den automatischen Rueckruf im 'Admin-Defined'-Modus zu aktivieren, muss beim 'pppd' die Option "cb" mit einer -beliebigen- Telefonnummer versorgt werden (siehe Punkt 7.1). Die hier angebebene Nummer dient in diesem Falle nur dazu, die 'Callback'-Option des 'pppd' zu aktivieren.

Ein -unkommentiertes- Protokoll einer erfolgreichen PPP-Verbindungsaufnahme via CHAP-Authentifizierung mit Rueckruf ("Admin Defined") durch den Windows NT Server sieht folgendermassen aus (der 'chat'-Verbindungsaufbau ist nicht mehr aufgefuehrt):



 pppd: Using interface ppp0
 pppd: Connect: ppp0 <--> /dev/ttyS0
 pppd: sent [LCP ConfReq id=0x1 <mru 1500> <callback 0x605>                    \
       < 06 0a 3f 4c 0b 07 02 08 02 00>]
 pppd: sent [LCP ConfReq id=0x1 <mru 1500> <callback 0x605>                    \
       < 06 0a 3f 4c 0b 07 02 08 02 00>]
 pppd: rcvd [LCP ConfReq id=0x0 <asyncmap 0x0> <auth chap msoft>               \
       <magic 0x81f> <pcomp> <accomp>]
 pppd: sent [LCP ConfAck id=0x0 <asyncmap 0x0> <auth chap msoft>               \
       <magic 0x81f> <pcomp> <accomp>]
 pppd: rcvd [LCP ConfAck id=0x1 <mru 1500> <callback 0x605>                    \
       < 06 0a 3f 4c 0b 07 02 08 02 07>]
 pppd: cbcp_lowerup
 pppd: want: 14
 pppd: rcvd [CHAP Challenge id=0x4 <9c0cceb72ffbbd37>, name = ""]
 pppd: sent [CHAP Response id=0x4 <000000000000000000000000000000000000000000  \ 
       0000386515129f151f5b2dca1092bd45b11bf0d25a2bbe7dc26801>,                \
       name = "my_login"]
 pppd: rcvd [CHAP Success id=0x4 ""]
 pppd: cbcp_open
 pppd: rcvd [CBCP Request id=0x1 < AdminDefined delay = 0>]
 pppd: length: 3
 pppd: user admin defined allowed
 pppd: cbcp_resp cb_type=8
 pppd: cbcp_resp CONF_ADMIN
 pppd: sent [CBCP Response id=0x1 < AdminDefined delay = 5 number = >]
 pppd: rcvd [CBCP Ack id=0x1 < AdminDefined delay = 5 number = >]
 pppd: sent [LCP TermReq id=0x2]
 pppd: rcvd [LCP TermAck id=0x2]
 pppd: Connection terminated.
 pppd: Exit.

Auszug Protokoll /var/log/messages : Aufbau einer CHAP/PPP-Verbindung mit Rueckruf ("Admin-Defined")

Interessant ist hierbei die Reaktion des Clients noch vor dem Request der CHAP-Authentisierung durch Senden eines "Callback-Requests"

 pppd: sent [LCP ConfReq ... <callback 0x605> ... ]

Dieser Request wird prompt beantwortet mit

 pppd: rcvd [LCP ConfAck ... <callback 0x605> ... ]

um spaeter nach der CHAP-Authentifizierung dem Windows NT Server die Antwort auf die "Admin-Defined" Callback-Vorgabe

 pppd: rcvd [CBCP Request id=0x1 < AdminDefined delay = 0>]

mitzuteilen

 pppd: sent [CBCP Response ...  number = >]   ...

Diese Mitteilung wird vom Windows NT Server angenommen

 pppd: rcvd [CBCP Ack      ...  number =  >]  ...

Die bestehende Verbindung wird nun vom Client unterbrochen und auf den Rueckruf gewartet. Erfolgt der Rueckruf, wird ueber den 'mgetty'-Prozess das 'pppd'-Modul erneut aufgerufen, wobei nun keine Telefonnummer mitgegeben werden darf. Der CHAP/PPP-Verbindungsaufbau erfolgt analog dem weiter oben schon gezeigten Schema (Abschnitt 6.1).

Desweiteren gelten auch fuer diese Variante die unter Abschnitt 7.3 genannten Aussagen.

7.5 Protokoll 'mgetty'-Prozess

Die Transaktionen des 'mgetty'-Prozesses koennen durch

      tail -f /tmp/log_mg.ttyS0 

beim Verbindungsaufbau am Bildschirm mitprotokolliert werden.

Nachfolgend ein -unkommentiertes- Protokoll einer erfolgreichen PPP-Verbindungsaufnahme ueber den 'mgetty'-Prozess via CHAP-Authentifizierung mit Rueckruf durch den Windows NT Server.


 yS0  mgetty: experimental test release 0.99-May31
 yS0   reading configuration data for port 'ttyS0'
 yS0  check for lockfiles
 yS0   checklock: stat failed, no file
 yS0  locking the line
 yS0   makelock(ttyS0) called
 yS0   do_makelock: lock='/var/lock/LCK..ttyS0'
 yS0   lock made
 yS0  lowering DTR to reset Modem
 yS0   tss: set speed to 38400 (017)
 yS0   tio_set_flow_control( HARD )
 yS0   waiting for line to clear (VTIME), read: [0d][0a]NO CARRIER[0d][0a]
 yS0  send: \d\d\d+++\d\d\d[0d]\dATQ0V1H0[0d]
 yS0  waiting for ``OK''
 yS0   got: +++[0d]
 yS0    CND: +++[0a]RING[0d]
 yS0    CND: RING[0a][0d]ATQ0V1H0[0d]
 yS0    CND: ATQ0V1H0[0d][0a]OK ** found **
 yS0  send: ATS0=0Q0&D3&C1[0d]
 yS0  waiting for ``OK''
 yS0   got: [0d]
 yS0    CND: OK[0a]ATS0=0Q0&D3&C1[0d]
 yS0    CND: ATS0=0Q0&D3&C1[0d][0a]OK ** found **
 yS0   waiting for line to clear (VTIME), read: [0d][0a]
 yS0   removing lock file
 yS0  waiting...
 yS0    select returned 1
 yS0   checking lockfiles, locking the line
 yS0   makelock(ttyS0) called
 yS0   do_makelock: lock='/var/lock/LCK..ttyS0'
 yS0   lock made
 yS0  waiting for ``RING''
 yS0   got: [0d]
 yS0    CND: OK[0a]RING ** found **
 yS0  send: ATA[0d]
 yS0  waiting for ``CONNECT''
 yS0   got: [0d]
 yS0    CND: RING[0a]ATA[0d]
 yS0    CND: ATA[0d][0a]CONNECT ** found **
 yS0  send: 
 yS0  waiting for `` ''
 yS0   got:  28800/ARQ/V34/LAPM[0d]
 yS0    CND: CONNECT 28800/ARQ/V34/LAPM
 yS0    CND: found: 28800/ARQ/V34/LAPM[0a] ** found **
 yS0   waiting for line to clear (VTIME), read: 
 yS0    looking for utmp entry... (my PID: 2412)
 yS0   utmp + wtmp entry made
 yS0   tio_set_flow_control( HARD )
 yS0   getlogname, read:~[ff][03]
 yS0   getlogname, read:[c0]!
 yS0   input finished with '\r', setting ICRNL ONLCR
 yS0    login: use login config file /etc/mgetty+sendfax/login.config
 yS0   match: user='/AutoPPP/', key='/FIDO/'
 yS0   match: user='/AutoPPP/', key=''
 yS0   match: user='/AutoPPP/', key='/AutoPPP/'*** hit!
 yS0   login: utmp entry: ppp
 yS0    looking for utmp entry... (my PID: 2412)
 yS0   utmp + wtmp entry made
 yS0   calling login: cmd='/usr/sbin/pppd', argv[]='pppd 38400 '             \
       08/28 19:23:14 ##### data dev=ttyS0, pid=2412, caller=none,           \
       conn='28800/ARQ/V34/LAPM', name='', cmd='/usr/sbin/pppd',             \
       user='/AutoPPP/'

...

... ... Aufruf von pppd nach erfolgtem Rueckruf

... ... und Warten auf Verbindungsende

...

 yS0  check for lockfiles
 yS0   checklock: no active process has lock, will remove
 yS0  locking the line
 yS0   makelock(ttyS0) called
 yS0   do_makelock: lock='/var/lock/LCK..ttyS0'
 yS0   lock made
 yS0  lowering DTR to reset Modem
 yS0   tss: set speed to 38400 (017)
 yS0   tio_set_flow_control( HARD )
 yS0   waiting for line to clear (VTIME), read: [0a][0a]NO CARRIER           \
       [0a][0a][0a][0a][0a][0a]NO CARRIER[0a][0a]......                      \
       [0a]NO CARRIER[0a][0a][0a][0a][0a][0a][0a][0a]
 yS0  clean_line: only 500 of 3124 bytes logged
 yS0  send: \d\d\d+++\d\d\d[0d]\dATQ0V1H0[0d]
 yS0  waiting for ``OK''
 yS0   got: +++[0d]
 yS0    CND: +++ATQ0V1H0[0d]
 yS0    CND: ATQ0V1H0[0d][0a]OK ** found **
 yS0  send: ATS0=0Q0&D3&C1[0d]
 yS0  waiting for ``OK''
 yS0   got: [0d]
 yS0    CND: OK[0a]ATS0=0Q0&D3&C1[0d]
 yS0    CND: ATS0=0Q0&D3&C1[0d][0a]OK ** found **
 yS0   waiting for line to clear (VTIME), read: [0d][0a]
 yS0   removing lock file
 yS0  waiting...

Auszug Protokoll /tmp/log_mg.ttyS0 : mgetty mit PPP-Protokoll-Erkennung

8 'Callback'-Funkion ohne 'mgetty'

8.1 Anpassung des Anwahlscriptes

Wem der Einsatz von 'mgetty' zu komplex oder zu aufwendig erscheint, kann die Funktion der 'Callback'-Erkennung durch Erweiterung des 'pppd' Anwahlscriptes auf einfache Weise nachbilden:


#!/bin/sh
# Aufbau einer PPP Verbindung
# zu einem Windows NT Server unter Verwendung des CALLBACK-Modus
phone="cb 555111"
/usr/sbin/pppd 38400 connect '/usr/sbin/chat -v -f $HOME/win_nt.chat' \
    lock $phone -detach
/usr/sbin/pppd 38400 connect '/usr/sbin/chat -v -f $HOME/win_nt_cb.chat' \
    lock -detach

Datei: dial_win_nt.callback


Parameterbeschreibung Datei dial_win_nt.callback :

-detach                   : verhindert dass 'pppd' ueber einen
                            fork(2)-Aufruf als Hintergrundprozess laeuft 

Entscheidend bei dieser Aufrufvariante ist die Verwendung der 'pppd'-Option '-detach', die dafuer sorgt, dass der erste 'pppd'-Prozess nicht im Hintergrund ablaeuft und damit der zweite 'pppd'-Prozess erst nach Beendigung des ersten gestartet wird.

Nach dem erstmaligen Aufruf des 'pppd', bei dem Windows NT nur die Telefonnummer mittgeteilt wird, unter der zurueckgerufen werden soll, erfolgt ein weiterer Aufruf des 'pppd', der den Rueckruf durch ein geaendertes 'chat'-Script (win_nt_cb.chat) abfaengt:


TIMEOUT  120
ABORT "NO CARRIER"
ABORT BUSY
ABORT "NO DIALTONE"
ABORT ERROR
"" +++ATZ 
OK ATE1Q0&C1&S0
RING ATA
CONNECT ""

Datei: win_nt_cb.chat

Es wird nach der Modeminitialisierung einfach auf die 'RING'-Kennung eines eingehenden Anrufes gewartet, durch 'ATA' erfolgt die manuelle Beantwortung des Klingelzeichens: das Modem hebt ab und wartet auf die 'CONNECT'-Meldung.

Kommt binnen des unter 'TIMEOUT' definierten Zeitraumes keine Verbindung zustande, wird 'chat' und somit auch 'pppd' beendet.

Bei einer positiven 'CONNECT'-Kennung, uebernimmt wie gehabt der 'pppd' die Steuerung und baut die PPP-Verbindung auf.

Voraussetzung ist natuerlich wieder die Deaktivierung des 'AUTOANSWER'-Modus beim angeschlossenen Modem (siehe Abschnitt 2.5).

8.2 Protokoll PPP/CHAP-Verbindung mit 'Callback' (ohne 'mgetty')

Ein -unkommentiertes- Protokoll einer erfolgreichen PPP-Verbindungsaufnahme via CHAP-Authentifizierung mit Rueckruf durch den Windows NT Server ohne Verwendung des 'mgetty'-Prozesses sieht folgendermassen aus (der 'pppd'-Aufruf zur Uebergabe der Telefonnummer ist nicht mehr aufgefuehrt):


 pppd: pppd 2.2.0f_SIGI.0 started by root, uid 0
 chat: timeout set to 120 seconds
 chat: abort on (NO CARRIER) 
 chat: abort on (BUSY) 
 chat: abort on (NO DIALTONE) 
 chat: abort on (ERROR) 
 chat: send (+++ATZ^M) 
 chat: expect (OK) 
 chat: +++ATZ^M^M 
 chat: OK -- got it 
 chat: send (ATE1Q0&C1&S0^M) 
 chat: expect (RING) 
 chat: ^M 
 chat: ATE1Q0&C1&S0^M^M 
 chat: OK^M 
 chat: ^M 
 chat: RING -- got it 
 chat: send (ATA^M) 
 chat: expect (CONNECT) 
 chat: ^M 
 chat: ATA^M^M 
 chat: CONNECT -- got it 
 chat: send (^M) 
 pppd: Serial connection established.
 pppd: Using interface ppp0
 pppd: Connect: ppp0 <--> /dev/ttyS0

Der restliche Verbindungsaufbau verlaeuft dann gemaess Punkt 7.3/Punkt 7.4.


Auszug Protokoll /var/log/messages : Aufbau einer CHAP/PPP-Verbindung mit Rueckruf ohne 'mgetty'


Previous Next Contents LINUX PPP/NT HOWTO V1.1