Protocolo SSH, principal aplicação e diferença do Telnet. Protocolo de rede SSH seguro, básico

SSH (Capsula segura- Casca protegida) -- isto é protocolo de rede fornecendo autenticação segura, conexão e transferência segura de dados entre hosts da rede, criptografando o tráfego que passa por ele, com possível compactação de dados. Outro importante característica funcional, é a capacidade de criar túneis criptografados seguros para transmissão segura em um ambiente inseguro (por exemplo, a Internet), outros protocolos de rede, bem como a capacidade de compactar o tráfego. Além disso, o protocolo SSH funciona muito bem com encaminhamento (encaminhamento, encaminhamento) de portas de uma máquina para portas de outra, incluindo encaminhamento de clientes remotos XWindow... Agora o protocolo SSH, é um padrão e é amplamente utilizado, por exemplo, para sistemas de servidor, ou seja, executando vários comandos e manipulações no shell do servidor por meio de uma conexão segura, copiando arquivos pela rede, como backups de dados.

Protocolo SSH, existe em duas versões, uma versão comercial desenvolvida por SSH inc, e gratuito, código aberto, OpenSSH que é usado principalmente na maioria das plataformas de servidor. Implementação OpenSSH, está disponível em qualquer sistema operacional da família Unix e, na maioria deles, SSH servidor e SSH cliente, são utilitários padrão... Tudo o que está escrito abaixo diz respeito OpenSSH e o sistema operacional FreeBSD. Existem duas versões do protocolo SSH não são compatíveis entre si. Primeira implementação do protocolo SSH, SSH - 1, foi desenvolvido em 1995. Segunda versão, SSH - 2, lançado em 1996. Em 2006, protocolo SSH foi adotado pelo IETF como um padrão da Internet. Agora é a segunda versão do protocolo que é amplamente utilizada. SSH porque, em primeiro lugar, o protocolo SSH a versão 1, sofria de vulnerabilidades graves; em segundo lugar, a versão 2 usa algoritmos de criptografia mais poderosos, além de oferecer suporte à capacidade de detectar corrupção deliberada de dados. Algoritmos de criptografia:

  • Protocolo SSH versão 1 DES, 3DES, baiacu
  • Protocolo SSH versão 2 AES-128, AES-192, AES-256, baiacu, CAST-128, ArcFour
Função de resumo:
  • Protocolo SSH versão 1 não
  • Protocolo SSH versão 2 HMAC-MD5, HMAC-SHA-1, HMAC-RIPEMD
Como você pode ver, a diferença é muito grande, então o protocolo SSH versões 1 , agora em geral, estritamente não é recomendado para uso em qualquer lugar.

Métodos de autenticação SSH, pacote de software OpenSSH

Segurança de protocolo SSH fornecido pelas seguintes soluções de software:
  • Criptografia de todo o tráfego de passagem SSH uma conexão realizada de acordo com um dos possíveis algoritmos selecionados durante a negociação das partes para a sessão de comunicação. A criptografia do tráfego de conexão evita que ele seja interceptado e usado para fins maliciosos. Ao escolher diferentes algoritmos de criptografia, o sistema torna-se muito flexível, permitindo, por exemplo, não usar algoritmos em que foram encontradas vulnerabilidades ou potenciais ameaças à segurança, ou usar apenas aqueles algoritmos que são suportados por cada uma das partes;
  • Autenticação SSH o servidor é executado sempre, com qualquer conexão, o que não permite a substituição do tráfego ou do próprio servidor;
  • Autenticação SSH cliente pode ocorrer jeitos diferentes, o que, por um lado, torna o próprio processo de autenticação mais seguro, por outro, torna o sistema ainda mais flexível, facilitando o trabalho com ele;
  • O controle da integridade dos pacotes da rede, permite rastrear alterações ilegais no tráfego da conexão, caso este fato seja detectado, a conexão é encerrada imediatamente;
  • Os parâmetros de autenticação temporários impedem o uso de dados de conexão interceptados e, depois de algum tempo, descriptografados.
Protocolo SSH suporta uma variedade de métodos de autenticação e autorização para clientes remotos em SSH servidor, aqui estão alguns deles:
  • Baseado em GSSAPI autenticação
  • Baseado em host autenticação;
  • Autenticação do usuário usando uma chave pública;
  • Autenticação de resposta de desafio ( resposta do desafio);
  • E, por fim, a autenticação usual do usuário, através de senha;
Os métodos de autenticação são usados ​​nesta ordem, no entanto, a versão 2 do protocolo tem uma opção, PreferredAuthentifications, permitindo que você altere a ordem padrão. Além disso, o SSH oferece suporte a métodos adicionais de autenticação do usuário, dependendo do sistema operacional específico (por exemplo, bsd_auth ou PAM). Em geral, a autenticação do usuário é baseada em chaves públicas. Cliente tentando instalar remotamente SSH conexão, criptografa os dados com a chave pública do servidor conhecida por ele, que ele recebe na primeira vez que se conecta ao servidor, e os transmite para SSH servidor. O servidor, por sua vez, descriptografa os dados, apenas conhecidos por ele, com uma chave secreta, e os envia ao cliente. Nesse esquema, o cliente pode ter certeza de que o servidor é quem afirma ser. Então você não precisa depender de DNS e roteamento, mesmo se o invasor conseguiu forjar a entrada DNS ou redirecionar pacotes para seu próprio host, a autenticação irá falhar, pois os hosts estrangeiros não possuem as chaves necessárias para isso. Porque SSH este é um protocolo de rede completo, é claro, este é um certo conjunto de programas necessários para sua operação, tanto a funcionalidade básica como vários oportunidades adicionais... Já que estamos falando sobre o sistema operacional FreeBSD (em outras versões do Unix, o conjunto pode ser um pouco diferente), os componentes principais SSH estão:
  • sshdé na verdade SSH servidor, programa daemon;
  • ssh- um programa cliente que se tornou um substituto para rlogin e telnet;
  • scp- programa para cópia remota via protocolo SSH, para substituição rcp;
  • sftp- cliente ftp seguro;
  • servidor sftp- um subsistema que fornece transferência de arquivos por meio do protocolo SSH;
  • ssh-keygen- gerador de chave
  • ssh-keyscan- "coletor" de chaves públicas de host;
  • agente ssh- um agente de autenticação para manter chaves privadas;
  • ssh-add- um pequeno programa para adicionar chaves a agente ssh;
Como acima mencionado, sshd, este é o programa responsável pela funcionalidade do servidor SSH, ele começa quando o sistema operacional é inicializado. Para usar o protocolo SSH logo após instalar o FreeBSD, você precisa habilitar o daemon para iniciar sshd no programa de instalação Sysinstall... Embora isso possa ser feito posteriormente, desde que você tenha acesso ao terminal do servidor. Permitir que o daemon inicie sshd, você pode através do script de início /etc/rc.conf, escrevendo a seguinte linha: Naturalmente, você não pode fazer isso, mas apenas inicie o daemon a partir do console / usr / sbin / sshd, mas na próxima reinicialização, ele não iniciará sozinho, respectivamente, o acesso ao servidor usando o protocolo SSH você não o terá, mas se o servidor estiver localizado no data center do provedor de hospedagem, você não poderá administrá-lo remotamente. Por esse motivo, se você pretende administrar o servidor remotamente, sshd incluído durante a fase de instalação.

O SSH permite a escolha de diferentes algoritmos de criptografia. Clientes SSH e servidores SSH estão disponíveis para a maioria dos sistemas operacionais de rede.

SSH
Nome Capsula segura
Nível (modelo OSI) Aplicado
Família TCP / IP
Porta / ID 22 / TCP
Objetivo do protocolo Acesso remoto
Especificação RFC 4251
Principais implementações (clientes)
  1. A autenticação por senha é a mais comum. Com cada conexão, como https, uma chave secreta compartilhada é gerada para criptografar o tráfego.
  2. Para autenticação de par de chaves, um par de chaves pública e privada é pré-gerado para um usuário específico. A máquina com a qual você deseja se conectar está armazenada chave privada e abra na máquina remota. Esses arquivos não são transferidos durante a autenticação, o sistema apenas verifica se o proprietário da chave pública também possui a chave privada. No esta abordagem Como regra, o logon automático é configurado em nome de um usuário específico no sistema operacional.
  3. A autenticação por endereço IP é insegura; esse recurso é geralmente desabilitado.

O algoritmo Diffie-Hellman (DH) é usado para criar um segredo compartilhado (chave de sessão). Criptografia simétrica, algoritmos AES, Blowfish ou 3DES são usados ​​para criptografar os dados transmitidos. A integridade da transferência de dados é verificada usando CRC32 em SSH1 ou HMAC -SHA1 / HMAC -MD5 em SSH2.

Os dados criptografados podem ser compactados usando o algoritmo LempelZiv (LZ77), que fornece o mesmo nível de compactação do arquivador ZIP. A compactação SSH é habilitada somente a pedido do cliente e raramente é usada na prática.

Padrões e implementações de software

A primeira versão do protocolo, SSH-1, foi desenvolvida em 1995 pelo pesquisador Tatu Ulönen, da Helsinki University of Technology (Finlândia). SSH-1 foi escrito para fornecer mais privacidade do que os protocolos rlogin, telnet e rsh. Em 1996, uma versão mais segura do protocolo, SSH-2, foi desenvolvida e era incompatível com SSH-1. O protocolo ganhou ainda mais popularidade e, em 2000, tinha cerca de dois milhões de usuários. Atualmente, o termo "SSH" geralmente significa exatamente SSH-2, uma vez que a primeira versão do protocolo, devido a deficiências significativas, agora praticamente não é utilizada.

Existem módulos para usar SSH em Python, como python-paramiko e python-twisted-conch.

Tunelamento SSH

Um túnel SSH é um túnel criado por meio de uma conexão SSH e usado para criptografar dados encapsulados. É usado para proteger a transmissão de dados na Internet (o IPsec tem uma finalidade semelhante). Quando enviado por um túnel SSH, o tráfego não criptografado de qualquer protocolo é criptografado em uma extremidade da conexão SSH e descriptografado na outra.

A implementação prática pode ser feita de várias maneiras:

  • Criação de um proxy Socks para aplicativos que não podem funcionar por meio de um túnel SSH, mas podem funcionar por meio de um proxy Socks
  • Usando aplicativos que podem funcionar por meio de um túnel SSH.
  • Criação de túnel VPN, adequado para quase todas as aplicações.
  • Se o aplicativo funcionar com um servidor específico, você pode configurar o cliente SSH para que ele permita conexões TCP por meio do túnel SSH que chega a uma porta TCP específica da máquina na qual o cliente SSH está sendo executado. Por exemplo, os clientes Jabber se conectam por padrão na porta 443. Em seguida, para configurar uma conexão com o servidor Jabber por meio de um túnel SSH, o cliente SSH é configurado para redirecionar as conexões de qualquer porta da máquina local (por exemplo, da porta 4430 ) para um servidor remoto (por exemplo, jabber .example.com e porta 443):

$ ssh -L 4430: jabber.example.com: 443 somehost

V este caso O cliente Jabber está configurado para se conectar à porta 4430 do servidor localhost (se o cliente ssh estiver sendo executado na mesma máquina que o cliente Jabber).

Para criar um túnel ssh, você precisa de uma máquina com um servidor ssh em execução e acesso a jabber.example.com. Esta configuração pode ser usada se o acesso a jabber.example.com da máquina local for fechado por um firewall, mas houver acesso a algum servidor ssh que não tenha restrições de acesso à Internet.

SSH (Secure Shell) é um protocolo de rede acesso remoto que usa criptografia e compactação para os dados transmitidos. Simplificando, esta é uma ferramenta muito útil e poderosa que permite que você se autentique no sistema e trabalhe totalmente em nome de usuário local estando a muitos quilômetros de distância de uma máquina em execução. Além disso, ao contrário do telnet e do rsh - o SSH criptografa todo o tráfego para que todas as informações transmitidas permaneçam confidenciais.

Portanto, já temos o ssh instalado e o ssh-daemon é adicionado para inicializar na inicialização do sistema. Você pode controlá-lo por comando:

serviço ssh parar | iniciar | reiniciar

No Ubuntu ou:

/etc/init.d/ssh (iniciar | parar | recarregar | forçar reload | reiniciar | status)

No Debian ou:

systemctl start | stop | restart sshd.service

No ArchLinux (após cada edição da configuração, você precisa reiniciar). O kit inclui um cliente e um servidor.

Vamos tentar em ação! Primeiro, crie uma pasta ~ / .ssh

mkdir ~ / .ssh

Gerar chaves para determinado usuário servidor com o comando:

ssh-keygen (como um usuário regular).

Ao gerar, você pode definir uma senha longa para a chave (é aconselhável definir uma longa - então, mesmo tendo obtido a chave, mas não sabendo a senha da chave, o invasor não será capaz de efetuar login), ou você pode ignore simplesmente pressionando "Enter" - neste caso, a senha nunca será solicitada. As mesmas chaves públicas e privadas apareceram na pasta ~ / .ssh.

Encontre outra máquina (até mesmo um smartphone serve - existem alguns ótimos clientes SSH no Android, como ConnectBot ou JuiceSSH), instale o ssh nele e conecte-se ao servidor com o comando:

ssh [email protegido]

Se tudo for feito corretamente, será solicitada a senha do usuário e, após entrar, você se encontrará em seu sistema com uma visão da linha de comando.

Para Windows, aliás, também existem servidores e clientes ssh.

Depois de aproveitar o resultado de nosso trabalho, vamos prosseguir para uma parte ainda mais entediante - configurar o cliente / servidor.

A configuração do lado do cliente está em / etc / ssh / ssh_config, e o servidor - / etc / ssh / sshd_config... Maioria orientação completa para configuração, provavelmente há uma página em man - man ssh e man sshd_config, portanto, recomendamos que você a leia. E neste artigo iremos considerar as coisas mais necessárias.

Costumização

A porta ssh padrão é 22. Ela pode ser alterada para qualquer não padrão (tornando mais difícil hackear devido à segurança através da obscuridade, ou para atrair a atenção de invasores em potencial :) - para fazer isso, descomente a linha:

#Port 22

E adicione o que quiser até 65535 (certificando-se de que a porta não entre em conflito com outros serviços com o comando #netstat -tupln | grep LISTEN).

Agora, ao se conectar ao servidor, o cliente precisará escrever com a chave:

ssh -p [porta]:

Por padrão, o acesso root é permitido. É altamente recomendável restringi-lo (e, em vez disso, delimitar adequadamente os direitos do usuário local usando sudo). Para fazer isso, localize a linha "PermitRootLogin" e altere o valor para "no". Você também pode alterá-lo para "sem senha" - neste caso, o login como root só será permitido em máquinas com uma chave confiável.

Você pode desativar a autenticação de senha e trabalhar apenas com chaves - encontre a linha: "PasswordAuthentication" e altere o valor para "no". Pelo que? Se alguém realmente deseja obter acesso ao seu sistema, ele pode usar a força bruta da senha ao tentar autorizar ou ouvir e descriptografar sua conexão. Se você desabilitar a autenticação por senha e adicionar a chave pública do seu, por exemplo, laptop de trabalho a ~ / .ssh / authorized_keys no servidor, então, como lembramos, teremos permissão para acessar o servidor imediatamente. Mas e se você estiver trabalhando na máquina de outra pessoa e precisar urgentemente acessar o servidor ssh, mas ele, como esperado, não nos deixa entrar? Então você não pode desabilitar a autenticação de senha, mas use o utilitário fail2ban. Basta instalá-lo de seu repositório, após o qual aplicará as configurações padrão e pelo menos protegerá seu canal ssh de ataques de força bruta. Mais sobre fail2ban - http://putty.org.ru/articles/fail2ban-ssh.html.

Caso as chaves para lançamento de mísseis nucleares estejam armazenadas em seu servidor, você pode fazer algo assim:

PermitRootLogin no - login como root é proibido.

PasswordAuthentication não - login sem senha

Vamos gerar uma chave longa na máquina remota (-t encryption_type, -b comprimento de bit):

ssh-keygen -t rsa -b 4096

Com uma frase-senha igualmente complexa (recuperar Palavra-chave esquecida, aliás, você não pode. Você pode alterá-lo com o comando "ssh-keygen -p", mas será solicitado o antigo de qualquer maneira). Vamos transferir a chave pública da máquina local remota para ~ / .ssh / authorized_keys no servidor, e voila - agora o acesso pode ser obtido de uma única máquina, usando a senha da chave privada. O SSH permite que você defina várias configurações de segurança e tem várias configurações específicas para isso - leia sobre elas no man.

Duas opções sshd_config têm o mesmo propósito:

LoginGraceTime- define o tempo após o qual a conexão será desconectada se a autenticação não ocorrer.

MaxAuthTries- define o número de tentativas incorretas de entrar no login, ao atingir o qual a conexão será encerrada.

MaxSessions- o número de sessões simultâneas (se o servidor for seu computador doméstico ao qual você vai se conectar da universidade ou do trabalho, então seria razoável limitar o número de sessões a um - um login rejeitado, neste caso, tornar-se um motivo para aumentar a paranóia, gerando novas chaves e alterando a senha). Porém, se você estiver atento, deve ter notado que a linha "Último Login" é exibida a cada login no servidor. Além disso, você pode adicionar sua própria mensagem de saudação - localize a linha "Banner" e, em vez de nenhuma, defina o caminho para o arquivo com o texto que será lido e exibido no login.

Entre outras coisas, você pode permitir que apenas alguns usuários façam login ou permitir que todos, exceto alguns usuários:

AllowUsers user1- permite apenas a entrada do usuário1.

DenyUsers user1- permitir a todos, exceto o usuário1.

E parâmetros semelhantes para acesso certos grupos- AllowGroups e DenyGroups.

Você também pode enviar uma sessão X11 por SSH. Para fazer isso, localize a linha "ForwardX11" e altere o valor para "yes".

Encontre uma linha semelhante na configuração do cliente - / etc / ssh / ssh_config, e também mude para "sim".

Agora você precisa se conectar ao servidor via ssh com o argumento -X:

ssh -X [email protegido]>

Você pode iniciar o aplicativo imediatamente quando conectado:

ssh -X [email protegido]"aplicativo"

Esta é a aparência de um GIMP em execução em uma sessão SSH:

Ou você pode obter a saída da webcam do laptop de um usuário desavisado :)

Os cálculos são executados diretamente no servidor e a saída é enviada para a máquina cliente (ou seja, mesmo se o próprio servidor não tiver o X11 instalado, os aplicativos gráficos podem ser renderizados em sua máquina remota). Este esquema funciona lentamente (não se esqueça de que todo o tráfego é criptografado dinamicamente) - mas esta função é muito útil.

Você também pode copiar arquivos em uma sessão SSH - há um utilitário "scp" simples para isso. Você pode transferir arquivos diretamente na sessão a partir do servidor para o cliente:

scp [email protegido]: / caminho / para / arquivo / em / servidor / onde / salvar / em / local / máquina

Então, do cliente ao servidor:

caminho scp / para / arquivo / cliente [email protegido]: / caminho / no / servidor

Isso é bastante conveniente se você precisar copiar um livro ou uma foto, mas e quando você tiver que trabalhar com muitos arquivos? Há uma coisa muito conveniente para isso - sshfs (disponível para instalação nos repositórios da maioria dos sistemas * nix).

Basta definir o caminho como scp:

sshfs [email protegido]: / home / usuário / mnt /

E a pasta server / home / user aparecerá no ponto de montagem / mnt da máquina local!

A desmontagem é feita via umount.

E, finalmente, vamos falar sobre um recurso pouco conhecido. Se você criar um arquivo /.ssh/config e preencha assim:

Nome de anfitrião]

nome de anfitrião

Usuário [nome de usuário do servidor]

opções desejadas

gostar

ForwardX11 sim

Porta 30.000

Então, podemos fazer o login por:

ssh [nome]

ssh -X -p 30000 [email protegido]

E todas as opções serão selecionadas automaticamente. Assim, com autenticação frequente em um servidor específico, você simplificará esse processo em alguns instantes.

Bem, cobrimos tudo (e ainda mais) que você precisa saber sobre SSH para seu uso diário - aprendemos como usar autenticação de chave, protegemos o servidor de ataques de força bruta e, em geral, corrigimos a maioria das falhas em potencial. Na verdade, o SSH pode fazer muitas outras coisas - por exemplo, tunelamento e encaminhamento de porta por meio de uma sessão ssh, mas é improvável que você, como um usuário comum, venha a usar isso. Recursos adicionais

Introdução

Na edição anterior, no artigo sobre segurança de servidores de Internet, foram discutidas questões relacionadas à escolha da plataforma e sistema operacional do servidor de Internet, a segurança do servidor em geral, sobre como trabalhar com usuários, bem como sobre trabalhando e configurações de firewall... Deixe-me lembrá-lo brevemente de que estamos considerando administrar um pequeno escritório ou rede doméstica quando você tiver um ou dois computadores dedicados. No primeiro caso, quando um computador é um firewall mais servidor de e-mail, Um servidor web e talvez um servidor ftp. Simplificando, um computador dedicado é usado como um tipo de recurso compartilhado. No segundo caso, o que implica a presença grande rede, um computador é usado como um gateway mais um firewall e o outro é usado como um servidor de e-mail, servidor da web, etc. Em princípio, o segundo método é preferível, uma vez que você separa fisicamente o gateway como o objeto do primeiro ataque possível de hackers e de servidor compartilhado redes. Em qualquer caso, no futuro, você pode abstrair do número de computadores dedicados, lembrando que mesmo que sejam dois, não é razoável carregá-los com outras tarefas.

Todos os itens a seguir continuam a linha do artigo anterior, pressupõe que uma máquina Linux seja usada como servidor e que o usuário esteja familiarizado com Linux e rede em um nível básico. As ideias para esses exemplos são tiradas de vários tutoriais do Linux. Então, que perguntas vamos examinar neste momento? Primeiro, os aplicativos de servidor que você deseja instalar no servidor. Em segundo lugar, os ataques à rede (incluindo tipos de vírus no Linux e cavalos de Tróia) e métodos para lidar com eles. Por que essas perguntas estão combinadas em um artigo? O fato é que geralmente o hacking ocorre ou por negligência do administrador, ou devido a lacunas na proteção dos aplicativos de servidor. O cliente, como a própria palavra indica, não controla os recursos do sistema, por isso é óbvio que são os servidores que podem ser alvo de um ataque.

Proteção de aplicativo de servidor

Qualquer pessoa familiarizada com UNIX percebe que quase qualquer programa de rede pode ser usado tanto como cliente quanto como servidor. No primeiro caso, você usa os serviços, no segundo, você os fornece. É claro que ambas as partes são necessárias em um serviço de rede. A questão é que tipo de programas de servidor são necessários em um servidor em sua rede. Ao instalar o Linux, é claro que você pode escolher pelo menos tudo, já que instalar em um disco não significa começar ainda. Mas quais ativar mais tarde? Há uma receita simples que eu sempre sigo quando trabalho com servidores - quanto menos servidores ativados, melhor (de maneira geral: quanto mais complicada uma coisa, mais fácil é quebrá-la). Não importa o quanto você fale sobre a confiabilidade do UNIX, falhas são regularmente descobertas e reparadas aqui. Portanto, quanto menos programas você executar, menos precisará monitorá-los. Na vida real, é claro, isso não deve se resumir ao fato de você proibir os usuários de literalmente tudo. É seguro, claro, mas por que se preocupar com um administrador? No entanto, coisas desnecessárias, como wais, certamente não devem ser colocadas.

Telnet e ssh

Agora vamos examinar mais de perto o que os usuários internos e externos realmente precisam. Precisamos de telnet e ssh (shell seguro). Talvez esse acesso não seja muito conveniente, mas é necessário, pelo menos para administradores. Este é um programa que fornece acesso em modo terminal, quando uma janela de caracteres de 80x25 aparece em seu computador, refletindo completamente o servidor chamado. Você pode executar qualquer comando e programas que não usam gráficos - em geral, este é um terminal remoto regular. A diferença entre telnet e ssh decorre dos nomes, mas ainda assim vamos explicar: telnet transmite informações desprotegidas, até mesmo a senha é transmitida pela rede em texto não criptografado, e ssh criptografa todas as informações transmitidas. Se você quiser ter mais ou menos confiança na proteção, desative o uso do telnet ou não o inicie. Bem, se você ainda quiser usá-lo, então, é claro, você precisa usar um firewall. Os comandos padrão podem ser os seguintes:

para ipfwadm -

Ipfwadm -I -a aceitar -P tcp -S 10.0.0.0/8 -D 0.0.0.0/0 23 ipfwadm -I -a aceitar -P tcp -S some.trusted.host -D 0.0.0.0/0 23 ipfwadm - I -a negar -P tcp -S 0.0.0.0/0 -D 0.0.0.0/0 23

para ipchains -

ipchains -A entrada -p todos -j ACEITAR -s 10.0.0.0/8 -d 0.0.0.0/0 23

Ipchains -A entrada -p todos -j ACEITAR -s some.trusted.host -d 0.0.0.0/0 23 ipchains -A entrada -p todos -j DENY -s 0.0.0.0/0 -d 0.0.0.0/0 23

Você também pode usar os arquivos /etc/hosts.allow e /etc/hosts.deny, para os quais você deve escrever, respectivamente:

no primeiro arquivo -

In.telnetd: 10.0.0.0/255.0.0.0, some.trusted.host

no segundo arquivo -

In.telnetd: ALL

Observe que, mesmo se essas regras estiverem habilitadas, qualquer programa escutando na rede em algum lugar ao longo do caminho de um pacote com uma senha pode interceptá-lo.

Dois outros arquivos importantes com informações relacionadas à segurança do sistema são / etc / securetty e / etc / shells. O primeiro especifica os terminais a partir dos quais o usuário root pode efetuar login. Na maioria dos sistemas, por padrão, o usuário root só pode efetuar login a partir do console. O segundo arquivo especifica uma lista de wrappers válidos que podem ser executados quando um usuário efetua logon. Um bom exemplo que tirei do manual do Linux é usar passwd como shell. Isso fornece aos usuários uma alteração de senha fácil e também garante que eles não façam mais nada no modo de terminal. Para fazer isso, insira o próprio programa passwd no arquivo / etc / shells, ou seja, insira a linha:

/ usr / bin / passwd

e no arquivo / etc / passwd escreva sobre o usuário:

Nome de usuário: x: 1000: 1000 :: / home / nome de usuário: / usr / bin / passwd

Agora, quando o usuário faz logon na rede, ele só pode alterar a senha. A saída para o terminal é parecida com esta:

Tentando 1.2.3.4 ... Conectado ao host local. O caractere de escape é "^]". Red Hat Linux versão 5.2 (Apollo) Kernel 2.2.5 em um login i586: senha do testador: Alterando a senha do testador (atual) Senha do UNIX: Nova senha do UNIX: Digite novamente a nova senha do UNIX: passwd: todos os tokens de autenticação atualizados com sucesso Conexão fechada por estrangeiro hospedeiro.

Mesmo que a tentativa de alterar a senha não tenha sido bem-sucedida, ele será desconectado do sistema. Você também deve prestar atenção à saída de inicialização ao conectar: ​​telnet escreve honestamente o nome do sistema e a versão. Em geral, isso é conveniente, mas, neste caso, você fornece a um hacker em potencial informações que ele pode usar para seus próprios fins. Como voce pode evitar isso? Quando um usuário efetua login, o telnet exibe o arquivo /etc/issue.net criado na inicialização do sistema. Ele é criado pelos comandos no arquivo rc.local:

# Isso substituirá / etc / issue a cada inicialização. Portanto, faça quaisquer alterações que # queira fazer em / etc / issue aqui ou você as perderá quando reiniciar. echo ""> / etc / issue echo "$ R" >> / etc / issue echo "Kernel $ (uname -r) em $ a $ (uname -m)" >> / etc / issue cp -f / etc / problema /etc/issue.net echo >> / etc / problema

Portanto, se você não está sobrecarregando o sistema, você pode simplesmente editar o arquivo /etc/issue.net, caso contrário, edite o próprio rc.local. Em qualquer caso, é recomendado usar telnet apenas quando for realmente necessário e não puder ser substituído por ssh.

Ssh é semelhante ao telnet do ponto de vista do usuário. Ao contrário do telnet, que usa a porta 23, ele usa a 22, mas a principal diferença interna é que todo o tráfego é criptografado. Em todos os outros aspectos, eles são semelhantes. Para ssh, você pode usar as mesmas regras de firewall (com o número da porta substituído) e configurações nos arquivos /etc/hosts.allow, /etc/hosts.deny. Um bom recurso é a presença de seu próprio arquivo de configuração / etc / sshd / sshd_config contendo as seguintes linhas de configuração:

Porta 22 # número da porta, que pode ser maior que 22 ListenAddress 0.0.0.0 # que endereça o daemon HostKey serve / etc / ssh / ssh_host_key # arquivo de códigos de cliente RandomSeed / etc / ssh / ssh_random_seed # arquivo de números aleatórios usado para gerar códigos ServerKeyBits 768 # comprimento do código em bits LoginGraceTime 300 # hora de inserir o nome e a senha KeyRegenerationInterval 3600 # frequência de regeneração de códigos PermitRootLogin não # se o usuário root pode ou não fazer login via ssh IgnoreRhosts sim # Ignorar ou não as informações do arquivo do usuário rhosts StrictModes sim # modo estrito, bloqueando as falhas do usuário, por exemplo, inserir a senha 5 vezes # ou imprensa acidental insira QuietMode não # sim - para não escrever o arquivo de log e não - caso contrário X11Forwarding não # enviar informações do servidor X através do canal ssh FascistLogging não # grau de integridade dos arquivos de log PrintMotd sim # exibir alguma frase do dia KeepAlive sim # manter comunicação fornecendo desconexão padrão SyslogFacility DAEMON # quem é responsável por gerar logs RhostsAuthentication não # permitir autenticação do usuário via rhosts RhostsRSAAuthentication não # se a verificação via rhosts ou /etc/hosts.equiv # é definida como sim por padrão RSAAuthentication sim # usar apenas Verificação RSA PasswordAuthentication sim # usar usuários suas senhas normais ou não PermitEmptyPasswords não # permitir usuários sem senha ou não

Existem também algumas configurações úteis, em particular:

AllowGroups, DenyGroups, AllowUsers, DenyUsers, AllowHosts, DenyHosts, IdleTimeout time (tempo após o qual a conexão será interrompida em caso de inatividade).

Como você pode ver acima, em geral o ssh tem tantas configurações que você pode controlar exatamente quem pode fazer o login e como. Mas isso é sobre o servidor, e os usuários da rede precisam rodar clientes ssh. Ao contrário do telnet, que está disponível no Windows, o ssh não está incluído na distribuição padrão. O Linux não tem esse problema - o cliente também está lá. É importante observar que o daemon ssh está disponível na primeira e na segunda versão. É desagradável, é claro, que não haja compatibilidade com versões anteriores, mas tenho certeza de que você, como administrador, fornecerá aos usuários os clientes que serão capazes de se comunicar com o servidor. Aqui estão alguns clientes ssh para Windows:

  • FiSSH grátis fresco. http://www.massconfusion.com/ssh/
  • Tera Term. http://hp.vector.co.jp/authors/VA002416/teraterm.html cliente telnet. http://www.zip.com.au/~roca/ttssh.html - dll adicional para suporte ssh
  • Putty. http://www.chiark.greenend.org.uk/~sgtatham/putty.html - apenas cerca de 200K
  • Mindterm http://www.mindbright.se/mindterm/ - cliente ssh Java
  • O aplicativo Java Telnet. http://www.mud.de/se/jta/ - há suporte para ssh
  • CRT seguro. http://www.vandyke.com/ - cliente comercial

É necessário mencionar o acesso ao terminal em conexão com programas como rlogin, rexec, rsh. Seu uso é desprovido de qualquer proteção e às vezes permite que os usuários passem de uma máquina para outra sem digitar uma senha. Embora seja conveniente, do ponto de vista da segurança, simplesmente não é bom para nada. Esses serviços geralmente são iniciados por padrão. Para desfazê-los, você precisa editar o arquivo /etc/inetd.conf e reiniciar o daemon inetd. Em geral, telnet e ssh esgotam as possibilidades de acesso do terminal ao sistema. Portanto, vamos passar para outros aplicativos de servidor que são úteis para os usuários.

Correio ou e-mail

O que é necessário para as pessoas terem correspondência, sem a qual a comunicação entre as pessoas muitas vezes não é mais concebível? Uma maneira bastante comum é instalar um servidor de e-mail, criar uma caixa de correio para cada usuário e configurar um pop-daemon para que as pessoas possam pegar esse e-mail. Mas para que o servidor possa receber e enviar cartas, ele deve estar instalado nele programa de correio como sendmail, postfix ou qmail, que lida com correio em uma máquina UNIX. Tradicionalmente, o sendmail tem sido usado para este propósito. Agora ele também é usado na maioria das máquinas, mas os outros dois programas mencionados são substituições boas e até aprimoradas. Como de costume, as principais preocupações estão relacionadas à proteção, no entanto últimas versões sendmail (8.9.x) são bastante robustos.

Sendmail está disponível em todos os sistemas Linux, com as distribuições mais recentes provavelmente contendo a versão 8.9.x. O programa usa vários arquivos de configuração, que analisa no processo. Mas antes de falar sobre a configuração, notamos que o programa pode ser iniciado tanto como daemon quanto em modo de espera. No primeiro caso, ele escutará constantemente a porta e, no segundo, será acionado uma vez e simplesmente processará todas as informações de entrada. O segundo método é preferível do ponto de vista da segurança. Para fazer isso, você só precisa remover o parâmetro -bd na linha de inicialização.

Agora sobre a configuração. O arquivo principal é sendmail.cf, que pode ou não ter links para outros arquivos. O arquivo de acesso também é analisado, onde você pode colocar os endereços de onde (ou para os quais) as cartas não serão enviadas. Por exemplo, as entradas:

10.0.0 RELAY spam.com REJEITAR

significa que emails de endereços .spam.com não serão aceitos e emails da rede interna podem ser aceitos e enviados.

Outro arquivo útil e usado são apelidos. Ele especifica quais nomes serão interpretados como o nome da caixa de correio fornecida. Por exemplo, se você definir

Petrov: estrela

cartas chegando a Petrov em [email protegido] será enviado para a caixa [email protegido] mesmo se alguém não souber endereço real... Isso é útil, em particular, se você deseja que os e-mails cheguem a um gerente que deseja ter uma caixa de correio, não com o gerente de nomes, mas com a sua própria. Isso significa que o gerente só dará seu endereço para quem achar adequado, e o gerente ficará pendurado na página da web. Obviamente, isso trará a máxima comodidade em caso de mudança de gerente. Qualquer número de nomes pode ser redirecionado para a mesma caixa de correio.

O arquivo virtusertable especifica o mapeamento de um endereço para outro, por exemplo:

[email protegido] Gerente

Usando esses dois arquivos (aliases e virtusertable), a duplicação de e-mail pode ser implementada, o que salvará todos os e-mails recebidos. O truque é que o arquivo virtusertable é examinado primeiro e, em seguida, os aliases. Se, com a última entrada em virtusertable, escreva no arquivo de aliases:

Gerente: estrela, "/ var / spool / mail2 / star"

então, a correspondência que chega aos endereços do gerenciador e estrela será gravada no diretório / var / spool / mail normal e / var / spool / mail2.

Uma das principais diferenças entre postfix e sendmail é a modularidade (que o qmail também possui). Ao contrário do sendmail, apenas uma pequena parte do código, apenas um módulo, é executado como root, e todas as outras partes são executadas conforme necessário e têm suas próprias configurações. Em geral, os arquivos de configuração do postfix são normalmente encontrados em / etc / postfix. O arquivo manager.cf gerencia a operação de vários módulos, especificando os usuários sob os quais eles são executados e o número de processos. O arquivo main.cf é o arquivo de configuração principal e define os parâmetros básicos do próprio e-mail. Aqui está sua forma aproximada com explicações (mais precisamente, aqueles componentes que provavelmente terão que ser editados):

# nome da máquina myhostname = mail.example.org # domain mydomain = example.org # de qual endereço você envia emails myorigin = $ mydomain # em quais interfaces executar o programa inet_interfaces = all # arquivo de nomes virtuais virtual_maps = hash: / etc / postfix / virtual # arquivo de substituições de nome alias_maps = hash: / etc / postfix / aliases # diretório onde o correio deve ser colocado quando o usuário o receber home_mailbox = Maildir / # onde armazenar o correio mail_spool_directory = / var / spool / mail # comando para recuperar mail mailbox_command = / usr / sbin / scanmails # um arquivo indicando os endereços de onde e para os quais os e-mails devem ser passados ​​# relay_domains = / etc / postfix / relaydomains # máquinas locais mynetworks = 10.0.0.0/24, 127.0.0.0/8 # o que produzir se os usuários se conectarem à porta 25 smtpd_banner = $ myhostname ESMTP $ mail_name

O programa postfix pode ser obtido em http://www.postfix.org.

Agora vamos falar sobre os protocolos POP e IMAP. O primeiro opera na porta 110, o segundo - no 143. Em princípio, ambos buscam o mesmo objetivo, mas são implementados de maneiras diferentes. POP (Post Office Protocol) é um protocolo bastante antigo e pobre. Tudo o que permite é se conectar ao servidor, receber e-mail e excluí-lo da caixa de correio no servidor. Protocolo IMAP mais avancado. Ele permite que você gerencie seu e-mail diretamente no servidor. Você não tem que baixar todo o correio, mas pegar apenas os cabeçalhos das cartas, criar diretórios no servidor e distribuir o correio entre eles. Do ponto de vista da segurança, esses protocolos são os mesmos, por isso é aconselhável usar um firewall para evitar problemas. Você também pode colocar o tráfego desses protocolos dentro do ssh. É muito importante verificar se há vírus em seu e-mail. Embora os vírus não sejam assustadores no UNIX, já que muitos usuários usam o Windows, é aconselhável executar e-mails por meio de um programa de varredura, como o AMAVIS. A maneira mais fácil de fazer isso (claro, assume-se que o programa AMAVIS já está instalado), se em postfix na linha de configuração

Mailbox_command = / usr / bin / procmail

Mailbox_command = / usr / sbin / scanmails

Resumidamente sobre como um usuário recebe e envia correspondência no local de trabalho. Felizmente, todos os programas populares são clientes POP ou IMAP (quero dizer, pelo menos Netscape e Outlook). Além disso, se o administrador concedeu a capacidade de acessar o servidor via telnet ou ssh, você pode ver o e-mail e trabalhar com ele no modo terminal (pegá-lo neste caso é mais difícil). Para fazer isso, você precisa se conectar ao servidor e executar algum programa de e-mail no terminal, como mail ou pine. Este último é muito mais conveniente e é um programa de tela inteira com menu, apenas em modo texto.

Acesso a arquivos e impressão em rede

Em um sistema UNIX, existem dois ferramentas padrão- NFS e LPD. O primeiro permite que você crie sistemas de arquivos de rede, o segundo - para imprimir em uma impressora. Quanto ao uso dos recursos de uma máquina UNIX do Windows, o Samba (SMB) é o mais adequado, a meu ver. Este programa permite que você acesse arquivos e também oferece a capacidade de imprimir em rede a partir de uma máquina Windows por meio de um servidor UNIX. Como este artigo é principalmente sobre segurança de servidor, deve-se observar que o compartilhamento de recursos dentro da rede não é perigoso, é claro, com a configuração normal de regras de firewall externo. Aqui podem surgir problemas de outro plano, ligados ao facto de nem todos deverem ter acesso a esta ou aquela informação, mas isso é inteiramente regulado pela configuração dos atributos dos ficheiros e das pastas. Por mais astuto que seja um administrador, você não pode evitar uma situação em que, por exemplo, alguém se esquece de fechar a sessão ssh e sai do computador. É outra questão se você conceder acesso de leitura a alguns arquivos, mas essas são coisas muito óbvias para se concentrar. Portanto, vamos agora considerar os aplicativos de servidor que são úteis não apenas para usuários internos, mas também para usuários externos. Quero dizer principalmente um servidor web e talvez ftp. Agora é difícil imaginar a menor empresa ou mesmo apenas uma rede sem a primeira, e a presença da segunda depende se você tem uma necessidade real de carregar separadamente alguns dados para um servidor ftp.

Servidores web e ftp

Apache é o líder indiscutível em termos de popularidade e desempenho entre os vários servidores Web existentes atualmente. Este servidor combina velocidade, estabilidade, alta segurança e ao mesmo tempo é gratuito. Nem sempre é possível encontrar esse programa para seus próprios fins, mas aqui está. E devemos admitir que os autores do programa se esforçam para alcançar a máxima eficiência e confiabilidade. Em primeiro lugar, observe que, se você usar seu servidor Web apenas para fins internos, como administração de sistema ou compartilhamento de arquivos, você deve definitivamente protegê-lo do mundo externo. Se este é um servidor para todos, você precisa entender que ele está aberto para todos. Por isso é necessário monitorá-lo adequadamente, a saber: configurá-lo de forma cuidadosa e correta e monitorar os arquivos de log para determinar com antecedência um possível ataque. No que diz respeito à segurança, o próprio servidor tem muito pouco acesso ao sistema, já que apenas sua primeira cópia é iniciada como root, e o resto normalmente é iniciado como ninguém. Além disso, nas configurações do servidor, ou seja, nos arquivos httpd.conf, smr.conf, access.conf, estão claramente indicados quais diretórios o servidor tem acesso e quais não. Se você escrever no arquivo httpd.conf, por exemplo:

Opções Nenhum AllowOverride Nenhum Opções Índices FollowSymLinks Inclui AllowOverride Nenhum

então você indicará explicitamente que o servidor tem acesso apenas ao diretório / WWW, onde você precisa colocar todo o material do site (ou sites) cujo trabalho é fornecido pelo servidor. Se você quiser ter certeza de que ninguém mudará os direitos de acesso incluindo, por exemplo, o arquivo .htaccess em algum diretório, em srm.conf você deve inserir:

pedido permitir, negar negar de todos

Do ponto de vista da segurança, não faz sentido falar mais detalhadamente sobre outras configurações, especialmente porque a instalação e configuração mínima do servidor Apache foram descritas na edição anterior em um artigo dedicado a este tópico.

É necessário insistir separadamente no uso do protocolo https (http seguro). Este protocolo geralmente é executado na porta 443 (em oposição ao http padrão executado na porta 80). Existem pelo menos duas maneiras de enriquecer o Apache com http seguro. O primeiro é usar o add-on do open-ssl, o segundo é usar o módulo mod_ssl. Ambas as opções levam a quase os mesmos resultados. Em geral, é possível estabelecer conexões usando https na porta 443. Isso cria um certificado para o servidor, que será verificado pelos clientes na conexão. Isso excluirá (é claro, não com garantia absoluta) a escuta do tráfego. Para criar um certificado ao usar o openssl, você precisa dar os comandos:

Openssl genrsa -des3> httpsd.key openssl req -new -key httpsd.key> httpsd.csr

além disso, os arquivos devem estar no mesmo diretório onde os arquivos de configuração do servidor estão localizados. Para que o servidor funcione corretamente com a porta 443, você também terá que alterar os arquivos de configuração. Eles precisam escrever algo como

# escuta na porta 443 (por padrão, o servidor escuta apenas na porta 80) escuta 443 # desativa uso global ssl SSLDisable # o local onde o servidor armazenará informações temporárias durante a conexão SSL. Sem # esta configuração, o servidor não funcionará SSLCacheServerPath / usr / bin / gcache # porta através da qual o servidor se comunica com CashServer SSLCacheServerPort 12345 # CashServer timeout SSLSessionCacheTimeout 300

Após essas configurações, seu servidor está basicamente pronto para trabalhar com https, mas por enquanto este protocolo é proibido. É aconselhável criar um host virtual com o mesmo nome do padrão, mas com indicação explícita da porta 443, ou seja, agora você tem um servidor web rodando. Ele é executado na porta 80 e usa o protocolo http. Ao adicionar apache-ssl e as configurações descritas acima, você deu aos usuários a capacidade de se comunicarem com seu servidor por meio do protocolo https. É improvável que todas as informações em seu servidor sejam classificadas de forma que você queira distribuí-las apenas em um modo de conexão segura. O servidor Apache permite que você crie máquinas virtuais, ou seja, você pode declarar um subdiretório raiz para um host, dar um nome a ele, escrever um conjunto de arquivos de configuração e tudo o mais que for necessário, mas fisicamente estará localizado no seu computador e será controlado pelo seu próprio servidor ... No nosso caso, nem é necessário dar um nome diferente, pois é o mesmo, apenas uma porta diferente. Esta é a aparência de uma configuração como esta:

DocumentRoot / www / secure / ServerName www.example.com ServerAdmin [email protegido] ErrorLog logs / https_error.log TransferLog logs / https_access.log # Permitir ssl para este host virtual SSLEnable # Exigir apenas ssl usar SSLRequireSSL SSLCertificateFile /usr/conf/httpsd.crt SSLCertificateKeyFile / usr / conf / httpslip

Além do http, também existe o ftp - um serviço útil e conveniente, especialmente se você tiver muitos arquivos que os usuários precisam baixar (por exemplo, você fornece alguns dados de pesquisa). A vantagem do ftp sobre o http é a velocidade. O protocolo ftp tem um mínimo de sobrecarga. No entanto, existem muitos problemas com ele. O principal deles é a sua "idade": o ftp é tão antigo quanto o telnet. A partir daqui, complicações relacionadas com a segurança surgem imediatamente: o nome de usuário e a senha são transmitidos em claro, e o tráfego das informações transmitidas não é protegido por nada. Além do ftp, só pode transferir arquivos. Portanto, se você tiver alguma informação que está disponível para todos, então é razoável criar um usuário, em cujo nome todos entrarão. Freqüentemente, em tais arquivos ftp, esse usuário é chamado de anônimo e ele passa seu endereço de e-mail como uma senha. Nesse caso, há muito menos problemas de segurança. Além disso, no caso de você precisar fornecer acesso ftp a vários usuários, faça um chroot para que eles possam colocar os arquivos apenas em seus próprios diretórios. Quanto aos servidores, então, é claro, eles estão disponíveis em pacotes padrão, mas talvez você queira instalar não um ftpd padrão, mas algum outro.

Um dos servidores ftp populares é o proftpd. Seus arquivos de configuração são semelhantes aos arquivos do Apache, o que torna mais fácil se adaptar a eles, já que provavelmente o seu servidor web é o Apache. O arquivo de configuração principal é /etc/proftpd.conf. Sua forma aproximada pode ser assim:

ServerName "ProFTPD Default Installation" ServerType inetd DefaultServer na porta 21 Umask 022 MaxInstances 30 Usuário ninguém Grupo ninguém AllowOverwrite em

A listagem acima indica que o servidor é iniciado via inetd, na porta 21 padrão, o número máximo de cópias é 30, e é iniciado como o grupo e usuário nobody. 022 - máscara de atributos do arquivo durante a criação, que será aplicada como padrão inicialmente. Esta configuração não dá acesso ao usuário anônimo. Para fazer isso, você precisa escrever aproximadamente as seguintes definições de configuração:

Usuário ftp Grupo ftp RequireValidShell desligado UserAlias ​​ftp anônimo MaxClients 10 DisplayLogin welcome.msg DisplayFirstChdir .message Negar Tudo

Após este acréscimo, torna-se possível trabalhar como anônimo, e apenas ler, ou seja, fazer download de arquivos. Darei outro exemplo de configuração dos direitos de uso de diretórios:

Permitir todos Negar Tudo

Essa entrada no arquivo de configuração dá acesso de gravação, mas não dá o direito de baixar arquivos. Isso é útil se você deseja que os usuários possam fazer upload de arquivos, mas não possam ver o que os outros colocaram.

Isso conclui o tópico de aplicativos de servidor. Claro, deve-se notar que existem muitos outros aplicativos de servidor: também há DNS, servidores de notícias, servidores NIS, o servidor X e muitos outros aplicativos interessantes e úteis. No entanto, tentei me concentrar no que pode realmente ser necessário ao operar uma rede que não afirma ser uma ciberpolis ou provedor global. Agora, vamos passar para a consideração da segunda questão, indicada no início do artigo - para ataques de rede e hacks.

Ataques e hacks de rede

Em primeiro lugar, algumas palavras gerais. No UNIX, ao contrário do Windows, não há problemas com vírus. A estrutura interna de alocação de memória e permissões de arquivo é capaz de lidar por conta própria com o que os vírus costumam fazer no DOS ou Windows antigos. A principal barreira para vírus (em seu sentido padrão) é a falta de acesso a dispositivos físicos para programas executados em nome de um usuário regular, bem como o fato de que os atributos de arquivo não são definidos de forma alguma, mas para o usuário, grupo e todos os usuários. Não existe tal coisa no Windows (isso é parcialmente implementado no Windows 2000). Embora o incômodo causado por vírus tradicionais seja quase impossível, os sistemas UNIX ainda são hackeados e destruídos. Isso se deve à presença de tecnologias completamente diferentes, que podem ser divididas em duas categorias. O primeiro são os chamados cavalos de Tróia, que são programas que aparentemente, e talvez de fato, executam ações bastante razoáveis ​​e legais. No entanto, em paralelo, eles estão fazendo outro "trabalho": ouvir a rede ou coletar informações sobre senhas e enviá-las para a rede, etc. É improvável que esses programas causem danos diretos - em vez disso, eles serão intermediários entre o seu sistema e um invasor externo. A segunda categoria são os hacks de rede. Essas ações não apelam inicialmente para o conteúdo interno da máquina, mas tentam destruir o sistema ou obter acesso a ele enviando algumas informações, como pacotes de rede deliberadamente incorretos, ou tentando "atrair" alguns dados ocultos por meio de solicitações especialmente formadas . Por que hackear sistemas? Esta é uma questão mais psicológica do que prática. O fato é que, na realidade, uma grande parte dos hacks de máquina não vem de propósitos egoístas, mas simplesmente do interesse no próprio processo. Entre as pessoas que normalmente são chamadas de hackers, não apenas aqueles que fazem hacks para algum benefício real, mas também "entusiastas" que quebram a rede só para quebrar. Isso parece inesperado, mas é, e as estatísticas mostram isso. Além disso, muitas vezes é muito difícil culpar uma pessoa pelo que ela fez, já que às vezes é impossível provar que foi ela e deste computador que executou certas ações ilegais. No entanto, neste artigo, estamos discutindo os hacks em si, e não seus aspectos psicológicos e jurídicos, portanto, passaremos para coisas específicas.

Hackear a rede, não importa o quão cuidadoso seja realizado e quaisquer que sejam os métodos usados, inevitavelmente leva a algumas mudanças no sistema. Pode ser uma nova lista de portas de escuta, programas desconhecidos, redimensionamento de programas existentes, especialmente ps ou netstat, ou até mesmo novos usuários. De uma forma ou de outra, a questão é que algo precisa mudar, e isso é inevitável. Portanto, a primeira ação razoável que aconselho a tomar imediatamente após a instalação e configuração do sistema é criar um arquivo com informações sobre o sistema. Algo como uma fotografia no momento em que você considera tudo o que acontece como correto. Mais especificamente, quero dizer as informações fornecidas pelos programas netstat, vmstat, free, du, df. A segunda dica é fazer backup dos arquivos de configuração do sistema e das configurações iniciais. Compará-los também pode fornecer algumas informações sobre o que aconteceu no sistema recentemente.

Vamos começar monitorando o sistema de arquivos, que envolve não apenas monitorar o uso do sistema de arquivos (o que pode ser feito com os comandos du e df), mas também verificar a imutabilidade de certos arquivos (por exemplo, arquivos de sistema). Existem vários programas que realizam essas funções:

  • AIDE - um programa que permite criar somas de verificação para arquivos, verificando assim sua integridade; permite que vários algoritmos sejam usados. http://www.cs.tut.fi/~rammer/aide.html. (O resto dos programas executam funções semelhantes, são todos gratuitos.)
  • Gog & Magog - cria uma lista de atributos e proprietários de arquivos, permite comparações automáticas. http://www.multimania.com/cparisel/gog/
  • Sentinel - cria somas de verificação usando o algoritmo RIPEMD-160bit MAC tem interface gráfica... http://zurk.netpedia.net/zfile.html
  • SuSEauditdisk é um programa colocado em um disquete, que permite realizar uma verificação do sistema de forma totalmente autônoma, inicializando diretamente de um disquete. Fornecido como padrão com SuSELinux. http://www.suse.de/~marc
  • ViperDB - Verifica os proprietários e atributos dos arquivos, criando arquivos de log que registram as mudanças ocorridas. O programa tem três parâmetros: -init - cria bancos de dados por arquivos, -check - verifica os arquivos no banco de dados e faz alterações no banco de dados se eles aconteceram no disco, -checkstrict - verifica os arquivos no banco de dados e retorna parâmetros antigos se as alterações ocorreram . http://www.resentment.org/projects/viperdb
  • Sxid - Cria somas de verificação de arquivos e verifica atributos e proprietários. ftp://marcus.seva.net/pub/sxid/
  • babá - lembra a hora de criação do arquivo. ftp://tools.tradeservices.com/pub/nannie/
  • confcollect - lembra informação do sistema como o estabelecido Programas, tabelas de roteador, etc. http://www.skagelund.com/confcollect/
  • Pikt é uma ferramenta que contém uma linguagem de script interna para criando programas que executam funções padrão, mas não implementadas na forma de comandos específicos (monitorar o uso horário do sistema, eliminar processos de longa duração, definir o tamanho caixa de correio etc.). Disponível para várias plataformas: Solaris, Linux e FreeBSD. http://pikt.uchicago.edu/pikt/

Você também pode falar sobre programas que realizam funções de backup, mas, na minha opinião, isso não está diretamente relacionado à segurança do sistema e, além disso, várias ferramentas padrão estão incluídas na distribuição do UNIX. A segurança só é relevante se backupsé necessário fazer, mas isso já foi mencionado acima.

Agora vamos descobrir o que fazer para evitar ataques à rede. Claro, você precisa instalar um firewall no gateway. De uma forma ou de outra, a proteção em nível de pacote é necessária. Se o firewall for ignorado de alguma forma, os seguintes programas serão necessários:

  • DTK - emula serviços e programas padrão e, no caso de solicitações fora do padrão enviadas a esses programas, informações deliberadamente falsas são emitidas para confundir o invasor. http://all.net/dtk/
  • Psionic PortSentry - monitora varreduras de portas. A principal tarefa é verificar as portas para varredura e exibir tudo em um arquivo de log. http://www.psionic.com/abacus/portsentry/
  • Psionic HostSentry - Cria um banco de dados de informações de uso da máquina pelos usuários, exibindo uma mensagem quando o uso de recursos é anormal. http://www.psionic.com/abacus/hostsentry/
  • Scanlogd - verifica os pacotes de rede, gerando arquivos de log com base nas configurações. http://www.openwall.com/scanlogd/
  • Firewalls é o nome coletivo dos programas de firewall.
  • TCP-WRAPPERS - programas que restringem o acesso a certos recursos por nome ou número de computador. Alguns desses programas estão disponíveis em. ftp://ftp.porcupine.org/pub/security/
  • NFR é um programa de estrutura semelhante a um sniffer (sniffer é um programa para ouvir o tráfego da rede). Registra arquivos de log e detecta ataques e varreduras de portas em tempo real. http://www.nfr.com/
  • Um FAQ detalhado e útil sobre ataques de rede e sua detecção pode ser encontrado em http://www.robertgraham.com/pubs/network-intrusion-detection.html.

É difícil responder inequivocamente à pergunta sobre o que e como deve ser feito durante os ataques à rede. Aqui, muito depende das especificidades da rede específica e da organização na qual ela está localizada. Mesmo com um ataque do mesmo tipo, em um caso, você vai querer salvar os dados primeiro e, no segundo, vai querer bloquear a origem do ataque, ou seja, tudo depende de prioridades. Os ataques são um problema muito difícil em organizações onde o tempo de inatividade da rede é inaceitável. Lá você terá que realizar todas as operações online, tanto quanto possível mantendo contato com o mundo exterior. Muito também depende da natureza do ataque. Hackear por hackear é uma coisa, e o roubo proposital de dados classificados é outra. Talvez, é verdade, e uma versão mais sofisticada, quando o ataque é realizado com o objetivo de distrair o administrador de um hacking mais sofisticado e pensativo executado em paralelo. Mas não pense que um ataque só pode vir de fora. Pode muito bem começar de dentro. Um cenário possível é o lançamento de um cavalo de Tróia em um computador Windows na rede interna. Obviamente, isso pode ser feito simplesmente enviando uma carta pelo correio. Agora vamos dar uma olhada mais de perto nos programas sniffer.

Geralmente farejar significa farejar. Portanto, sniffers são programas que de uma forma ou de outra escutam a rede e todas as informações que por ela passam. Um exemplo ilustrativo é uma senha em texto não criptografado de computador interno para o servidor. Como os pacotes viajam pela rede até encontrarem um destinatário, instalar um farejador em pelo menos um computador da rede interna (por exemplo, usando uma carta, como mencionado acima) é ferramenta conveniente para um cracker externo. Na maioria dos casos, os farejadores são bastante passivos, o que os torna difíceis de detectar. Abaixo está uma lista de vários programas sniffer que podem ser usados ​​para monitorar o que está acontecendo na rede:

  • Tcpdump é o programa mais antigo fornecido com todo o UNIX.
  • Sniffit - tem a capacidade de filtrar pacotes e traduzir informações em formato de texto; equipado com uma interface gráfica. http://sniffit.rug.ac.be/~coder/sniffit/sniffit.html
  • Ethereal é um analisador de protocolo de rede.
  • Snort - projetado para monitorar a rede, pode detectar varreduras de portas. http://www.clark.net/~roesch/security.html
  • SPY é um farejador, mas não de graça. Existe uma licença de rede gratuita para um único usuário de até cinco máquinas. http://pweb.uunet.de/trillian.of/Spy/

Não se deve esquecer, porém, que além do software, existe também um hardware que escuta, por exemplo, simplesmente conectando outro computador ou simplesmente conectando a um cabo. É curioso que se você usar uma Ethernet fina (cabo coaxial), você pode ouvi-lo sem abri-lo.

  • AntiSniff é um programa que verifica a rede em busca de farejadores. O princípio do seu funcionamento é muito simples: envia um pedido e, pela resposta e pelo tempo de resposta, determina se está a ser processado por algum outro programa ou não. http://www.l0pht.com/antisniff/

Um FAQ sniffer detalhado e útil pode ser encontrado em. http://www.robertgraham.com/pubs/sniffing-faq.html.

Outra técnica que pode ajudar a prevenir ataques é testar o sistema usando programas que emulam ataques, ou os próprios programas com os quais esses ataques são executados. Você meio que verifica o sistema em condições de combate. Se a proteção for realmente uma prioridade para esta máquina em particular, verificar a configuração do sistema antes de conectar é uma etapa muito importante. Chamo sua atenção para alguns desses programas.

Programas que fazem a varredura do sistema por conta própria:

  • Tiger é um programa ainda em desenvolvimento. ftp://net.tamu.edu/pub/security/TAMU/
  • check.pl é um script Perl que verifica a árvore de diretórios e os arquivos nele e aponta vários atributos questionáveis ​​e nomes de proprietários. http://opop.nols.com/proggie.html

Scanners de rede apontando para serviços disponíveis em outro sistema (uma boa ideia para verificar as configurações do firewall, por exemplo):

  • Strobe é um scanner de rede antigo, mas rápido e eficaz. Às vezes incluído no UNIX. ftp://suburbia.net/pub/
  • Nmap é um programa que usa novos métodos de varredura de portas e é altamente configurável. Permite obter parâmetros do sistema operacional (nome, versão). http://www.insecure.org/nmap/index.html
  • O Portscanner é um scanner de porta pequena que possui muitos formatos para a saída de informações processadas. http://www.ameth.org/~veilleux/portscan.html
  • O Queso não é realmente um scanner; é um programa projetado para determinar o tipo de sistema operacional em um computador remoto. http://www.apostols.org/projectz/queso/

A varredura de software em busca de brechas de segurança em potencial é, sem dúvida, um avanço em relação aos scanners de portas. Aqui, um nível mais alto de análise de informações é aplicado e não as portas abertas em si são determinadas, mas aquelas vulnerabilidades no sistema para as quais o caminho através dessas portas está aberto. Vou citar vários desses programas:

  • O Nessus é um software de rastreamento de ataques cliente-servidor. Existem servidores para Linux, FreeBSD, NetBSD e Solaris, e clientes para Linux e Windows. Além de varrer portas e rastrear ataques, o programa pode realizar pesquisas de DNS para encontrar computadores associados à máquina comprometida. http://www.nessus.org/
  • Saint é descendente do programa Satan, que antes era um dos mais populares para coletar informações sobre carros. Saint usa uma arquitetura cliente-servidor, mas substitui o cliente por um programa da web. O objetivo principal é coletar informações sobre vulnerabilidades na proteção do sistema. http://www.wwdsi.com/saint/
  • Cheops é um programa que faz um mapa do ambiente de rede IP com uma indicação do sistema operacional em execução nos computadores. http://www.marko.net/cheops/
  • SARA (Security Auditor's Research Assistant) é um programa semelhante ao Saint. Pode escanear várias máquinas ao mesmo tempo, além disso, produz o resultado do trabalho em formato HTML. http://home.arc.com/sara/
  • BASS (Bulk Auditing Security Scanner) é um programa cuja ideologia se baseia no fato de que a Internet não é protegida. A principal tarefa é verificar os sistemas em busca de "brechas de segurança" neles. http://www.securityfocus.com/data/tools/network/bass-1.0.7.tar.gz

O programa para fazer a varredura do firewall e verificar se ele está configurado corretamente é o Firewalk. Ao enviar vários pacotes, o programa busca calcular as regras de funcionamento do firewall. http://www.packetfactory.net/firewalk/

O arquivo em http://www.rootshell.com/ contém dados conhecidos sobre erros na proteção do sistema e links para complementos de fabricantes de sistemas operacionais que corrigem esses erros. É verdade que às vezes, em vez de tal link, você pode ver a mensagem "Atualizar para a próxima versão", o que é ofensivo, especialmente se o sistema for comercial. Isso, por exemplo, costuma ser o caso do IBM AIX.

Com isso, gostaria de encerrar a descrição das questões relacionadas à segurança dos sistemas para Servidores de internet... É uma descrição, não um guia de ação e não uma referência detalhada. Meu principal objetivo era dar uma ideia do que precisa ser feito para proteger o sistema. É provável que, em alguns casos, algumas das dicas pareçam supérfluas ou simplesmente desnecessárias e talvez os links para os programas fornecidos não sejam suficientes. No entanto, parece-me que os principais pontos relacionados à proteção de sistemas e redes UNIX foram refletidos em um grau ou outro. Alguns assuntos particulares, talvez, serão discutidos nas próximas edições da revista.

ComputerPress 3 "2001

  • A coerção administrativa e sua diferença de outros tipos de coerção estatal é um sistema de medidas de coerção administrativa.
  • O endereço da instituição que completou o protocolo ___________________________________________________
  • Atos, protocolos. A composição dos detalhes do ato e do protocolo. Localização dos requisitos no formulário A4. Requisitos para o registro do ato e protocolo. Dando ao documento força legal.
  • Anistia: conceito e signos. Perdão: conceito, consequências jurídicas, diferença com a anistia.
  • Sistema de tribunais de arbitragem da Federação Russa. O papel do sistema judicial na resolução de disputas econômicas, incluindo disputas relacionadas à aplicação da legislação tributária.
  • SSH - (Secure Shell) - um protocolo de rede que permite que você controle remoto computador e transferência de arquivos. É semelhante em funcionalidade aos protocolos Telnet e rlogin, mas usa algoritmos de criptografia para as informações transmitidas.
    As deficiências do telnet levaram a uma eliminação muito rápida do protocolo em favor de um protocolo SSH mais seguro e funcional. SSH fornece todos aqueles funcionalidade que foram apresentados em telnet, com a adição de codificação eficaz para evitar a interceptação de dados como nomes de usuário e senhas. O sistema de autenticação de chave pública SSH garante que computador remoto realmente é quem afirma ser.

    A proteção criptográfica do protocolo SSH não é fixa; é possível escolher entre diferentes algoritmos de criptografia. Clientes e servidores que suportam este protocolo estão disponíveis para várias plataformas. Além disso, o protocolo permite não apenas o uso de um shell remoto seguro na máquina, mas também o tunelamento da interface gráfica - X Tunneling (somente para SO tipo Unix ou aplicativos que usam a interface gráfica do X Window System). O SSH também é capaz de transmitir qualquer outro protocolo de rede por meio de um canal seguro (Port Forwarding), fornecendo (com a configuração adequada) a capacidade de encaminhar com segurança não apenas a interface X, mas também, por exemplo, som.
    No entanto, o SSH não resolve todos os problemas de segurança de rede. Ele apenas concentra sua atenção em fornecer trabalho seguro aplicativos como emuladores de terminal. O uso de implementações de protocolo SSH em servidores e aplicativos cliente ajuda a proteger os dados apenas em trânsito. SSH não é de forma alguma um substituto para firewalls, sistemas de detecção de intrusão, scanners de rede, sistemas de autenticação ou outras ferramentas para ajudar a proteger Sistemas de informação e redes contra ataques.
    39. A função e as tarefas do servidor na rede local.

    Em um sentido geral, um servidor é um computador que, via de regra, possui alto desempenho e outros recursos de computação, projetados para fornecer determinados recursos para computadores em uma rede local ou global. Essas oportunidades são chamadas serviços de rede .

    Tarefas do servidor:

    1. fornecer acesso aos dados armazenados nos discos do servidor da organização;

    2. armazenamento, processamento e acesso aos bancos de dados da empresa;

    3. processamento programado dos dados que o usuário envia para ele, e dá a este usuário os resultados finais;

    4. entrega de uma página web ao usuário que a solicita;

    5. enviar, receber, armazenar e distribuir emails que são enviados por todos os usuários da rede local.


    Serviços de rede.

    Para o usuário final, a rede não é computadores, cabos e hubs, ou mesmo fluxos de informação, para ele a rede é, antes de tudo, o conjunto de serviços de rede com os quais ele pode visualizar a lista de computadores na rede, leia um arquivo remoto, imprimir documento em uma impressora "estrangeira" ou enviar uma mensagem de correio. É a totalidade dos recursos fornecidos - quão ampla é sua escolha, quão conveniente, confiável e seguro eles são - que determina a aparência de uma rede particular para o usuário.
    Além da troca de dados real, os serviços de rede devem resolver outras tarefas mais específicas, por exemplo, tarefas geradas pelo processamento distribuído de dados. Essas tarefas incluem garantir a consistência de várias cópias de dados localizados em máquinas diferentes (serviço de replicação) ou organizar a execução de uma tarefa em paralelo em várias máquinas da rede (serviço de chamada de procedimento remoto). Dentre os serviços de rede, destacam-se os administrativos, ou seja, aqueles que se concentram principalmente não em um simples usuário, mas em um administrador e servem para organizar o correto funcionamento da rede como um todo.
    Implementação de serviços de rede é realizada por software... Os serviços principais - o serviço de arquivo e o serviço de impressão - são normalmente fornecidos pelo sistema operacional da rede, enquanto os serviços de suporte, como banco de dados, fax ou serviço de voz, são fornecidos por aplicativos de rede do sistema ou utilitários que trabalham em estreita colaboração com o sistema operacional de rede. De modo geral, a distribuição de serviços entre o sistema operacional e os utilitários é bastante arbitrária e varia em implementações específicas do sistema operacional.
    O termo "transparência" é freqüentemente usado para definir a conveniência de um recurso compartilhado. O acesso transparente é aquele em que o usuário não percebe onde está localizado o recurso de que precisa - em seu computador ou em um remoto. Depois de montar o sistema de arquivos remoto em sua árvore de diretórios, acesse arquivos apagados torna-se completamente transparente para ele. A própria operação de montagem também pode ter um grau de transparência diferente - em redes com menos transparência, o usuário deve saber e especificar no comando o nome do computador no qual o sistema de arquivos remoto está armazenado; em redes com maior grau de transparência , o componente de software correspondente da rede procura volumes compartilhados de arquivos, independentemente de sua localização, armazenamento e, em seguida, os fornece ao usuário de uma forma conveniente, por exemplo, na forma de uma lista ou um conjunto de ícones.
    A maneira de endereçar (nomear) recursos de rede compartilhados é importante para a transparência. Os nomes dos recursos de rede compartilhados não devem depender de sua localização física em um computador específico. O ideal é que um usuário não mude nada em seu trabalho se o administrador da rede tiver movido um volume ou diretório de um computador para outro. O próprio administrador e a rede sistema operacional tem informação de localização sistemas de arquivos, mas está oculto para o usuário. Esse grau de transparência ainda é raramente visto em redes - normalmente, para obter acesso aos recursos de um determinado computador, primeiro é necessário estabelecer uma conexão lógica com ele. Esta abordagem é usada, por exemplo, em Redes Windows NT