SlideShare une entreprise Scribd logo
1  sur  27
Télécharger pour lire hors ligne
1

Camada de Aplicação

A camada de Aplicação contém todos os protocolos de nível mais alto
do modelo TCP/IP .
Alguns dos protocolos de aplicação são:


DNS (Domain Name System): Usado para identificar máquinas através


de nomes em vez de endereços IP;
Telnet: Protocolo de terminal       virtual,   usado   para   controlar
remotamente uma máquina;
FTP (File Transfer Protocol): Usado na transferência de arquivos pela
rede;
HTTP (Hyper Text Transfer Protocol): Usado na transferência de


documentos hipermídia.

Os serviços (aplicações) de rede são iniciados de duas maneiras:

●Pomo programas independentes que permanecem na memória o
tempo todo.
●Por demanda, isto é, conforme são necessários (ocupando espaço na

memória somente quanto estão sendo utilizados).
2
inetd - O Super-Servidor de Internet

Serviços de redes são executados por programas denominados
servidores de rede, um programa servidor de rede é chamado em
inglês de daemon.

Servidores de rede são programas que abrem portas de rede
(referente ao modelo TCP/IP) e tais portas ficam aguardando por
solicitações de clientes.

Quando uma solicitação de cliente é recebida, o servidor de rede cria
um processo filho, o qual trata aquela conexão específica, enquanto o
processo pai continua à escutar na porta, aguardando novas
solicitações de clientes da rede.

É claro que um serviço de rede consome recursos do computador onde
está sendo executado, tal como memória, espaço de processamento,
recursos de rede, etc.
3

Porém, praticamente todo sistema Like-UNIX executa uma espécie de
Super-servidor, que pode ser visto como um servidor de servidores.

O Super-servidor é capaz de criar conectores para uma série de
serviços de rede e ouvir todas as portas de rede simultaneamente e
quando uma máquina remota solicita algum de seus serviços, o Super-
servidor percebe o fato e aciona o servidor específico da porta
envolvida.

Por exemplo, imagine que você tenha uma máquina servindo de
Firewall/Roteador e está é uma máquina que não possui monitor,
teclado e mouse (já que um Firewall não deve ser utilizado
diretamente). Assim, você provavelmente irá precisar de um serviço
como Telnet para gerenciar a máquina remotamente, mas você não
quer que o Telnet ocupe recursos do computador enquanto o Telnet
não está sendo utilizado, você então irá utilizar o inetd (Super-Servidor
de Internet). O inetd irá ficar responsável por abrir a porta de rede
referente ao Telnet e ficar monitorando pedidos a este serviço, tão logo
alguém solicite o Telnet o inetd irá carregar o Telnet na memória, o
usuário remoto irá usar o Telnet normalmente a conexão for finalizada
o inetd irá retirar o serviço da memória e continua a “ouvir” a porta.
4

Portanto, o Super-servidor conhecido por inetd (Internet Daemon) é
um servidor de servidores que é utilizado dentro outros, para poupar
recursos da máquina servidora, centralizar a ativação de serviços, etc.

O inetd é normalmente inicializado quando o sistema é inicializado. O
inetd recebe uma lista de serviços a serem monitorados a partir de um
arquivo de configuração denominado /etc/inetd.conf.

O arquivo /etc/inetd.conf é um arquivo texto e contém como
informação como e quais são os serviços de rede fornecidos pelo inetd.
Uma linha típica do arquivo /etc/inetd.conf é composta pelos
seguintes campos:

<serviço> <tipo> <protocolo> <espera> <usuário> <servidor> <linha_de_comando>
finger stream tcp         nowait nobody /usr/libexec/fingerd fingerd -s


O significado de cada campo do /etc/inetd.conf é o seguinte:

Serviço ou Name - Este campo é o nome do serviço a ser
disponibilizado. Os nomes do serviço podem ser vistos no arquivo
/etc/services. Este nome mapeia o número de porta ao serviço.
5


Tipo ou Type - Este é o tipo de soquete (socket-type) oferecido ao
serviço para a entrega de dados. Os dois tipos de soquetes para
entrega de dados mais utilizados são: dgram para o serviço de
datagramas (sem conexão) e stream para o serviço de fluxo de dados
orientado a conexão.

Protocolo ou Protocol - É o nome do protocolo usado pelo serviço, é
definido no arquivo /etc/protocols. O nome mapeia um número de
protocolo. São na maioria tcp e udp.

Espera ou Wait-status - indica se o daemon invocado pelo inetd é
capaz de lidar com seu próprio socket ou não. Sockets do tipo dgram
precisam usar a opção wait, enquanto daemons de sockets tipo
stream, os quais geralmente são multi-threaded, devem usar a opção
nowait. O tipo wait geralmente repassa múltiplos sockets para um
único daemon, enquanto nowait dispara um daemon filho para
cada novo socket.
6

O número máximo de daemons filho (de conexões abertas para um
serviço de rede) que o inetd pode disparar pode ser ajustado usando a
opção usando-se uma barra (/) após as opções nowait. Se um limite de
dez instâncias de um daemon em particular é necessária, um /10 deve
ser colocado após a opção nowait.

Outra opção pode ser ativada para limitar o número máximo de
conexões a partir de um único lugar (host) para um daemon em
particular. Assim, um valor de dez nesta opção limitaria qualquer
endereço IP a se conectar a determinado serviço a dez tentativas por
minuto. Isto é útil para evitar consumo de recursos intencional ou não
e ataques de Negação de Serviço (Denial of service - DoS) para a
máquina.

Neste campo, wait ou o máximo de filhos e máximo conexões por host
são opcionais.

Estas opções são todas utilizadas pela configuração padrão do daemon
fingerd, como visto aqui:

finger stream tcp   nowait/3/10 nobody /usr/libexec/fingerd fingerd -s
7

Usuário ou UID - Nome de usuário sob o qual o serviço é executado.
Normalmente este é root, mas por razoes de segurança, alguns
processos executam sob o ID do usuário nobody.

Servidor ou Server - Caminho do programa de servidor a ser
executado.    As   entradas   compartilham    o   mesmo    caminho
/usr/sbin/tcp, mas este realmente não é o caminho para o servidor
ftp, telnet ou qualquer outro servidor. Na realidade, o tcpd é um
recurso de segurança usado pelo Linux, sendo que o tcpd chamado de
TCP Wrapper (invólucro de TCP), é usado para prover segurança
veremos mais este serviço posteriormente.

Linha de comando ou Arguments - São argumentos de linha de
comando que são passados ao programa de servidor. O primeiro
argumento sempre é o nome do programa de servidor executado. A
lista de argumentos parece exatamente com o comando se estivesse
sendo digitado em um prompt shell.

Atenção, dentro do arquivo /etc/inetd.conf (tal como, a maioria dos
arquivos de configuração do Linux), tudo que preceder um # é um
comentário e será ignorado pelo script de inicialização do indetd
8
Exemplo do arquivo /etc/inetd.conf:

# daytime        stream tcp         nowait root       internal
# daytime        dgram    udp       wait     root     internal
time             stream tcp         nowait root       internal
time             dgram    udp       wait     root     internal
# These are standard services:
# Very Secure File Transfer Protocol (FTP) server.
#ftp     stream tcp      nowait root       /usr/sbin/tcpd vsftpd
# Professional File Transfer Protocol (FTP) server.
ftp     stream tcp      nowait root       /usr/sbin/tcpd proftpd
# Telnet server:
telnet stream tcp        nowait root       /usr/sbin/tcpd      in.telnetd
# The comsat daemon notifies the user of new mail when biff is set to y:
comsat        dgram   udp      wait     root    /usr/sbin/tcpd in.comsat
# Shell, login, exec and talk are BSD protocols
#shell stream tcp         nowait root        /usr/sbin/tcpd    in.rshd -L
#login stream tcp         nowait root        /usr/sbin/tcpd    in.rlogind
# exec stream tcp         nowait root        /usr/sbin/tcpd    in.rexecd
# talk dgram     udp      wait      root     /usr/sbin/tcpd    in.talkd
#ntalk dgram     udp      wait      root     /usr/sbin/tcpd    in.talkd
9


Habilitando ou Desabilitando um serviço no inetd

Para habilitar um serviço de rede pelo inetd, basta editar o arquivo
/etc/inetd.conf e descomentar (retirar o #) da linha referente ao
serviço desejado, ou ainda, caso a linha não exista acrescentar uma
linha passando os parâmetros para iniciar o serviço via inetd.

Por exemplo, caso queira-se iniciar o Telnet com o Super-servidor
inetd, basta procurar a seguinte linha do Telnet no arquivo
/etc/inetd.conf e descomenta-la, tal como:

Antes de editar:
# Telnet server:
#telnet stream tcp   nowait   root   /usr/sbin/tcpd   in.telnetd


Depois de editar:
# Telnet server:
telnet stream tcp    nowait   root   /usr/sbin/tcpd   in.telnetd
10
Habilitando ou Desabilitando um serviço no inetd

Após, descomentar ou acrescentar o serviço desejado faz se necessário
reiniciar o servidor inetd, isto é possível através da execução do script
de inicialização /etc/rc.d/rc.inedt. O diretório /etc/rc.d/ contém
a grande maioria dos scripts de inicialização de serviços da rede.

Assim, para re-iniciar o inetd execute:

#/etc/rc.d/rc.inedt restart

ou

#/etc/rc.d/rc.inedt stop
#/etc/rc.d/rc.inedt start

Tão logo o servidor seja reiniciado o serviço estará pronto para ser
utilizado. Lembre-se     sempre      que  você alterar o arquivo
/etc/inetd.conf é obrigatório que o servidor seja reiniciado para a
alteração ser valida, caso contrário, a alteração será válida somente
quando o sistema for reinicializado.
11
Habilitando ou Desabilitando um serviço no inetd

Para desabilitar um serviço de rede pelo inetd, basta editar o arquivo
/etc/inetd.conf e comentar (adicionar no inicio da linha um #) na
linha referente ao serviço, não recomenda-se a exclusão da linha, pois
quando for necessário ativar o serviço o usuário terá que refazer a
linha novamente, o que pode ser muito trabalhosol

Por exemplo, caso queira-se desativar o Telnet com o Super-servidor
inetd, basta procurar a linha do Telnet no arquivo /etc/inetd.conf e
comenta-la, tal como:

Antes de editar:
# Telnet server:
telnet stream tcp     nowait   root    /usr/sbin/tcpd   in.telnetd


Depois de editar:
# Telnet server:
# telnet stream tcp    nowait   root    /usr/sbin/tcpd   in.telnetd


Reinicie o servidor após a alteração, para que o processo torne-se
válido.
12
Servidores de rede independentes


Executar um servidor via Super-servidores é uma forma de se iniciar
um serviço de rede, porém outro tipo muito utilizado é executar o
programa de forma independente (não via inetd ou xinetd).


Serviços de rede que são iniciados de forma independente ocupam
recursos da máquina estando o serviço sendo usados ou não, o que é o
contrário dos serviços executados pelo inetd e xinetd.


Cada técnica de inicialização de serviços de rede tem suas próprias
vantagens e desvantagens:
• No caso do Super-servidor os serviços só serão carregados na
memória quando o serviço estiver sendo realmente utilizado, isto
poupa recursos da máquina, entretanto um serviço executado pelo
inetd provavelmente terá um tempo de resposta mais lento do que
serviços executados independentes, pois o processo não estar na
memória e terá de ser carregado para à memória para sua execução;
• Já um serviço de rede executado de forma independente tem um
tempo de resposta mais rápida aos pedidos de conexões de rede, pois
estes serviços já estão na memória e prontos para uso, porém caso não
estejam sendo utilizados estes serviços continuarão na memória
ocupando um espaço de memória que poderia ser útil para outras
tarefas.
13


Iniciando um servidor FTP de forma independente (standalone)

Quando um serviço é muito requisitado, talvez não seja uma boa
escolha iniciá-lo com o Super-servidor, mas sim de forma independente
(em inglês, standalone).

Pois, iniciando um serviço em standalone o serviço estará sempre
pronto para responder os pedidos dos usuários.

O Very Secure FTP Daemon ou simplemente vsftpd, é um bom servidor
de FTP e funciona tanto em modo Super-servidor quanto standalone.

Para a configuração do vsftpd, é necessário editar o arquivo
/etc/vsftpd.conf. Para colocar o vsftpd de forma que este funcione
em standalone, é necessário apenas descomentar (retirar o #) da
seguinte linha: listen=YES.
14


Iniciando um servidor FTP de forma independente (standalone)

Para que o vsftpd funcione em standalone o este serviço não pode
estar sendo executado com o inetd ou xinetd.

Após, editar o arquivo /etc/vsftpd.conf e colocá-lo em standalone,
faz-se necessário iniciar o servidor chamando o comando vsftpd.

Iniciando em standalone, é possível executar o comando ps -ax e
verificar que vsftpd está direto na memória.

Para desligar o servidor FTP agora é necessário “matar” o processo
vsftpd. Isso pode ser feito com o comando killall vsftpd.
15


A funcionalidade do tcpd para Controle de Acesso

Habilita um computador para acesso pela rede envolve muitos riscos
de segurança.

Uma ferramenta útil nestes casos é o servidor tcpd, que é um servidor
de observação. Para os serviços TCP que se deseje monitorar ou
protegendo, o tcpd poderá ser acionado ao invés do programa
servidor.

O programa tcpd registra todas as requisições através do servidor de
mensagens do sistema denominado syslog, verificando se a máquina
remota tem permissão ou não de usar o serviço solicitado por ela e
somente se a resposta for positiva executará o real servidor do serviço.
16


Cabe ressaltar que a funcionalidade do tcpd não está disponível para
serviços baseados em UDP, já que estes não possuem um controle
adequado para isto.

Um exemplo de um servidor executado via tcpd, no arquivo
/etc/inetd.conf:

#servidor observado pelo tcpd
finger stream tcp nowait root /usr/sbin/tcpd in.fingerd

Sem a adição de qualquer controle de acesso, o cliente não perceberá
qualquer diferença de um serviço finger usual e um servidor finger
utilizando tcpd, exceto pelo fato de que todas as requisições serão
registradas pelo syslog.

O controle de acesso é implementado através de dois arquivos
denominados /etc/hosts.allow e /etc/hosts.deny.
17


Números de porta e protocolo
Dados viajam por uma rede TCP/IP em pacotes chamados datagramas.


Cada datagrama é endereçado individualmente com o seguinte
formato:

➢Endereço IP do host de origem e destino, para o qual deve ser
entregue;

➢Número de protocolo do protocolo de transporte que deve controlar o
pacote depois de serem entregues ao host;

➢E número de porta do serviço ao qual os dados no pacote são
destinados.


No Linux os protocolos e os números de portas podem ser predefinidos
em dois arquivos, /etc/protocols para os protocolos e /etc/services
para o número de portas.
18


Protocolos no arquivo /etc/protocols
ip      0      IP              # internet protocol, pseudo protocol
number
#hopopt 0      HOPOPT          #   hop-by-hop options for ipv6
icmp    1      ICMP            #   internet control message protocol
igmp    2      IGMP            #   internet group management protocol
ggp     3      GGP             #   gateway-gateway protocol
ipencap 4      IP-ENCAP        #   IP encapsulated in IP (officially
``IP'')
st2     5      ST2             # ST2 datagram mode (RFC 1819)
tcp     6      TCP             # transmission control protocol
cbt     7      CBT             # CBT, Tony Ballardie
<A.Ballardie@cs.ucl.ac.uk>
egp     8      EGP             # exterior gateway protocol
igp     9      IGP             # any private interior gateway (Cisco:
for IGRP)
bbn-rcc 10     BBN-RCC-MON     #   BBN RCC Monitoring
nvp     11     NVP-II          #   Network Voice Protocol
pup     12     PUP             #   PARC universal packet protocol
argus   13     ARGUS           #   ARGUS
emcon   14     EMCON           #   EMCON
xnet    15     XNET            #   Cross Net Debugger
chaos   16     CHAOS           #   Chaos
udp     17     UDP             #   user datagram protocol
19


O arquivo /etc/protocols


O arquivo /etc/protocols identifica o número de cada protocolo. De
forma que, o protocolos possam se comunicar.


Apesar do tamanho do arquivo, só duas entradas são realmente
significantes, que são as entradas tcp e udp.


A tcp, define o número de protocolo para o protocolo de transporte
TCP, e seu número de identificação é o 6.


O udp, define o número de protocolo para o protocolo de transmissão
UDP como 17.


As inúmeros outras entradas neste arquivo definem números de
protocolos de roteamento e protocolos experimentais que não são
usados com freqüência.
20

O arquivo /etc/services de mapeamento de serviços:

echo             7/tcp
echo             7/udp
daytime         13/tcp
daytime         13/udp
qotd            17/tcp   quote       #Quote of the Day
qotd            17/udp   quote       #Quote of the Day
msp             18/tcp   #Message Send Protocol
msp             18/udp   #Message Send Protocol
chargen         19/tcp   ttytst source       #Character Generator
chargen         19/udp   ttytst source       #Character Generator
ftp-data        20/tcp   #File Transfer [Default Data]
ftp-data        20/udp   #File Transfer [Default Data]
ftp             21/tcp   #File Transfer [Control]
ftp             21/udp   #File Transfer [Control]
ssh             22/tcp   #Secure Shell Login
ssh             22/udp   #Secure Shell Login
telnet          23/tcp
telnet          23/udp
#               24/tcp   any private   mail system
#               24/udp   any private   mail system
smtp            25/tcp   mail          #Simple Mail Transfer
smtp            25/udp   mail          #Simple Mail Transfer
21


O arquivo /etc/services

O arquivo /etc/services identifica o número de porta de rede padrão
para que a camada de transporte possa entregar seus dados a camada
de aplicação.

Os números de porta para serviços bem conhecidos são padrões na
Internet, assim você não deve mudar o número de porta de um serviço
existente.

Existem inúmeros serviços de rede, para citar apenas duas, o telnet
usa a porta 23 e executa sobre o protocolo de transporte TCP. O DNS,
usa a porta 53 e TCP e UDP.

Existe um número de porta para o UDP assim como existe um mesmo
número de porta para o TCP.

O inetd e o xinetd podem monitorar qualquer porta listada no arquivo
/etc/services. Qual protocolo e números de portas são monitorados
por estes daemons está definido no arquivo /etc/inetd.conf para
inetd ou no arquivo /etc/xinetd.conf para xinetd. Estes arquivos,
por sua vez definem quais serviços são inicializados por estes
daemons.
22

O xinetd
Uma alternativa ao inetd é o Extended Internet Services Daemon
(xinetd). O xinetd é configurado no arquivo /etc/xinetd.conf.
O arquivo xinetd.conf define valores padrões para cinco atributos
diferentes:


instances – Especifica o número máximo de daemons (serviços) que
podem estar sendo executados simultaneamente, para qualquer tipo de
serviço. Se este número for 2 significara que não mais de dois serviços
telnetd serão executados simultaneamente. O valor pode ser definido
como ilimitado através de UNLIMITED.
log_type – Define onde as mensagens de log serão registradas. FILE
teste, informa para registrar a atividade no arquivo /var/log/teste. Já
com a configuração em SYSLOG informa para informar na saída
padrão /var/log/messagen.
log_on_success – Define a informação que deve ser registrada quando
uma conexão bem –sucedida é feita a um serviço xinetd. Neste caso
estamos registrando o endereço da máquina (HOTS) e o número de
processo associado a este (PID).
log_on_failure – Define a informação que é registrada quando uma
tentativa para conectar a um serviço for malsucedida.
23


Configurando o xinetd
Cps – ajusta os limites de conexão, por segundo, de cada
serviço. O primeiro valor é o valor para o número de
conexões aceitas em um único segundo. O segundo valor indica
quantos segundos deve-se esperar antes de vazer qualquer
conexão nova, caso o primeiro valor for excedido. O cps
impede que um serviço possa monopolizar os recursos, é muito
útil em ataques de negação de serviço.


A opção includedir, indica o diretório que contem os
arquivos de configuração de cada serviço, ter arquivos
separados para cada serviço melhora o gerenciamento dos
serviços.
Os arquivos contidos em /etc/xinetd.d representam todos os
serviço que podem ser iniciados através de xinetd neste
sistema.
Outros serviços de rede estão disponíveis neste servidor por
que são iniciados através de scripts de inicialização, mas o
xinetd só pode começar um serviço para o qual tenha um
arquivo de configuração.
O nome de cada arquivo normalmente representa claramente o
nome do serviço exemplo telnetd para o serviço TELNET.
24


Configurando o xinetd



# Some defaults, and include /etc/xinetd.d/

defaults
{
        instances             =   25
       per_source             =   10
        log_type              =   SYSLOG authpriv
        log_on_success        =   HOST PID USERID
        log_on_failure        =   HOST USERID
}

includedir /etc/xinetd.d
25


Configurando o Telnet com o xinetd
Service é o nome oficial do serviço do arquivo /etc/services
socket_type - especifica o tipo de socket usado para este serviço,
normalmente dgram para UDP e stream para TCP.
wait – informa ao xinetd se deve esperar pelo serviço para liberar a
porá antes de escutar por mais conexões daquele serviço. Yes significa
esperar (normalmente para dgram), e no não esperar (para stream).
user – Define o nome do usuário que deverá executar o serviço.
server – Caminho que indica o programa a ser executado em caso de
atividade na porta.
server_args - Argumentos passados ao programa.
log_on_success e log_on_failure – funciona da mesma maneira que
inetd.
nice – Define o valor nice que xinetd usa quando lança o programa de
servidor.
disable – Informa ao xinetd se este serviço foi desabilidado (yes) ou
habilitado (no).
26


Configurando o Telnet com o xinetd


service telnet
{
        disable = no                 // no para ativado e yes para
desativado
         flags           = REUSE
         socket_type     = stream
         protocol        = tcp
         wait            = no
         user            = root
         server          = /usr/sbin/in.telnetd
        log_on_failure   += USERID
}
27


Configurando o ftpd com o xinetd

service ftp
{
        disable          =   yes
        flags            =   REUSE
        socket_type      =   stream
        instances        =   50
        wait             =   no
        user             =   root
        server           =   /usr/sbin/proftpd
        log_on_success   =   HOST PID
        log_on_failure   =   HOST
}

Contenu connexe

En vedette

En vedette (8)

TUTORIAL WINDOWS SERVER 2003
TUTORIAL WINDOWS SERVER 2003TUTORIAL WINDOWS SERVER 2003
TUTORIAL WINDOWS SERVER 2003
 
Protocolos; SNMP, TELNET, SSH
Protocolos; SNMP, TELNET, SSHProtocolos; SNMP, TELNET, SSH
Protocolos; SNMP, TELNET, SSH
 
Telnet
TelnetTelnet
Telnet
 
Telnet
TelnetTelnet
Telnet
 
Telnet
TelnetTelnet
Telnet
 
Telnet
TelnetTelnet
Telnet
 
TELNET Protocol
TELNET ProtocolTELNET Protocol
TELNET Protocol
 
FTP - File Transfer Protocol
FTP - File Transfer ProtocolFTP - File Transfer Protocol
FTP - File Transfer Protocol
 

Similaire à Camada Aplicação e inetd

Seguranca da Informação - Filtros/tcpd
Seguranca da Informação - Filtros/tcpdSeguranca da Informação - Filtros/tcpd
Seguranca da Informação - Filtros/tcpdLuiz Arthur
 
Linux network administration | Curso de Redes | 3Way Networks
Linux network administration | Curso de Redes | 3Way NetworksLinux network administration | Curso de Redes | 3Way Networks
Linux network administration | Curso de Redes | 3Way Networks3Way Networks
 
Redes prática - NFS
Redes prática - NFSRedes prática - NFS
Redes prática - NFSLuiz Arthur
 
Configurando ambiente ltsp_4.2_com_mt1000_lx_ta2000lx
Configurando ambiente ltsp_4.2_com_mt1000_lx_ta2000lxConfigurando ambiente ltsp_4.2_com_mt1000_lx_ta2000lx
Configurando ambiente ltsp_4.2_com_mt1000_lx_ta2000lxjrrsouzaj
 
Alta Disponibilidade na Prática utilizando servidores Linux
Alta Disponibilidade na Prática utilizando servidores LinuxAlta Disponibilidade na Prática utilizando servidores Linux
Alta Disponibilidade na Prática utilizando servidores Linuxelliando dias
 
Manual UFCD 0839.pptx
Manual UFCD 0839.pptxManual UFCD 0839.pptx
Manual UFCD 0839.pptxFormador2
 
WANs e Roteadores Cap. 4 Outros Dispositivos - CCNA 3.1 Wellington Pinto de O...
WANs e Roteadores Cap. 4 Outros Dispositivos - CCNA 3.1 Wellington Pinto de O...WANs e Roteadores Cap. 4 Outros Dispositivos - CCNA 3.1 Wellington Pinto de O...
WANs e Roteadores Cap. 4 Outros Dispositivos - CCNA 3.1 Wellington Pinto de O...Wellington Oliveira
 
Protocolos de Redes: TFTP e DHCP
Protocolos de Redes: TFTP e DHCPProtocolos de Redes: TFTP e DHCP
Protocolos de Redes: TFTP e DHCPDaniel Brandão
 
Protocolos TCP IP UDP
Protocolos TCP IP UDPProtocolos TCP IP UDP
Protocolos TCP IP UDPAndré Nobre
 
Redes de Computadores 2 - Conceitos Gerais
Redes de Computadores 2 - Conceitos GeraisRedes de Computadores 2 - Conceitos Gerais
Redes de Computadores 2 - Conceitos GeraisJosé Ronaldo Trajano
 
Redes de computadores 2 - Protocolos
Redes de computadores 2 - ProtocolosRedes de computadores 2 - Protocolos
Redes de computadores 2 - ProtocolosJosé Ronaldo Trajano
 
Linux - Servidor de FTP VSFTPD
Linux - Servidor de FTP VSFTPDLinux - Servidor de FTP VSFTPD
Linux - Servidor de FTP VSFTPDFrederico Madeira
 
TcpiP redes internas externas
TcpiP redes internas externasTcpiP redes internas externas
TcpiP redes internas externasCarlos Pereira
 
Personalizacao Do Sistema E Servicos
Personalizacao Do Sistema E ServicosPersonalizacao Do Sistema E Servicos
Personalizacao Do Sistema E Servicosarturramisio
 

Similaire à Camada Aplicação e inetd (20)

Seguranca da Informação - Filtros/tcpd
Seguranca da Informação - Filtros/tcpdSeguranca da Informação - Filtros/tcpd
Seguranca da Informação - Filtros/tcpd
 
Linux network administration | Curso de Redes | 3Way Networks
Linux network administration | Curso de Redes | 3Way NetworksLinux network administration | Curso de Redes | 3Way Networks
Linux network administration | Curso de Redes | 3Way Networks
 
Redes prática - NFS
Redes prática - NFSRedes prática - NFS
Redes prática - NFS
 
Configurando ambiente ltsp_4.2_com_mt1000_lx_ta2000lx
Configurando ambiente ltsp_4.2_com_mt1000_lx_ta2000lxConfigurando ambiente ltsp_4.2_com_mt1000_lx_ta2000lx
Configurando ambiente ltsp_4.2_com_mt1000_lx_ta2000lx
 
Ntop
NtopNtop
Ntop
 
Alta Disponibilidade na Prática utilizando servidores Linux
Alta Disponibilidade na Prática utilizando servidores LinuxAlta Disponibilidade na Prática utilizando servidores Linux
Alta Disponibilidade na Prática utilizando servidores Linux
 
Manual UFCD 0839.pptx
Manual UFCD 0839.pptxManual UFCD 0839.pptx
Manual UFCD 0839.pptx
 
WANs e Roteadores Cap. 4 Outros Dispositivos - CCNA 3.1 Wellington Pinto de O...
WANs e Roteadores Cap. 4 Outros Dispositivos - CCNA 3.1 Wellington Pinto de O...WANs e Roteadores Cap. 4 Outros Dispositivos - CCNA 3.1 Wellington Pinto de O...
WANs e Roteadores Cap. 4 Outros Dispositivos - CCNA 3.1 Wellington Pinto de O...
 
Protocolos de Redes: TFTP e DHCP
Protocolos de Redes: TFTP e DHCPProtocolos de Redes: TFTP e DHCP
Protocolos de Redes: TFTP e DHCP
 
02 configurando placa de rede
02   configurando placa de rede02   configurando placa de rede
02 configurando placa de rede
 
Apostila internet
Apostila internetApostila internet
Apostila internet
 
Protocolos TCP IP UDP
Protocolos TCP IP UDPProtocolos TCP IP UDP
Protocolos TCP IP UDP
 
Redes de Computadores 2 - Conceitos Gerais
Redes de Computadores 2 - Conceitos GeraisRedes de Computadores 2 - Conceitos Gerais
Redes de Computadores 2 - Conceitos Gerais
 
Redes de computadores 2 - Protocolos
Redes de computadores 2 - ProtocolosRedes de computadores 2 - Protocolos
Redes de computadores 2 - Protocolos
 
Linux - Servidor de FTP VSFTPD
Linux - Servidor de FTP VSFTPDLinux - Servidor de FTP VSFTPD
Linux - Servidor de FTP VSFTPD
 
Servicos de internet
Servicos de internetServicos de internet
Servicos de internet
 
Dhcp com controle_ip_compartilhamento
Dhcp com controle_ip_compartilhamentoDhcp com controle_ip_compartilhamento
Dhcp com controle_ip_compartilhamento
 
TcpiP redes internas externas
TcpiP redes internas externasTcpiP redes internas externas
TcpiP redes internas externas
 
Conceitos associado às redes
Conceitos associado às redesConceitos associado às redes
Conceitos associado às redes
 
Personalizacao Do Sistema E Servicos
Personalizacao Do Sistema E ServicosPersonalizacao Do Sistema E Servicos
Personalizacao Do Sistema E Servicos
 

Plus de Luiz Arthur

Pint of Science - Cibersegurnça x ciberameaças: Até onde você está seguro?
Pint of Science - Cibersegurnça x ciberameaças: Até onde você está seguro?Pint of Science - Cibersegurnça x ciberameaças: Até onde você está seguro?
Pint of Science - Cibersegurnça x ciberameaças: Até onde você está seguro?Luiz Arthur
 
Desafios da cibersegurança - ontem, hoje e amanhã
Desafios da cibersegurança - ontem, hoje e amanhãDesafios da cibersegurança - ontem, hoje e amanhã
Desafios da cibersegurança - ontem, hoje e amanhãLuiz Arthur
 
Slides - Uma abordagem autonômica para mitigar ciberataques em redes de compu...
Slides - Uma abordagem autonômica para mitigar ciberataques em redes de compu...Slides - Uma abordagem autonômica para mitigar ciberataques em redes de compu...
Slides - Uma abordagem autonômica para mitigar ciberataques em redes de compu...Luiz Arthur
 
Uma Arquitetura Autonômica para Detecção e Reação a Ameaças de Segurança em R...
Uma Arquitetura Autonômica para Detecção e Reação a Ameaças de Segurança em R...Uma Arquitetura Autonômica para Detecção e Reação a Ameaças de Segurança em R...
Uma Arquitetura Autonômica para Detecção e Reação a Ameaças de Segurança em R...Luiz Arthur
 
Detecção de alertas de segurança em redes de computadores usando redes sociai...
Detecção de alertas de segurança em redes de computadores usando redes sociai...Detecção de alertas de segurança em redes de computadores usando redes sociai...
Detecção de alertas de segurança em redes de computadores usando redes sociai...Luiz Arthur
 
Evaluating the Utilization of Twitter Messages as a Source of Security Alerts
Evaluating the Utilization of Twitter Messages as a Source of Security AlertsEvaluating the Utilization of Twitter Messages as a Source of Security Alerts
Evaluating the Utilization of Twitter Messages as a Source of Security AlertsLuiz Arthur
 
Análise de Mensagens de Segurança Postadas no Twitter
Análise de Mensagens de Segurança Postadas no TwitterAnálise de Mensagens de Segurança Postadas no Twitter
Análise de Mensagens de Segurança Postadas no TwitterLuiz Arthur
 
match making e propaganda na web
match making e propaganda na webmatch making e propaganda na web
match making e propaganda na webLuiz Arthur
 
Mineração de dados no Gmail e Facebook
Mineração de dados no Gmail e FacebookMineração de dados no Gmail e Facebook
Mineração de dados no Gmail e FacebookLuiz Arthur
 
Invasao kernel.org
Invasao kernel.orgInvasao kernel.org
Invasao kernel.orgLuiz Arthur
 
Núcleo do Linux (Kernel Linux)
Núcleo do Linux (Kernel Linux)Núcleo do Linux (Kernel Linux)
Núcleo do Linux (Kernel Linux)Luiz Arthur
 
Palestra Ferramentas de Segurança Open Source v.2
Palestra Ferramentas de Segurança Open Source v.2Palestra Ferramentas de Segurança Open Source v.2
Palestra Ferramentas de Segurança Open Source v.2Luiz Arthur
 
Palestra mau uso da tecnologia
Palestra mau uso da tecnologiaPalestra mau uso da tecnologia
Palestra mau uso da tecnologiaLuiz Arthur
 
UTFPR-inventario-patrimonio-laboratorio-e105
UTFPR-inventario-patrimonio-laboratorio-e105UTFPR-inventario-patrimonio-laboratorio-e105
UTFPR-inventario-patrimonio-laboratorio-e105Luiz Arthur
 
01 programação - introdução computação
01 programação - introdução computação01 programação - introdução computação
01 programação - introdução computaçãoLuiz Arthur
 
Bibliografia recomendada - programação C
Bibliografia recomendada - programação CBibliografia recomendada - programação C
Bibliografia recomendada - programação CLuiz Arthur
 
Bibliografia recomendada-programacao-python
Bibliografia recomendada-programacao-pythonBibliografia recomendada-programacao-python
Bibliografia recomendada-programacao-pythonLuiz Arthur
 
Bibliografia recomendada-seguranca
Bibliografia recomendada-segurancaBibliografia recomendada-seguranca
Bibliografia recomendada-segurancaLuiz Arthur
 
Bibliografia recomendada-redes
Bibliografia recomendada-redesBibliografia recomendada-redes
Bibliografia recomendada-redesLuiz Arthur
 

Plus de Luiz Arthur (20)

Pint of Science - Cibersegurnça x ciberameaças: Até onde você está seguro?
Pint of Science - Cibersegurnça x ciberameaças: Até onde você está seguro?Pint of Science - Cibersegurnça x ciberameaças: Até onde você está seguro?
Pint of Science - Cibersegurnça x ciberameaças: Até onde você está seguro?
 
Desafios da cibersegurança - ontem, hoje e amanhã
Desafios da cibersegurança - ontem, hoje e amanhãDesafios da cibersegurança - ontem, hoje e amanhã
Desafios da cibersegurança - ontem, hoje e amanhã
 
Slides - Uma abordagem autonômica para mitigar ciberataques em redes de compu...
Slides - Uma abordagem autonômica para mitigar ciberataques em redes de compu...Slides - Uma abordagem autonômica para mitigar ciberataques em redes de compu...
Slides - Uma abordagem autonômica para mitigar ciberataques em redes de compu...
 
NAPSOL
NAPSOLNAPSOL
NAPSOL
 
Uma Arquitetura Autonômica para Detecção e Reação a Ameaças de Segurança em R...
Uma Arquitetura Autonômica para Detecção e Reação a Ameaças de Segurança em R...Uma Arquitetura Autonômica para Detecção e Reação a Ameaças de Segurança em R...
Uma Arquitetura Autonômica para Detecção e Reação a Ameaças de Segurança em R...
 
Detecção de alertas de segurança em redes de computadores usando redes sociai...
Detecção de alertas de segurança em redes de computadores usando redes sociai...Detecção de alertas de segurança em redes de computadores usando redes sociai...
Detecção de alertas de segurança em redes de computadores usando redes sociai...
 
Evaluating the Utilization of Twitter Messages as a Source of Security Alerts
Evaluating the Utilization of Twitter Messages as a Source of Security AlertsEvaluating the Utilization of Twitter Messages as a Source of Security Alerts
Evaluating the Utilization of Twitter Messages as a Source of Security Alerts
 
Análise de Mensagens de Segurança Postadas no Twitter
Análise de Mensagens de Segurança Postadas no TwitterAnálise de Mensagens de Segurança Postadas no Twitter
Análise de Mensagens de Segurança Postadas no Twitter
 
match making e propaganda na web
match making e propaganda na webmatch making e propaganda na web
match making e propaganda na web
 
Mineração de dados no Gmail e Facebook
Mineração de dados no Gmail e FacebookMineração de dados no Gmail e Facebook
Mineração de dados no Gmail e Facebook
 
Invasao kernel.org
Invasao kernel.orgInvasao kernel.org
Invasao kernel.org
 
Núcleo do Linux (Kernel Linux)
Núcleo do Linux (Kernel Linux)Núcleo do Linux (Kernel Linux)
Núcleo do Linux (Kernel Linux)
 
Palestra Ferramentas de Segurança Open Source v.2
Palestra Ferramentas de Segurança Open Source v.2Palestra Ferramentas de Segurança Open Source v.2
Palestra Ferramentas de Segurança Open Source v.2
 
Palestra mau uso da tecnologia
Palestra mau uso da tecnologiaPalestra mau uso da tecnologia
Palestra mau uso da tecnologia
 
UTFPR-inventario-patrimonio-laboratorio-e105
UTFPR-inventario-patrimonio-laboratorio-e105UTFPR-inventario-patrimonio-laboratorio-e105
UTFPR-inventario-patrimonio-laboratorio-e105
 
01 programação - introdução computação
01 programação - introdução computação01 programação - introdução computação
01 programação - introdução computação
 
Bibliografia recomendada - programação C
Bibliografia recomendada - programação CBibliografia recomendada - programação C
Bibliografia recomendada - programação C
 
Bibliografia recomendada-programacao-python
Bibliografia recomendada-programacao-pythonBibliografia recomendada-programacao-python
Bibliografia recomendada-programacao-python
 
Bibliografia recomendada-seguranca
Bibliografia recomendada-segurancaBibliografia recomendada-seguranca
Bibliografia recomendada-seguranca
 
Bibliografia recomendada-redes
Bibliografia recomendada-redesBibliografia recomendada-redes
Bibliografia recomendada-redes
 

Camada Aplicação e inetd

  • 1. 1 Camada de Aplicação A camada de Aplicação contém todos os protocolos de nível mais alto do modelo TCP/IP . Alguns dos protocolos de aplicação são: DNS (Domain Name System): Usado para identificar máquinas através  de nomes em vez de endereços IP; Telnet: Protocolo de terminal virtual, usado para controlar remotamente uma máquina; FTP (File Transfer Protocol): Usado na transferência de arquivos pela rede; HTTP (Hyper Text Transfer Protocol): Usado na transferência de  documentos hipermídia. Os serviços (aplicações) de rede são iniciados de duas maneiras: ●Pomo programas independentes que permanecem na memória o tempo todo. ●Por demanda, isto é, conforme são necessários (ocupando espaço na memória somente quanto estão sendo utilizados).
  • 2. 2 inetd - O Super-Servidor de Internet Serviços de redes são executados por programas denominados servidores de rede, um programa servidor de rede é chamado em inglês de daemon. Servidores de rede são programas que abrem portas de rede (referente ao modelo TCP/IP) e tais portas ficam aguardando por solicitações de clientes. Quando uma solicitação de cliente é recebida, o servidor de rede cria um processo filho, o qual trata aquela conexão específica, enquanto o processo pai continua à escutar na porta, aguardando novas solicitações de clientes da rede. É claro que um serviço de rede consome recursos do computador onde está sendo executado, tal como memória, espaço de processamento, recursos de rede, etc.
  • 3. 3 Porém, praticamente todo sistema Like-UNIX executa uma espécie de Super-servidor, que pode ser visto como um servidor de servidores. O Super-servidor é capaz de criar conectores para uma série de serviços de rede e ouvir todas as portas de rede simultaneamente e quando uma máquina remota solicita algum de seus serviços, o Super- servidor percebe o fato e aciona o servidor específico da porta envolvida. Por exemplo, imagine que você tenha uma máquina servindo de Firewall/Roteador e está é uma máquina que não possui monitor, teclado e mouse (já que um Firewall não deve ser utilizado diretamente). Assim, você provavelmente irá precisar de um serviço como Telnet para gerenciar a máquina remotamente, mas você não quer que o Telnet ocupe recursos do computador enquanto o Telnet não está sendo utilizado, você então irá utilizar o inetd (Super-Servidor de Internet). O inetd irá ficar responsável por abrir a porta de rede referente ao Telnet e ficar monitorando pedidos a este serviço, tão logo alguém solicite o Telnet o inetd irá carregar o Telnet na memória, o usuário remoto irá usar o Telnet normalmente a conexão for finalizada o inetd irá retirar o serviço da memória e continua a “ouvir” a porta.
  • 4. 4 Portanto, o Super-servidor conhecido por inetd (Internet Daemon) é um servidor de servidores que é utilizado dentro outros, para poupar recursos da máquina servidora, centralizar a ativação de serviços, etc. O inetd é normalmente inicializado quando o sistema é inicializado. O inetd recebe uma lista de serviços a serem monitorados a partir de um arquivo de configuração denominado /etc/inetd.conf. O arquivo /etc/inetd.conf é um arquivo texto e contém como informação como e quais são os serviços de rede fornecidos pelo inetd. Uma linha típica do arquivo /etc/inetd.conf é composta pelos seguintes campos: <serviço> <tipo> <protocolo> <espera> <usuário> <servidor> <linha_de_comando> finger stream tcp nowait nobody /usr/libexec/fingerd fingerd -s O significado de cada campo do /etc/inetd.conf é o seguinte: Serviço ou Name - Este campo é o nome do serviço a ser disponibilizado. Os nomes do serviço podem ser vistos no arquivo /etc/services. Este nome mapeia o número de porta ao serviço.
  • 5. 5 Tipo ou Type - Este é o tipo de soquete (socket-type) oferecido ao serviço para a entrega de dados. Os dois tipos de soquetes para entrega de dados mais utilizados são: dgram para o serviço de datagramas (sem conexão) e stream para o serviço de fluxo de dados orientado a conexão. Protocolo ou Protocol - É o nome do protocolo usado pelo serviço, é definido no arquivo /etc/protocols. O nome mapeia um número de protocolo. São na maioria tcp e udp. Espera ou Wait-status - indica se o daemon invocado pelo inetd é capaz de lidar com seu próprio socket ou não. Sockets do tipo dgram precisam usar a opção wait, enquanto daemons de sockets tipo stream, os quais geralmente são multi-threaded, devem usar a opção nowait. O tipo wait geralmente repassa múltiplos sockets para um único daemon, enquanto nowait dispara um daemon filho para cada novo socket.
  • 6. 6 O número máximo de daemons filho (de conexões abertas para um serviço de rede) que o inetd pode disparar pode ser ajustado usando a opção usando-se uma barra (/) após as opções nowait. Se um limite de dez instâncias de um daemon em particular é necessária, um /10 deve ser colocado após a opção nowait. Outra opção pode ser ativada para limitar o número máximo de conexões a partir de um único lugar (host) para um daemon em particular. Assim, um valor de dez nesta opção limitaria qualquer endereço IP a se conectar a determinado serviço a dez tentativas por minuto. Isto é útil para evitar consumo de recursos intencional ou não e ataques de Negação de Serviço (Denial of service - DoS) para a máquina. Neste campo, wait ou o máximo de filhos e máximo conexões por host são opcionais. Estas opções são todas utilizadas pela configuração padrão do daemon fingerd, como visto aqui: finger stream tcp nowait/3/10 nobody /usr/libexec/fingerd fingerd -s
  • 7. 7 Usuário ou UID - Nome de usuário sob o qual o serviço é executado. Normalmente este é root, mas por razoes de segurança, alguns processos executam sob o ID do usuário nobody. Servidor ou Server - Caminho do programa de servidor a ser executado. As entradas compartilham o mesmo caminho /usr/sbin/tcp, mas este realmente não é o caminho para o servidor ftp, telnet ou qualquer outro servidor. Na realidade, o tcpd é um recurso de segurança usado pelo Linux, sendo que o tcpd chamado de TCP Wrapper (invólucro de TCP), é usado para prover segurança veremos mais este serviço posteriormente. Linha de comando ou Arguments - São argumentos de linha de comando que são passados ao programa de servidor. O primeiro argumento sempre é o nome do programa de servidor executado. A lista de argumentos parece exatamente com o comando se estivesse sendo digitado em um prompt shell. Atenção, dentro do arquivo /etc/inetd.conf (tal como, a maioria dos arquivos de configuração do Linux), tudo que preceder um # é um comentário e será ignorado pelo script de inicialização do indetd
  • 8. 8 Exemplo do arquivo /etc/inetd.conf: # daytime stream tcp nowait root internal # daytime dgram udp wait root internal time stream tcp nowait root internal time dgram udp wait root internal # These are standard services: # Very Secure File Transfer Protocol (FTP) server. #ftp stream tcp nowait root /usr/sbin/tcpd vsftpd # Professional File Transfer Protocol (FTP) server. ftp stream tcp nowait root /usr/sbin/tcpd proftpd # Telnet server: telnet stream tcp nowait root /usr/sbin/tcpd in.telnetd # The comsat daemon notifies the user of new mail when biff is set to y: comsat dgram udp wait root /usr/sbin/tcpd in.comsat # Shell, login, exec and talk are BSD protocols #shell stream tcp nowait root /usr/sbin/tcpd in.rshd -L #login stream tcp nowait root /usr/sbin/tcpd in.rlogind # exec stream tcp nowait root /usr/sbin/tcpd in.rexecd # talk dgram udp wait root /usr/sbin/tcpd in.talkd #ntalk dgram udp wait root /usr/sbin/tcpd in.talkd
  • 9. 9 Habilitando ou Desabilitando um serviço no inetd Para habilitar um serviço de rede pelo inetd, basta editar o arquivo /etc/inetd.conf e descomentar (retirar o #) da linha referente ao serviço desejado, ou ainda, caso a linha não exista acrescentar uma linha passando os parâmetros para iniciar o serviço via inetd. Por exemplo, caso queira-se iniciar o Telnet com o Super-servidor inetd, basta procurar a seguinte linha do Telnet no arquivo /etc/inetd.conf e descomenta-la, tal como: Antes de editar: # Telnet server: #telnet stream tcp nowait root /usr/sbin/tcpd in.telnetd Depois de editar: # Telnet server: telnet stream tcp nowait root /usr/sbin/tcpd in.telnetd
  • 10. 10 Habilitando ou Desabilitando um serviço no inetd Após, descomentar ou acrescentar o serviço desejado faz se necessário reiniciar o servidor inetd, isto é possível através da execução do script de inicialização /etc/rc.d/rc.inedt. O diretório /etc/rc.d/ contém a grande maioria dos scripts de inicialização de serviços da rede. Assim, para re-iniciar o inetd execute: #/etc/rc.d/rc.inedt restart ou #/etc/rc.d/rc.inedt stop #/etc/rc.d/rc.inedt start Tão logo o servidor seja reiniciado o serviço estará pronto para ser utilizado. Lembre-se sempre que você alterar o arquivo /etc/inetd.conf é obrigatório que o servidor seja reiniciado para a alteração ser valida, caso contrário, a alteração será válida somente quando o sistema for reinicializado.
  • 11. 11 Habilitando ou Desabilitando um serviço no inetd Para desabilitar um serviço de rede pelo inetd, basta editar o arquivo /etc/inetd.conf e comentar (adicionar no inicio da linha um #) na linha referente ao serviço, não recomenda-se a exclusão da linha, pois quando for necessário ativar o serviço o usuário terá que refazer a linha novamente, o que pode ser muito trabalhosol Por exemplo, caso queira-se desativar o Telnet com o Super-servidor inetd, basta procurar a linha do Telnet no arquivo /etc/inetd.conf e comenta-la, tal como: Antes de editar: # Telnet server: telnet stream tcp nowait root /usr/sbin/tcpd in.telnetd Depois de editar: # Telnet server: # telnet stream tcp nowait root /usr/sbin/tcpd in.telnetd Reinicie o servidor após a alteração, para que o processo torne-se válido.
  • 12. 12 Servidores de rede independentes Executar um servidor via Super-servidores é uma forma de se iniciar um serviço de rede, porém outro tipo muito utilizado é executar o programa de forma independente (não via inetd ou xinetd). Serviços de rede que são iniciados de forma independente ocupam recursos da máquina estando o serviço sendo usados ou não, o que é o contrário dos serviços executados pelo inetd e xinetd. Cada técnica de inicialização de serviços de rede tem suas próprias vantagens e desvantagens: • No caso do Super-servidor os serviços só serão carregados na memória quando o serviço estiver sendo realmente utilizado, isto poupa recursos da máquina, entretanto um serviço executado pelo inetd provavelmente terá um tempo de resposta mais lento do que serviços executados independentes, pois o processo não estar na memória e terá de ser carregado para à memória para sua execução; • Já um serviço de rede executado de forma independente tem um tempo de resposta mais rápida aos pedidos de conexões de rede, pois estes serviços já estão na memória e prontos para uso, porém caso não estejam sendo utilizados estes serviços continuarão na memória ocupando um espaço de memória que poderia ser útil para outras tarefas.
  • 13. 13 Iniciando um servidor FTP de forma independente (standalone) Quando um serviço é muito requisitado, talvez não seja uma boa escolha iniciá-lo com o Super-servidor, mas sim de forma independente (em inglês, standalone). Pois, iniciando um serviço em standalone o serviço estará sempre pronto para responder os pedidos dos usuários. O Very Secure FTP Daemon ou simplemente vsftpd, é um bom servidor de FTP e funciona tanto em modo Super-servidor quanto standalone. Para a configuração do vsftpd, é necessário editar o arquivo /etc/vsftpd.conf. Para colocar o vsftpd de forma que este funcione em standalone, é necessário apenas descomentar (retirar o #) da seguinte linha: listen=YES.
  • 14. 14 Iniciando um servidor FTP de forma independente (standalone) Para que o vsftpd funcione em standalone o este serviço não pode estar sendo executado com o inetd ou xinetd. Após, editar o arquivo /etc/vsftpd.conf e colocá-lo em standalone, faz-se necessário iniciar o servidor chamando o comando vsftpd. Iniciando em standalone, é possível executar o comando ps -ax e verificar que vsftpd está direto na memória. Para desligar o servidor FTP agora é necessário “matar” o processo vsftpd. Isso pode ser feito com o comando killall vsftpd.
  • 15. 15 A funcionalidade do tcpd para Controle de Acesso Habilita um computador para acesso pela rede envolve muitos riscos de segurança. Uma ferramenta útil nestes casos é o servidor tcpd, que é um servidor de observação. Para os serviços TCP que se deseje monitorar ou protegendo, o tcpd poderá ser acionado ao invés do programa servidor. O programa tcpd registra todas as requisições através do servidor de mensagens do sistema denominado syslog, verificando se a máquina remota tem permissão ou não de usar o serviço solicitado por ela e somente se a resposta for positiva executará o real servidor do serviço.
  • 16. 16 Cabe ressaltar que a funcionalidade do tcpd não está disponível para serviços baseados em UDP, já que estes não possuem um controle adequado para isto. Um exemplo de um servidor executado via tcpd, no arquivo /etc/inetd.conf: #servidor observado pelo tcpd finger stream tcp nowait root /usr/sbin/tcpd in.fingerd Sem a adição de qualquer controle de acesso, o cliente não perceberá qualquer diferença de um serviço finger usual e um servidor finger utilizando tcpd, exceto pelo fato de que todas as requisições serão registradas pelo syslog. O controle de acesso é implementado através de dois arquivos denominados /etc/hosts.allow e /etc/hosts.deny.
  • 17. 17 Números de porta e protocolo Dados viajam por uma rede TCP/IP em pacotes chamados datagramas. Cada datagrama é endereçado individualmente com o seguinte formato: ➢Endereço IP do host de origem e destino, para o qual deve ser entregue; ➢Número de protocolo do protocolo de transporte que deve controlar o pacote depois de serem entregues ao host; ➢E número de porta do serviço ao qual os dados no pacote são destinados. No Linux os protocolos e os números de portas podem ser predefinidos em dois arquivos, /etc/protocols para os protocolos e /etc/services para o número de portas.
  • 18. 18 Protocolos no arquivo /etc/protocols ip 0 IP # internet protocol, pseudo protocol number #hopopt 0 HOPOPT # hop-by-hop options for ipv6 icmp 1 ICMP # internet control message protocol igmp 2 IGMP # internet group management protocol ggp 3 GGP # gateway-gateway protocol ipencap 4 IP-ENCAP # IP encapsulated in IP (officially ``IP'') st2 5 ST2 # ST2 datagram mode (RFC 1819) tcp 6 TCP # transmission control protocol cbt 7 CBT # CBT, Tony Ballardie <A.Ballardie@cs.ucl.ac.uk> egp 8 EGP # exterior gateway protocol igp 9 IGP # any private interior gateway (Cisco: for IGRP) bbn-rcc 10 BBN-RCC-MON # BBN RCC Monitoring nvp 11 NVP-II # Network Voice Protocol pup 12 PUP # PARC universal packet protocol argus 13 ARGUS # ARGUS emcon 14 EMCON # EMCON xnet 15 XNET # Cross Net Debugger chaos 16 CHAOS # Chaos udp 17 UDP # user datagram protocol
  • 19. 19 O arquivo /etc/protocols O arquivo /etc/protocols identifica o número de cada protocolo. De forma que, o protocolos possam se comunicar. Apesar do tamanho do arquivo, só duas entradas são realmente significantes, que são as entradas tcp e udp. A tcp, define o número de protocolo para o protocolo de transporte TCP, e seu número de identificação é o 6. O udp, define o número de protocolo para o protocolo de transmissão UDP como 17. As inúmeros outras entradas neste arquivo definem números de protocolos de roteamento e protocolos experimentais que não são usados com freqüência.
  • 20. 20 O arquivo /etc/services de mapeamento de serviços: echo 7/tcp echo 7/udp daytime 13/tcp daytime 13/udp qotd 17/tcp quote #Quote of the Day qotd 17/udp quote #Quote of the Day msp 18/tcp #Message Send Protocol msp 18/udp #Message Send Protocol chargen 19/tcp ttytst source #Character Generator chargen 19/udp ttytst source #Character Generator ftp-data 20/tcp #File Transfer [Default Data] ftp-data 20/udp #File Transfer [Default Data] ftp 21/tcp #File Transfer [Control] ftp 21/udp #File Transfer [Control] ssh 22/tcp #Secure Shell Login ssh 22/udp #Secure Shell Login telnet 23/tcp telnet 23/udp # 24/tcp any private mail system # 24/udp any private mail system smtp 25/tcp mail #Simple Mail Transfer smtp 25/udp mail #Simple Mail Transfer
  • 21. 21 O arquivo /etc/services O arquivo /etc/services identifica o número de porta de rede padrão para que a camada de transporte possa entregar seus dados a camada de aplicação. Os números de porta para serviços bem conhecidos são padrões na Internet, assim você não deve mudar o número de porta de um serviço existente. Existem inúmeros serviços de rede, para citar apenas duas, o telnet usa a porta 23 e executa sobre o protocolo de transporte TCP. O DNS, usa a porta 53 e TCP e UDP. Existe um número de porta para o UDP assim como existe um mesmo número de porta para o TCP. O inetd e o xinetd podem monitorar qualquer porta listada no arquivo /etc/services. Qual protocolo e números de portas são monitorados por estes daemons está definido no arquivo /etc/inetd.conf para inetd ou no arquivo /etc/xinetd.conf para xinetd. Estes arquivos, por sua vez definem quais serviços são inicializados por estes daemons.
  • 22. 22 O xinetd Uma alternativa ao inetd é o Extended Internet Services Daemon (xinetd). O xinetd é configurado no arquivo /etc/xinetd.conf. O arquivo xinetd.conf define valores padrões para cinco atributos diferentes: instances – Especifica o número máximo de daemons (serviços) que podem estar sendo executados simultaneamente, para qualquer tipo de serviço. Se este número for 2 significara que não mais de dois serviços telnetd serão executados simultaneamente. O valor pode ser definido como ilimitado através de UNLIMITED. log_type – Define onde as mensagens de log serão registradas. FILE teste, informa para registrar a atividade no arquivo /var/log/teste. Já com a configuração em SYSLOG informa para informar na saída padrão /var/log/messagen. log_on_success – Define a informação que deve ser registrada quando uma conexão bem –sucedida é feita a um serviço xinetd. Neste caso estamos registrando o endereço da máquina (HOTS) e o número de processo associado a este (PID). log_on_failure – Define a informação que é registrada quando uma tentativa para conectar a um serviço for malsucedida.
  • 23. 23 Configurando o xinetd Cps – ajusta os limites de conexão, por segundo, de cada serviço. O primeiro valor é o valor para o número de conexões aceitas em um único segundo. O segundo valor indica quantos segundos deve-se esperar antes de vazer qualquer conexão nova, caso o primeiro valor for excedido. O cps impede que um serviço possa monopolizar os recursos, é muito útil em ataques de negação de serviço. A opção includedir, indica o diretório que contem os arquivos de configuração de cada serviço, ter arquivos separados para cada serviço melhora o gerenciamento dos serviços. Os arquivos contidos em /etc/xinetd.d representam todos os serviço que podem ser iniciados através de xinetd neste sistema. Outros serviços de rede estão disponíveis neste servidor por que são iniciados através de scripts de inicialização, mas o xinetd só pode começar um serviço para o qual tenha um arquivo de configuração. O nome de cada arquivo normalmente representa claramente o nome do serviço exemplo telnetd para o serviço TELNET.
  • 24. 24 Configurando o xinetd # Some defaults, and include /etc/xinetd.d/ defaults { instances = 25 per_source = 10 log_type = SYSLOG authpriv log_on_success = HOST PID USERID log_on_failure = HOST USERID } includedir /etc/xinetd.d
  • 25. 25 Configurando o Telnet com o xinetd Service é o nome oficial do serviço do arquivo /etc/services socket_type - especifica o tipo de socket usado para este serviço, normalmente dgram para UDP e stream para TCP. wait – informa ao xinetd se deve esperar pelo serviço para liberar a porá antes de escutar por mais conexões daquele serviço. Yes significa esperar (normalmente para dgram), e no não esperar (para stream). user – Define o nome do usuário que deverá executar o serviço. server – Caminho que indica o programa a ser executado em caso de atividade na porta. server_args - Argumentos passados ao programa. log_on_success e log_on_failure – funciona da mesma maneira que inetd. nice – Define o valor nice que xinetd usa quando lança o programa de servidor. disable – Informa ao xinetd se este serviço foi desabilidado (yes) ou habilitado (no).
  • 26. 26 Configurando o Telnet com o xinetd service telnet { disable = no // no para ativado e yes para desativado flags = REUSE socket_type = stream protocol = tcp wait = no user = root server = /usr/sbin/in.telnetd log_on_failure += USERID }
  • 27. 27 Configurando o ftpd com o xinetd service ftp { disable = yes flags = REUSE socket_type = stream instances = 50 wait = no user = root server = /usr/sbin/proftpd log_on_success = HOST PID log_on_failure = HOST }