Camada de Sessão chat

OSI Layer 5

Introdução

A Camada de Sessão (OSI Layer 5) gerencia diálogos entre aplicações, coordenando comunicação, estabelecendo e encerrando sessões, e sincronizando dados. Situada acima da Camada de Transporte (Aula 9) e abaixo da Camada de Apresentação, ela usa TCP/UDP (RFC 793, RFC 768) como base para troca de dados.

Funções Principais

Função Descrição Exemplo
Controle de Diálogo Gerencia turnos: half-duplex (um lado por vez) ou full-duplex (simultâneo, como TCP, Aula 9 Slide 3). Walkie-talkie (half), HTTP (full)
Gerenciamento de Tokens Garante exclusão mútua via tokens (Slide 2). Token Ring, FDDI
Sincronização Usa checkpoints para recuperação após falhas (Slide 4). File transfer (NetBIOS, NFS)

📌 Sessões NetBIOS Layer 5 OSI

Protocolo de camada de sessão (Layer 5 OSI) originalmente desenvolvido pela IBM para redes locais, amplamente utilizado em sistemas Windows NT até Server 2003.

🔧 Funcionamento

# Portas UDP 137–139
137 NetBIOS Name Service (nbt-ns)
138 NetBIOS Datagram Service (nbt-dgm)
139 NetBIOS Session Service (nbt-ssn)

💡 Aplicações

  • Compartilhamento de arquivos (SMB/CIFS)
  • Resolução de nomes em redes Windows antigas
  • Browser Service (lista de máquinas na rede)
  • Print Spooling (compartilhamento de impressoras)
⚠ Segurança
  • Vulnerável a NTLM relay attacks
  • Exposição de informações via NetBIOS Name Service
  • Substitua por: DNS moderno + SMB direto (TCP 445)

📌 PPTP (Point-to-Point Tunneling Protocol) RFC 2637

Protocolo VPN obsoleto desenvolvido pela Microsoft (1999), encapsulando pacotes PPP sobre IP, amplamente utilizado em soluções de acesso remoto corporativo até meados dos anos 2010.

🔧 Funcionamento

# Porta TCP 1723 (controle)
# GRE (47) para encapsulamento
Cliente ⇄ Servidor PPTP (autenticação: MS-CHAPv2)
# MPPE Criptografia (RC4-128)

💡 Aplicações Históricas

  • Acesso remoto corporativo (1990–2010)
  • Túneis simples entre redes
  • VPN para usuários móveis
  • Embarcado em roteadores antigos
⚠ Problemas
MS-CHAPv2
  • Quebra em <24h com ASIC
  • Vulnerável a dictionary attacks
RC4-128
  • Criptografia obsoleta
  • Vulnerável a bit-flipping

Substitua por: WireGuard (UDP 51820), IKEv2/IPsec (UDP 500/4500)

Exemplo de Topologia

session_topology.txt
[Host1: 192.168.1.10:137]---[Router]---[Host2: 192.168.1.11:137]
! Exemplo: Sessão NetBIOS (TCP) para compartilhamento de arquivos

Contexto Prático

Protocolos como NetBIOS (portas 137–139, Slide 2), PPTP (VPNs), e RPC gerenciam sessões para aplicações como compartilhamento de arquivos, túneis, e chamadas remotas (Slide 4). Use netstat -tunap (Aula 9 Slide 6) para observar sessões ativas.

Atividade Introdutória (5 min)

Execute netstat -tunap | grep 137 em um sistema com compartilhamento de arquivos ativo (e.g., Windows com SMB). Identifique portas NetBIOS (137–139) e processos associados.
Entregável: Screenshot da saída do netstat.

Leitura: ISO/IEC 7498-1 (OSI Model), RFC 793 (TCP), RFC 768 (UDP); Kurose §3; Tanenbaum §6.

Half- vs. Full-Duplex & Token Passing sync_alt

Controle de Diálogo

Introdução

O controle de diálogo na Camada de Sessão (Slide 1) gerencia como aplicações trocam dados, usando half-duplex (um lado por vez) ou full-duplex (simultâneo, como TCP, Aula 9 Slide 3). Token passing evita colisões em redes compartilhadas, garantindo exclusão mútua.

Half-Duplex vs. Full-Duplex

Modo Descrição Exemplo
Half-Duplex Transmissão ou recepção por vez, alternando turnos (Aula 3: CSMA/CD). Walkie-talkie, Token Bus
Full-Duplex Transmissão e recepção simultâneas via canais separados (Aula 9 Slide 3: TCP). NetBIOS (port 139), HTTP

Exemplo Prático: Full-Duplex

Observe uma sessão NetBIOS (full-duplex) com netstat -tunap (Aula 9 Slide 6):

netstat_session.txt
$ netstat -tunap | grep 139
tcp 0 0 192.168.1.10:139 0.0.0.0:* LISTEN 1234/smbd
tcp 0 0 192.168.1.10:139 192.168.1.11:12345 ESTABLISHED 1234/smbd

Token Passing

Em redes de acesso compartilhado, um token circula entre dispositivos, permitindo transmissão apenas ao portador, evitando colisões:

  • Token Ring (IEEE 802.5): Anel lógico, 4/16 Mbps, token circula em ordem fixa.
  • FDDI: Anel duplo, 100 Mbps, suporta falhas com redundância.
  • Protocolos de Reserva: Bit-map (slots de tempo) e countdown (prioridade) gerenciam acesso.

Topologia: Token Ring

token_ring_topology.txt
[Host1]----[Host2]
| |
[Host4]----[Host3]
! Token circula: Host1 → Host2 → Host3 → Host4 → Host1

Atividade Prática (10 min)

1. Execute netstat -tunap | grep 139 em um sistema com compartilhamento de arquivos (e.g., SMB) para observar uma sessão NetBIOS full-duplex.
2. Em Packet Tracer, configure uma topologia Token Ring com 4 hosts (IEEE 802.5).
3. Simule tráfego (e.g., ping entre hosts) e observe a ordem de transmissão.
Entregáveis: Screenshot do netstat mostrando sessão NetBIOS e captura do Packet Tracer mostrando tráfego Token Ring.

Leitura: IEEE 802.5 (Token Ring), ANSI X3.139 (FDDI), ISO/IEC 7498-1 (OSI Model), RFC 793 (TCP); Kurose §3; Tanenbaum §6.

Estabelecimento & Encerramento de Sessão link

Three-Way Handshake, Four-Way Handshake & Renegociação

Introdução

A Camada de Sessão (Slide 1) gerencia o estabelecimento e encerramento de sessões entre aplicações, garantindo comunicação confiável. Protocolos como TCP (Aula 9 Slide 3) e PPTP (Slide 4) utilizam handshakes para iniciar sessões e processos de encerramento para finalizá-las. Esta seção explora o three-way handshake (TCP), o four-way handshake, e a renegociação de parâmetros para ajustes dinâmicos (e.g., Window Scale, PPP LCP).

Three-Way Handshake (Estabelecimento)

O three-way handshake do TCP estabelece uma sessão confiável entre cliente e servidor (RFC 793):

  1. SYN: Cliente envia um segmento com flag SYN (Synchronize) e um número de sequência inicial (Seq).
  2. SYN-ACK: Servidor responde com SYN e ACK (Acknowledgment), confirmando o SYN do cliente (Ack=Seq+1) e propondo seu próprio Seq.
  3. ACK: Cliente envia ACK, confirmando o SYN do servidor (Ack=Seq+1). A sessão entra no estado ESTABLISHED.
tcp_handshake.txt
10:00:00 IP 192.168.1.10:12345 → 192.168.1.11:80 TCP [SYN] Seq=100
10:00:00 IP 192.168.1.11:80 → 192.168.1.10:12345 TCP [SYN, ACK] Seq=300 Ack=101
10:00:01 IP 192.168.1.10:12345 → 192.168.1.11:80 TCP [ACK] Seq=101 Ack=301

Four-Way Handshake (Encerramento)

O four-way handshake do TCP encerra a sessão, permitindo que ambos os lados finalizem a transmissão (Slide 4):

  1. FIN: Uma extremidade (e.g., cliente) envia FIN para indicar que terminou de enviar dados.
  2. ACK do FIN: A outra extremidade (e.g., servidor) confirma com ACK.
  3. FIN Reverso: O servidor envia seu próprio FIN quando termina de enviar dados.
  4. ACK Final: O cliente confirma o FIN do servidor, encerrando a sessão (estado CLOSED).
tcp_teardown.txt
10:05:00 IP 192.168.1.10:12345 → 192.168.1.11:80 TCP [FIN] Seq=500
10:05:00 IP 192.168.1.11:80 → 192.168.1.10:12345 TCP [ACK] Seq=800 Ack=501
10:05:01 IP 192.168.1.11:80 → 192.168.1.10:12345 TCP [FIN] Seq=800
10:05:01 IP 192.168.1.10:12345 → 192.168.1.11:80 TCP [ACK] Seq=501 Ack=801

Renegociação de Parâmetros

Durante o handshake, parâmetros como Window Scale, MSS, e autenticação podem ser negociados para otimizar a sessão (Slide 4). Em túneis PPTP, o protocolo LCP (Link Control Protocol) negocia compressão e autenticação antes do IPCP.

Parâmetro Descrição Protocolo Exemplo
Window Scale Fator de escala para aumentar a janela TCP (RFC 7323). TCP Shift de 0–14 bits
MSS Tamanho máximo do segmento TCP (Aula 9 Slide 3). TCP 1460 bytes (Ethernet)
SACK Selective Acknowledgment para recuperação seletiva (RFC 2018). TCP Retransmissão parcial
PPP LCP Negocia compressão e autenticação (e.g., PAP, CHAP) em PPTP (Slide 4). PPTP VPN setup

Topologia: Sessão TCP

tcp_session_topology.txt
[Client: 192.168.1.10:12345]---[Router]---[Server: 192.168.1.11:80]
! Sessão TCP (e.g., HTTP) com three-way handshake e four-way handshake

Atividade Prática (10 min)

Capture e analise um handshake TCP e seu encerramento usando Wireshark ou tcpdump:

  1. Execute tcpdump -i any tcp port 80 ou use Wireshark com filtro tcp.port == 80.
  2. Acesse um site HTTP (e.g., http://example.com) para gerar tráfego TCP.
  3. Identifique o three-way handshake (SYN, SYN-ACK, ACK) e o four-way handshake (FIN, ACK).
  4. Observe opções negociadas (e.g., Window Scale, MSS) no Wireshark (detalhes do pacote).
  5. Alternativa: Simule uma conexão TCP em Packet Tracer com um cliente e servidor HTTP.

Entregáveis: Screenshot da captura Wireshark ou tcpdump mostrando o three-way handshake, four-way handshake, e pelo menos uma opção negociada (e.g., MSS).

Leitura: RFC 793 (TCP), RFC 7323 (Window Scale), RFC 2018 (SACK), RFC 2637 (PPTP), ISO/IEC 7498-1 (OSI Model); Kurose §3; Tanenbaum §6.

Sincronização & Protocolos sync

Checkpointing e Serviços

Introdução

A Camada de Sessão (Slide 1) usa sincronização e protocolos para gerenciar diálogos confiáveis, suportando longas transferências e recuperação de falhas. Protocolos como NetBIOS e PPTP utilizam TCP/UDP (Aula 9 Slide 3) como transporte.

Sincronização & Checkpointing

Checkpoints são marcadores periódicos que permitem retomar transferências (e.g., arquivos, bancos de dados) após falhas, sem reiniciar. Exemplo: NFS insere checkpoints em transferências de arquivos para recuperação (Slide 1).

Protocolos de Sessão

Protocolo Função Porta Exemplo
NetBIOS Gerencia sessões de compartilhamento (full-duplex, TCP). 137–139 Windows file sharing
PPTP Tunelamento L2 para VPNs (Slide 3). 1723 VPN corporativa
RPC Chamadas remotas cliente-servidor. 135 Microsoft Exchange
SMB/CIFS Compartilhamento de arquivos/impressoras (baseado em NetBIOS). 445 Windows Samba
NFS Compartilhamento de arquivos Unix com checkpoints. 2049 Linux file server
Sockets SOCK_STREAM (TCP) vs. SOCK_DGRAM (UDP, Aula 9 Slide 2). Variável Programação de rede
WebSocket HTTP Upgrade para canal full-duplex (port 80/443). 80, 443 Chat em tempo real

Exemplo Prático: Sessões Ativas

Observe sessões NetBIOS e PPTP com netstat -tunap (Aula 9 Slide 6):

netstat_sessions.txt
$ netstat -tunap | grep -E '139|1723'
tcp 0 0 192.168.1.10:139 0.0.0.0:* LISTEN 1234/smbd
tcp 0 0 192.168.1.10:1723 192.168.1.11:12345 ESTABLISHED 5678/pptpd

Exemplo Prático: WebSocket Handshake

Capture WebSocket com Wireshark (filtro tcp.port == 80 and http.upgrade):

wireshark_websocket.txt
HTTP 192.168.1.10:12345 → 203.0.113.2:80 GET /chat HTTP/1.1
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
HTTP 203.0.113.2:80 → 192.168.1.10:12345 HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=

Topologia: Sessão NetBIOS

netbios_topology.txt
[Host1: 192.168.1.10:139]---[Router]---[Host2: 192.168.1.11:139]
! Sessão NetBIOS (TCP) para compartilhamento de arquivos

Atividade Prática (10 min)

1. Execute netstat -tunap | grep -E '139|1723' para listar sessões NetBIOS/PPTP.
2. Use Wireshark (filtro tcp.port == 80 and http.upgrade) para capturar um handshake WebSocket (e.g., acesse um site com WebSocket, como wss://echo.websocket.org).
3. Identifique portas e processos (NetBIOS, PPTP) e o handshake WebSocket.
Entregáveis: Screenshot do netstat e captura Wireshark do handshake WebSocket.

Leitura: RFC 1001/1002 (NetBIOS), RFC 2637 (PPTP), RFC 3530 (NFS), RFC 6455 (WebSocket), ISO/IEC 7498-1 (OSI Model); Kurose §3; Tanenbaum §6.

Atividade Prática assignment

Explorando Sessões

Introdução

Esta atividade aplica conceitos da Camada de Sessão (Slides 1–4) para explorar o estabelecimento, manutenção e encerramento de sessões (Slide 3) usando protocolos como PPTP, SSH, e RPC (Slide 4). Ferramentas como tcpdump, Wireshark, e Python (Aula 9 Slide 6) serão usadas para análise.

Atividade 1: Captura de Túneis PPTP/SSH (10 min)

Configure um túnel PPTP (port 1723) ou SSH (port 22) e capture o tráfego para analisar o estabelecimento e encerramento da sessão.

  1. Configure um túnel PPTP (e.g., servidor VPN) ou SSH (e.g., ssh user@192.168.1.11).
  2. Capture com tcpdump -i any tcp port 1723 (PPTP) ou tcp port 22 (SSH).
  3. Alternativa: Use Wireshark com filtros tcp.port == 1723 ou tcp.port == 22.
  4. Simule em Packet Tracer se túneis reais não estiverem disponíveis: configure um servidor PPTP/SSH e cliente.
  5. Identifique o handshake (Slide 3) e encerramento (e.g., TCP FIN/ACK).
tcpdump_pptp.txt
$ tcpdump -i any tcp port 1723
10:00:01 IP 192.168.1.10.12345 > 192.168.1.11.1723: Flags [S], seq 123456789
10:00:01 IP 192.168.1.11.1723 > 192.168.1.10.12345: Flags [S.], seq 987654321, ack 123456790
10:00:02 IP 192.168.1.10.12345 > 192.168.1.11.1723: Flags [.], ack 1
wireshark_ssh.txt
TCP 192.168.1.10:12345 → 192.168.1.11:22 [SYN] Seq=0 Win=65535
TCP 192.168.1.11:22 → 192.168.1.10:12345 [SYN, ACK] Seq=0 Ack=1 Win=64240
TCP 192.168.1.10:12345 → 192.168.1.11:22 [ACK] Seq=1 Ack=1 Win=65535
SSH Protocol: Client: SSH-2.0-OpenSSH_8.9

Atividade 2: Mini-RPC com Python (10 min)

Implemente um servidor RPC simples usando xmlrpc.server e um cliente para testar chamadas remotas, observando a sequência de chamadas.

  1. Execute o servidor RPC (código abaixo) em uma máquina (e.g., 192.168.1.10).
  2. Execute o cliente RPC para chamar funções remotas (e.g., soma).
  3. Habilite logging no servidor (logging.basicConfig) para ver chamadas.
  4. Capture com Wireshark (filtro tcp.port == 8000) para analisar a sessão RPC.
  5. Identifique a sequência de chamadas e sessão TCP (Slide 3).
rpc_server.py
import xmlrpc.server
import logging
logging.basicConfig(level=logging.INFO)
class Calculator:
    def add(self, x, y):
        logging.info(f"Chamando add({x}, {y})")
        return x + y
server = xmlrpc.server.SimpleXMLRPCServer(("0.0.0.0", 8000))
server.register_instance(Calculator())
print("Servidor RPC rodando em 0.0.0.0:8000...")
server.serve_forever()
rpc_client.py
import xmlrpc.client
server = xmlrpc.client.ServerProxy("http://192.168.1.10:8000")
result = server.add(5, 3)
print(f"Resultado: {result}") # Saída: Resultado: 8
rpc_log.txt
INFO:root:Chamando add(5, 3)
INFO:root:192.168.1.11:12345 - "POST / HTTP/1.1" 200 -

Topologia: Túnel PPTP/SSH

tunnel_topology.txt
[Client: 192.168.1.10:12345]---[Router]---[Server: 192.168.1.11:1723/22]
! Túnel PPTP (port 1723) ou SSH (port 22) com TCP

Entregáveis

  • Screenshot do tcpdump ou Wireshark mostrando handshake e encerramento (PPTP/SSH).
  • Screenshot do log do servidor RPC (rpc_log.txt) e captura Wireshark do tráfego RPC.
  • Breve descrição (100 palavras) do handshake observado e sequência de chamadas RPC.

Leitura: RFC 2637 (PPTP), RFC 4253 (SSH), RFC 1831 (RPC), RFC 1001/1002 (NetBIOS), RFC 6455 (WebSocket), ISO/IEC 7498-1 (OSI Model); Kurose §3; Tanenbaum §6.