(Internet Super-Server Daemon)
De uma maneira geral existem duas formas de se rodar um serviço no mundo Unix/Like que são o standalone e o inetd. O standalone é serviço/daemon independente de qualquer outro, provendo todos os recursos necessários para que o mesmo funcione (ex: SSH, HTTP, SMTP etc). Já o inetd (Internet “super-server” daemon) é um daemon que “ouve” várias portas TCP e/ou UDP que estão relacionadas a serviços que não podem fazer por eles mesmos. Em outras palavras, o “inetd” tem a função de ouvir conexões de vários serviços de rede (internet sockets) através de um único daemon (ex: FTP e TelNet).
O “inetd” conhece qual serviço o socket corresponde e invoca um programa para o serviço requisitado. Essencialmente, o inetd permite rodar um daemon que invocar várias outros, reduzindo a carga no sistema. Só para constar o inetd pode habilitar o libwrap connection logging, contudo os serviços internet, contidos nele, não.
Instalação
# apt-get install openbsd-inetd (existe também o inetutils-inetd que é equivalente e o xinetd que tem opções mais avançadas -> será visto nesse artigo)
Arquivo de configuração
# vi /etc/inetd.conf (veja a seguir duas figuras do conteúdo existente nesse arquivo)
Os serviços são adicionados no arquivo de configuração do INETD que fica em “/etc/inetd.conf”, sendo que seguem o seguinte padrão:
- service_name: nome do serviço propriamente dito que fica relacionado dentro do “/etc/services”. Contudo, quando é usado um serviço baseado em um SUN-RPC deve verificar dentro do “/etc/rpc”;
- sock_type: deve ser substituídos por um desses: stream, dgram, raw, rdm ou seqpacket, dependendo se o socket é um Stream, Datagrama, RAW, RDM (Reliably Delivered Message) ou Sequenced Packet Socket:
- stream: streaming, geralmente usado com o protocolo TCP;
- dgram: datagrama, geralmente usado com o protocolo UDP;
- RAW sockets: é uma maneira de transpor (bypass) o Kernel em relação a manipulação da pilha TCP/IP. Em vez de seguir o padrão de encapsulamento e desencapsulamento ao passar pelas camadas do TCP/IP manipulado pelo Kernel, com o RAW o pacote é passado para aplicação tomar conta desse encapsulamento e desencapsulamento. A aplicação que usa o pacote RAW é a responsável pelo seu cabeçalho, analisando o pacote (cabeçalho + dados), ou seja, todas as coisas que a pilha TCP/IP no Kernel normalmente fazia. Em outras palavras, um socket RAW é um socket que faz/elabora pacotes, sobrepondo (bypass) o processamento TCP/IP feito pelo Kernel e enviando tais pacotes para a aplicação que saberá como tratá-los. Só para conhecimento, uma aplicação que usa o socket RAW recebe todo o pacote (cabeçalho + dados) em oposição de uma aplicação que usa o socket padrão que recebe somente os dados (payload) sem o cabeçalho;
- proto: as opções mais comuns são udp e tcp. o udp é refere User Datagram Protocol e o tcp ao Transmission Control Protocol. O udp e tcp são usados corrente ao IPv4, contudo no futuro teremos o IPv6, se houve a necessidade de especificar explicidamente a versão, use udp4, udp6, tcp4 ou tcp6. Na verdade o proto é referente a um protocolo especificado em “/etc/protocols” ou “unix”. O “udp” e “tcp” são dois protocolos dentre outros que constam dentro desse arquivo e o “unix” é usado para especificar um socket Unix;
- flags: as opções mais comuns são wait e nowait. Eles são usados para dizer a “inetd” se ele deveria esperar por um programa servidor pelo retorno ou continuar o processamento da conexão no socket. Servidores de Stream (Stream Servers) são usualmente marcados como “nowait’;
- user: essa entrada contém o nome de usuário que rodará (run) o servidor. Isso permite que os servidores tenham menos permissões que o “root”. Um opcional nome de grupo pode ser especificado colocando um ponto final ao nome de usuário seguido do nome do grupo (ex:user.group). Também se pode especificar o grupo e não especificar o usuário (ex: .group);
- server_path: contém o caminho do program que será executado pelo “inetd” quando uma requisição for feito no socket:
- internal: se o serviço é provido internamente, a entrada deve ser “internal”;
- /usr/sbin/tcpd: é muito usual ver essa entra “/usr/sbin/tcpd”. Ele é um facility para o controle de acesso para os internet services (serviços da Internet). O tcpd é um programa que pode ser configurado para monitorar as requisições à serviços do “inet” como o telnet, finger, ftp, exec, rsh, rlogin, tftp, talk, comsat e outros serviços que tem um mapeamento de um-para-um em arquivos executáveis (ssh, http etc). Devido a essas características, ele é usado para gerenciar as conexões. Existem dois modos de operação para monitorar as conexões com o "tcpd": um é através do inetd e o outro é através de um daemon que possue a biblioteca compartilha chamada "libwrap";
- args: programa normalmente usado. Se o serviço é provido internamente (server_path: internal) a palavra “internal” pode ser usado. Ex: “/usr/sbin/in.ftpd” e “/usr/sbin/in.telnetd”;
Restartando o serviço
# /etc/init.d/openbsd-inetd restart (ao modificar “/etc/inetd.conf” e/ou “/etc/inetd.d/” é necessário restartar o serviço)
(Internet Super-Server Daemon Advanced)
Substitui o “inetd” com muitos recursos avançados. xinetd tem mecanismos de controle de acesso, capacidade de registro/logging extensivo, a habilidade de disponibilização do serviço baseada na hora e colocação de limites no número de servidores que podem iniciar, redirecionar o strem TCP para um host remoto e porta, interligar um serviço especifico à uma interface de rede específica (ex: poderia se ter diferentes serviços rodar na mesma porta, só que em interfaces de rede diferentes).
Instalação
# apt-get install xinetd (o inetd será removido, contudo o “/etc/inetd.conf” não)
Obs: todos os serviços inetd já instalados continuarão funcionando. Na verdade, ao restartar o xinetd, ele lerá o arquivo de configuração do inetd (/etc/inetd.conf).
Arquivo de configuração
# ls /etc/xinetd/ (diretório que é lido ao restartar o xinetd. Na verdade no “/etc/xinetd.conf” existe um include chamado “includedir /etc/xinetd.d” adicionando tal diretório)
# vi /etc/xinetd.conf (arquivo de configuração do xinetd)
Ao instalar qualquer programa/serviço xinetd, ele ainda será colocado em “/etc/inetd.conf” e a seguinte mensagem aparecerá:
A seguir é mostrado o conteúdo do arquivo “/etc/xinetd.d/time” que é instalado por padrão pelo “xinetd”. Coloquei essa figura só para termos uma idéia da diferença entre o "xinetd" e o "inetd". Veja que o "xinetd" é estruturado uma opção por linha e o "inetd" fica tudo numa linha só:
Algumas das opções mais usadas dentro dos arquivos de configuração do "xinetd" são:
- disable: as opções são “yes” e “no”, habilitando e desabilitando o serviço, respectivamente;
- type: qualquer das seguintes combinações;
- RPC: se for um serviço RCP;
- INTERNAL: se for um serviço provido pelo xinetd;
- TCPMUX/TCPMUXPLUS: se for um serviço que estiver de acordo com a RFC 1078;
- UNLISTED: se o serviço não estiver listado nos arquivos de sistema padrão (“/etc/rpc” para serviços RPC ou “/etc/services” para serviços não RCP);
- id: identifica unicamente um serviço. É útil para diferenciar um serviço que usa diferentes protocolos (ex: tcp e udp). Por padrão, o id é o mesmo que o nome do serviço;
- service_name: idem do arquivo de configuração do “inet”;
- sock_type: idem do arquivo de configuração do “inet”;
- protocol: idem do arquivo de configuração do “inet”;
- user: idem do arquivo de configuração do “inet”, menos em relação ao grupo;
- group: essa entrada contém o nome do grupo que rodará (run) o servidor;
- wait: idem do arquivo de configuração do “inet”;
- server: idem ao campo “args” do arquivo de configuração do “inet”. Ex: “server = /usr/sbin/in.ftpd”;
- server_args: determina os argumentos passados para o servidor, ou seja, as opções. Em contraste ao inet que não pode passar argumentos;
- only_from: determina qual host poderá acessar um serviço. Parecido como o TCP_Wrapper;
- no_access: determina qual host não poderá acessar um serviço. Parecido como o TCP_Wrapper;
- access_times: determina o intervalo de tempo quando um serviço estará disponível;
- log_type: determina qual é a saída do serviço de log;
- port: determina a porta usada pelo serviço. O padrão é usar as portas especificadas em “/etc/services”;
- redirect: permite que o serviço TCP seja redirecionado para um outro host, seguindo o padrão “redirect =
; - bind: permite especifica a “interface de rede/endereço IP” que será usado por um serviço, seguindo o padrão “bind =
; - interface: idem;
- include: inclui um arquivo como parte do arquivo de configuração xinetd;
- includedir: inclui um diretório como parte do arquivo de configuração xinetd;
- bind: permite especifica a “interface de rede/endereço IP” que será usado por um serviço, seguindo o padrão “bind =
Exemplo:
# /etc/init.d/xinetd restart (ao modificar “/etc/inetd.conf”, “/etc/xinetd.conf” e/ou “/etc/xinetd.d/” é necessário restartar o serviço)
Referências Bibliográgicas