Atua nas áreas de segurança em redes de computadores e sistemas operacionais UNIX.

Tamanho: px
Começar a partir da página:

Download "Atua nas áreas de segurança em redes de computadores e sistemas operacionais UNIX."

Transcrição

1 VoIP: Segurança da Informação em Telefonia Baseada em SIP Este tutorial apresenta uma revisão bibliográfica sucinta acerca dos principais protocolos empregados na telefonia VoIP e sobre questões de segurança relevantes para o serviço. São abordadas ameaças legadas das redes IP (que já existiam antes mesmo da tecnologia de voz sobre IP), bem como ameaças específicas à arquitetura SIP. André de Almeida Lima Tecnólogo em Redes de Computadores pelo Instituto Federal de Educação, Ciência e Tecnologia do Espírito Santo (IFES, 2008) e Especialista em Engenharia de Redes e Sistemas de Telecomunicações pelo Instituto Nacional de Telecomunicações (Inatel, 2011). Atualmente trabalha como Trainee Expert na operadora de Telecomunicações Oi, atuando no tratamento de falhas de banda larga e vídeo. Guilherme Rezende dos Santos Bacharel em Sistemas de Informação pela Faculdade de Administração e Informática (2008) e Especialista em Segurança da Informação pela Faculdade Impacta Tecnologia (2010). Atua nas áreas de segurança em redes de computadores e sistemas operacionais UNIX. Atualmente trabalha com Analista de Segurança da Informação na empresa Cipher Security S/A, e também é professor da disciplina Segurança em Redes de Telecomunicações do curso de Pós-graduação em Engenharia de Redes e Sistemas de Telecomunicações do Inatel. 1

2 Categoria: VoIP Nível: Introdutório Enfoque: Técnico Duração: 20 minutos Publicado em: 21/05/2012 2

3 VoIP: Introdução A telefonia VoIP promete, eventualmente, por fim a mais de um século de rede pública de telefonia comutada (RPTC), transferindo a inteligência do sistema para as bordas da rede, seguindo a tradição da Internet. Como aplicações IP são mais facilmente criadas e distribuídas, tem-se visto um proeminente crescimento do número de soluções VoIP, vindas de múltiplos fornecedores, sendo apresentadas ao mercado. Neste modelo, os próprios usuários terão um importante papel na definição, implementação e controle dos serviços de telefonia ( SICKER e LOOKBAUGH, 2004). Aliada a isto, a flexibilidade do SIP (Session Initiation Protocol), atualmente o protocolo mais usado para o estabelecimento de sessões VoIP, torna esta tecnologia cada vez mais viável e atrativa economicamente quando comparada com o serviço oferecido pela RPTC (SIÉCOLA, 2010). Em contrapartida, toda esta flexibilidade e disseminação também atrai a atenção dos hackers. O fato da tecnologia se proliferar não quer dizer que as infraestruturas para comunicação VoIP apresentadas pelos fornecedores tem se preocupado em blindar as ameaças que são inerentes ao SIP, tampouco as conhecidas brechas de segurança que flagelam as redes IP e praticamente qualquer serviço oferecido sobre elas. Diante disto, este tutorial se propõe a examinar quais sãos os principais protocolos que oferecem suporte à telefonia VoIP e enumera algumas das ameaças que devem ser levadas em consideração quando se pretende levantar uma infraestrutura baseada em SIP para esta tecnologia, preocupando-se inclusive com as ameaças legadas das já existentes redes IP. 3

4 VoIP: Protocolos da Telefonia VoIP Basicamente, dois tipos de protocolos são utilizados para viabilizar a comunicação VoIP: um protocolo para sinalização (com objetivo de estabelecer e gerenciar a chamada sessão) e outro para o transporte da voz por uma rede IP (SIÉCOLA, 2010). Diversos protocolos de sinalização foram concebidos por instituições padronizadoras, contudo a maior parte das aplicações utiliza o SIP (Session Initiation Protocol), descrito no RFC 3261, visto que este protocolo apresenta flexibilidade quanto à adição de novas features, além de facilidade de implementação e solução de problemas (DALGIC e FANG, 2011), por isto este trabalho aborda as situações onde este protocolo é utilizado para o estabelecimento de chamadas VoIP. O SIP é um protocolo textual baseado em requisições e respostas, bastante similar ao HTTP, que possui campos de cabeçalho e um corpo. No corpo de uma mensagem SIP é encapsulado algum protocolo de descrição de sessão responsável pela negociação dos tipos e formatos de mídias que serão trocadas entre as partes comunicantes, chamadas de User Agents (UA). O RFC 3261 não determina qual protocolo de descrição de sessão deve ser usado, portanto implementações SIP podem oferecer suporte a múltiplos protocolos de descrição de sessão. Entretanto, é mandatório o suporte ao SDP (Session Description Protocol), descrito no RFC 2327, o que faz deste o mais utilizado para negociação de mídias numa sessão SIP (JOHNSTON, 2009). Em se tratando do transporte da voz digitalizada por uma rede IP, o protocolo que ganhou o mercado foi o RTP (Real-time Transport Protocol), definido pelo RFC 3550, que não depende do tipo de protocolo de sinalização e descrição sendo utilizados. Também no mesmo RFC é definido o RTCP, um protocolo associado ao RTP que permite a troca de relatórios estatísticos entre os participantes de uma sessão a respeito da recepção de mídia. A seguir, é apresentado um tratamento de caráter introdutório sobre os protocolos SIP, SDP, RTP e RTCP. SIP Session Initiation Protocol O SIP é um protocolo da camada de sessão do modelo OSI (camada de aplicação do modelo TCP/IP) que pode estabelecer, modificar e terminar sessões multimídias - onde sessão é considerada uma troca de dados entre uma associação de UAs - como uma chamada telefônica pela Internet (ROSENBERG, SCHULZRINNE e CAMARILLO et al, 2011). Nesta sessão serão introduzidas as funções básicas do protocolo SIP que tem participação fundamental na viabilização de VoIP: localização de um sistema final, sinalização da intensão de se comunicar, negociação dos parâmetros e estabelecimento de uma sessão e término de uma sessão previamente estabelecida (ROSENBERG, SCHULZRINNE e CAMARILLO et al, 2011). A Figura1 exibe uma típica troca de mensagens SIP entre dois usuários que desejam se comunicar, André e Guilherme. Para referência no texto, cada mensagem foi identificada com uma letra M e um número entre parênteses. O processo começa com o usuário André, no domínio lima.com desejando realizar uma chamada ao usuário Guilherme, no domínio santos.com. Os usuários são identificados fora de seu domínio pela sua identidade SIP, um tipo de URI (Uniform Resource Identifier) similar a um endereço de . Para o caso presente, as identidades SIP poderiam ser: e Portanto, o usuário André constrói uma solicitação SIP INVITE (a mensagem M1) conforme a seguir: 4

5 INVITE SIP/2.0 Via:SIP/2.0/UDP pc145.lima.com:5060;branch=z9hg4bkfw19b Max-Forwards: 70 To: Guilherme Santos From: André Lima Call-ID: jlaks984309k CSeq: 1 INVITE Contact: Content-Type: application/sdp Content-Length: 158 (Conteúdo SDP não exibido) Figura 1: Estabelecimento de uma sessão SIP O cabeçalho da mensagem SIP vai da primeira linha até o campo Content-Length. A primeira linha da mensagem de solicitação exibe o método (INVITE), a identidade SIP do destino e a versão do protocolo (SIP/2.0). A seguir vem o campo Via, que exibe o endereço e a porta para o qual o usuário André espera receber a resposta de sua solicitação. Neste caso, pc145.lima.com é um nome que pode ser traduzido por DNS para o endereço IP e a porta 5060 é a porta padrão do SIP. Ainda no campo Via, há o parâmetro branch que serve como um identificador de transação. Desta forma, respostas referentes a esta transação podem ser identificadas, pois deverão possuir o mesmo valor no parâmetro branch. O campo Max-Forwards exibe a quantidade máxima de dispositivos SIP que a mensagem pode atravessar. A cada salto o campo é decrementado e quando chega a zero é descartado pelo dispositivo SIP que receber a mensagem. 5

6 O campo To carrega um nome de exibição (opcional) e a URI SIP que identifica o destinatário. O campo From carrega um nome de exibição (opcional) e a URI SIP que identifica o chamador. Observa-se também a presença do parâmetro tag, que é uma sequência de caracteres gerada aleatoriamente pela fonte. O próximo campo é o Call-ID, outra sequência de caracteres aleatória gerada pela fonte com o objetivo de identificar uma sessão SIP e, portanto, deve ser única no dispositivo SIP de origem. Na verdade, os User Agents de origem e destino, também chamados de User Agent Client (UAC) e User Agent Server (UAS), respectivamente, contribuem com a identificação da chamada cada um com mais uma sequência de caracteres aleatória, que são os parâmetros tag nos campos To e From. Esses três valores (Call-ID, tag do campo To e tag do campo From) identificarão completamente um diálogo aberto entre origem e destino. Na mensagem anterior não há parâmetro tag no campo To porque ele será adicionado quando o destinatário responder a solicitação INVITE. O campo seguinte é o CSeq (Command Sequence), que traz um valor inteiro e o nome do método. A cada nova solicitação enviada dentro de um diálogo o valor inteiro deve ser incrementado. No exemplo acima, o valor do campo foi iniciado com um (1), mas poderia ser qualquer inteiro maior que zero. É oportuno dizer que os campos Via, Max-Forwards, To, From, Call-ID e CSeq compõem o menor conjunto de campos obrigatórios no cabeçalho de qualquer solicitação SIP (JOHNSTON, 2009). O próximo campo na mensagem INVITE é o Contact, que contém o SIP URI do originador da chamada para o qual o User Agent de destino poderá encaminhar as transações seguintes diretamente (sem passar por dispositivos SIP intermediários). Os dois campos seguintes, Content-Type e Content-Length, informam o tipo de mensagem que está sendo carregada no corpo do protocolo SIP e qual o tamanho desta mensagem, respectivamente. Importa dizer que a mensagem INVITE aqui exibida não contém todos os campos possíveis para o método em questão. Uma lista completa dos campos possíveis numa mensagem INVITE, bem como em qualquer outra mensagem, está disponível em (JOHNSTON, 2009) e (ROSENBERG, SCHULZRINNE e CAMARILLO et al, 2011). Apesar de conhecer a identidade SIP do destinatário, o usuário André não conhece o seu endereço IP atual. Portanto, de alguma forma, a mensagem SIP deve ser roteada até o dispositivo onde está o UA de destino. Para isso, o UAC confia num servidor SIP chamado proxy. Servidores SIP serão abordados posteriormente, por hora importa que um SIP proxy é capaz de receber uma mensagem SIP em seu domínio local, determinar para qual domínio ela está endereçada, encaminhar essa mensagem para o SIP proxy no domínio de destino para que este, finalmente, o entregue ao UAS. Assim, como pode ser observado na Figura 1, a M1 é encaminhada ao servidor proxy do domínio lima.com. Através de uma pesquisa DNS SRV, o servidor proxy do domínio local obterá o endereço do servidor proxy do domínio remoto, santos.com. Contudo, antes de encaminhar uma mensagem SIP, um dispositivo SIP adiciona um campo Via com seu próprio endereço, adiciona um parâmetro received (que tem como valor o endereço IP do UAC) ao campo Via original da mensagem e decrementa o valor no campo Max-Forwards. Desta forma, M2 será: INVITE SIP/2.0 Via: SIP/2.0/UDP proxy.lima.com:5060;branch=z9hg4bk

7 Via: SIP/2.0/UDP pc145.lima.com:5060;branch=z9hg4bkfw19b;received= Max-Forwards: 69 (O resto não se altera) Adicionalmente, o servidor proxy do domínio lima.com também opta por retornar uma mensagem 100 Trying (M3) para o UAC, informando que recebeu a solicitação INVITE e tomou providências acerca dela. Isto impede que o UAC faça retransmissões da solicitação INVITE (ROSENBERG, SCHULZRINNE e CAMARILLO et al, 2011). Vale destacar que essa não é uma mensagem obrigatória. Ao receber M2, o servidor proxy do domínio santos.com adiciona mais um campo Via com seu endereço, adiciona um parâmetro received ao campo Via inserido pelo servidor proxy anterior, decrementa o valor no campo Max-Forwards e encaminha a mensagem ao UAS, Guilherme. Desta forma, M4 será: INVITE SIP/2.0 Via: SIP/2.0/UDP pr.santos.com:5060;branch=z9hg4bkhjasu8898ukf Via: SIP/2.0/UDP proxy.lima.com:5060;branch=z9hg4bk898.78;received= Via: SIP/2.0/UDP pc145.lima.com:5060;branch=z9hg4bkfw19b;received= Max-Forwards: 68 (O resto não se altera) Como anteriormente, o proxy do domínio santos.com envia uma mensagem 100 Trying para o proxy do domínio lima.com informando que está trabalhando na solicitação que lhe foi encaminhada. Contudo, essa mensagem não é repassada pelo proxy do domínio lima.com para o UAC, pois mensagens 100 Trying são do tipo hop-to-hop, isto é: nunca são repassadas. Ao receber a M4, o UAS opta por gerar uma mensagem 180 Ringing, M6, para informar que já recebeu a solicitação INVITE e está aguardando ação do usuário (por exemplo, atender ou rejeitar a ligação). Mensagens 180 Ringing também são opcionais, mas, ao contrário da 100 Trying, devem ser repassadas até retornar ao UAC. Como M4 chegou ao destinatário final com três campos Via, o User Agent sabe que a solicitação passou por dois dispositivos SIP intermediários e a rota de retorno para todas as mensagens dentro do contexto da transação INVITE devem passar pelos mesmos dispositivos SIP. Desta forma, M6 é encaminhada ao proxy do domínio santos.com conforme mostrado a seguir: SIP/ Ringing Via: SIP/2.0/UDP pr.santos.com:5060;branch=z9hg4bkhjasu8898ukf; received= Via: SIP/2.0/UDP proxy.lima.com:5060;branch=z9hg4bk898.78;received= Via: SIP/2.0/UDP pc145.lima.com:5060;branch=z9hg4bkfw19b;received= Max-Forwards: 70 To: Guilherme Santos From: André Lima Call-ID: jlaks984309k CSeq: 1 INVITE Contact: Content-Length: 0 Essa mensagem simplesmente copia os campos Via, To, From, Call-ID e CSeq da mensagem de requisição INVITE original, mas como agora não há corpo na mensagem, o campo Content-Type não existe e o valor de 7

8 Content-Length é zero. Além disto, o parâmetro tag foi adicionado ao campo To. É importante atentar para o fato que, ainda que esta mensagem tenha como origem o usuário Guilherme e destino o usuário André, os campos To e From não se alteram. Isto acontece porque estes campos identificam a direção da requisição e não a direção de uma mensagem específica (ROSENBERG, SCHULZRINNE e CAMARILLO et al, 2011). Deve-se notar ainda que o campo Contact agora contém o endereço para o qual o usuário André poderá enviar as próximas transações diretamente para o usuário Guilherme sem auxílio dos servidores proxy, a saber: um nome que pode ser traduzido por DNS para o endereço IP Ao receber M6, o proxy do domínio santos.com checa que o primeiro campo Via contém seu próprio endereço, então ele o remove e encaminha a mensagem para o endereço e porta informados no segundo campo Via (proxy.lima.com, 5060). Similarmente, o proxy do domínio lima.com, ao receber M7 observa que o endereço no primeiro campo Via é o seu próprio endereço. Logo, ele o remove e, finalmente, encaminha a mensagem ao originador, o UAC. Assim, M8 é: SIP/ Ringing Via: SIP/2.0/UDP pc145.lima.com:5060;branch=z9hg4bkfw19b;received= Max-Forwards: 68 To: Guilherme Santos From: André Lima Call-ID: jlaks984309k CSeq: 1 INVITE Contact: Content-Length: 0 No exemplo presente o usuário Guilherme decide atender a ligação, portanto uma mensagem 200 OK é enviada. Essa resposta é construída da mesma forma que a 180 Ringing, contendo o mesmo parâmetro tag no campo To e o mesmo endereço de contato direto no campo Contact. Uma resposta 200 OK também indica que os tipos e formatos de mídias negociadas pelo SDP foram aceitos, por isso no corpo da mensagem SIP é levada uma mensagem SDP carregando essa informação. Como a mensagem 200 OK ainda faz parte da transação INVITE, o caminho de retorno deve passar pelos mesmos dispositivos SIP como aconteceu com a mensagem 180 Ringing. Desta forma, M9 é: SIP/ OK Via: SIP/2.0/UDP pr.santos.com:5060;branch=z9hg4bkhjasu8898ukf; received= Via: SIP/2.0/UDP proxy.lima.com:5060;branch=z9hg4bk898.78;received= Via: SIP/2.0/UDP pc145.lima.com:5060;branch=z9hg4bkfw19b;received= Max-Forwards: 70 To: Guilherme Santos From: André Lima Call-ID: jlaks984309k CSeq: 1 INVITE Contact: 8

9 Content-Type: application/sdp Content-Length: 158 (Conteúdo SDP não exibido) Como anteriormente, os servidores proxy no caminho verificam seus endereços no primeiro campo Via da mensagem que recebem, removem este campo, decrementam o valor no campo Max-Forwards e repassam a mensagem para o próximo endereço e porta do campo Via abaixo. Neste ponto, é interessante destacar que respostas à requisições SIP são sempre compostas por um número de três dígitos seguido por uma frase informativa, como em: 100 Trying, 180 Ringing, 200 OK. Estas respostas são classificadas de acordo com o primeiro dígito de seu número. Os dois dígitos seguintes servem como um subtipo. A Tabela I, extraída de (SIÉCOLA, 2010), mostra as respostas SIP com suas classificações. Tabela 1: Classes de respostas SIP RESPOSTA CLASSE 1xx 2xx 3xx 4xx 5xx 6xx Informativas Sucesso Redirecionamento Falha na Requisição Falha no Servidor Falha Global O último passo para estabelecer a sessão é o UAC confirmar o recebimento da resposta 200 OK, permitindo então o início do tráfego de mídia usando outro protocolo (o RTP, por exemplo). Essa confirmação é feita com uma requisição ACK, que é a mensagem M12: ACK SIP/2.0 Via: SIP/2.0/UDP pc145.lima.com:5060;branch=z9hg4bkf992uij Max-Forwards: 70 To: Guilherme Santos From: André Lima Call-ID: jlaks984309k CSeq: 2 ACK Content-Length: 0 Inicialmente deve-se observar que a primeira linha da requisição agora conta com o endereço que o UAS previamente informou como sendo seu endereço de contato direto. Desta forma, o usuário André pode enviar o ACK diretamente para o usuário Guilherme sem intervenção dos servidores proxy. O campo Contact também foi removido, uma vez que o UAS já foi informado do endereço de contato direto do UAC. Nota-se ainda que o parâmetro branch do campo Via é diferente dos anteriores, uma vez que esta mensagem ACK é considerada uma transação diferente da INVITE. Por outro lado, os parâmetros tag dos campos To e From, bem como o Call-ID não se alteraram porque esta mensagem ainda faz parte do mesmo diálogo que as mensagens anteriores. Agora, a troca de informações da mídia negociada pode então finalmente 9

10 acontecer. Após o tráfego de mídia, o usuário Guilherme deseja encerrar a sessão e para isso envia uma Requisição BYE para o usuário André, a mensagem M13: BYE SIP/2.0 Via: SIP/2.0/UDP soft667.santos.com:5060;branch=z9hg4bk098jukj Max-Forwards: 70 To: André Lima From: Guilherme Santos Call-ID: jlaks984309k CSeq: 3 BYE Content-Length: 0 Novamente, o parâmetro branch é diferente daquele nas requisições INVITE e ACK porque o BYE é uma transação diferente, contudo os parâmetros tag e o Call-ID permanecem os mesmos já que ainda trata-se do mesmo diálogo. Contudo, como agora esta é uma requisição direcionada ao usuário André, os campos To e From estão trocados em relação às mensagens anteriores. Portanto, neste momento o usuário Guilherme age como um UAC e o usuário André como um UAS. Isto posto, infere-se que toda implementação SIP deve contar com um módulo cliente e um módulo servidor, visto que estes papéis são dinâmicos dentro de um mesmo diálogo. Para finalizar a sessão, o UAS (usuário André) agora responde a solicitação BYE com uma mensagem 200 OK, M14: SIP/ OK Via: SIP/2.0/UDP soft667.santos.com:5060;branch=z9hg4bkfw19b; received= Max-Forwards: 70 To: André Lima From: Guilherme Call-ID: jlaks984309k CSeq: 2893 BYE Content-Length: 0 Com isso, completa-se o ciclo SIP de localização de usuário, sinalização, estabelecimento e encerramento de um diálogo. Contudo, não discutido aqui é como os servidores proxy são capazes de localizar um usuário. Na verdade há diferentes mecanismos para cumprir com esta finalidade, seja usando o protocolo SIP ou outros protocolos. Servidores SIP Servidores SIP são aplicações que recebem solicitações SIP, executam alguma operação com ela e devolvem uma resposta ao dispositivo que a solicitou. Há três tipos de servidores SIP: servidor de proxy, servidor de redirecionamento e servidor de registro. Como são entidades lógicas, mais de um servidor SIP pode estar hospedado num mesmo dispositivo físico (YOSHIOKA, 2003). 10

11 Servidor Proxy A sessão 2.1 introduziu o servidor proxy como um facilitador de troca de mensagens SIP, sendo o elemento responsável pela localização do User Agent alvo da requisição. É importante esclarecer que um proxy diferencia-se de um User Agent em três pontos chave (ROSENBERG, SCHULZRINNE e CAMARILLO et al, 2011): Não formula requisições SIP, apenas responde e trabalha em solicitações de User Agents (os métodos CANCEL e ACK são exceções); Não é multimídia, isto é, não produz fluxos de mídia (exceto o próprio texto contido nas mensagens SIP); Não analisa o corpo de uma mensagem SIP, trabalhando exclusivamente nos campos de cabeçalho. Na configuração exibida na Figura 1, conhecida como Trapezoide SIP, cada User Agent é configurado previamente para saber qual é o proxy padrão no seu domínio. Toda mensagem SIP será encaminhada para este servidor quando o UAC não souber qual endereço de contato direto do UAS com quem pretende estabelecer uma sessão. Quando recebe uma requisição SIP, o proxy analisa para qual domínio a mensagem está destinada e obtém o endereço do servidor de proxy do domínio de destino, tipicamente através de uma pesquisa DNS SRV. Alternativamente, por motivos que estão fora do escopo da presente discussão, um proxy também pode rejeitar uma solicitação. Neste caso é retornada uma mensagem 406 Not Acceptable ao UA. Dentro do seu domínio, um servidor proxy tem acesso a uma abstração chamada de serviço de localização, tipicamente um banco de dados populado pelo servidor de registros (Registrar tratado posteriormente) que armazena a relação entre identidades SIP externas e o endereço atual do dispositivo onde o UA está sendo executado. É desta forma que os servidores proxy resolvem o problema de localização do alvo de uma requisição SIP. Ademais, um servidor proxy pode operar com estado (stateful)ou sem estado (stateless). No modo stateful, o proxy mantém um contador de tempo e registros para todas as requisições e respostas que recebe e repassa e usa essas informações no processamento futuro de mensagens pertencentes a um mesmo diálogo. No modo stateless não há contadores de tempo nem registros das requisições e respostas repassadas anteriormente, desta forma não há retransmissões de mensagens perdidas e nenhum tipo de processamento para mensagens futuras pertencentes a um mesmo diálogo (YOSHIOKA, 2003). Servidor de Redirecionamento Tal como um servidor proxy, um servidor de redirecionamento também auxilia no processo de localização do destinatário de uma requisição SIP, mas não encaminha requisições SIP. Em vez disto, apenas responde ao UA de origem qual é o endereço de contato para atingir o UA de destino, ou um endereço de próximo salto para um servidor proxy ou outro servidor de redirecionamento mais próximo, sem se envolver de fato na comunicação (YOSHIOKA, 2003). Detalhamentos sobre as mensagens trocadas entre um UA e um servidor de redirecionamento podem ser obtidos em (JOHNSTON, 2009). Servidor de Registro 11

12 Um servidor de registro, também chamado Registrar, aceita requisições SIP REGISTER. Qualquer outra solicitação recebe como resposta um 501 Not Implemented (ROSENBERG, SCHULZRINNE e CAMARILLO et al, 2011). A Figura 2 mostra uma situação em que o usuário Guilherme solicita ao servidor de registro em seu domínio que crie um vínculo entre sua identidade SIP externa (também chamada de Address-of-Record, ou simplesmente AOR) e seu endereço atual. A solicitação REGISTER é: Figura 2: Exemplo de Registro SIP REGISTER sip:reg.santos.com SIP/2.0 Via: SIP/2.0/UDP :5060;branch=z9hG4bK019jesd Max-Forwards: 70 To: Guilherme Santos From: Guilherme Santos Call-ID: CSeq: 1 REGISTER Contact: Content-Length: 0 O campo To traz o AOR que para o qual o UA deseja registrar o seu endereço de contato atual. O campo Contact traz o endereço de contato atual que deve ser associado ao AOR. Os campos To e From usualmente trazem o mesmo endereço, exceto quando há um terceiro dispositivo que faz o registro em nome de outro UA (JOHNSTON, 2009). Ao receber a requisição REGISTER, o servidor de registro atualiza o banco de dados usado pelos servidores proxy e de redirecionamento para localização de usuário e responde com uma mensagem 200 OK informando que o registro foi feito com sucesso da seguinte forma: SIP/ OK Via: SIP/2.0/UDP :5060;branch=z9hG4bK019jesd Max-Forwards: 70 To: Guilherme Santos From: Guilherme Santos Call-ID: CSeq: 1 REGISTER 12

13 Contact: Content-Length: 0 O campo Contact confirma o endereço de contato que foi registrado para o AOR e traz um parâmetro expires que informa a quantidade de tempo em segundos para a qual o registro permanecerá válido. Se o UA desejar que o seu registro continue válido por mais tempo, basta enviar outra requisição REGISTER ao servidor de registro antes que o tempo expire. Analogamente a um sistema de telefonia celular, o registro tipicamente é feito enquanto o dispositivo SIP está iniciando. A forma como o UA toma conhecimento do endereço do servidor de registro está descrita na seção de (ROSENBERG, SCHULZRINNE e CAMARILLO et al, 2011). SDP Session Description Protocol Para garantir o processo de negociação das mídias a serem trocadas numa sessão, o SIP encapsula outro protocolo, comumente o SDP. O SDP, definido inicialmente em no RFC 2327 (HANDLEY e JACOBSON, 2011), teve como propósito original descrever sessões multicast estabelecidas sobre o backbone multicast da Internet, o MBONE e, portanto, vários de seus campos tem uso limitado (ou nenhum uso) para as sessões unicast estabelecidas atualmente com o SIP, mas foram mantidos na nova definição do protocolo, RFC 4566 (HANDLEY, JACOBSON e PERKINS, 2011), para garantir a compatibilidade. De acordo com (JOHNSTON, 2009), as principais informações carregadas numa mensagem SDP sobre a sessão de mídia são: endereço IP (IPv4 ou IPv6) ou nome de host, perfil RTP (tipicamente RTP/AVP ), número da porta que será usada para troca de fluxo de mídia, tipo de mídia a ser trocada (vídeo, áudio, texto e etc.) e esquema de codificação de mídia. Similarmente ao SIP, o SDP é um protocolo textual cujas mensagens são compostas por campos. Cada linha da mensagem é um campo e começa com uma letra minúscula. Nem todos os campos são obrigatórios, mas, se presentes, devem aparecer na ordem especificada na Tabela II, retirada de (SIÉCOLA, 2010). Tabela 2: Campos SDP CAMPO NOME OBRIGATÓRIO v = Versão do protocolo Sim o = Criador e identificador da sessão (origem) Sim s = Nome da sessão Sim i = u = Informação sobre a sessão Uniforme Resource Identifier URI Não Não e = Endereço de Não p = Número de telefone Não 13

14 c = b = t = Informação sobre a conexão Informação sobre largura de banda Tempo para início e término da sessão Sim Não Sim r = Número de repetições Não z = k = a = m = Correções de fuso horário Chave de criptografia (não utilizado mais) Linha de atributos da sessão Informações sobre a mídia Não Não Não Não a = Atributos da mídia Não Como detalhado em (ROSENBERG e SCHULZRINE, 2011) e amplamente exemplificado em (JOHNSTON e SPARKS, 2011), o SDP é baseado no modelo de oferta e resposta (Offer/Answer Model). Resumidamente, neste modelo um participante da sessão (o UAC) gera uma mensagem SDP (a oferta) informando quais mídias (e seus respectivos esquemas de codificação) gostaria de trocar, bem como seu endereço IP e porta onde gostaria de receber o fluxo de mídia. O outro participante (UAS) responde com uma mensagem SDP (a resposta) que tem um fluxo de mídia correspondente para cada fluxo de mídia descrito na oferta (isto é, para cada campo m = na oferta, deve haver um campo m = correspondente na resposta) indicando se o fluxo é aceitável ou não. Na resposta, também são informados o endereço IP e porta onde o UAS gostaria de receber o fluxo de mídia sendo negociado. Para exemplificar, abaixo segue a oferta SDP carregada em M1 da Figura 1: v = 0 o = André IN IP4 pc145.lima.com s = - c = IN IP t = 0 0 m = audio RTP/AVP a = rtpmap : 0 PCMU/8000 a = rtpmap : 6 DVI4/16000 a = rtpmap : 8 PCMA/8000 A primeira linha traz o campo versão. A versão atual e única do protocolo SDP é a zero (0). Portanto, uma mensagem SDP válida sempre começa com v = 0. O campo seguinte contém informações sobre o originador da mensagem. Esse campo identifica exclusivamente a sessão no contexto do SDP. O primeiro valor depois do = é o parâmetro username, que 14

15 tipicamente contém o nome de login ou host do originador, ou simplesmente -. A seguir estão os parâmetros session-id e version. Em (HANDLEY e JACOBSON, 2011) e (HANDLEY, JACOBSON e PERKINS, 2011) recomenda-se que estes parâmetros sejam um timestamp NTP (Network Time Protocol) ou um número aleatório qualquer. Logo após, está o parâmetro network-type que é sempre IN para Internet, seguido pelos parâmetros address-type ( IP4 ou IP6, para IPv4 e IPv6 respectivamente) e address, que informa o endereço IP do originador ou nome DNS do host. O campo seguinte é o nome de sessão. Este campo não tem utilidade para o estabelecimento de uma sessão unicast com o SIP, contudo trata-se de um campo obrigatório e como tal não pode deixar de ser incluído. Assim, (ROSENBERG e SCHULZRINE, 2011) recomenda que o campo seja preenchido com um espaço em branco ou com um traço ( - ). A linha seguinte traz informações sobre a conexão. Os parâmetros neste campo são network-type, address-type e address, que são preenchidos conforme já explicado no campo o =, exceto que aqui o parâmetro address deve conter o endereço IP do participante. A próxima linha indica o tempo para início e término da sessão. Contudo, conforme (ROSENBERG e SCHULZRINE, 2011), sessões unicast devem ser criadas e terminadas através de um protocolo de sinalização, como o SIP. Então os parâmetros start-time e stop-time neste campo devem ser preenchidos com 0. A mensagem SDP segue com o campo m =, que especifica qual o tipo de mídia deseja-se trocar. O primeiro parâmetro é media que, de acordo com (HANDLEY e JACOBSON, 2011) pode ser áudio, vídeo, text, application, message, image, ou control. Seguindo, há os parâmetros port, que identifica em qual porta o participante gostaria de receber o fluxo de mídia, e o transport que exibe o protocolo de camada de transporte ou o perfil RTP que será usado. O último parâmetro é o format-list que traz os esquemas de codificação para a mídia sendo negociada que estão disponíveis. As três linhas seguintes são atributos, campos opcionais e que podem ser usados para trazer mais informações sobre a mídia listada no campo m =. Neste caso, apenas trazem explicitamente informações sobre os esquemas de codificação listados no parâmetro format-list. Como determina o modelo Offer/Answer, o UAS agora deve construir uma resposta que aceite ou rejeite a oferta. No caso de rejeição, basta que o UAS formule uma mensagem SDP que tenha 0 (zero) no parâmetro port do campo m =. Esta é a forma que o SDP usa para comunicar ao outro participante que não tem interesse em trocar uma mídia oferecida (ROSENBERG e SCHULZRINE, 2011). No exemplo da Figura 1, o usuário Guilherme aceita a oferta. Neste caso, a resposta deve conter uma especificação de mídia coincidente com a oferta. Portanto, a mensagem SDP carregada em M9 pode ser: v = 0 o = Guilherme IN IP4 soft667.santos.com s = - c = IN IP t = 0 0 m = audio RTP/AVP 8 a = rtpmap : 8 PCMA/8000 Deve-se notar que o UAS selecionou apenas um dos três esquemas de codificação oferecidos, indicando que este deve ser o codec usado. 15

16 Os exemplos de mensagens SDP abordados aqui exploraram apenas os campos obrigatórios. Em (JOHNSTON, 2009) e (HANDLEY, JACOBSON e PERKINS, 2011) são oferecido detalhamentos sobre cada campo da Tabela II. Em (JOHNSTON e SPARKS, 2011) há numerosos exemplos de trocas de mensagens oferta/resposta. RTP Real-time Transport Protocol O RTP (Real-Time Transport Protocol), definido em (SCHULZRINNE, CASNER e FREDERICK, 2011), foi desenvolvido para tornar possível o transporte de pacotes contendo voz, vídeo ou outro tipo de mídia (informação) sobre uma rede IP. O protocolo permite a detecção de pacotes perdidos, variações no atraso (jitter) e chegada fora de ordem, contudonão garante qualidade de serviço para a mídia sendo transportada, isto é: pacotes RTP são tratados da mesma forma como qualquer outro pacote numa rede IP. Assim sendo, o que ocorre é um trabalho em conjunto com o RTCP (Real-time Transport Control Protocol), que é usado para monitorar estatísticas referentes às trocas de pacotes RTP (SCHULZRINNE, 2011). Sendo usado por aplicações cuja natureza é de tempo real, o transporte de pacotes RTP requer uma latência fim-a-fim tão baixa quanto possível através da Internet. Para isto, as aplicações tipicamente utilizam o protocolo UDP na camada de transporte, uma vez que não há tempo para detectar, sinalizar e retransmitir um pacote perdido. Diferentemente do SIP e do SDP, o RTP é um protocolo orientado a bit e possui um formato predefinido de cabeçalho composto por 12 bytes fixos, podendo ser estendido. O cabeçalho RTP é mostrado na Figura 3. Figura 3: Cabeçalho RTP O empacotamento da mídia codificada se dá simplesmente pela adição de um cabeçalho RTP a pequenas amostras do fluxo de bits codificado pelo codec negociado anteriormente com o SDP, formando então um pacote RTP. Na recepção, os pacotes RTP são tratados de acordo com seu cabeçalho, podendo até ser descartado caso seja um pacote contendo um fragmento de mídia que esteja atrasado demais para ser reproduzido, por exemplo. O cabeçalho RTP contém, de acordo com (JOHNSTON, 2009): Version (V): Traz a versão do protocolo sendo usado. A versão atual em uso do RTP é a 2. Padding (P): Se este bit estiver setado (igual a 1), significa que há bytes de preenchimento no final do pacote RTP para garantir que este tenha um tamanho fixo. O uso deste campo é mais comumente observado quando a mídia está criptografada. Extension (X): Se este bit estiver setado, há uma extensão ao final do cabeçalho. CSRC Count (CC): Contém o número de campos CSRC identifiers que há no cabeçalho. Este campo 16

17 é usado apenas quando mixers unem diferentes fluxos RTP formando um fluxo só. Marker (M): Esse bit é usado no nível de aplicação. Quando setado, significa que os dados deste pacote têm alguma relevância especial para aplicação em questão. Por exemplo, pode indicar o fim de um quadro completo em um vídeo, ou o início de um surto de fala numa conversa com supressão por silêncio. Payload Type (PT): O RTP foi desenvolvido para ser um protocolo de transporte de mídia genérico, isto é, permitir o transporte de mídias codificadas de diversas formas (com codecs distintos). Assim sendo, este campo é necessário para identificar com um número inteiro o codec previamente negociado com o SDP (e agora em uso na sessão). Em (SCHULZRINNE e CASNER, 2011) é detalhado o perfil RTP/AVP e pode ser encontradas tabelas que especificam os valores possíveis para o campo TP. Sequence Number: O valor nesse campo é incrementado a cada pacote RTP enviado e é usado para detectar pacotes perdidos ou que chegaram foram de ordem. Importa notar que apesar de detectar estes problemas o RTP não os trata, deixando essa função para o algoritmo do codec sendo utilizado. Timestamp: Este campo indica quando o primeiro byte do payload deste pacote foi amostrado, possibilitando ao receptor reproduzir a amostra no tempo adequado, pela introdução de atrasos para remoção de jitter, por exemplo. SSRC identifiers: O valor neste campo identifica a fonte (Synchronization Source) do pacote RTP. Para iniciar uma sessão, cada participante escolhe de forma aleatória um identificador, caso este seja igual ao de alguma outra fonte participando da sessão, o processo de escolha se repete até que todos os participantes tenham um identificador exclusivo. Esse campo introduz uma camada de segurança na comunicação RTP contra um ataque do tipo media spamming, onde uma terceira parte tenta invadir uma sessão de mídia já estabelecida. A menos que o atacante possa determinar o SSRC de uma das partes, qualquer pacote por ele enviado será descartado. CSRC identifiers: Pode haver nenhum ou até quinze campos deste num pacote RTP (haja visto que o tamanho do campo CC é de 4 bits). Só existirá se o pacote RTP estiver sendo enviado por um mixer, que junta pacotes RTP vindos de diferentes fontes. RTCP Real-time Transport Control Protocol Para que os participantes de uma sessão RTP tenham subsídios para medir a qualidade da comunicação, (SCHULZRINNE e CASNER, 2011) também define o RTCP (Real-Time Transport Control Protocol), que se baseia na transmissão periódica de pacotes de controle para todos os participantes da sessão. O RTCP desempenha, dentre outros, dois papéis que importa destacar. Primeiro, e principalmente, ele deve reunir informações estatísticas sobre aspectos de qualidade a respeito do recebimento da mídia e enviar tais informações à fonte (ou fontes, se na sessão houver vários participantes sessão multicast). Esses dados podem ser usados para realizar codificação adaptativa da mídia, por exemplo, além de detecção de falhas na transmissão. Em segundo lugar, o RTCP provê um identificador exclusivo para os sistemas finais da sessão RTP conhecido como CNAME. Essa é também a função do SSRC visto anteriormente, contudo o SSRC de um participante pode ser alterado caso seja detectado um conflito ou caso a aplicação comunicante reinicie. Nestes casos, o CNAME permite correlacionar um participante ao seu novo SSRC, evitando que todo o processo de estabelecimento da sessão seja executado novamente. A taxa com a qual um participante envia pacotes RTCP para os demais deve ser controlada, caso contrário a comunicação de mídia, que é a principal razão do RTP, ficaria comprometida. Sendo assim, o protocolo também provê mecanismos para que seja calculado um intervalo de envio entre pacotes RTCP, de tal forma 17

18 que a banda ocupada por eles seja suficientemente baixa. Contudo, a forma como isto é realizado está além do escopo deste trabalho e está detalhada na sessão 6.2 de (SCHULZRINNE e CASNER, 2011). São definidos cinco tipos de pacotes RTCP no RFC 3551, (SCHULZRINNE e CASNER, 2011): Sender report (SR): São os relatórios enviados por um participante ativo a todos os outros participantes ativos da sessão com estatísticas sobre a recepção e transmissão dos pacotes RTP no intervalo decorrido. Receiver report (RR): São relatórios para participantes ouvintes, isto é, que não enviam pacotes RTP. Source description (SDES): Usado para enviar o CNAME de um participante. Também pode conter informações adicionais como nome, , telefone, entre outras. End of participation (BYE): Enviado por um participante quando deseja deixar a sessão. Application specific (APP): Este tipo de pacote foi inserido na definição do protocolo para permitir extensões, isto é: um pacote APP levará informações específicas para a aplicação, para realizar uma ação não definida em (SCHULZRINNE e CASNER, 2011). Para diminuir o overhead de controle na comunicação, múltiplos pacotes RTCP são concatenados e enviados num único datagrama UDP. Cada pacote RTCP neste datagrama poderia ser processado individualmente sem que nenhuma restrição quanto a sua ordem ou combinação fosse imposta, contudo para que as funcionalidades do protocolo sejam garantidas, cada datagrama enviado deve conter no mínimo dois pacotes RTCP diferentes: um pacote de relatório (isto é um SR ou um RR) e um SDES com o CNAME para garantir que participantes recém chegados obtenham o CNAME dos demais participantes tão logo quanto possível. 18

19 VoIP: Segurança da Informação A informação já se tornou o ativo mais valioso das corporações e como tal, independente da forma como existe e é manipulada (em papel ou eletronicamente), sua proteção passou a ser mandatória. A norma ABNT NBR ISO/IEC define segurança da informação como a proteção da informação contra os diferentes tipos de ameaças a fim de minimizar o risco ao negócio, garantir sua continuidade e maximizar o retorno sobre os investimentos e as oportunidades de negócio. Existem três aspectos chave da segurança da informação comumente referidos como CIA Triad, ou Tríade CID: Confidencialidade, Integridade e Disponibilidade. A seguir estão expostos estes conceitos de maneira breve e posteriormente apresentam-se definições para alguns dos termos mais usados em se tratando de segurança da informação. Confidencialidade, Integridade e Disponibilidade A confidencialidade significa, conforme (BRAUMANN, CAVIN e SCHMID, 2011), que nenhum acesso à informação deverá ser garantido a sujeitos ou sistemas não autorizados, isto é, apenas aqueles com os direitos e privilégios necessários serão capazes de acessar a informação, esteja ela armazenada, em processamento ou em trânsito. A violação da confidencialidade pode ocorrer por modo intencional através de ataques, captura de tráfego, engenharia social, entre outros, bem como de forma não deliberada por imperícia ou negligência. No caso específico do VoIP, a confidencialidade preocupa-se com a não intercepção de uma conversa por uma terceira parte não autorizada, como nos ataques do tipo man-in-the-middle (MITM). A integridade é o aspecto que se preocupa com a confiança que pode ser depositada sobre uma informação obtida. Além disto, uma informação é dita íntegra se não sofreu nenhuma alteração entre os momentos de transmissão e recepção. Desta forma, em (BRAUMANN, CAVIN e SCHMID, 2011) são definidas duas categorias de integridade: integridade de fonte e integridade de dados. A integridade de fonte garante que uma informação realmente vem do remetente correto. A integridade dados se refere à confiabilidade da informação em si, isto é se a informação não foi comprometida (manipulada) em algum momento anterior à leitura pelo destinatário pretendido. Adicionalmente, (STEWART, TITTEL e CHAPPLE, 2008) atribui à integridade três objetivos: Impedir que sujeitos não autorizados realizem modificações na informação; Impedir que sujeitos autorizados realizem modificações não autorizadas; e Garantir a legitimidade, verificabilidade e consistência da informação, esteja ela armazenada, em trânsito ou em processamento. Em se tratando de VoIP, a integridade deve garantir que os pacotes de mídia cheguem ao destinatário sem sofrerem manipulações maliciosas. A disponibilidade é o aspecto da segurança da informação que diz que esta deve estar disponível para ser 19

20 acessada quando solicitada por um sujeito ou sistema legítimo (BRAUMANN, CAVIN e SCHMID, 2011). Isto requer que toda estrutura que permite acesso e transporte da informação deve ser protegida para que não seja degradada ou se torne indisponível. Com relação à disponibilidade, os tipos de ataque que representam maior ameaça são DoS (Denial of Service) e DDoS (Distributed Denial of Service), que visam danificar ou sobrecarregar sistemas. Especificamente para o VoIP, disponibilidade significa garantir que o serviço estará operante para os usuários, evitando qualquer efeito adverso resultante de um ataque do tipo negação de serviço, cujas consequências podem ser perda total ou parcial da comunicação (BRAUMANN, CAVIN e SCHMID, 2011). Definições Nesta sessão definem-se termos importantes mais comumente usados quando se discute sobre segurança da informação. De acordo com (STEWART, TITTEL e CHAPPLE, 2008), tem-se: Vulnerabilidade: Diz respeito às fraquezas de um sistema que podem ser exploradas maliciosamente. Podem estar relacionadas à software, hardware ou processos que apresentam falhas passíveis de serem exploradas de tal forma que comprometa o funcionamento de um sistema ou serviço. Ameaça: A forma como uma vulnerabilidade pode ser explorada determina uma ameaça. É chamada de agente de ameaça a entidade que tira proveito da vulnerabilidade, que pode ser uma pessoa (hacker), um processo ou um evento natural. Risco: É a probabilidade de um agente de ameaça se aproveitar de uma vulnerabilidade. Proteção: É um mecanismo usado para diminuir o risco, podendo ser em nível de software, hardware ou processo. Exemplos de proteção são: firewalls, isolamento de tráfego (VLAN), antivírus, entre outros. Incidente: Quando um agente de ameaça consegue explorar uma vulnerabilidade com sucesso, diz-se que houve um incidente de segurança. Neste caso, um ou mais princípios da tríada CID foram violados. 20

Protocolo de Sinalização SIP

Protocolo de Sinalização SIP Protocolos de Sinalização Protocolos com processamento distribuído e clientes/terminais inteligentes SIP - Session Initiation Protocol, desenvolvido pelo IETF para comunicação multimídia pela Internet

Leia mais

Introdução ao protocolo SIP*

Introdução ao protocolo SIP* Introdução ao protocolo SIP* 1. SIP (Session Initiation Protocol) Pode se dizer que SIP trata se de um protocolo de controle referente à camada de aplicações do Modelo de Referência OSI (Open System Interconnection),

Leia mais

SIP. Fabrício Tamusiunas. Comitê Gestor Internet BR

SIP. Fabrício Tamusiunas. Comitê Gestor Internet BR SIP Fabrício Tamusiunas Comitê Gestor Internet BR SIP RFC 3261 (antiga RFC 2543) Protocolo de controle que trabalha na camada de aplicação Permite que EndPoints encontrem outros EndPoints Gerencia sessões

Leia mais

11. VOZ SOBRE IP. VoIP. 25 Capitulo 11

11. VOZ SOBRE IP. VoIP. 25 Capitulo 11 11. VOZ SOBRE IP 11.1 INTRODUÇÃO Voz com qualidade de operador (carrier-grade voice) significa o seguinte: - Elevada disponibilidade. Um operador tem a rede disponível 99.999% do tempo (down-time< 5min.

Leia mais

SIP Session Initiation Protocol

SIP Session Initiation Protocol Session Initiation Protocol Carlos Gustavo A. da Rocha Session Initiation Protocol Desenvolvido pelo IETF RFC 2543 (Fev 1999) RFC 3261 (Jun 2002) É um protocolo de sinalização para sessões multimídia Negociação;

Leia mais

SIP Session Initiation Protocol

SIP Session Initiation Protocol SIP Session Initiation Protocol Pedro Silveira Pisa Redes de Computadores II 2008.2 Professores: Luís Henrique Maciel Kosmalski Costa Otto Carlos Muniz Bandeira Duarte Outubro de 2008 Índice Introdução

Leia mais

Aplicações Multimídia Distribuídas. Aplicações Multimídia Distribuídas. Introdução. Introdução. Videoconferência. deborams@telecom.uff.br H.

Aplicações Multimídia Distribuídas. Aplicações Multimídia Distribuídas. Introdução. Introdução. Videoconferência. deborams@telecom.uff.br H. Departamento de Engenharia de Telecomunicações - UFF Aplicações Multimídia Distribuídas Aplicações Multimídia Distribuídas Videoconferência Padrão H.323 - ITU Padrão - IETF Profa. Débora Christina Muchaluat

Leia mais

TP 318 Introdução às Redes Multimídia

TP 318 Introdução às Redes Multimídia Especialização em Telecomunicações TP 318 Introdução às Redes Multimídia Prof. Antônio M. Alberti Prof. José Marcos C. Brito 1 Tópicos Introdução RTP RSTP RTCP Arquitetura SIP Arquitetura OPT Referências

Leia mais

2 Fundamentação Conceitual

2 Fundamentação Conceitual Fundamentação Conceitual 19 2 Fundamentação Conceitual Este capítulo apresenta alguns conceitos importantes que são utilizados ao longo do trabalho. Primeiramente, é apresentado o Session Initiation Protocol

Leia mais

O Paradigma da Alta Disponibilidade e da Alta Confiabilidade do SIP

O Paradigma da Alta Disponibilidade e da Alta Confiabilidade do SIP O Paradigma da Alta Disponibilidade e da Alta Confiabilidade do SIP Visão Geral As redes convergentes trilharam um longo caminho desde a década de 1990. Novas aplicações, como as mensagens instantâneas,

Leia mais

VoIP. Redes de Longa Distância Prof. Walter Cunha

VoIP. Redes de Longa Distância Prof. Walter Cunha Redes de Longa Distância Prof. Walter Cunha As principais tecnologias de Voz sobre Rede de dados: Voz sobre Frame Relay Voz sobre ATM Voz sobre IP VoIP sobre MPLS VoIP consiste no uso das redes de dados

Leia mais

Protocolos Multimídia. Alunos: Roberto Schemid Rafael Mansano

Protocolos Multimídia. Alunos: Roberto Schemid Rafael Mansano Alunos: Roberto Schemid Rafael Mansano Exemplos de Aplicações Multimídia Mídia Armazenada: conteúdo gravado e armazenado play/pause/rewind/forward Streaming : vê o conteúdo enquanto baixa o arquivo evita

Leia mais

Instituto Superior Técnico. Projecto VoIP. Sistema IVVR

Instituto Superior Técnico. Projecto VoIP. Sistema IVVR Instituto Superior Técnico Projecto VoIP Sistema IVVR 68239 Rui Barradas 68477 Helton Miranda 68626 Ludijor Barros 72487 Bruna Gondin Introdução O objectivo deste projecto é desenvolver um sistema de Interactive

Leia mais

VoIPFix: Uma ferramenta para análise e detecção de falhas em sistemas de telefonia IP. Paulo César Siécola

VoIPFix: Uma ferramenta para análise e detecção de falhas em sistemas de telefonia IP. Paulo César Siécola VoIPFix: Uma ferramenta para análise e detecção de falhas em sistemas de telefonia IP Paulo César Siécola DISSERTAÇÃO APRESENTADA AO INSTITUTO DE MATEMÁTICA E ESTATÍSTICA DA UNIVERSIDADE DE SÃO PAULO PARA

Leia mais

A Família de Protocolos RTP

A Família de Protocolos RTP A Família de Protocolos RTP O que não é Não é um protocolo que trate de reserva de recursos ou de garantias de qualidade de serviço para serviços de tempo real. Não existem mecanismos que garantam a entrega

Leia mais

Capítulo 11 - Camada de Transporte TCP/IP e de Aplicação. Associação dos Instrutores NetAcademy - Julho de 2007 - Página

Capítulo 11 - Camada de Transporte TCP/IP e de Aplicação. Associação dos Instrutores NetAcademy - Julho de 2007 - Página Capítulo 11 - Camada de Transporte TCP/IP e de Aplicação 1 Introdução à Camada de Transporte Camada de Transporte: transporta e regula o fluxo de informações da origem até o destino, de forma confiável.

Leia mais

UNIVERSIDADE DO VALE DO RIO DOS SINOS UNISINOS CENTRO DE CIÊNCIAS EXATAS E TECNOLÓGICAS SUPERIOR DE TECNOLOGIA EM SEGURANÇA DA INFORMAÇÃO

UNIVERSIDADE DO VALE DO RIO DOS SINOS UNISINOS CENTRO DE CIÊNCIAS EXATAS E TECNOLÓGICAS SUPERIOR DE TECNOLOGIA EM SEGURANÇA DA INFORMAÇÃO UNIVERSIDADE DO VALE DO RIO DOS SINOS UNISINOS CENTRO DE CIÊNCIAS EXATAS E TECNOLÓGICAS SUPERIOR DE TECNOLOGIA EM SEGURANÇA DA INFORMAÇÃO GÜNTER FISCHBORN IMPLEMENTAÇÃO DE QOS E MONITORAMENTO DE TRÁFEGO

Leia mais

A Camada de Rede. A Camada de Rede

A Camada de Rede. A Camada de Rede Revisão Parte 5 2011 Modelo de Referência TCP/IP Camada de Aplicação Camada de Transporte Camada de Rede Camada de Enlace de Dados Camada de Física Funções Principais 1. Prestar serviços à Camada de Transporte.

Leia mais

Ameaças a Tecnologia VoIP. Frederico Madeira LPIC-1, CCNA fred@madeira.eng.br www.madeira.eng.br

Ameaças a Tecnologia VoIP. Frederico Madeira LPIC-1, CCNA fred@madeira.eng.br www.madeira.eng.br Ameaças a Tecnologia VoIP Frederico Madeira LPIC-1, CCNA fred@madeira.eng.br www.madeira.eng.br Agenda Introdução Infra-Estrutura VoIP Cenário Atual Protocolos SIP (Session Initiation Protocol) s Ameaças

Leia mais

Walter Cunha Tecnologia da Informação Redes WAN

Walter Cunha Tecnologia da Informação Redes WAN Walter Cunha Tecnologia da Informação Redes WAN Frame-Relay 1. (FCC/Pref. Santos 2005) O frame-relay é uma tecnologia de transmissão de dados que (A) opera no nível 3 do modelo OSI. (B) tem velocidade

Leia mais

Teia de alcance mundial (World Wide Web WWW) Web composta de

Teia de alcance mundial (World Wide Web WWW) Web composta de Web Teia de alcance mundial (World Wide Web WWW) Web composta de Agentes de usuário para a Web (browsers) Servidores Web Protocolo de transferência de hipertexto (HyperText Transfer Protocol HTTP) Web

Leia mais

2 O Protocolo SIP 2.1. Introdução Histórica

2 O Protocolo SIP 2.1. Introdução Histórica 2 O Protocolo SIP 2.1. Introdução Histórica O protocolo SIP teve suas origens em 1996 como um componente do conjunto de ferramentas e protocolos da Mbone, ou Multicast backbone [44]. A Mbone era uma rede

Leia mais

Capítulo 7 CAMADA DE TRANSPORTE

Capítulo 7 CAMADA DE TRANSPORTE Capítulo 7 CAMADA DE TRANSPORTE SERVIÇO SEM CONEXÃO E SERVIÇO ORIENTADO À CONEXÃO Serviço sem conexão Os pacotes são enviados de uma parte para outra sem necessidade de estabelecimento de conexão Os pacotes

Leia mais

Mobilidade na camada de Aplicação. Session Initiation Protocol (SIP)

Mobilidade na camada de Aplicação. Session Initiation Protocol (SIP) Mobilidade na camada de Aplicação usando o Session Initiation Protocol (SIP) Referências: RFC 3261, IETF SIP Working Group http://www.radvision.com www.cs.columbia.edu/hgs/ www.networkcomputing.com Introdução

Leia mais

Módulo 9 Conjunto de Protocolos TCP/IP e endereçamento IP

Módulo 9 Conjunto de Protocolos TCP/IP e endereçamento IP CCNA 1 Conceitos Básicos de Redes Módulo 9 Conjunto de Protocolos TCP/IP e endereçamento IP Introdução ao TCP/IP 2 Modelo TCP/IP O Departamento de Defesa dos Estados Unidos (DoD) desenvolveu o modelo de

Leia mais

Prof. Luís Rodolfo. Unidade III REDES DE COMPUTADORES E TELECOMUNICAÇÃO

Prof. Luís Rodolfo. Unidade III REDES DE COMPUTADORES E TELECOMUNICAÇÃO Prof. Luís Rodolfo Unidade III REDES DE COMPUTADORES E TELECOMUNICAÇÃO Redes de computadores e telecomunicação Objetivos da Unidade III Apresentar as camadas de Transporte (Nível 4) e Rede (Nível 3) do

Leia mais

3 Qualidade de serviço na Internet

3 Qualidade de serviço na Internet 3 Qualidade de serviço na Internet 25 3 Qualidade de serviço na Internet Além do aumento do tráfego gerado nos ambientes corporativos e na Internet, está havendo uma mudança nas características das aplicações

Leia mais

F n u d n a d ment n os o Vo V I o P Introdução

F n u d n a d ment n os o Vo V I o P Introdução Tecnologia em Redes de Computadores Fundamentos de VoIP Professor: André Sobral e-mail: alsobral@gmail.com Introdução VoIP (Voice over Internet Protocol) A tecnologia VoIP vem sendo largamente utilizada

Leia mais

2 Q-20102010. Prof. Roberto Jacobe (roberto.jacobe@gmail.com)

2 Q-20102010. Prof. Roberto Jacobe (roberto.jacobe@gmail.com) INF-207 Sistemas Computacionais para Processamento Multimídia Sistemas Multimídia Aula 04 Redes Multimídia 2 Q-20102010 Prof. Roberto Jacobe (roberto.jacobe@gmail.com) Prof. Marcelo Z. do Nascimento (marcelo.ufabc@gmail.com)

Leia mais

INTERNET = ARQUITETURA TCP/IP

INTERNET = ARQUITETURA TCP/IP Arquitetura TCP/IP Arquitetura TCP/IP INTERNET = ARQUITETURA TCP/IP gatewa y internet internet REDE REDE REDE REDE Arquitetura TCP/IP (Resumo) É útil conhecer os dois modelos de rede TCP/IP e OSI. Cada

Leia mais

Capítulo 9 - Conjunto de Protocolos TCP/IP e Endereçamento. Associação dos Instrutores NetAcademy - Julho de 2007 - Página

Capítulo 9 - Conjunto de Protocolos TCP/IP e Endereçamento. Associação dos Instrutores NetAcademy - Julho de 2007 - Página Capítulo 9 - Conjunto de Protocolos TCP/IP e Endereçamento IP 1 História e Futuro do TCP/IP O modelo de referência TCP/IP foi desenvolvido pelo Departamento de Defesa dos Estados Unidos (DoD). O DoD exigia

Leia mais

TCP/IP TCP UDP IP HTTP HTTPS FTP TFTP TELNET POP3 IMAP SMTP SNMP DHCP

TCP/IP TCP UDP IP HTTP HTTPS FTP TFTP TELNET POP3 IMAP SMTP SNMP DHCP TCP/IP TCP UDP IP HTTP HTTPS FTP TFTP TELNET POP3 IMAP SMTP SNMP DHCP HTTP (Hypertext Transfer Protocol ) Protocolo usado na Internet para transferir as páginas da WWW (WEB). HTTPS (HyperText Transfer

Leia mais

Streaming vídeo com RTSP e RTP

Streaming vídeo com RTSP e RTP Descrição da tarefa de programação a ser feita na disciplina de Redes de Alto Desempenho (RAD) SSC-144. Turmas A e B. A tarefa de programação é referente ao Capítulo 7 do Livro: Redes de Computadores e

Leia mais

Gerência de Redes de Computadores Gerência de Redes de Computadores As redes estão ficando cada vez mais importantes para as empresas Não são mais infra-estrutura dispensável: são de missão crítica, ou

Leia mais

FACSENAC. Versão:1.5. Identificador do documento: Projeto Lógico de Redes. Versão do Template Utilizada na Confecção: 1.0. Histórico de revisões

FACSENAC. Versão:1.5. Identificador do documento: Projeto Lógico de Redes. Versão do Template Utilizada na Confecção: 1.0. Histórico de revisões FACSENAC ECOFROTA Documento de Projeto Lógico de Rede Versão:1.5 Data: 21/11/2013 Identificador do documento: Projeto Lógico de Redes Versão do Template Utilizada na Confecção: 1.0 Localização: FacSenac

Leia mais

CÓDIGO DA VAGA: TP08 QUESTÕES DE MÚLTIPLAS ESCOLHAS

CÓDIGO DA VAGA: TP08 QUESTÕES DE MÚLTIPLAS ESCOLHAS QUESTÕES DE MÚLTIPLAS ESCOLHAS 1) Em relação à manutenção corretiva pode- se afirmar que : a) Constitui a forma mais barata de manutenção do ponto de vista total do sistema. b) Aumenta a vida útil dos

Leia mais

Redes de Computadores

Redes de Computadores Redes de Computadores Prof. Marcelo Gonçalves Rubinstein Programa de Pós-Graduação em Engenharia Eletrônica Faculdade de Engenharia Universidade do Estado do Rio de Janeiro Ementa Introdução a Redes de

Leia mais

Teleprocessamento e Redes

Teleprocessamento e Redes Teleprocessamento e Redes Aula 21: 06 de julho de 2010 1 2 3 (RFC 959) Sumário Aplicação de transferência de arquivos de/para um host remoto O usuário deve prover login/senha O usa duas conexões TCP em

Leia mais

Um estudo do protocolo SIP e sua utilização em redes de telefonia móvel

Um estudo do protocolo SIP e sua utilização em redes de telefonia móvel Um estudo do protocolo SIP e sua utilização em redes de telefonia móvel Romildo Martins da Silva Bezerra 1 1 Mestrado em Redes de Computadores (UNIFACS) romildo@cdl.com.br Resumo. Este trabalho visa apresentar

Leia mais

Prof. Manuel A Rendón M

Prof. Manuel A Rendón M Prof. Manuel A Rendón M Tanenbaum Redes de Computadores Cap. 1 e 2 5ª. Edição Pearson Padronização de sistemas abertos à comunicação Modelo de Referência para Interconexão de Sistemas Abertos RM OSI Uma

Leia mais

REDES CONVERGENTES PROFESSOR: MARCOS A. A. GONDIM

REDES CONVERGENTES PROFESSOR: MARCOS A. A. GONDIM REDES CONVERGENTES PROFESSOR: MARCOS A. A. GONDIM Roteiro Introdução a Redes Convergentes. Camadas de uma rede convergente. Desafios na implementação de redes convergentes. Introdução a Redes Convergentes.

Leia mais

Protocolo SIP. Licenciatura em Engenharia de Sistemas Informáticos PL. Comunicação de Dados. Pedro Fernandes 7839 Nuno Costa 3676 1

Protocolo SIP. Licenciatura em Engenharia de Sistemas Informáticos PL. Comunicação de Dados. Pedro Fernandes 7839 Nuno Costa 3676 1 Pedro Fernandes 7839 Nuno Costa 3676 1 Protocolo SIP Licenciatura em Engenharia de Sistemas Informáticos PL Comunicação de Dados Resumo Neste documento pretende-se explicar o funcionamento do protocolo

Leia mais

www.projetoderedes.com.br Gestão da Segurança da Informação Professor: Maurício AULA 04 Tipos de Ataques

www.projetoderedes.com.br Gestão da Segurança da Informação Professor: Maurício AULA 04 Tipos de Ataques Ataque de Dicionário www.projetoderedes.com.br Trata-se de um ataque baseado em senhas que consiste na cifragem das palavras de um dicionário e posterior comparação com os arquivos de senhas de usuários.

Leia mais

Funcionamento de ARP entre redes (sub-redes) distintas. Mecanismos de entrega. Funcionamento entre redes (sub-redes): default gateway

Funcionamento de ARP entre redes (sub-redes) distintas. Mecanismos de entrega. Funcionamento entre redes (sub-redes): default gateway Introdução Inst tituto de Info ormátic ca - UF FRGS Redes de Computadores Protocolos ARP e ICMP Aula 18 A camada de rede fornece um endereço lógico Uniforme, independente da tecnologia empregada pelo enlace

Leia mais

Redes. Pablo Rodriguez de Almeida Gross

Redes. Pablo Rodriguez de Almeida Gross Redes Pablo Rodriguez de Almeida Gross Conceitos A seguir serão vistos conceitos básicos relacionados a redes de computadores. O que é uma rede? Uma rede é um conjunto de computadores interligados permitindo

Leia mais

Redes de Computadores. Trabalho de Laboratório Nº7

Redes de Computadores. Trabalho de Laboratório Nº7 Redes de Computadores Curso de Eng. Informática Curso de Eng. de Electrónica e Computadores Trabalho de Laboratório Nº7 Análise do tráfego na rede Protocolos TCP e UDP Objectivo Usar o Ethereal para visualizar

Leia mais

A recomendação H.323 define um arcabouço (guarda-chuva) para a estruturação dos diversos

A recomendação H.323 define um arcabouço (guarda-chuva) para a estruturação dos diversos Videoconferência: H.323 versus SIP Este tutorial apresenta uma avaliação técnica e as tendências que envolvem os serviços providos pela pilha de protocolos do padrão H.323, especificados pelo ITU-T, e

Leia mais

Redes de Computadores LFG TI

Redes de Computadores LFG TI Redes de Computadores LFG TI Prof. Bruno Guilhen Camada de Aplicação Fundamentos Fundamentos Trata os detalhes específicos de cada tipo de aplicação. Mensagens trocadas por cada tipo de aplicação definem

Leia mais

Arquitetura TCP/IP. Parte V Inicialização e auto-configuração (RARP, BOOTP e DHCP) Fabrízzio Alphonsus A. M. N. Soares

Arquitetura TCP/IP. Parte V Inicialização e auto-configuração (RARP, BOOTP e DHCP) Fabrízzio Alphonsus A. M. N. Soares Arquitetura TCP/IP Parte V Inicialização e auto-configuração (RARP, BOOTP e DHCP) Fabrízzio Alphonsus A. M. N. Soares Tópicos Atribuição de endereço IP RARP (Reverse ARP) BOOTP (BOOTstrap Protocol) DHCP

Leia mais

REDES DE COMPUTADORES Prof. Ricardo Rodrigues Barcelar http://www.ricardobarcelar.com

REDES DE COMPUTADORES Prof. Ricardo Rodrigues Barcelar http://www.ricardobarcelar.com - Aula Complementar - MODELO DE REFERÊNCIA OSI Este modelo se baseia em uma proposta desenvolvida pela ISO (International Standards Organization) como um primeiro passo em direção a padronização dos protocolos

Leia mais

REDES ESAF. leitejuniorbr@yahoo.com.br 1 Redes - ESAF

REDES ESAF. leitejuniorbr@yahoo.com.br 1 Redes - ESAF REDES ESAF 01 - (ESAF - Auditor-Fiscal da Previdência Social - AFPS - 2002) Um protocolo é um conjunto de regras e convenções precisamente definidas que possibilitam a comunicação através de uma rede.

Leia mais

VoIPFix: Uma ferramenta para análise e detecção de falhas em sistemas de telefonia IP

VoIPFix: Uma ferramenta para análise e detecção de falhas em sistemas de telefonia IP XXIX Simpósio Brasileiro de Redes de Computadores e Sistemas Distribuídos 915 VoIPFix: Uma ferramenta para análise e detecção de falhas em sistemas de telefonia IP Paulo C. Siécola 1, Fabio Kon 1 1 Departamento

Leia mais

CONTROLE DE REDE. Prof. José Augusto Suruagy Monteiro

CONTROLE DE REDE. Prof. José Augusto Suruagy Monteiro CONTROLE DE REDE Prof. José Augusto Suruagy Monteiro 2 Capítulo 3 de William Stallings. SNMP, SNMPv2, SNMPv3, and RMON 1 and 2, 3rd. Edition. Addison-Wesley, 1999. Baseado em slides do Prof. Chu-Sing Yang

Leia mais

REDES INTEGRADAS DE COMUNICAÇÕES. Enunciado do Projecto de. VoIP

REDES INTEGRADAS DE COMUNICAÇÕES. Enunciado do Projecto de. VoIP REDES INTEGRADAS DE COMUNICAÇÕES Enunciado do Projecto de VoIP Paulo Rogério Pereira, SETEMBRO DE 2011 1. Objectivo Este trabalho tem como objectivo desenvolver um sistema de Interactive Video Voice Response

Leia mais

Protocolo TCP/IP. Protocolo TCP/IP. Protocolo TCP/IP. Protocolo TCP/IP. Conexão de Redes. Protocolo TCP/IP. Arquitetura Internet.

Protocolo TCP/IP. Protocolo TCP/IP. Protocolo TCP/IP. Protocolo TCP/IP. Conexão de Redes. Protocolo TCP/IP. Arquitetura Internet. Origem: Surgiu na década de 60 através da DARPA (para fins militares) - ARPANET. Em 1977 - Unix é projetado para ser o protocolo de comunicação da ARPANET. Em 1980 a ARPANET foi dividida em ARPANET e MILINET.

Leia mais

IV. Em uma rede Frame Relay o roteamento dos quadros é de responsabilidade do protocolo IP da família de protocolos TCP/IP.

IV. Em uma rede Frame Relay o roteamento dos quadros é de responsabilidade do protocolo IP da família de protocolos TCP/IP. Exercícios: Redes WAN Prof. Walter Cunha http://www.waltercunha.com/blog http://twitter.com/timasters http://br.groups.yahoo.com/group/timasters/ Frame-Relay 1. (FCC/Pref. Santos 2005) O frame-relay é

Leia mais

REDES DE COMPUTADORES

REDES DE COMPUTADORES REDES DE COMPUTADORES 09/2013 Cap.3 Protocolo TCP e a Camada de Transporte 2 Esclarecimentos Esse material é de apoio para as aulas da disciplina e não substitui a leitura da bibliografia básica. Os professores

Leia mais

3 Gerenciamento de Mobilidade

3 Gerenciamento de Mobilidade Gerenciamento de Mobilidade 38 3 Gerenciamento de Mobilidade A Internet não foi originalmente projetada para suportar a mobilidade de dispositivos. A infra-estrutura existente e o conjunto dos principais

Leia mais

Redes de Computadores I Conceitos Básicos (6 a. Semana de Aula)

Redes de Computadores I Conceitos Básicos (6 a. Semana de Aula) Redes de Computadores I Conceitos Básicos (6 a. Semana de Aula) Prof. Luís Rodrigo lrodrigo@lncc.br http://lrodrigo.lncc.br 2013.09 v2 2013.09.10 (baseado no material de Jim Kurose e outros) Arquiteturas

Leia mais

Rede de Computadores II

Rede de Computadores II Slide 1 Técnicas para se alcançar boa qualidade de serviço Reserva de recursos A capacidade de regular a forma do tráfego oferecido é um bom início para garantir a qualidade de serviço. Mas Dispersar os

Leia mais

TCP/IP TCP UDP IP HTTP HTTPS FTP TFTP TELNET POP3 IMAP SMTP SNMP DHCP

TCP/IP TCP UDP IP HTTP HTTPS FTP TFTP TELNET POP3 IMAP SMTP SNMP DHCP TCP/IP TCP UDP IP HTTP HTTPS FTP TFTP TELNET POP3 IMAP SMTP SNMP DHCP HTTP (Hypertext Transfer Protocol ) Protocolo usado na Internet para transferir as páginas da WWW (WEB). HTTPS (HyperText Transfer

Leia mais

MANUAL DE PREVENÇÃO E SEGURANÇA DO USUÁRIO DO PABX. PROTEJA MELHOR OS PABXS DA SUA EMPRESA CONTRA FRAUDES E EVITE PREJUÍZOS.

MANUAL DE PREVENÇÃO E SEGURANÇA DO USUÁRIO DO PABX. PROTEJA MELHOR OS PABXS DA SUA EMPRESA CONTRA FRAUDES E EVITE PREJUÍZOS. MANUAL DE PREVENÇÃO E SEGURANÇA DO USUÁRIO DO PABX. PROTEJA MELHOR OS PABXS DA SUA EMPRESA CONTRA FRAUDES E EVITE PREJUÍZOS. MANUAL DE PREVENÇÃO E SEGURANÇA DO USUÁRIO DO PABX. Caro cliente, Para reduzir

Leia mais

Protocolos, DNS, DHCP, Ethereal e comandos em Linux

Protocolos, DNS, DHCP, Ethereal e comandos em Linux Redes de Computadores Protocolos, DNS, DHCP, Ethereal e comandos em Linux Escola Superior de Tecnologia e Gestão Instituto Politécnico de Bragança Março de 2006 Endereços e nomes Quaisquer duas estações

Leia mais

REDES DE COMPUTADORES Prof. Ricardo Rodrigues Barcelar http://www.ricardobarcelar.com.br

REDES DE COMPUTADORES Prof. Ricardo Rodrigues Barcelar http://www.ricardobarcelar.com.br - Aula 2 - MODELO DE REFERÊNCIA TCP (RM TCP) 1. INTRODUÇÃO O modelo de referência TCP, foi muito usado pela rede ARPANET, e atualmente usado pela sua sucessora, a Internet Mundial. A ARPANET é de grande

Leia mais

Redes de Computadores

Redes de Computadores s de Computadores s de Computadores s de Computadores 2 1 Roteamento como visto cada gateway / host roteia mensagens não há coordenação com outras máquinas Funciona bem para sistemas estáveis e sem erros

Leia mais

CCNA 1 Conceitos Básicos de Redes. Módulo 11 Camada de Transporte TCP/IP Camada de Aplicação

CCNA 1 Conceitos Básicos de Redes. Módulo 11 Camada de Transporte TCP/IP Camada de Aplicação CCNA 1 Conceitos Básicos de Redes Módulo 11 Camada de Transporte TCP/IP Camada de Aplicação Camada de Transporte TCP/IP 2 Introdução à Camada de Transporte As responsabilidades principais da camada de

Leia mais

SMTP, POP, IMAP, DHCP e SNMP. Professor Leonardo Larback

SMTP, POP, IMAP, DHCP e SNMP. Professor Leonardo Larback SMTP, POP, IMAP, DHCP e SNMP Professor Leonardo Larback Protocolo SMTP O SMTP (Simple Mail Transfer Protocol) é utilizado no sistema de correio eletrônico da Internet. Utiliza o protocolo TCP na camada

Leia mais

Contribuição acadêmica

Contribuição acadêmica Contribuição acadêmica Origem deste trabalho em cadeiras do curso de mestrado na COPPE/UFRJ; Continuidade da contribuição acadêmica através do laboratório RAVEL: desenvolvimento de sw para apoio; intercâmbio

Leia mais

Redes de Computadores. 1 Questões de múltipla escolha. TE090 - Prof. Pedroso. 17 de junho de 2015

Redes de Computadores. 1 Questões de múltipla escolha. TE090 - Prof. Pedroso. 17 de junho de 2015 TE090 - Prof. Pedroso 17 de junho de 2015 1 Questões de múltipla escolha Exercício 1: Suponha que um roteador foi configurado para descobrir rotas utilizando o protocolo RIP (Routing Information Protocol),

Leia mais

3 SERVIÇOS IP. 3.1 Serviços IP e alguns aspectos de segurança

3 SERVIÇOS IP. 3.1 Serviços IP e alguns aspectos de segurança 3 SERVIÇOS IP 3.1 Serviços IP e alguns aspectos de segurança Os serviços IP's são suscetíveis a uma variedade de possíveis ataques, desde ataques passivos (como espionagem) até ataques ativos (como a impossibilidade

Leia mais

Redes de Computadores

Redes de Computadores 1 Elmano R. Cavalcanti Redes de Computadores Camada de Rede elmano@gmail.com facisa-redes@googlegroups.com http://sites.google.com/site/elmano Esta apresentação contém slides fornecidos pela Editora Pearson

Leia mais

CAMADA DE TRANSPORTE

CAMADA DE TRANSPORTE Curso Técnico de Redes de Computadores Disciplina de Fundamentos de Rede CAMADA DE TRANSPORTE Professora: Juliana Cristina de Andrade E-mail: professora.julianacrstina@gmail.com Site: www.julianacristina.com

Leia mais

Capítulo 8 - Aplicações em Redes

Capítulo 8 - Aplicações em Redes Capítulo 8 - Aplicações em Redes Prof. Othon Marcelo Nunes Batista Mestre em Informática 1 de 31 Roteiro Sistemas Operacionais em Rede Modelo Cliente-Servidor Modelo P2P (Peer-To-Peer) Aplicações e Protocolos

Leia mais

MÓDULO 8 Modelo de Referência TCP/IP

MÓDULO 8 Modelo de Referência TCP/IP MÓDULO 8 Modelo de Referência TCP/IP A internet é conhecida como uma rede pública de comunicação de dados com o controle totalmente descentralizado, utiliza para isso um conjunto de protocolos TCP e IP,

Leia mais

Redes de Computadores I Conceitos Básicos

Redes de Computadores I Conceitos Básicos Redes de Computadores I Conceitos Básicos (6 a. Semana de Aula) Prof. Luís Rodrigo lrodrigo@lncc.br http://lrodrigo.lncc.br 2011.02 v1 2011.09.05 (baseado no material de Jim Kurose e outros) Arquiteturas

Leia mais

Redes de Computadores

Redes de Computadores Redes de Computadores Capítulo 1 Gustavo Reis gustavo.reis@ifsudestemg.edu.br - O que é a Internet? - Milhões de elementos de computação interligados: hospedeiros = sistemas finais - Executando aplicações

Leia mais

MINISTÉRIO DA DEFESA COMANDO DA AERONÁUTICA

MINISTÉRIO DA DEFESA COMANDO DA AERONÁUTICA MINISTÉRIO DA DEFESA COMANDO DA AERONÁUTICA TELECOMUNICAÇÕES ICA 102-15 CONTROLES DE SEGURANÇA DA INFORMAÇÃO PARA A REDE DE TELEFONIA IP DO COMAER 2013 MINISTÉRIO DA DEFESA COMANDO DA AERONÁUTICA DEPARTAMENTO

Leia mais

Redes Mul)mídia. Tópicos. Streaming de Áudio e Vídeo. Aplicações de Rede Mul:mídia Introdução Classes de Aplicações Mul:mídia

Redes Mul)mídia. Tópicos. Streaming de Áudio e Vídeo. Aplicações de Rede Mul:mídia Introdução Classes de Aplicações Mul:mídia Redes Mul)mídia Streaming de Áudio e Vídeo Mário Meireles Teixeira Departamento de Informá:ca UFMA 2012 Tópicos Aplicações de Rede Mul:mídia Introdução Classes de Aplicações Mul:mídia Áudio e Vídeo de

Leia mais

FTP Protocolo de Transferência de Arquivos

FTP Protocolo de Transferência de Arquivos FTP Protocolo de Transferência de Arquivos IFSC UNIDADE DE SÃO JOSÉ CURSO TÉCNICO SUBSEQUENTE DE TELECOMUNICAÇÕES! Prof. Tomás Grimm FTP - Protocolo O protocolo FTP é o serviço padrão da Internet para

Leia mais

1. PRINCIPAIS PROTOCOLOS TCP/IP

1. PRINCIPAIS PROTOCOLOS TCP/IP 1. PRINCIPAIS PROTOCOLOS TCP/IP 1.1 IP - Internet Protocol RFC 791 Esse protocolo foi introduzido na ARPANET no início dos anos 80, e tem sido utilizado juntamente com o TCP desde então. A principal característica

Leia mais

Uma arquitectura IPtel baseada no protocolo SIP

Uma arquitectura IPtel baseada no protocolo SIP Uma arquitectura IPtel baseada no protocolo SIP João Paulo Sousa Instituto Politécnico de Bragança R. João Maria Sarmento Pimentel, 5370-326 Mirandela, Portugal + 351 27 820 13 40 jpaulo@ipb.pt RESUMO

Leia mais

ARP. Tabela ARP construída automaticamente. Contém endereço IP, endereço MAC e TTL

ARP. Tabela ARP construída automaticamente. Contém endereço IP, endereço MAC e TTL ARP Protocolo de resolução de endereços (Address Resolution Protocol) Descrito na RFC 826 Faz a tradução de endereços IP para endereços MAC da maioria das redes IEEE 802 Executado dentro da sub-rede Cada

Leia mais

Redes de Computadores

Redes de Computadores Departamento de Informática UFPE Redes de Computadores Nível de Redes - Exemplos jamel@cin.ufpe.br Nível de Rede na Internet - Datagramas IP Não orientado a conexão, roteamento melhor esforço Não confiável,

Leia mais

Planejando uma política de segurança da informação

Planejando uma política de segurança da informação Planejando uma política de segurança da informação Para que se possa planejar uma política de segurança da informação em uma empresa é necessário levantar os Riscos, as Ameaças e as Vulnerabilidades de

Leia mais

6 Redução do Overhead na Interface Aérea para os Pacotes de VoIP Transmitidos no Modo IMS

6 Redução do Overhead na Interface Aérea para os Pacotes de VoIP Transmitidos no Modo IMS 6 Redução do Overhead na Interface Aérea para os Pacotes de VoIP Transmitidos no Modo IMS Este Capítulo objetiva fornecer uma análise para a redução do número de bits a serem transmitidos na interface

Leia mais

ALCY JOSÉ VIEIRA NETO ALEXANDRE SOHN CINTIA CAVICHIOLO PROTOCOLO HTTP

ALCY JOSÉ VIEIRA NETO ALEXANDRE SOHN CINTIA CAVICHIOLO PROTOCOLO HTTP ALCY JOSÉ VIEIRA NETO ALEXANDRE SOHN CINTIA CAVICHIOLO PROTOCOLO HTTP CURITIBA 2006 ALCY JOSÉ VIEIRA NETO ALEXANDRE SOHN CINTIA CAVICHIOLO PROTOCOLO HTTP Trabalho apresentado para a disciplina de REDES,

Leia mais

Conceitos de Segurança em Sistemas Distribuídos

Conceitos de Segurança em Sistemas Distribuídos Conceitos de Segurança em Sistemas Distribuídos Francisco José da Silva e Silva Laboratório de Sistemas Distribuídos (LSD) Departamento de Informática / UFMA http://www.lsd.ufma.br 30 de novembro de 2011

Leia mais

Arquitetura TCP/IP. Parte IX Multicast (IGMP e roteamento) Fabrízzio Alphonsus A. M. N. Soares

Arquitetura TCP/IP. Parte IX Multicast (IGMP e roteamento) Fabrízzio Alphonsus A. M. N. Soares Arquitetura TCP/IP Parte IX Multicast (IGMP e roteamento) Fabrízzio Alphonsus A. M. N. Soares Tópicos Hardware multicast Ethernet multicast IP multicast Endereçamento e mapeamento para Ethernet multicast

Leia mais

Redes de Computadores

Redes de Computadores Redes de Computadores Prof. Macêdo Firmino Camada de Transporte Macêdo Firmino (IFRN) Redes de Computadores Março de 2011 1 / 59 Camada de Transporte Os protocolos dessa camada supervisionam o fluxo de

Leia mais

Professor(es): Fernando Pirkel. Descrição da(s) atividade(s):

Professor(es): Fernando Pirkel. Descrição da(s) atividade(s): Professor(es): Fernando Pirkel Descrição da(s) atividade(s): Definir as tecnologias de redes necessárias e adequadas para conexão e compartilhamento dos dados que fazem parte da automatização dos procedimentos

Leia mais

Servidor de E-mails e Protocolo SMTP. Professor: João Paulo de Brito Gonçalves Disciplina: Serviços de Redes

Servidor de E-mails e Protocolo SMTP. Professor: João Paulo de Brito Gonçalves Disciplina: Serviços de Redes Campus Cachoeiro Curso Técnico em Informática Servidor de E-mails e Protocolo SMTP Professor: João Paulo de Brito Gonçalves Disciplina: Serviços de Redes Definições Servidor de Mensagens Um servidor de

Leia mais

RELATÓRIO SOBRE AS TENDÊNCIAS DO ATAQUE DISTRIBUÍDO DE NEGAÇÃO DE SERVIÇO DA VERISIGN 1A EDIÇÃO - 1O TRIMESTRE DE 2014

RELATÓRIO SOBRE AS TENDÊNCIAS DO ATAQUE DISTRIBUÍDO DE NEGAÇÃO DE SERVIÇO DA VERISIGN 1A EDIÇÃO - 1O TRIMESTRE DE 2014 RELATÓRIO SOBRE AS TENDÊNCIAS DO ATAQUE DISTRIBUÍDO DE NEGAÇÃO DE SERVIÇO DA VERISIGN 1A EDIÇÃO - 1O TRIMESTRE DE 214 RESUMO EXECUTIVO Este relatório contém as observações e conhecimentos derivados de

Leia mais

Redes de Computadores

Redes de Computadores 6. Camada de Transporte DIN/CTC/UEM 2008 Principais Funções Oferece conexão lógica entre duas extremidades da rede Oferece controle fim-a-fim de fluxo e confiabilidade Independente da tecnologia utilizada

Leia mais

Serviço de datagrama não confiável Endereçamento hierárquico. Facilidade de fragmentação e remontagem de pacotes

Serviço de datagrama não confiável Endereçamento hierárquico. Facilidade de fragmentação e remontagem de pacotes IP Os endereços IP são números com 32 bits, normalmente escritos como quatro octetos (em decimal), por exemplo 128.6.4.7. A primeira parte do endereço identifica uma rede especifica na interrede, a segunda

Leia mais

ETI/Domo. Português. www.bpt.it. ETI-Domo Config 24810180 PT 29-07-14

ETI/Domo. Português. www.bpt.it. ETI-Domo Config 24810180 PT 29-07-14 ETI/Domo 24810180 www.bpt.it PT Português ETI-Domo Config 24810180 PT 29-07-14 Configuração do PC Antes de realizar a configuração de todo o sistema, é necessário configurar o PC para que esteja pronto

Leia mais

Introdução à Redes de Computadores

Introdução à Redes de Computadores Introdução à Redes de Computadores 1 Agenda Camada 4 do modelo OSI 2 1 Camada 4 do modelo OSI 3 Camada 4 - Transporte O termo "qualidade de serviço" é freqüentemente usado para descrever a finalidade da

Leia mais

3) Na configuração de rede, além do endereço IP, é necessário fornecer também uma máscara de subrede válida, conforme o exemplo:

3) Na configuração de rede, além do endereço IP, é necessário fornecer também uma máscara de subrede válida, conforme o exemplo: DIRETORIA ACADÊMICA DE EDUCAÇÃO E TECNOLOGIA COORDENAÇÃO DOS CURSOS DA ÁREA DE INFORMÁTICA! Atividade em sala de aula. 1) A respeito de redes de computadores, protocolos TCP/IP e considerando uma rede

Leia mais

HTVix HA 211. Entrada de alimentação 12VDC / 500mA (Positivo no centro)

HTVix HA 211. Entrada de alimentação 12VDC / 500mA (Positivo no centro) 1 HTVix HA 211 1. Interfaces Entrada de alimentação 12VDC / 500mA (Positivo no centro) Conector RJ11 para conexão de aparelho telefônico analógico ou o adaptador para telefone e rede de telefonia convencional

Leia mais

MÓDULO 7 Modelo OSI. 7.1 Serviços Versus Protocolos

MÓDULO 7 Modelo OSI. 7.1 Serviços Versus Protocolos MÓDULO 7 Modelo OSI A maioria das redes são organizadas como pilhas ou níveis de camadas, umas sobre as outras, sendo feito com o intuito de reduzir a complexidade do projeto da rede. O objetivo de cada

Leia mais