C - Instytut Informatyki PW

Transkrypt

TIN – zima-lato 2006, Grzegorz Blinowski
TIN
Techniki Internetowe
zima-lato 2006
Grzegorz Blinowski
Instytut Informatyki
Politechniki Warszawskiej
Plan wykładów
2
3
4
5
6
7, 8
9, 10, 11
12
13
14
Intersieć, ISO/OSI, protokoły sieciowe, IP
Protokół IP i prot. transportowe: UDP, TCP
Model klient-serwer, techniki progr. serwisów
Protokoły aplikacyjne: telnet, ftp, smtp, nntp, inne
HTTP
HTML, XML
Aplikacje WWW, CGI, sesje, serwery aplikacji
serwlety, integracja z backended SQL
Aspekty zaawansowane: wydajność,
przenośność, skalowalność; klastering
Inne: P2P, SOAP, RDF, WSDL, ontologie
Wstęp do zagadnień bezpieczeństwa
(IPSec, VPN, systemy firewall)
oraz aspekty kryptograficzne (DES, AES, RSA,
PGP, S/MIME), tokeny i akceleracja sprzętowa
Zdalna praca znakowa:
telnet, rlogin (i rsh), ...
Przykład - sesje zdalne
skinner:~> telnet mulder
Trying 192.168.1.5...
mulder% ctrl-]
Connected
to mulder.xyz.com.pl.
telnet>
?
Escape
character
is '^]'.
Commands may be abbreviated.
SunOS 5.7
Commands are:
close
close current connection
…
login: gjb
set
set operating parameters
Password:
unset
unset operating parameters
Last
login: Fri Oct
10 status
15:17:14
from nanny
status
print
information
Sun… Microsystems Inc.
SunOS 5.7
mulder%
Telnet
RFC0158(!) - 1971,
RFC: 0854
• Podstawowy protokół pracy zdalnej w trybie
tekstowym
• Telnet realizuje sesję zdalną - pozwala na
zalogowanie się do odległej maszyny
• Obecny w każdym systemie "Unix-o podobnym" często domyślnie włączony!
• Wykorzystuje TCP/IP, port TCP serwera: 23
• Znaczny wysiłek włożono w przenośność: liczne
opcje negocjowane między klientem i serwerem
• Protokół o minimalnym (żadnym?) poziomie
bezpieczeństwa
Telnet
Serwer Telnet
Klient telnet
Terminal
driver
TCP/IP
Użytkownik
przy
terminalu
Schemat sesji
klient-serwer
dla prot. telnet
TCP/IP
Login shell
Pseudo-terminal
driver
Sesja TCP
Pseudo terminal:
Pozwala na realizację funkcji terminalowych dla danych niepochodzących
z "fizycznych" terminali - obsługa sygnałów, grupy terminalowe procesów praca w tle (SIGINT SIGQUIT, SIGTSTP, SIGTTIN, SIGTTOU)
Telnet
• Trzy podstawowe serwisy:
– Symetryczna traktowanie obydwu stron połączenia (w
sensie transmisji danych)
– NVT - Network Virtual Terminal - standardowy interfejs
do zdalnych systemów
– Mechanizm negocjacji opcji połączenia (poprzez NVT)
• Każdy znak podróżuje zazwyczaj w osobnym
pakiecie ("tinygram") - echo jest zazwyczaj
zdalne, co podwaja liczbę przesyłanych pakietów
(zob. alg. Nagle'a limitujący liczbę
niepotwierdzonych pakietów)
Alg. Nagle'a i alg. opóźnionego
potwierdzenia
• Założenie: w miarę możności unikać przesyłania
pakietów małych (rozm. < MSS)
• Alg. Nagle'a - nie wysyłaj pakietu małego jeśli poprzednie
nie zostały potwierdzone
– przy trybie konwersacyjnym w wolnej sieci nastąpi sklejenie kilku
mniejszych pakietów w jeden
• Alg. "delayed ACK" - nie wysyłaj potwierdzenia od razu
po otrzymaniu danych
– … może pojawią sie jakieś dane do wysłania zwrotnego (po co
wysyłać samo potwierdzenie)
– dobrze sie sprawdza ze zdalnym echem
• Uwaga - rozwiązania dobrze sprawują się przy pracy
konwersacyjnej, często źle w przypadku innych prot.
Telnet NVT
• NVT - definiuje uniwersalną reprezentację danych
• Translacja różnych reprezentacji znaków CR-LF
– niektóre systemy określają koniec linii jako CR, inne LF, inne
CR/LF
– NVT: zawsze CR/LF
• Praca w trybie 7/8 bitów
• Przesyłanie znaków specjalnych - sekwencje IAC
(Interpret as Command, kod: 255)
255 Cmd
Opt
255
Cmd
Opt,opt, ...
Przykładowe polecenia IAC w NVT
•
BRK -
"Break", odp. Ctrl-C
•
IP -
"Suspend, interrupt abort" - zdalnego procesu
•
AO -
"Abort output" - rezygnuję z otrzymywania wyników
•
AYT -
"Are you there?" - prośba o potwierdzenie
•
EC -
"Erase" - kasuj ostatni znak
•
EL -
"Erase line" - kasuj ostatnią linię
•
SB/SE -
"Subnegotiation" - negocjacja dodatkowych opcji
Opcje telnet
• Negocjowane przez obydwie strony {IAC, typ, opcja} –
–
–
–
WILL
DO
WONT
DONT
251
252
253
254
Nadawca chce włączyć
Nadawca chce aby odbiorcą włączył
Nadawca chce wyłączyć
Nadawca chce aby odbiorca wyłączył
• Druga strona musi potwierdzić/odmówić ustawienia opcji
• Typowe opcje:
uzgodnienie typu terminala
praca w trybie liniowym
zdalne echo
half/full duplex
transmisja binarna
– Przykład: supress go-ahead: 255(IAC),251(WILL),3
–
–
–
–
–
Opcje Telnet
Nadawca
Odbiorca
•
WILL
DO
N: chce skorzystać, O: ok
•
WILL
DONT
N: chce, O: nie
•
DO
WILL
N: jest gotowy, O: ustawia
•
DO
WONT
N: jest gotowy, O: nie
•
WONT
DONT
N: wyłączam, O: ok
•
DONT
WONT
N: wyłącz, O: ok
$ telnet
telnet> toggle options
Will show option processing.
telnet> open ccub
Trying 134.220.1.20 ...
Connected to ccub.wlv.ac.uk.
Escape character is '^]'.
SENT do SUPPRESS GO AHEAD
SENT will TERMINAL TYPE (reply)
RCVD do TERMINAL TYPE (don't reply)
RCVD will SUPPRESS GO AHEAD
(don't reply)
RCVD will ECHO (reply)
SENT do ECHO (reply)
RCVD do ECHO (reply)
SENT wont ECHO (reply)
Opcje telnet c.d.
Opcje telnet c.d.
Client 255(IAC),251(WILL),24 (term type)
Server 255(IAC),253(DO),24
Value required
Server 255(IAC),250(SB),24,1,255(IAC),240(SE)
Client 255(IAC),250(SB),24,0,'V','T','2','2','0',255
(IAC),240(SE)
Value supplied
•
Klient i serwer ustalają tryb terminala
•
SB/SE -
"Subnegotiation" - negocjacja dodatkowych opcji
Protocol
Name
Number
========
=====================================
TOPT-BIN
Binary Transmission
0
TOPT-ECHO Echo
1
TOPT-RECN Reconnection
2
TOPT-SUPP Suppress Go Ahead
3
TOPT-APRX Approx Message Size Negotiation
4
TOPT-STAT Status
5
TOPT-TIM
Timing Mark
6
TOPT-REM
Remote Controlled Trans and Echo
7
TOPT-OLW
Output Line Width
8
TOPT-OPS
Output Page Size
9
TOPT-OCRD Output Carriage-Return Disposition 10
TOPT-OHT
Output Horizontal Tabstops
11
TOPT-OHTD Output Horizontal Tab Disposition 12
TOPT-OFD
Output Formfeed Disposition
13
TOPT-OVT
Output Vertical Tabstops
14
TOPT-OVTD Output Vertical Tab Disposition
15
TOPT-OLD
Output Linefeed Disposition
16
TOPT-EXT
Extended ASCII
17
TOPT-LOGO Logout
18
TOPT-BYTE Byte Macro
19
TOPT-DATA Data Entry Terminal
20
TOPT-SUP
SUPDUP
21
TOPT-SUPO SUPDUP Output
22
TOPT-SNDL Send Location
23
TOPT-TERM Terminal Type
24
TOPT-EOR
End of Record
25
TOPT-TACACS TACACS User Identification
26
TOPT-OM
Output Marking
27
TOPT-TLN
Terminal Location Number
28
TOPT-3270 Telnet 3270 Regime
29
TOPT-X.3
X.3 PAD
30
TOPT-NAWS Negotiate About Window Size
31
TOPT-TS
Terminal Speed
32
TOPT-RFC
Remote Flow Control
33
TOPT-LINE Linemode
34
State
=====
Std
Std
Prop
Std
Prop
Std
Std
Prop
Prop
Prop
Prop
Prop
Prop
Prop
Prop
Prop
Prop
Prop
Prop
Prop
Prop
Prop
Prop
Prop
Prop
Prop
Prop
Prop
Prop
Prop
Prop
Prop
Prop
Prop
Draft
Status
======
Rec
Rec
Ele
Rec
Ele
Rec
Rec
Ele
Ele
Ele
Ele
Ele
Ele
Ele
Ele
Ele
Ele
Ele
Ele
Ele
Ele
Ele
Ele
Ele
Ele
Ele
Ele
Ele
Ele
Ele
Ele
Ele
Ele
Ele
Ele
RFC STD
==== ===
856 27
857 28
...
858 29
...
859 30
860 31
726
...
...
652
653
654
655
656
657
658
698
727
735
1043
736
749
779
1091
885
927
933
946
1041
1053
1073
1079
1372
1184
Liczba opcji
prot. telnet jest
dość długa...
rlogin, rsh,
rcp, ...
rlogin
• Mechanizm zdalnej pracy pochodzący z
systemów BSD:
– rlogin - praca zdalna - odpowiednik telnet
– rsh - zdalne wywoływanie poleceń
– rcp, rdist - kopiowane plików na zdalne maszyny
• W stosunku do telnet:
– dołączono mechanizmy (pół)automatycznej
autoryzacji
– możliwe jest standardowe przekierowanie we/wy
(szczególnie przydatne przy rsh)
– poziom bezpieczeństwa - podobny (praktycznie
zerowy)
Rlogin, rsh
• Przykłady
• rlogin nazwa_maszyny
• rlogin user-zdalny nazwa_maszyny
• rsh user-zdalny nazwa_maszyny
• rsh nazwa_maszyny polecenie
• rsh nazwa_maszyny 'polecenie arg'
• rsh nazwa_maszyny 'polecenie > /tmp/x'
• rsh nazwa_maszyny 'polecenie arg' > /tmp/x
Rlogin - autoryzacja
• Autoryzacja opiera się na mechanizmie rcmd (funkcja):
– lokalnej nazwie użytkownika, zdalnym koncie użytkownika
– pliku .rhosts lokalnym dla zdalnego użytkownika
– ogólnosystemowym pliku /etc/hosts.equiv
• Typowo podjęta jest próba zalogowania użytkownika na
identyczne konto na zdalnej maszynie, możliwe jest też
logowanie na arbitralne konto zdalne - zawsze będzie
sprawdzane .rhosts
• rsh - nie pyta o hasło, użytkownicy zaufani (trusted)
• Bezpieczeństwo opiera się na zaufaniu do zdalnego
użytkownika root-a (prawo do otwarcia portu < 1024)
• rhosts: pozwala/zakazuje dostępu na podstawie nazw
użytkowników, maszyn ("netgroups")
Plik .rhosts i hosts.equiv
Plik .rhosts w kat. $HOME użytkownika określa jacy użytkownicy z
jakich maszyn mogą działać zdalnie na tym koncie (/etc/hosts.equiv plik ogólnosystemowy)
hostname [username]
[+-]hostname [[+-]username]
Wymienieni lub wszyscy
użytkownicy z danego hosta
Wymienieni lub wszyscy
użytkownicy z danego hosta,
dozwoleni lub zakazani
[+-][hostname|@netgroup] [[+-][username|@netgroup]]
J.w. ale lista
użytkowników
zawarta w
netgroup-ie
Rlogin, rsh inne
• Rsh jest wygodnym mechanizmem zdalnego
wykonywania poleceń, np.:
– W skrypcie na wielu maszynach
– wykonywania zdalnych kopii, przykład
dump <lokalne parametry> | rsh …
– zdalnej instalacji: rdist (remote distribution)
• rsh/rlogin obsługuje także stderr poprzez
dodatkowe gniazdo (co pozwala na rozdzielenie
stdout i stderr i zwrotne przekazywnie sygnałów)
• rlogin sprawdza czy nie są ustawione opcje IP zobaczyć kod w [Stevens]
Przekazywanie danych pilnych w
prot. interaktywnych - Wstęp opcje gniazd
int getsockopt(int sockfd, int level, int
optname, char *optval, int *optlen)
int setsockopt(int sockfd, int level, int
optname, char *optval, int optlen)
• level: IPPROTO_IP, IPPROTO_TCP, SOL_SOCKET
• optname - opcja
• optval - wartość ustawianego parametru (często: 0, 1)
• optlen - długość bufora opcji dla opcji niebinarnych
(IP_OPTIONS)
prot. interaktywnych
• Nadejście danych pilnych (urgent, OOB),
powoduje wysłanie sygnału SIGURG
• Dane pilne (1 bajt) mogą:
– być umieszczone w strumieniu (tj. buforze odbiorczym)
danych "zwykłych" (in-line)
– być umieszczone poza strumieniem danych zwykłych
– W obydwu przypadkach w strumieniu danych
"zwykłych" znajduje się znacznik pozwalający określić
położenie danych pilnych
int off=0;
setsockopt(sockfd, SOL_SOCKET,
SO_OOBINLINE, (char*)&off, sizeof(off));
prot. interaktywnych, c.d.
Wczytaj bajt danych OOB inline odrzucając wszystkie
poprzedzające go dane:
for (;;){
if (ioctl(s, SIOCATMARK, &mark)<0){
perror("ioctl");
break; }
if (mark)
// czy doszliśmy do OOB?
break;
read(s, trash, sizeof trash); // nie, odrzuć dane
}
if (recv(s, &oob, 1, MSG_OOB) < 0) { // weź bajt OOB
perror("recv"); …
}
FTP File Transfer Protocol
FTP
• Podstawowy protokół wymiany plików - TCP/IP,
RFC 959, porty 21 i 20
• klient-serwer - wymaga procesu serwera obsługującego
FTP na porcie 21 - transfer plików do/z serwera
• Interaktywny
• Prot. stanowy - serwer przechowuje takie informacje jak:
aktualny katalog, tryb transmisji, i wiele innych
• Zakłada autoryzację, zwyczajowo pozwala też na dostęp
anonimowy
• Cechą charakterystyczną jest komunikacja przez 2 porty
(21 - control, 20 - data)
Sesja FTP
3-cyfrowy
kod
5xx - wymaga
akcjj
1xx=OK, I will
2xx=OK, done.
3xx=OK so far
4xx=NO, temp
klient% ftp ftp.ii.pw.edu..pl
Connected to ftp ftp.ii.pw.edu..pl
220 Welcome to II PW FTP Server
530 Please login with USER and PASS.
Name (ftp.ii.pw.edu..pl): anonymous
331 Please specify the password.
Password: XXXXXXX
230 Login successful. Remember - the computer is your friend
Remote system type is UNIX.
Using binary mode to transfer files.
ftp> cd pub
250 Directory successfully changed.
ftp> ls
200 PORT command successful. Consider using PASV.
150 Here comes the directory listing.
drwxrwxrwx 2 0
0
2048 Aug 23 12:56 mirrors
226 Directory send OK.
ftp> quit
221 Goodbye.
klient%
Polecenia klienckie FTP
•
•
•
•
•
•
•
•
•
open, user
dir, ls
cd, lcd, pwd
binary, ascii, cr
put, get
mput, mget, mdelete, mls
prompt
nmap
ntrans
•
•
•
•
•
open [port]
dir [rdir] [nazwa-pliku]
cd/lcd - zdalny/ lokalany
cr - transl. CR/LF
put plik-lok [plik-odlegl]
• można stosować wzorce
• translacja nazw:
nmap $1.$2 $1_$2
• translacja znaków
Elementy protokołu FTP
Przykładowe polecenia:
Typowe odpowiedzi:
• wysyłane w trybie ASCII
do portu 21
• USER username
• PASS password
(otwartym tekstem!)
• LIST - zwraca listę plików
• Kod statusu i opis
• 331 Username OK,
password required
• 125 data connection
already open;
transfer starting
• 425 Can’t open data
connection
• 452 Error writing
file
• RETR filename pobiera
zawartość pliku
• STOR filename wgrywa
zawartość pliku na serwer
FTP
• Protokół bazuje na NVT ASCII (z telnet)
• Typy danych: ASCII (NVT-ASCII), image
(binarne, 8-o bitowe liczby), local, EBCDIC
• Przy transferze danych klient otwiera port 20, zaś
serwer inicjuje do niego połączenie z danymi
(czy zachowana jest unikalność asocjacji?)
sockets API: bind(…)
• Tryb PASV (passive) jeśli serwer nie może
zainicjować połączenia do klienta
Polecenia FTP
• Dostęp: USER, PASS, ACCT (account), REIN (reinitialize
- jak logout, bez zamykania poł.), QUIT
• katalogi: CWD (zmiana), CDUP (cd ..)
• Transfer danych: PORT h1,h2,h3,h4,p1,p2; PASV, TYPE
(A - ascii, I- image, …)
• Serwis: RETR, STOR, STOU (store unique), APPE
(append), ALLO (allocate storage), RNFR/RNTO
(rename from/to), ABOR, DELE, RMD/MKD
(remove/make directory), PWD, LIST, STAT (status)
• Inne: NOOP, HELP
• Mało używane: struktura pliku (file, record, page); tryby
transmisji: strumieniowy, blokowy oraz z kompresją
Kody statusu FTP
• jednolinijkowy:
123 opis kodu
• wielolinijkowy:
123-opis kodu
nastepna linijka
234 liczby dozwolone
123 ostatnia linia
• Statusy:
– 1yz - Positive Preliminary reply (będzie dalszy ciąg, nie wysyłać
poleceń)
– 2yz - Positivie completion (można przesłać nast. polecenie)
– 3yz - Positive Intermediate (OK, wysłać dalszy ciąg polecenia)
– 4yz - Transient Negative
– 5yz - Permanent Negative
Kody statusu FTP
• x0z Syntax - błędy skladni, inne błędy poleceń,
niezaimplementowane polecenia
• x1z Information - odpowiedzi o charakterze
informacyjnym (status, pomoc)
• x2z Connections - Odpowiedzi na polecenia sterujące i
połączeniowe
• x3z Authentication and accounting - login
• x4z Unspecified as yet.
• x5z File system - związane z systemem plików serwera
• Przykłady:
– 211 System status, or system help reply
– 250 Requested file action okay, completed
Kody statusu FTP
•
•
•
•
•
•
•
•
•
•
•
•
•
200 Command okay.
211 System status, or system help reply.
212 Directory status.
213 File status.
221 Service closing control connection.
225 Data connection open; no transfer in progress.
226 Closing data connection. Requested file action successful (for
example, file transfer or file abort).
227 Entering Passive Mode (h1,h2,h3,h4,p1,p2).
230 User logged in, proceed.
250 Requested file action okay, completed.
257 "PATHNAME" created.
331 User name okay, need password.
350 Requested file action pending further information.
Kody statusu FTP
•
•
•
•
•
•
•
•
•
•
•
•
421 Service not available, closing control connection. This may be a
reply to any command if the service knows it must shut down.
425 Can't open data connection.
426 Connection closed; transfer aborted.
450 Requested file action not taken. File unavailable (e.g., file busy).
451 Requested action aborted: local error in processing.
452 Requested action not taken. Insufficient storage space in
system.
500 Syntax error, command unrecognized..
501 Syntax error in parameters or arguments.
502 Command not implemented.
503 Bad sequence of commands.
504 Command not implemented for that parameter.
530 User name okay, need password
Sesja FTP - tryb zwykły
SERWER
KLIENT
1025
Cntrl
Katalog: LIST, 1199
21
Cntrl
PORT command OK
Data
1199
Data
20
Katalog plików
1200
RETR plik.zip, 1200
21
Cntrl
Cntrl
PORT command OK
Data
Data
Dane, dane, (dużo danych)
1200
20
Sesja FTP - tryb PASV
KLIENT
SERWER
PASV
1025
21
Cntrl
Cntrl
LIST
Data
Data
firewall
1025
Passive Mode, 4107
21
Cntrl
Cntrl
1673
4107
Data
Data
Katalog plików
Zmiana nr portu w API gniazd
int on=1;
setsockopt(sockfd, SOL_SOCKET,
SO_REUSEADDR, (char*)&on, sizeof(on));
bind(sockfd, (struct sockaddr*)&newsin,
sizeof(newsin));
• Włączenie opcji SO_REUSEADDR pozwoli na
ponowne dowiązanie do gniazda adresu, w
szczególności pozwala to na zmianę numeru
portu.
Poczta elektroniczna:
SMTP
E-mail
Kolejka
serwera
Skrzynka użytk.
•
•
•
•
•
MTA - Mail Transfer Agent
(serwer) - sendmail, postfix,
Exchange, …
PO - Post Office - przechowuje
skrzynki, może ale nie musi
być to ten sam serwer co MUA
MUA - Mail User Agent (klient)
- Mozilla, Outlook, Eudora, ...
Protokół SMTP (Simple Mail
Transfer Protocol) - RFC 821,
1982, szereg późniejszych
rozszerzeń
"maildrop" - POP3, IMAP4;
inne - OWA
MUA
SMTP
MUA
SMTP
MTA
SMTP
MTA
PO
MUA
IMAP, POP
SMTP
• Komunikacja klient do serwera; serwer do serwera
• SMTP obejmuje:
–
–
–
–
–
specyfikację protokołu wymiany danych
uwierzytelnianie
adresowanie
ruting poczty
nie obejmuje: dostarczenia poczty do MUA, sposobu zapisu
treści przesyłki
• Port TCP: 25
• Komunikacja (ASCII):
– nawiązanie połączenia (greeting)
– wymiana danych
– zakończenie sesji
Sesja SMTP
S:
C:
S:
C:
S:
C:
S:
C:
S:
C:
C:
C:
C:
S:
C:
S:
220 This is XYZ smtp server at uczelnia.edu
HELO nikt.pl
250 Hello nikt.pl, pleased to meet you
MAIL FROM: <[email protected]>
250 [email protected]... Sender ok
RCPT TO: <[email protected]>
250 [email protected] ... Recipient ok
DATA
354 Enter mail, end with "." on a line by itself
Szanowny Panie
Nasza firma oferuje rewelacyjny program do
obslugi dziekanatow oraz calych uczelni ...
.
250 Message accepted for delivery
QUIT
221 uczelnia.edu closing connection
Polecenia SMTP
• HELO
• EHLO (ESMTP)
– najpopularniejsze rozszerzenia: pipelining, ...
• MAIL FROM
• RCPT TO
• VRFY, EXPN - zazwyczaj nieaktywne ze
względów bezpieczeństwa
• DATA
• QUIT
• NOOP
Więcej o sesji i danych w SMTP
S: 220 This is XYZ smtp server at ...
...
C: MAIL FROM: <[email protected]>
S: 250 [email protected]... Sender ok
C: RCPT TO: <[email protected]>
S: 250 [email protected] ... Recipient ok
C: DATA
S: 354 Enter mail, end with "." ...
C: To: <[email protected]>
C: Subject: ciekawa oferta
C:
C: Szanowny Panie
C: Nasza firma oferuje rewelacyjny ...
C: ...
C: .
S: 250 Message accepted for delivery
C: QUIT
envelope
header
body
Więcej o sesji i danych w SMTP
• Pola nagłówka wiadomości (header - RFC822)
sa podobne i mogą (ale nie muszą) mieć
identyczną zawartość jak pola z envelope - nie
jest to jednak to samo!
• Pola nagłówka takie jak np.: Subject, To, CC są
przez SMTP traktowane na równi z danymi
• Pola nagłówka są przeznaczone dla MUA
• Serwer e-mail może przepisać informacje
zawarte w envelope do header
• Serwer e-mail może dodatkowo analizować pola
nagłówka, np. realizując funkcje anty-spam
Pola nagłówka E-mail
Return-Path: <[email protected]>
Delivered-To: grzegorz.blinowski@[81.153.28.98]
Received: from localhost (localhost [127.0.0.1])
by …….
Received: from freza.core.ignum.cz (217.31.49.12)
by ….
From: "Ludek Hrdina" <[email protected]>
To: "Up-to-date_CHKP" <[email protected]>
Subject: Check Point's ….
Date: Tue, 11 Nov 2003 14:08:51 +0100
Message-ID: <[email protected]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-2"
Content-Transfer-Encoding: 8bit
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
X-AntiVirus: OK! AntiVir MailGate Version 2.0.0.9; ...
X-Mozilla-Status: 8001
Ruting SMTP
• W transmisji wiadomości serwer SMTP może być
serwerem docelowym lub pośrednim
• Ruting SMTP - zestaw reguł pozwalających określić co
serwer ma dalej robić z otrzymaną wiadomością
• W najprostszym przypadku:
– jeśli serwer obsługuje dane konto e-mail (obsługuje domenę i zna
użytkownika) to wiadomość zostaje wysłana do” message store”
– w przeciwnym wypadku na podstawie rekordu MX pobranego z
DNS serwer określa adres serwera do przekazania wiadomości
• Rekordy MX zawierają adres serwera SMTP i priorytet
– Przykład:
smallcom.com MX www.smallcom.com 10
smallcom.com MX www.hoster.com 20
– im priorytet niższy tym "ważniejszy" MX
Ruting SMTP
•
Ruting jest w rzeczywistości o wiele bardziej skomplikowany,
gdyż:
– wewnątrz domeny obsługiwanej przez jeden MX może
funkcjonować wiele serwerów SMTP, np. wydziałowych, do
których wiadomości rozdzielane są na podstawie wewnętrznych
reguł rutingu:
n.p.: firma.com.pl - SMTP srv.: kadry.firma,
finanse.firma, misc.firma
– serwer STMP może otrzymywać wiadomości z innych systemów
E-mail (nie SMTP) - RFC2820 definjuje "SMTP gateway"
– Serwery obsługują szereg historycznych konwencji takich jak:
user%domena@domena lub serwer1!serwer2!serwer3...
– Inne: konieczne jest wykrywanie i usuwanie pętli w rutingu
Maildrop - POP3 (port: 110)
Autoryzacja
•
•
Polecenia klienta:
– user
– pass
odpowiedzi serwera
– +OK, -ERR
Maildrop
client:
• list - nr wiad, wielkość
• stat - liczba wiad, suma wielk.
• retr - pobierz wiad.
• dele - usuń wiad (dopiero po quit)
• rset - usuń znaczniki dele
• top - początek wiad
• uidl - zwraca unikalne id-y
• quit
S:
C:
S:
C:
S:
RFC1939
+OK POP3 server ready
user jasio
+OK
pass iza123
+OK user successfully logged
on
C: list
S: 1 711
S: 2 654
S: .
C: retr 1
S: <message 1 contents>
S: .
C: dele 1
C: retr 2
S: <message 1 contents>
S: .
C: dele 2
C: quit
S: +OK POP3 server signing off
POP3 - APOP
S: +OK POP3 server ready
<[email protected]>
C: APOP mrose c4c9334bac560ecc979e58001b3e22fb
S: +OK maildrop has 1 message (369 octets)
•
•
•
•
•
Prosta weryfikacja tożsamości klienta na podstawie algorytmy Ch/Rp
Polecenie: APOP <digest>
Odpowiedź: +OK lub –ERR
Banner powitalny musi zawierać "challenge"
Challenge ma postać jak niżej:
– challenge opiera się na timestamp, np. standard proponuje: <processID.clock@hostname>
klient oblicza kryptograficzną sumę kontrolną
md5(challenge+secret)
•
Dostępne jest też polecenie AUTH (RFC1734) - autentykacja Kerberos
Maildrop - IMAP4
RFC2060
• Zaprojektowany pod kątem przechowywania
znacznej liczby wiadomości na serwerze
• Wiadomości grupowane w foldery
• Wiadomości posiadają "flagi" (seen, deleted,
answered, itp.)
• Manipulowanie wiadomościami bez konieczności
ładowania całej wiadomości do klienta (tylko
nagłówki)
• Zalety: oszczędność pasma, dostęp do poczty z
wielu lokalizacji, SSL - bezpieczeństwo
• Wady: skomplikowany protokół, implementacje
nie zawsze zgodne ze sobą
Sesja IMAP
Initial connection and server greeting
1
Non-authenticated
2
4
3
Authenticated
7
6
5
7
Selected
7
Logout and close connection
Maildrop - IMAP4
• Protokół - asynchroniczny - odpowiedź na
polecenie nie musi nadejść "od razu", czekając
na odpowiedź można zlecić inne polecenia
• Aby zidentyfikować odpowiedzi serwera
wprowadzono "tagi"
• Podstawowe stany serwera:
–
–
–
–
Non-authenticated
Authenticated (po zalogowaniu)
Selected – wybrano folder
Logout
Sesja IMAP
C: a001 LOGIN SMITH SESAME
S: a001 OK LOGIN completed
C: A142 SELECT INBOX
S: * 172 EXISTS
S: * 1 RECENT
S: A142 OK [READ-WRITE] SELECT completed
...
C: A023 LOGOUT
S: * BYE IMAP4rev1 Server logging out
S: A023 OK LOGOUT completed
IMAP c.d.
• Flagi wiadomości:
–
–
–
–
–
–
\seen: wiadomość "przeczytana"
\answered: na wiadomość odpowiedziano
\flagged: wiadomość zaznaczono
\deleted: wiadomość ma być skasowana
\draft: wiadomość w trakcie tworzenia
\recent: wiadomość nowa
Polecenia IMAP
•
•
•
•
•
•
•
•
•
•
•
•
CAPABILITY
NOOP
LOGOUT
AUTHENTICATE
LOGIN
SELECT
EXAMINE
CREATE
DELETE
RENAME
SUBSCRIBE
UNSUBSCRIBE
•
pyt. o opcje funkcjonalne serwera
•
•
•
•
•
•
•
•
•
•
serwer zamyka transakcje, odp: “BYE”
opcjonalna autentykacja (np. Kerberos)
wymagana autoryzacja
wybiera mailbox (folder), tylko 1 na raz
j.w. w trybie read-only
tworzy folder
usuwa folder
zmienia nazwę folderu
subskrybuje folder (zob. LSUB)
de-subskrybuje folder
Polecenia IMAP c.d.
•
•
•
•
•
•
•
•
•
•
•
•
LIST
LSUB
STATUS
APPEND
CHECK
CLOSE
EXPUNGE
SEARCH
FETCH
STORE
COPY
UID
•
•
•
•
•
•
•
•
•
•
•
•
zwraca listę folderów
zwraca listę subskrybowanych folderów
zwraca inf. o folderze (liczba wiad, etc)
Dodaje wiadomość do folderu
wymusza "checkpoint"
zamyka akt. folder, usuwa ozn. wiadomości
usuwa ozn. wiadomości (\Deleted)
szuka wiad. wg.zadanych kryteriów w akt. folderze
pobiera (część) wiadomości
uaktualnia wiadomość
kopiuje wiadomości do zadanego folderu
wykonuje inne polecenia (SEARCH, COPY,
FETCH) w trybie zwracajacym uniklane uid-y
MIME
(Multipurpose Internet Mail Extensions)
MIME - podstawy
RFC2045
• MIME - aktualny standard RFC 2045, 2046 (pierwsze wersje RFC2046
RFC1341 - 1992)
• Dodatkowe pola nagłówka definiują format danych binarnych
• Uwaga - MIME pomyślany dla e-mail, jednak aktualne
zastosowanie wykracza poza SMTP!
Wersja MIME
Metoda kodowania
Typ, podtyp, opcjonalnie
parametry
danych
Dane
From: [email protected]
To: [email protected]
Subject: Zdjecie 1/1
MIME-Version: 1.0
Content-Transfer-Encoding: base64
Content-Type: image/jpeg
dane kodowane base64 ....
.........................
.... dane kodowane base64
Podstawowe typy MIME
Content-type: type/subtype; parameters
Text
Video
• video/mpeg, video/
text/plain; charset=us-ascii
quicktime
• text/plain, text/html
Image
• image/jpeg, image/gif
Audio
• audio/basic
jeden kanał, 8bit PCM 8000 Hz
Application
• application/msword,
application/octetstream
Złożone typy MIME
Content-Type: multipart/mixed; boundary=bndr-string
• Wiadomość podzielona na wiele części
oddzielonych przez unikalny (ale arbitralny) ciąg
znaków "boundary string"
• Generowanie boundary string – heurystyczne (?)
• Każda część może mieć własny content-type, np:
– pierwsza część może być typu text/plain
– druga typu image/gif kodowana base64
MIME Multipart/mixed - przykład
From: <[email protected]>
To: <[email protected]>
Subject: blah
MIME-Version: 1.0
Content-Type: multipart/mixed;
00=_9W2T/VtQiQcNR1P"
boundary= "Boundary-
--Boundary-00=_9W2T/VtQiQcNR1P
Content-Type: text/plain; charset=US-ASCII
tekst tekst tekst tekst tekst tekst tekst tekst
Content-Type: application/octet-stream
...
MIME Multipart/mixed - przykład
From: <[email protected]>
To: <[email protected]>
Subject: blah
MIME-Version: 1.0
Content-Type: multipart/mixed;
00=_9W2T/VtQiQcNR1P"
...
boundary= "Boundary-
Boundry poprzedzone jest --
Content-Type: application/octet-stream
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
filename= "nazwa_pliku.bin"
base64base64base64base64base64...
base64base64base64base64base64...
--Boundary-00=_9W2T/VtQiQcNR1P--
Ostatnie boundry
zakończone jest --
Inne złożone typy MIME
• multipart/alternative - ta sama treść przesłana w kilku
wariantach, np. w formacie text i HTML, klient wybiera
właściwą postać do prezentacji danych
• multipart/digest - format identyczny jak w mixed, służy
do wysyłania wielu wiadomości formatu message/rfc822
• multipart/parallel - format identyczny jak w mixed, służy
do równeległej prezentacji danych w kilku formatach
• message/partial - pozwala na przesłanie dużej
wiadomości w "kawałkach":
Content-Type: Message/Partial; number=2;
total=3;
Kodowanie Base64
• Proste kodowanie pozwalające na przesłanie dowolnych
danych binarnych w postaci "drukowalnych" znaków ASCII
(7bit)
• Wielkość danych zwiększa się o 4/3, np. plik o rozmiarze 3KB
ma po zakodowaniu 4KB
• Bloki 3 bajtowe zamieniane są na 4 liczby 6-o bitowe
• Każda liczba 6-o bitowa zamieniana jest na znak drukowalny z
przedziału: A-Za-z0-9+/
• Jeśli wielkość danych kodowanych w bajtach nie jest
podzielna przez 3 - uzupełnienie zerami/znakami = na końcu
• Wynikowy tekst jest dzielony na linie o długości 76 znaków
• Tak otrzymany tekst jest do zaakceptowania przez każdy
MUA/MTA zgodny z podstawowym SMTP
Więcej o MIME
• RFC:
– RFC 2045 - nagłówki definiowane w standardzie
MIME
– RFC 2046 - struktura danych MIME i podstawowe typy
danych w MIME
– RFC 2047 - rozszerzenia MIME w treści nagłówków
wiadomości
– RFC 2048, - procedury rejestracji nowych typów MIME
w IANA
– RFC 2049 - reguły zgodności aplikacji z MIME oraz
przykłady
MIME - kodowanie
•
Zdefiniowane są następujące typy "Content-Transfer-Encoding":
– "7bit"
– "8bit"
nie dokonano przekodowania
– "binary"
– "quoted-printable"
Wiadomość jest kodowana w
specjalny sposób
– "base64"
– ietf-token oraz x-token
• Typ "quoted-printable" - do kodowania wiadomości
składających się głównie, ale nie wyłącznie, ze
standardowych znaków ASCII
• Uwaga: RFC 2045 określa dozwolone typy kodowania dla
złożonych typów danych (multipart i message) jako
wyłącznie: 7/8 bit oraz binary
MIME - "quoted-printable"
• Kodowanie mające na celu zachowanie danych (zwykle
tekstu) bez modyfikacji nawet przez serwery niezgodne
ze standardami
• każdy oktet może być reprezentowany jako: =hh, gdzie h
- cyfra szesnastkowa: 0123456789ABCDEF
• oktety o kodach: 33-60 (większość znaków
przestankowych) oraz: 62-126 (litery, cyfry, [, ] , |, ~)
mogą być reprezentowane bezpośrednio
• białe znaki reprezentowane są bezpośrednio, chyba, że
są na końcu linii
• znak = na końcu linii oznacza "soft line break" (można
łamać długie linie)
• Przykład: Dzia=B3aj=B1c w imieniu i na rzecz=
sp=F3=B3ki "Zielone buraczki" Sp. =
RFC 2047 - "Message Header Extensions"
Do tej pory omówione rozwiązania nie pozwalają na zawarcie
znaków nie ASCII w nagłówku wiadomości - co może być przydatne
np. w nagłówku "Subject" (znaki narodowe)
• RFC 2047 rozwiązuje ten problem wprowadzając tzw. "encoded
word"
•
encoded-word = "=?" charset "?" encoding "?" encoded-text "?="
•
•
•
Charset - określa kodowanie (np. ISO-8859-2)
encoding - Q - quoted printable, B - base64
encoded-text - kodowany tekst
Przykład:
From: =?ISO-8859-1?Q?Olle_J=E4rnefors?= <[email protected]>
Subject: =?ISO-8859-1?B?SWYgeW91IGNhbiByZWFkIHRoaXMgeW8=?=
=?ISO-8859-2?B?dSB1bmRlcnN0YW5kIHRoZSBleGFtcGxlLg==?=
Inne nagłówki MIME
• Content-ID:
–
–
–
–
jak message-id,
muszą być unikalne,
pozwalają identyfikować daną zawartość,
zwykle opcjonalne (poza typem message/externalbody)
• Content-Description:
– opis zawartości,
– zawsze opcjonalne
RFC 2049 - Zgodność z MIME
• RFC 2049: "[…] There exist many widely-deployed nonconformant MTAs in the Internet. These MTAs, speaking
the SMTP protocol, alter messages on the fly to take
advantage of the internal data structure of the hosts they
are implemented on, or are just plain broken. […]"
• RFC 2049 - określa minimalny poziom zgodności, w
szczególnosci sytuacje gdy program natrafi na nieznany
typ danych (zalecenie - traktować jak multipart/mixed),
lub nieobsługiwany zestaw znaków (zalecenie - traktować
jak application/octed-stream)
• RFC 2049 precyzuje standard, określa kroki jakie musi
wykonać aplikacja generując wiadomość MIME
Usenet News:
NNTP
Usenet
• Model "tablicy ogłoszeniowej"
• Format wiadomości - dość podobny do E-mail,
zupełnie inna metoda dystrybucji
• Dystrybucja - każdy artykuł (posting) powinien
teoretycznie dotrzeć do każdego klienta
subskrybujacego daną grupę
• Tematy grup są hierarchiczne:
– tematycznie: alt., comp., rec., sci, np. comp.lang.java
– hierarchie regionalnie/językowe: np. pl.* pl.rec.modelarstwo
NNTP
RFC0977 - 1986,
RFC: 2980,
...
• Wiadomość "rozgłaszane" są między serwerami
• "feed" - logiczne połączenie pomiędzy serwerami
• Serwer musi być uprawniony do pobierania /
wysyłania wiadomości do / z innego serwera,
uprawnienia ustalane są "recznie" (uzgadniane
przez administratorów
• Wiadomość, podobna do e-mail (MIME, itp), plus:
– Newsgroups
– unikalny w skali świata Message-Id
– Path (scieżka serwerów propagujacych wiadomość)
Przykład - Posting NNTP
Path: news.litech.org!lnsnews.lns.cornell.edu!paradoxa.ogoense.net!notfor-meow
From: [email protected] (A Meowbot)
Newsgroups: alt.dev.null
Subject: Why?
Date: Sun, 27 Jan 2002 23:25:52 +0000 (UTC)
Organization: a tyranny of meowing fascist censor cabalists
Lines: 4
Approved: nope.
Message-ID: <[email protected]>
X-Trace: paradoxa.ogoense.net 1012173952 6565 141.154.205.147 (27
Jan
2002 23:25:52 GMT)
X-Complaints-To: [email protected]: news.litech.org
alt.dev.null:492
Because we like you.
-Meow
Usenet/NNTP - problemy
• C.a. 70 GB wiadomości w ciągu doby, wyzwania
technologiczne:
– indeksowanie wiadomości
– określenie czy daną wiadomość już "widzieliśmy"
• Model "tablicy ogłoszeniowej" - generowany ruch
jest b. duży
• Utrzymanie spójnej hierarchii grup - tworzenie i
usuwanie grup
• Grupy moderowane - wiadomość musi zostać
zaakceptowana przez osobę(osoby)
odpowiedzialną przed upublicznieniem
Serwer NNTP
• Serwer końcowy, serwer tranzytowy
• Moduły
– Spool - wiadomości
– Overview - indeksy
– History - indeks przyjętych wiadomości
• Tryby pracy serwer-serwer:
– "pull" -NEWNEWS- (klasyczny, obecnie nie używany przy dużym
ruchu) - żądanie przesłania listy wiadomości, następnie
pobierane wiadomości
– "push" (streaming) -CHECK, TAKETHIS - feed przesyła
wszystkie wiadomości "hurtem" do odbiorcy:
• CHECK - serwer źródłowy "sprawdza" czy serwer docelowy chce
przyjmować artykuły
• TAKETHIS - strumieniowe przesłanie artykułów bez potwierdzeń
NTTP - wybrane polecenia
• ARTICLE <message-id> - pobierz posting, polecenia
spokrewnione: HEAD, BODY, STAT
• POST - wysłanie postingu (przez klienta EU)
• GROUP <group-name> - podaje informacje o groupie, także id
postingów (pierwszy, ostatni)
• IHAVE - informacja dla serwera o posiadanych postingach (serwerserwer)
• LIST, NEWGROUPS - lista obsługiwanych grup
• NEWGROUPS - nowe grupy,
• NEWNEWS <grups> <date> <time> - lista nowych postingów problem - wygenerowanie listy może b. obciążyć serwer źródłowy
• streaming / push - MODE STREAM, TAKETHIS (push
wiadomości), CHECK <msg-id> (czy przesłać sekwencję wiad.
przy pomocy takethis)
NNTP - przykłady
klient prosi o listę grup:
C:
S:
S:
S:
LIST
215 list of newsgroups follows
net.wombats 00543 00501 y
net.unix-wizards 10125 10011 y
(more information here)
klient wybiera grupe (w grupie 104 postingi, o podanych #):
C:
GROUP net.unix-wizards
S:
211 104 10011 10125 net.unix-wizards group selected
klient pobiera artykuł:
C:
STAT 10110
S:
223 10110 <[email protected]> article retrieved statistics only (article 10110 selected, its
message-id is <[email protected]>)
C:
HEAD
S:
221 10110 <[email protected]> article retrieved head follows (text of the header appears here)
NNTP - przykłady
klient pobiera artykuł:
C:
S:
HEAD
221 10110 <[email protected]> article retrieved head follows (text of the header appears here)
S:
.
C:
BODY
S:
222 10110 <[email protected]> article retrieved body follows (body text here)
S:
.
klient pobiera nastepny artykuł:
C:
NEXT
S:
223 10113 <[email protected]> article retrieved statistics only (article 10113 was next in group)
NNTP - przykłady
klient pobiera wybrany artykuł:
C:
S:
GROUP msgs
211 103 402 504 msgs Your new group is msgs
(there are 103 articles, from 402 to 504)
C:
S:
ARTICLE 401
423 No such article in this newsgroup
C:
S:
ARTICLE 402
220 402 <[email protected]> Article retrieved,
text follows
(article header and body follow)
S:
NNTP - c.d.
• Moderowanie:
– (1) serwer odbierający posting stwierdza, że grupa jest
moderowana
– (2) nie publikuje wiadomości, wysyła e-mail do
moderatora
– (3) moderator akceptuje wiadomość, i dokonuje
publikacji
Usenet
Credit:
CAIDA (1999)
Organizacja Usenet - 1980
reed
phs
\ / \
uok---duke-unc
/ \
research vax135
|
ucbvax
pdp
(Misc)
! (NC)
(Misc)
decvax sii reed phs--unc--grumpy duke34 utzoo cincy teklabs
! ! !
!
!
!
!
!
!
!
! +--+----+-----+-+--+-------------+-------+------+
!
!
!
!
!
duke
!
!
!
!
!
+------+---+-----------------------+--------+ !
!
!
!
!
! !
ucbopt
! hocsr--mhtsa----research
mh135a
harpo-----chico
:
!
! !
!
ucbcory !
! eagle
ihnss
vax135 (Bell Labs)
(UCB) :
!
! !
!
!
ucbvax--++----------+--+--+-----+--+------+--------+
:
@
!
!
! (Silicon Valley)
ucbarpa @
(UCSD) sdcsvax
!
menlo70--hao
:
@
sdcattb-----+
!
!
!
ucbonyx @
+-----ucsfcgl
sytek sri-unix
@
phonlab-----+
cca-unix
sdcarl

C - Instytut Informatyki PW

Transkrypt

Podobne dokumenty

No Slide Title

Szkolne wydarzenia - Jednym zdaniem!

Uczniowie klas : I TPS, I TIN, I

Value - Instytut Informatyki PW

Nazwa jednostki organizacyjnej: Zakład Badania Środowiska Ilość

Figurka bogini Tin Hau - Narodowe Muzeum Morskie w Gdańsku