Zurück Weiter Inhalt

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

Es wird die oben erwähnte gepatchte "pppd"-Version eingesetzt und zusätzlich das Callback-Feature verwendet.

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

7.1 `pppd'-Anwahlskript (`Callback')

Um den automatischen Rückruf zu aktivieren, muß dem "pppd" die -variable- benutzerdefinierte Telefonnummer unter der Windows NT zurückruft mitgeteilt werden; dies erfolgt mit der Option "cb", die in das Anwahlskript 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 Rückruf korrekt zu übernehmen, muß hierzu ein entsprechender "mgetty"-Prozess für die Schnittstelle durch Eintrag in die Datei /etc/inittab definiert werden. Dieser "mgetty"-Prozess wird beim nächsten Systemstart automatisch aktiviert und übernimmt 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 für
                        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' über das Modem abhebt

Schließlich 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 Telefonhauptanschluß die Gefahr, daß "mgetty" bei jedem eingehenden Telefonanruf abhebt. Diese Funktion ist aber nicht erwünscht, denn wer unterhält sich schon gerne mit einem Modem.

"mgetty" bietet hierfür eine Lösung, "login"-Prozesse zeitweise zu sperren. Durch Anlegen einer Datei namens /etc/nologin.<device> (hier /etc/nologin/ttyS0) wird "mgetty" gehindert, einem eingehenden Anruf selbstständig zu antworten.

Diese Funktion muß natürlich in den entsprechenden Anwahl-/Abwahlskripts, 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 Rückruf ("User-Defined") durch den Windows NT Server sieht folgendermaßen aus (der "chat"-Verbindungsaufbau ist nicht mehr aufgeführt):


 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 Rückruf ("User-Defined")

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

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

Dieser Request wird prompt beantwortet mit

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

um später 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 Rückruf gewartet. Erfolgt der Rückruf, wird über 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 erwähnten Sicherheitsaspekte (MS-CHAP-Authentifizierung und "Callback"-Schema) erfüllt.

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 zuläßt.

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

Um den automatischen Rückruf im "Admin-Defined"-Modus zu aktivieren, muß 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 Rückruf ("Admin Defined") durch den Windows NT Server sieht folgendermaßen aus (der "chat"-Verbindungsaufbau ist nicht mehr aufgeführt):


 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 Rückruf ("Admin-Defined")

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

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

Dieser Request wird prompt beantwortet mit

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

um später 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 Rückruf gewartet. Erfolgt der Rückruf, wird über 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 für diese Variante die unter Abschnitt 7.3 genannten Aussagen.

7.5 Protokoll `mgetty'-Prozess

Die Transaktionen des "mgetty"-Prozesses können durch

      tail -f /tmp/log_mg.ttyS0

beim Verbindungsaufbau am Bildschirm mitprotokolliert werden.

Nachfolgend ein -unkommentiertes- Protokoll einer erfolgreichen PPP-Verbindungsaufnahme über den "mgetty"-Prozess via CHAP-Authentifizierung mit Rückruf 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 Rückruf
  ... ... 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


Zurück Weiter Inhalt