Primário Xinetd

O Xinetd é um tutor que gerencia o acesso ao seu computador pela Internet. É um daemon que executa o tempo todo e escuta em todas as portas solicitações de conexão ou serviço. Se você não executar um servidor, não precisará do xinetd. No entanto, mesmo que seu computador seja apenas para uso doméstico, pode ser necessário permitir que outras pessoas acessem os serviços no seu computador em algum momento no futuro. Quando você faz, você precisará instalar o xinetd para proteger seu computador contra atividades maliciosas.

Sistema operacional

O utilitário xinetd foi escrito para sistemas Unix e Unix-like. Portanto, ele será instalado no Linux e Mac OS, mas não no Windows. O programa é gratuito e pode ser acessado no GitHub.

Você pode obter o programa neste repositório principal e também há uma bifurcação do código. Este é um programa conhecido e confiável que foi baixado e instalado várias vezes, portanto você não deve se preocupar com os perigos do programa como um falso malicioso.

Objetivo do xinetd

O sistema xinet destina-se a funcionar como um servidor. Você provavelmente sabe que em uma conexão típica à Internet, um computador entra em contato com outro. O computador que inicia o contato é chamado de “cliente“E o programa que é contatado é o”servidor.O motivo usual da conexão é para que o cliente possa obter um serviço do servidor. No entanto, o computador contatado precisa ter um programa em execução, aguardando solicitações. Esta é a função do xinetd.

O requisito básico para o xinetd é que ele receba solicitações e encaminhe-as para o aplicativo correto, indicado pelo número da porta que está escrito no cabeçalho da conexão ou solicitação de serviço que chega. O programa xinetd, na verdade, não fornece o serviço solicitado, mas atua como um gatekeeper.

Alternativas: xinetd vs inetd

Os desenvolvedores do xinetd não foram as primeiras pessoas a ter a idéia de um programa que escuta na rede os pedidos recebidos. De fato, o xinetd pretende ser uma melhoria no programa original que executou esta tarefa, chamada inetd.

O nome “xinetd” é uma abreviação de “daemon de serviços de Internet estendidos”. O “daemon de serviços da Internet” descreve o original inetd. Com o inetd, você obtém o mesmo monitoramento de solicitação do servidor que o xinetd fornece. No entanto, esse daemon não possui mecanismos de defesa e, portanto, agora é considerado inseguro.

O velho inetd não trabalhava sozinho. Ele passou solicitações para tcpd, que verificou nos arquivos de permissões (hosts.allow e hosts.deny) Como o nome sugere, o tcpd lida com solicitações de conexão TCP. No entanto, ele também examina portas UDP, por isso é uma implementação de interface de Camada de Transporte. Você também pode ver a menção de um wrapper TCP – este é apenas outro nome para o tcpd. A inclusão do tcpd adicionou algumas melhorias no controle de acesso. No entanto, o processo de permissão foi conduzido por dois arquivos preenchidos manualmente e, portanto, não era uma solução de segurança muito abrangente.

Recursos do Xinetd

O modo de operação xinetd é semelhante ao do inetd combinado com o tcpd. No entanto, a solução xinetd possui recursos de segurança muito melhores que a combinação inetd / tcpd. Os recursos do daemon incluem:

• controle de acesso para TCP e UDP
• log de eventos que registra sucesso e falha da conexão
• controle de acesso com base em segmentos de tempo
• limite de servidor simultâneo – defesa contra ataques de negação de serviço (DoS)
• limite de tamanho do arquivo de log
• alocação de serviços a diferentes interfaces, permitindo que certos serviços sejam limitados à rede privada
• função de proxy, incluindo conversão de endereço de rede

O Xinetd é capaz de operar como mediador de Serviços RPC. No entanto, essa função não está muito bem implementada. A falta de recurso de segurança no RPC reduziu a demanda de acesso a esse serviço, por isso é duvidoso que os desenvolvedores do xinetd gastem tempo aperfeiçoando sua interface RPC.

Métodos de controle de acesso

Como inetd, xinetd permite permitir ou bloquear conexões de acordo com o endereço IP do solicitante. Com o inetd, você também pode identificar fontes de conexão permitidas e bloqueadas por nome de host ou por nome de domínio. Cada uma dessas opções requer um procedimento de pesquisa. No caso da opção de nomes de host, você precisará configurar esses nomes no sistema DNS da sua própria rede. Para domínios, provavelmente seria melhor confiar no sistema DNS público.

A escolha de identificar solicitantes por endereço IP, nome do host ou nome de domínio é com você. Contudo, manter o endereço IP cria conexões mais rapidamente porque elimina a necessidade de uma fase de pesquisa.

Configuração do sistema

Para usar o xinetd, você primeiro precisa instalá-lo e depois atualize o arquivo de configuração. Essencialmente, o arquivo de configuração é seu centro de comando para o xinetd. Como este programa é um daemon, depois que você o inicia, continuará a correr para sempre. Não é um utilitário interativo que você pode ajustar na linha de comando. Toda a sua comunicação com o programa ocorre através do arquivo de configuração.

O daemon continuará a verificar o arquivo de configuração sempre que receber uma solicitação do mundo exterior. Ele não carrega a configuração na memória quando é inicializada. Que significa você pode ajustar o desempenho do daemon enquanto ele estiver em execução alterando as instruções mantidas no arquivo de configuração.

O arquivo de configuração para o xinet é muito mais importante que os sistemas de configuração para outros utilitários. Isso ocorre porque você pode alterar as instruções para o daemon através da configuração sem precisar parar o programa xinetd e reiniciá-lo.

Configurando o arquivo de configuração

Procure o arquivo /etc/xinetd.conf. Este é o principal arquivo de configuração do programa e atua como uma tabela de pesquisa que o aplicativo lê para descobrir quais conexões permitir e quais serviços chamar.

Você pode criar o arquivo xinetd.conf a partir de um arquivo existente. inetd.conf arquivo com o xconv.pl programa, que faz parte do pacote que você pode baixar do repositório GitHub para xinetd. Execute o programa de conversão com o seguinte comando:

/usr/local/sbin/xconv.pl < /etc/inetd.conf > /etc/xinetd.conf

O novo arquivo de configuração não é perfeito e precisará de mais modificações antes de iniciar o xinetd.

Seção Padrões do Arquivo de Configuração

Ao procurar no seu arquivo xinetd.conf recém-gerado, você precisa se concentrar em duas seções principais de configuração. O primeiro deles é o padrões seção e o segundo é o Serviços seção.

Como você provavelmente já adivinhou, a seção padrão informa ao xinetd o que fazer se não encontrar instruções específicas para sua tarefa atual na seção serviços.

Algumas opções principais que você pode definir na seção de padrões são:

• Apenas de
• no_access
• log_type
• log_on_success
• log_on_failure
• instâncias
• per_source

As próximas seções explicam essas opções com mais detalhes.

Condições de acesso

Apenas de e no_access efetivamente executar a mesma tarefa, que é bloquear (sem acesso) ou permitir (somente_de) endereços ou intervalos de endereços específicos. É aconselhável usar uma dessas opções para bloquear tudo por padrão e criar uma lista de serviços mais abaixo no arquivo de configuração. Com essa estratégia, você se cobre se ocorrer um evento que não considerou.

Essas duas opções também são comandos válidos para incluir na seção de serviços. Então você pode comece banindo tudo por padrão e depois adicione serviços. Se houver uma seção de serviço relacionada ao tipo de solicitação de conexão que o xinetd recebe, ela não examinará a seção de padrões da configuração.

As instruções de only_from e no_access em uma descrição para um serviço substituem as instruções only_from e no_access na seção de padrões.

O formato para essas duas opções é

=

Lembre-se de que os endereços podem ser expressos como endereços IP, nomes de host ou nomes de domínio. No entanto, é melhor manter os endereços IP. Você pode usar a notação CIDR para especificar um intervalo. Aqui estão dois exemplos de como você pode usar essas opções:

no_access = 0.0.0.0/0

Essa é provavelmente a linha mais comum na seção de padrões, pois bloqueia todos. A seção de padrões está lá apenas no arquivo de configuração para informar ao xinetd o que fazer no caso de uma solicitação de serviço que não esteja coberta na seção de serviços. Você deve trabalhar no pressuposto de que poderá fornecer instruções específicas para cada tipo de serviço que o seu computador possa fornecer; portanto, é razoável afirmar que todas as outras solicitações estão bloqueadas. Como o porteiro de uma festa VIP exclusiva dizia: “Se você não está na lista, não está entrando”.

Uma alternativa a essa estratégia é deixar todos entrarem. Você implementaria isso com:

only_from = 0.0.0.0/0

Essa política realmente não faz sentido na seção de padrões. A seção padrão é mencionada apenas se você não tiver fornecido instruções para um serviço; portanto, quando o xinetd recorre aos padrões, há um caso em que não há instruções fornecidas. Portanto, permitir o acesso nessas circunstâncias resultaria em um erro, porque você não disse ao xinetd o que fazer com a solicitação. É lógico usar essa opção catch-all only_from na descrição de um serviço, portanto, esta mensagem informa ao xinetd para permitir que solicitações de todas as fontes possíveis usem esse serviço.

Infelizmente, há um recurso das opções only_from e no_access que criariam um conflito se você implementasse uma política conforme descrito acima. Isso é, no_access e only_from são globais e o xinetd verifica os dois toda vez que uma tarefa é executada. Portanto, se você tiver definido os dois, o daemon validará a solicitação recebida com relação à instrução no_access na seção de padrões, mesmo que exista uma configuração de serviço válida..

Essa peculiaridade de não acesso e apenas ser global pode ser superada ao se decidir sobre uma política de sempre usando um ou outro no seu arquivo xinetd.conf. É prática comum ficar com only_from e ignorar a opção no_access. Você pode criar uma instrução abrangente, deixando a lista de endereços em branco na seção de padrões, ou seja, “only_from = ”E isso permitirá que o programa xinetd use a configuração only_from nas descrições de serviços. Isso ocorrerá sem gerar conflito, pois a seção “default” only_from será substituída pela configuração only_from do serviço.

Irritantemente, se você não colocar uma instrução only_from ou no_access na seção de padrões, o xinetd permitirá todas as conexões que você não abordou na seção de serviços, o que provavelmente criará um erro.

O formato para listar vários endereços como parâmetros de ambas as opções é deixar um espaço entre cada endereço (sem vírgulas). Você também pode incluir intervalos CIDR na lista.

Comandos do arquivo de log

o log_type, log_on_success, e log_on_failure todas as opções funcionam juntas. Cada um possui uma série de constantes que você precisa alimentar na opção como parâmetros.

Use o atributo log_type para forneça o caminho e o nome de um arquivo de log e use os atributos log_on_success e log_on_failure para especificar quais campos devem ser gravados no registro do arquivo de log para cada evento.

Por exemplo, você escreveria um endereço de arquivo de log com:

log_type = ARQUIVO / usr / log / internetlog

Outra opção disponível com o atributo log_type é SYSLOG, que define o nível de mensagem para esses eventos que serão relatados pelo syslogd. Os valores possíveis são:

• daemon
• auth
• do utilizador
• local0-7

Um exemplo seria:

log_type = SYSLOG local1

o SYLOG atributo não é essencial e é muito menos importante que o atributo ARQUIVO opção. Você realmente precisa dar ao seu xinetd o nome de um arquivo de log para gravar; você não precisa especificar o nível de syslog para mensagens de evento.

As opções de relatório disponíveis para log_on_success são:

• PID – 0 se for um serviço xinetd interno
• HOST – endereço do cliente
• USERID – identidade do usuário remoto
• EXIT – status de saída do processo
• DURATION – período de duração da sessão

As opções de relatório para log_on_failure são:

• HOST – endereço do cliente
• USERID – identidade do usuário remoto
• ATTEMPT – registra uma tentativa de acesso com falha
• RECORD – todas as informações disponíveis sobre o cliente

Você pode incluir várias opções em cada linha log_on_success e log_on_failure e elas devem ser separadas por espaços sem nenhum tipo de pontuação. Por exemplo:

log_type = ARQUIVO / usr / log / internetlog
log_on_success = SAÍDA DA DURAÇÃO DO USERID DO PID DO HOST
log_on_failure = HOST USERID ATTEMPT RECORD

É prática comum manter as instruções log_type, log_in_success e log_on_failure em linhas sucessivas no arquivo.

Controles de capacidade

Mais duas opções que você precisa colocar no xinetd.conf limitam o número de conexões simultâneas que o servidor deve aceitar. Esse é um fator importante e é uma maneira simples, mas poderosa, de combater ataques de negação de serviço (DoS). As duas opções que implementam essa estratégia são instâncias e per_source.

A opção de instâncias na seção de padrões especifica o número de conexões que o xinetd permitirá que sejam executadas simultaneamente e a opção per_source especifica o número de solicitações de conexão às quais o daemon responderá do mesmo endereço de origem. Ataques distribuídos de negação de serviço (DDoS) contornará o limite per_source, mas não a opção de instâncias. Infelizmente, a implementação desse limite de serviço bloqueará usuários genuínos pela duração do ataque.

O formato para essas duas opções é muito direto:

= número.

O valor per_source deve ser menor que o valor das instâncias.

Exemplo da seção Padrões

Reunindo todos os detalhes explicados nesta seção, sua instrução padrão xinetd.conf deve ficar assim:

padrões
{
instâncias = 20
per_source = 5
log_type = ARQUIVO / usr / log / internetlog
log_on_success = SAÍDA DA DURAÇÃO DO USERID DO PID DO HOST
log_on_failure = HOST USERID ATTEMPT RECORD
only_from =
}

Cada arquivo xinetd.conf deve ter uma instrução padrão. Você não precisa ter nenhuma declaração de serviço.

Seções de configuração de serviço

Para cada um dos serviços que você deseja que seu servidor ofereça, escreva uma seção de instruções de serviço em xinetd.conf. Se você não gravar nenhum serviço no arquivo de configuração, o xinetd utilizará as especificações estabelecidas na seção de padrões. Você também pode sobrescrever as configurações definidas nas seções padrões, restaurando esses atributos com valores diferentes na seção escrita para definir um serviço.

Tipos de serviço

Os atributos disponíveis para a seção de serviços são diferentes para cada uma das três categorias de serviço. Esses são:

• INTERNO
• NÃO-LISTADO
• RPC

A categoria de serviço (INTERNAL / UNLISTED / RPC) pode ser especificada com o atributo tipo. No entanto, esse atributo não é obrigatório e geralmente é deixado de fora.

Definições de atributo de serviço

Ao escrever uma especificação de atributo, todos os campos são separados por espaços ou retornos de carro – você não usa nenhuma forma de separador ou pontuação na definição.

O layout de uma declaração de serviço é o mesmo para a seção Padrões:

serviço
{
  valor do operador de atributo
}

O operador usado para instruções de atributo geralmente é igual a (“=“). Muito poucos atributos permitem que valores sejam adicionados a uma lista existente com “+=“Ou retirado de uma lista com”-=”- nesses dois casos, você escreve o operador sem as aspas mostradas aqui.

Aqui estão os atributos disponíveis para um INTERNO tipo de serviço:

• socket_type
• bandeiras
• legais
• esperar
• protocolo (se não estiver listado em / etc / services)
• porta (se não estiver listado em / etc / services)
• cps
• access_times

Os atributos disponíveis para um RPC serviço são:

• socket_type
• bandeiras
• do utilizador
• servidor
• server_args
• legais
• esperar
• protocolo
• rpc_version
• rpc_number
• cps
• access_times

o NÃO-LISTADO tipos de serviço podem ter qualquer um dos seguintes atributos:

• socket_type
• bandeiras
• do utilizador
• servidor
• server_args
• carregamento máximo
• legais
• esperar
• protocolo (se não estiver listado em / etc / services)
• porta (se não estiver listado em / etc / services)
• access_times
• cps

Objetivos do atributo de serviço

Os significados desses atributos são mostrados na tabela abaixo:

AttributeDescription

tipo	INTERNO, RPC, NÃO LISTADO ou INTERNO NÃO LISTADO
socket_type	stream (TCP), dgram (UDP), raw (acesso direto ao IP) ou seqpacket ().
Eu iria	crie um nome exclusivo para este serviço
bandeiras	explicado abaixo da tabela
do utilizador	especifica a prioridade do servidor
servidor	O caminho e o programa do serviço
args do servidor	argumentos para passar com a chamada de serviço
carregamento máximo	número de processos simultâneos para um serviço
legais	aumenta a prioridade do serviço
esperar	sim não – bloqueia ou permite o processamento simultâneo de novas solicitações
protocolo	pode ficar de fora se o protocolo estiver listado em / etc / protocols
porta	o número da porta também deve existir em / etc / services e ter o mesmo número
rpc_version	versão do RPC
rpc_number	Número RPC
cps	limite de conexão, o segundo argumento é opcional e fornece o número de segundos para aguardar quando o limite atingir
access_times	horas do dia em que um serviço pode ser executado
ligar	responder a conexões com um endereço IP específico
redirecionar	encaminha solicitações de serviço para outro computador

o bandeiras O atributo pode ter os seguintes valores:

IDONLY: aceita apenas conexões de clientes que possuem um servidor de identificação

NORETRIA: impede a criação de um novo processo em falha de conexão

NAMEINARGS: o primeiro argumento em server_args é o servidor valor. Usado ao chamar tcpd

Além dos atributos acima, as opções disponíveis na seção de padrões também podem ser gravadas na definição de um serviço. Esses são:

• Apenas de
• no_access
• log_type
• log_on_success
• log_on_failure
• instâncias
• per_source

O uso desses atributos novamente substituirá quaisquer valores definidos para eles na seção de padrões. No entanto, lembre-se de que o Apenas de e no_access atributos são globais, portanto, você deve organizar o uso dessas opções para evitar parâmetros conflitantes.

Exemplos de declaração de serviço

Aqui estão dois exemplos da definição de um serviço.

serviço ntalk
{
socket_type = dgram
espera = sim
usuário = ninguém
server = /usr/sbin/in.ntalkd
access_times = 7: 00-12: 30 13: 30-21: 00
only_from = 192.168.1.0/24
}

ftp de serviço
{
socket_type = stream
espera = não
usuário = raiz
server = /usr/sbin/in.ftpd
server_args = -l
instâncias = 4
nice = 10
}

Observe o uso de access_times no ntalk definição. Isso usa dois intervalos de tempo com os tempos de e para separados por um traço (“-”) sem espaços. Os dois intervalos de tempo são separados por um espaço. As definições de hora usam o formato de relógio de 24 horas.

o Apenas de atributo no ntalk A definição limita o acesso a esse serviço, para que apenas endereços na rede local possam usá-lo.

o ntalk serviço tem um socket_type do dgram, o que significa que é um serviço UDP. o socket_type no ftp definição é corrente, o que significa que este é um serviço TCP.

Crie várias instâncias de um serviço

A definição de serviços usa o nome do serviço como seu identificador por padrão. No entanto, convém criar várias cópias de um serviço e atribuir a cada atributo diferente. Como o nome do serviço precisa corresponder ao nome usado no / etc / services arquivo, seria impossível obter várias versões de um serviço em execução. No entanto, o atributo id permite essa estratégia operacional.

Um uso muito comum desse cenário seria quando você deseja criar diferentes servidores FTP para acesso interno e externo. Por esse método, você pode manter o armazenamento de arquivos para o escritório completamente separado dos arquivos para download disponibilizados ao público em geral.

Nesse caso de uso, você definiria “Service ftp” duas vezes. Você atribuiria a uma instância o atributo id = ftp-interno e o outro id = ftp-externo. A partir de então, o xinetd pode distinguir entre os dois. Para tornar cada instância disponível para diferentes públicos, você usaria o Apenas de atributo para limitar o acesso ao serviço FTP interno a apenas endereços na rede e o acesso ao serviço externo FTP a todos os endereços que não sejam de rede.

Vincular um endereço a um serviço

O cenário de criação de serviços diferentes para usuários internos e externos pode ser bastante ajudado pelo atributo de ligação. O termo “ligar”É freqüentemente usado na programação TCP. Geralmente significa associar uma conexão a uma porta, criando assim um ID para a sessão. Nesse caso, no entanto, “vincular” significa algo diferente. No exemplo do acesso interno e externo ao servidor FTP, você pode vincular o endereço de rede do computador à instância interna do ftp e o endereço IP público desse computador à instância externa do ftp.

Neste exemplo, pode ser possível deixar de fora o atributo only_from na definição do serviço. No entanto, é mais seguro deixar essas restrições. Portanto, a definição completa de seus servidores FTP internos e externos seria:

ftp de serviço
{
id = ftp-externo
server = /usr/sbin/in.ftpd
server_args = -l
instâncias = 4
only_from = 0.0.0.0/0
bind = 202.19.244.130
}

ftp de serviço
{
id = ftp-interno
socket_type = stream
server = /usr/sbin/in.ftpd
server_args = -l
only_from = 192.168.1.0/24
bind = 192.168.1.5
}

Essa estratégia exige que o servidor FTP tenha um endereço IP estático alocado para acesso público. Além disso, você precisaria configurar o servidor DHCP para reservar o mesmo endereço para o servidor FTP interno. Embora o cenário acima funcione quando um único computador é usado para acesso interno e externo, você também pode alocar os endereços de computadores separados para cada instância de FTP.

Desativar serviços específicos do inetd

tem três serviços xinetd que fornecem informações sobre o sistema.

• servidores: relatório sobre os servidores em uso
• services: relatório sobre serviços disponíveis, seus protocolos e portas
• xadmin: combina os dois comandos acima

Esses serviços são uma fraqueza de segurança porque eles podem ser usados ​​por hackers para obter informações sobre sua rede e servidor. Portanto, é melhor desativá-los. Você pode fazer isso com o atributo desativado, que entra no seu padrões definição. Basta incluir a seguinte linha na seção de padrões para remover esses recursos:

disabled = serviços de servidores xadmin

Com as alterações do arquivo de configuração detalhadas acima, agora você pode começar a usar o xinetd.

Executando o xinetd

Você inicia o xinetd na linha de comando. O comando também pode ser executado a partir de um arquivo em lotes, para que você possa adicioná-lo aos procedimentos de inicialização do computador. O programa pode ser executado com as seguintes opções:

SwitchOptionDescription

-d		Modo de depuração
-syslog	syslog_facility	O mesmo que log_type SYSLOG nos padrões do arquivo conf
-filelog	arquivo de log	O mesmo que log_type FILE no arquivo conf padrão
-f	config_file	Especifica o arquivo de configuração – o padrão é /etc/xinetd.conf
-pidfile	pid_file	Escreva o ID do processo em pid_file
-ficar vivo		Nunca terminar
-limite	proc_limit	Número máximo de processos que podem ser executados simultaneamente
-logprocs	limite	Número máximo de servidores que podem ser executados simultaneamente
-versão		Imprimir a versão xinetd
-inetd_compat		Leia o arquivo /etc/inetd.conf e o arquivo de configuração xinetd
-cc	intervalo	Executar verificações de consistência a cada intervalo de segundos

Também é possível iniciar o xinetd sem nenhuma opção.

Use xinetd

Se você possui um computador Linux, talvez o xinetd já esteja instalado. Você pode verificar executando xinetd -version. Se o seu computador estiver executando o inetd, é provável que você não esteja executando o Linux. Substitua o programa pelo xinetd e converta seu arquivo de configuração da compatibilidade inetd para o uso do xinetd, conforme explicado acima.

Você usa o xinetd no momento? Deixe uma mensagem no Comentários seção abaixo para compartilhar suas experiências com a comunidade.

Veja também: 15 Melhores Servidores Syslog Gratuitos

Imagem: Conexão de rede à Internet do Pixabay. Licenciado sob CC0 Creative Commons