Conceitos e Portas Locais<\/p>\n
Conceitos<\/p>\n
Hoje em dia, \u00e9 comum trabalharmos com v\u00e1rios aplicativos diferentes abertos ao mesmo tempo, como por exemplo um navegador com v\u00e1rias abas, um cliente de mensagem instant\u00e2nea, um cliente de e-mail, um player de MP3, etc. Todos eles recebendo e enviando dados ao mesmo tempo. <\/p>\n
Mas voc\u00ea j\u00e1 parou para pensar, em como o computador sabe para qual programa enviar um dados, quando este chega na interface de rede? Como ele sabe que um determinado pacote \u00e9 para a primeira aba do navegador e n\u00e3o para o cliente de e-mail? <\/p>\n
Quando uma aplica\u00e7\u00e3o de rede \u00e9 iniciada, ela abre uma porta com um numera\u00e7\u00e3o \u00fanica. Cada aplica\u00e7\u00e3o fica associada a uma porta. As aplica\u00e7\u00f5es cliente abrem uma porta aleat\u00f3ria que varia de 1024 at\u00e9 65535. Aplica\u00e7\u00f5es servidoras possuem portas padr\u00e3o. <\/p>\n
Por exemplo, um Servidor Web vai abrir a porta 80 e ficar aguardando conex\u00f5es. Se voc\u00ea quiser acessar a p\u00e1gina do Viva o Linux, o seu navegador abrir\u00e1 uma porta alta aleat\u00f3ria e tentar\u00e1 a conex\u00e3o na porta 80 do Servidor que hospeda o site. <\/p>\n
Na figura abaixo, isto est\u00e1 exemplificado melhor.<\/p>\n
Resumidamente, o IP identifica a m\u00e1quina na Internet, o MAC address identifica a m\u00e1quina dentro do segmento de rede, e a porta identifica a aplica\u00e7\u00e3o. <\/p>\n
O arquivo \u201c\/etc\/services\u201d, cont\u00e9m uma lista das principais portas usadas por padr\u00e3o. Abaixo um trecho do arquivo. <\/p>\n
#\/etc\/services
\nftp 21\/tcp
\nssh 22\/tcp # SSH Remote Login Protocol
\nsmtp 25\/tcp
\ntacacs 49\/tcp # Login Host Protocol (TACACS)
\ndomain 53\/tcp # name-domain server
\nbootps 67\/tcp # BOOTP server
\nbootpc 68\/tcp # BOOTP client
\nwww 80\/tcp http # WorldWideWeb HTTP
\nkerberos 88\/tcp kerberos5 krb5 kerberos-sec # Kerberos v5
\nkerberos 88\/udp kerberos5 krb5 kerberos-sec # Kerberos v5
\npop3 110\/tcp pop-3 # POP version 3
\nnntp 119\/tcp readnews untp # USENET News Transfer Protocol
\nntp 123\/udp # Network Time Protocol
\nnetbios-ssn 139\/tcp # NETBIOS session service
\nimap2 143\/tcp imap # Interim Mail Access P 2 and 4
\nsnmp 161\/tcp # Simple Net Mgmt Protocol
\nsnmp 161\/udp # Simple Net Mgmt Protocol
\nsnmp-trap 162\/tcp snmptrap # Traps for SNMP
\nsnmp-trap 162\/udp snmptrap # Traps for SNMP<\/p>\n
H\u00e1 v\u00e1rios tipos de portas. As principais s\u00e3o TCP, UDP e ICMP. <\/p>\n
– Portas ICMP: <\/p>\n
S\u00e3o usadas para controle de tr\u00e1fego. N\u00e3o se transfere dados ‘\u00fateis’ por ele, apenas dados relacionados a conex\u00e3o, ao link, ao tempo de resposta, etc. <\/p>\n
Um exemplo t\u00edpico de ICMP, \u00e9 o famoso comando Ping. O Ping envia uma requisi\u00e7\u00e3o ao destino e gera estat\u00edsticas, com o tempo da resposta. <\/p>\n
Outro comando t\u00edpico \u00e9 o Tracert, que nada mais \u00e9 do que um Ping com ‘ttl 1’, depois outro Ping com ‘ttl 2’, assim por diante, at\u00e9 que o alvo seja atingido, ou algum erro for encontrado. <\/p>\n
O resultado \u00e9 uma rela\u00e7\u00e3o dos saltos (roteadores) usados para se alcan\u00e7ar o alvo, com seus respectivos tempos de resposta. <\/p>\n
– Portas TCP: <\/p>\n
S\u00e3o usadas para transfer\u00eancia de dados que requerem integridade. Em uma comunica\u00e7\u00e3o TCP, as partes estabelecem uma conex\u00e3o que fica aberta enquanto os dados s\u00e3o trafegados. <\/p>\n
Para cada sequ\u00eancia de dados enviada, espera-se como resposta uma confirma\u00e7\u00e3o do recebimento. Por isso, dizemos que o TCP possui qualidade na comunica\u00e7\u00e3o. <\/p>\n
– Porta UDP: <\/p>\n
\u00c9 usada para conex\u00f5es onde a integridade n\u00e3o \u00e9 necess\u00e1ria, ou quando o dado trafegado \u00e9 muito pequeno. <\/p>\n
Por exemplo, em uma V\u00eddeo-Confer\u00eancia ou Stream de \u00e1udio, se um pacote de dados se perder durante a comunica\u00e7\u00e3o, isto n\u00e3o afetar\u00e1 o entendimento. <\/p>\n
Uma requisi\u00e7\u00e3o DNS tamb\u00e9m \u00e9 feita por UDP, pois seus pacotes s\u00e3o muito pequenos. Por isso, o UDP \u00e9 mais r\u00e1pido que o TCP, mas n\u00e3o pode ser usado onde a integridade \u00e9 essencial, como numa transfer\u00eancia banc\u00e1ria, ou mesmo no envio de um e-mail. <\/p>\n
Entendidos esses pormenores, vamos fazer algo pr\u00e1tico. <\/p>\n
Pesquisando Portas Locais<\/p>\n
Para ver quais portas est\u00e3o abertas em sua m\u00e1quina, use o Netstat. <\/p>\n
No exemplo abaixo, estou mostrando apenas as portas TCP e UDP.<\/p>\n
Cada linha \u00e9 uma conex\u00e3o aberta em sua m\u00e1quina. As colunas mais importantes aqui, s\u00e3o Endere\u00e7o Local, Endere\u00e7o Remoto e Estado. <\/p>\n
Os endere\u00e7os cont\u00e9m o nome do Host e o nome da porta separados por ‘:’. O nome do Host \u00e9 resolvido via DNS, e o da porta \u00e9 retirado do \u201c\/etc\/services\u201d. Para evitar a resolu\u00e7\u00e3o de nomes, melhorando o desempenho do Netstat, execute-o com a op\u00e7\u00e3o: -n <\/p>\n
A \u00faltima coluna cont\u00e9m o estado da conex\u00e3o. Abaixo descrevo os estados poss\u00edveis. Dependendo da l\u00edngua padr\u00e3o do seu sistema, a \u00faltima coluna pode mudar um pouco. <\/p>\n
– ESTABELECIDO: A conex\u00e3o est\u00e1 estabelecida. <\/p>\n
– SYN_SENT: O Socket est\u00e1 tentando estabelecer uma conex\u00e3o. Indica que a esta\u00e7\u00e3o tentou estabelecer uma conex\u00e3o enviando um pacote SYN, mas ainda n\u00e3o recebeu a resposta SYN ACC. Isso pode ocorrer quando h\u00e1 algum problema para se conectar, como um firewall bloqueando a conex\u00e3o, ou quando a conex\u00e3o est\u00e1 lenta. <\/p>\n
– SYN_RECV: Uma requisi\u00e7\u00e3o de conex\u00e3o foi recebida da rede. <\/p>\n
– FIN_WAIT1: O Socket est\u00e1 fechado e a conex\u00e3o est\u00e1 terminando. <\/p>\n
– FIN_WAIT2: A conex\u00e3o est\u00e1 fechada e o Socket est\u00e1 esperando por uma termina\u00e7\u00e3o pela m\u00e1quina remota. <\/p>\n
– TIME_WAIT: A conex\u00e3o est\u00e1 aberta, mas n\u00e3o h\u00e1 dados trafegando neste momento. Ap\u00f3s um per\u00edodo de inatividade, a conex\u00e3o ser\u00e1 fechada. <\/p>\n
– FECHADO: A conex\u00e3o est\u00e1 fechada. <\/p>\n
– CLOSE_WAIT: O lado remoto terminou, esperando pelo fechamento do Socket. <\/p>\n
– \u00daLTIMO_ACK: O lado remoto terminou, e o Socket est\u00e1 fechado. Esperando por uma confirma\u00e7\u00e3o. <\/p>\n
– OUVINDO: O Socket est\u00e1 aguardando conex\u00f5es, ou seja, tem uma aplica\u00e7\u00e3o servidor rodando em sua m\u00e1quina. <\/p>\n
– FECHANDO: Ambos os Sockets est\u00e3o terminados, mas n\u00f3s ainda n\u00e3o enviamos todos os nossos dados. <\/p>\n
– DESCONHECIDO: O estado do Socket \u00e9 desconhecido. <\/p>\n
\u00c9 poss\u00edvel descobrir qual o programa que est\u00e1 usando a porta em quest\u00e3o atrav\u00e9s do ‘lsof’. <\/p>\n
# netstat -na | grep :4200
\ntcp 0 0 0.0.0.0:4200 0.0.0.0:* OU\u00c7A<\/p>\n
# lsof -i TCP:4200
\nCOMMAND PID USER FD TYPE DEVICE SIZE\/OFF NODE NAME
\nshellinab 1423 shellinabox 4u IPv4 5541 0t0 TCP *:4200 (LISTEN)<\/p>\n
Podemos perceber com isso, que o programa ‘shell in a box’, est\u00e1 usando a porta 4200 e est\u00e1 aguardando por conex\u00f5es. <\/p>\n
Outro exemplo: <\/p>\n
# netstat -na | grep :37319
\ntcp 0 0 172.20.16.60:37319 74.125.65.125:5222 ESTABELECIDA<\/p>\n
# lsof -i TCP:37319
\nCOMMAND PID USER FD TYPE DEVICE SIZE\/OFF NODE NAME
\npidgin 7188 ricardo 15u IPv4 172198 0t0 TCP compaq:37319->gx-in- f125.1e100.net:xmpp-client (ESTABLISHED)<\/p>\n
Neste exemplo, o Pidgin abriu a porta 37319 na minha esta\u00e7\u00e3o de trabalho, e se conectou na porta 5222 do servidor 74.125.65.125.
\n Pr\u00f3xima p\u00e1gina >><\/p>\n
http:\/\/www.vivaolinux.com.br\/artigo\/Entendendo-TCP-IP-(Parte-5)-Portas-TCP-UDP<\/p>\n","protected":false},"excerpt":{"rendered":"
Conceitos e Portas Locais Conceitos Hoje em dia, \u00e9 comum trabalharmos com v\u00e1rios aplicativos diferentes abertos ao mesmo tempo, como por exemplo um navegador com v\u00e1rias abas, um cliente de mensagem instant\u00e2nea, um cliente de e-mail, um player de MP3, etc. Todos eles recebendo e…<\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_angie_page":false,"page_builder":"","footnotes":""},"categories":[12],"tags":[],"class_list":["post-2810","post","type-post","status-publish","format-standard","hentry","category-iptables"],"amp_enabled":true,"_links":{"self":[{"href":"https:\/\/blog.deuzebranaweb.com.br\/index.php\/wp-json\/wp\/v2\/posts\/2810","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/blog.deuzebranaweb.com.br\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blog.deuzebranaweb.com.br\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blog.deuzebranaweb.com.br\/index.php\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/blog.deuzebranaweb.com.br\/index.php\/wp-json\/wp\/v2\/comments?post=2810"}],"version-history":[{"count":0,"href":"https:\/\/blog.deuzebranaweb.com.br\/index.php\/wp-json\/wp\/v2\/posts\/2810\/revisions"}],"wp:attachment":[{"href":"https:\/\/blog.deuzebranaweb.com.br\/index.php\/wp-json\/wp\/v2\/media?parent=2810"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blog.deuzebranaweb.com.br\/index.php\/wp-json\/wp\/v2\/categories?post=2810"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blog.deuzebranaweb.com.br\/index.php\/wp-json\/wp\/v2\/tags?post=2810"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}