O problema foi detectado na interface de notificação kqueue, o que possibilita o ganho de privilégios a partir de um usuário com acesso local. O problema está apresenta nas versões 6.0 e 6.4 do sistema operacional. De acordo com o The Register as versões a partir da 7.1 não sofrem com a vulnerabilidade.

Frasunek informou que o invasor deve ter acesso local ao sistema e executar um script simples para explorar a falha. Segundo ele, um processo extremamente simples. O especialista chegou a postar um vídeo de 16 segundos na rede Vimeo (vimeo.com/6554787) para apontar o problema.

Os desenvolvedores receberam um aviso sobre a falha no dia 29 de agosto mas, segundo o Register, nenhuma atitude foi tomada até o momento.

Fonte: Geek

• boot;
• lilo (ou grub).

 
Neste artigo vou mostrar como recuperar a senha do root através lilo (com o grub fica parecido, com apenas alguns detalhes a alterar).

O método utilizado foi testado nas distribuições Conectiva e Slackware, porém seu resultado não deve ser diferente em outras distribuições, visto que o software de gerenciamento de boot é o mesmo, mas pelo menos fica a deixa.

Ao inicializar a máquina e aparecer o prompt do LILO (LILO:), digite:

linux init=/bin/bash

Se o seu lilo estiver protegido por senha (através da opção restricted¹) você irá precisar lembrar da senha que definiu no arquivo lilo.conf. Caso não se lembre, a recuperação da senha de root será possível somente através de boot por disquete ou CDROM.

Caso contrário, o LILO carregará o kernel normalmente e te trará o prompt do shell do super usuário sem a necessidade de login. Uma vez no shell, digite:

mount -o remount -rw /
passwd

Digite a nova senha para o root e pronto, “recuperamos” a senha do root! 

Fonte: VivaoLinux

Já foi discutida a teoria, demonstrado como se faz e passados alguns modos de tornar rede mais difícil para um sniffer . Desta vez irei comentar sobre algumas tecnicas para detectar quem na rede está fazendo sniffing . Detectar? Na primeira parte deste artigo eu mesmo não havia dito quesniffing era transparente?

Sim, ele é invisível e, em teoria, indetectável pois apenas coleta informações sem transmitir nada. Porém durante o processo eles acabam produzindo alguns efeitos colateriais que, se estiverem sendo procurandos, podem denunciá-los.

Modo Promíscuo

Como já foi dito outras vezes, quem esta fazendo sniffing está com o adaptador de rede operando em modo promíscuo, logo basta descobrir quem está agindo assim, e a forma mais fácil é simplesmente perguntando! Que no caso do GNU/Linux significa:

artemis:~# ifconfig 
eth0 Link encap:Ethernet HWaddr 00:00:21:CE:11:43 
inet addr:10.0.0.1 Bcast:10.0.0.255 Mask:255.255.255.0 
UP BROADCAST RUNNING PROMISC 
MULTICAST MTU:1500 Metric:1 
RX packets:0 errors:0 dropped:0 overruns:0 frame:0 
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 
collisions:0 txqueuelen:100 
Interrupt:12 Base address:0xf680

Nota: em alguns UNIXes (como Solaris e OpenBSD) você precisará acrescentar o “-a” à linha de comando.

Claro que isto não é 100% confiável pois o invasor pode muito bem ter substituído o ifconfig original por um que não mostre esta mensagem, assim para ter certeza use uma versão original do binário (por exemplo, o binário gravado no CD da sua distribuição). Inclusive uma boa dica de segurança para verificar invasões é fazer uma verificação periódica da integridade dos binários comparando a assinatura MD5 deles.

Outra maneira é explorando uma curiosidade na implementação TCP/IP de alguns sistemas (inclusive no GNU/Linux). Neste caso um computador operando em modo promíscuo acaba por responder a todos os pacotes TCP/IP enviados para seu endereço IP, mesmo que o endereço MAC de destino dos frames estejam errados. Algo que não aconteceria em um modo norlam de operação, pois com o “MAC Address Filter” ligado o adaptador descartaria os frames que não o pertencem. Como isto já foi bastante divulgado, programas mais novos de sniffing cuidam de fazer o “MAC Address Filter” por software.

E apenas por curiosidade alguns sistemas operacionais, por exemplo o Microsoft Windows, incluem estes filtros nos próprios drivers.

Armadilhas

Outra forma de detectar um sniffing é usar alguns truques e deixar que eles se denunciem. Geralmente programas de sniffing fazem uma pesquisa usando DNS-reverso com os IPs que são descobertos. Então basta fazer um “ICMP Echo Request” (mais conhecido como ping ) para endereços IP que certamente não existem e monitorar as requisições feitas em seu servidor de nomes (DNS). Apenas quem tenta descobrir o nome de um host à partir de endereços IP “pescados” em pacotes ARP é quem está fazendo sniffing .

Outra maneira é um teste latência. Apesar de ser meio “sujo” pois pode degradar consideravelmente a performance da rede pode conseguir denunciar quem está fazendo sniffing . O método é simples e baseia-se no envio de grandes quantidades de dados. Para um host que não esteja operando em modo promíscuo é inofensivo mas para quem está em modo promíscuo fazendo captura e análise de pacotes procurando por senhas e outras coisas acaba surtindo algum efeito.

Basta um ping feito antes e durante o teste, quem apresentar diferenças no tempo de resposta pode estar sobrecarregado por algum motivo. Este teste não pode ser considerado como definitivo pois fatores como o tráfego natural da rede pode provocar um atraso no tempo de resposta.

Métodos de detecção que usem ARP ou PING são limitados a redes locais portanto para algo mais abrangente o “Decoy Method” (método do engodo) pode ser bastante útil. Ele se baseia no fato de que vários protocolos enviam a senha aberta sem qualquer tipo de encriptação ( plain text ) e que, provavelemnte, há sempre alguem à procura delas.

Neste caso cria-se um usuário isca, que do outro lado da rede precisará se conectar por Telnet, POP, etc… Este usuário tanto pode ser uma conta que não tenha nenhum tipo de direito (sem “shell”, diretório $HOME apontando para /dev/null, etc.) ou até mesmo o prável cliente de uma servidor que não existe. Um sistema bem simples pode ser montado para registrar as tentativas de uso desta conta, inclusive os arquivos de log padrão do sistema podem ajudar. Depois de tudo pronto tudo é só divulgar conta e senha (mande um e-mail!) e espere que alguém tente usá-la.

Considerações Finais

E assim encerramos esta série, para quem quiser saber um pouco mais recomendo uma pesquisa pelo assunto em sites com http://www.linuxsecurity.com , http://www.secureteam.com e outros sites relacionados com segurança. Até a próxima!

Autor: Giovanni Nunes - Fonte: Olinux.uol.com.br

Basicamente um packet sniffer é um programa que captura os pacotes que estão trafegando na rede e os exibe na tela ou armazena em disco para uma análise posterior. Apesar desta aparente mal intencionada função, as primeiras ferramentas de sniffing foram criadas com o objetivo de ajudar na administração de redes.

O que é um sniffer?

Assim como outras ferramentas que acabaram virando um interessante brinquedo para qualquer candidato a invasor, o sniffer já era transparente aos dispositivos da rede (um port scanner por exemplo pode ser registrado nos roteadores), quase impossível de se detectar e acabou se tornando uma das mais utilizadas ferramentas com propósitos não éticos.

Mas como um programa destes funciona e consegue ter este tipo de acesso privilegiado à rede? Para entender é necessário lembrar como as redes Ethernet funcionam. Quem já fez algum curso/disciplina de redes locais conhece a forma como os adaptadores Ethernet acessam o meio físico, através do CSMA/CD (Carrier Sense Multiple Access/Collision Detect), ou seja, todos os adaptadores competem entre si para transmitir dados e quando dois ou mais tentam fazê-lo ao mesmo tempo há uma colisão, todos ficam calados por um tempo para depois transmitirem.

E por todos usarem o mesmo meio físico para transmitir, por consequência, o mesmo é usado também para receber. Assim cada adaptador fica “escutando” o meio físico (no nosso caso o cabo), carregando cada frame que aparece por lá, comparando o endereço de destino deles, estampado no início de cada pacote, com o endereço gravado na sua ROM e tratando-o. Estes sendo iguais passa adiante (para a camada acima, seja ela IP, IPX, etc…), senão o frame é descartado e começa-se tudo de novo. Este endereço é o MAC (Media Access Control), também conhecido como endereço de hardware, um número único que identifica cada adaptador gravado diretamente pelo fabricante (as operações se baseiam nessa unicidade).

Quando se utiliza um programa de sniffing o adaptador tem seu funcionamento alterado passando a funcionar no chamado “modo promíscuo”, ou seja, independente do endereço de destino do frame ser igual ou não ao da placa, ele é lido como se fosse dele. É o equivalente ao grampo telefônico, só que em escala muito maior pois, dependendo da forma como a rede foi montada, todos que estão ligados nela vão estar vulneráveis.

Técnicas

Dependendo do volume de tráfego na rede, alguns minutos de sniffing são mais que necessários para conseguir quantidade suficiente de informações desde as mais comuns como as senhas de acesso ou números de cartão de crédito dos usuários até trechos de documentos sigilosos da empresa armazenados, por segurança, no servidor de arquivos. De posse dessas informações os usos vão desde simples fraude até espionagem industrial.

E para ter acesso a tudo isto um invasor externo precisa apenas invadir alguma máquina dentro rede, seja explorando alguma falha de segurança ou até mesmo mandando um “cavalo de Tróia” para algum usuário incauto do lado de dentro. Mas até aí tudo bem, basta investir em um bom sistema de segurança com firewall, IP Masquerading, etc… escondendo totalmente a rede interna do mundo exterior. Mas e quanto ao invasor interno? Para um usuário de dentro da rede executar um sniffing basta querer, ainda mais sabendo que vai ser difícil de alguém descobrir.

Mas os programas de sniffing não são de todo mal. Muitas vezes precisamos saber como determinados serviços estão se comportando na rede, principalmente os que não possuem um sistema eficiente de logging como o SMB (Service Message Block, as “redes de windows”) ou serviços mais ligados à camada física como ARP, RARP, BOOTP, DHCP, etc. Nestes casos é bem mais eficiente analisar o que trafegou pela rede à ficar tentando entender o motivo pelo qual, apesar de tudo estar configurado corretamente, as coisas teimam em não funcionar como deveriam.

Outra função prática, seguindo a filosofia do combater fogo com fogo, é a de usá-lo para descobrir que tipo de recursos um provável invasor está usando. Quem é (ou pelo menos quem diz ser), quem está tentando atacar, que portas está usando, qual o método de ataque, etc.

Conclusão

Para GNU/Linux existem vários programas de sniffing , isto graças a libpcapque faz boa parte do trabalho. Basta uma pesquisa rápida por sniffer noFreshMeat para se ter idéia disto. No próximo artigo, além de explicar quem é essa tal de libpcap , inclusive demonstrando como é um ataque de sniffing e como pode-se bloquear, ou pelo menos restringir, a ação deles. Nao perca!

Abraços, 
Giovanni Nunes

Autor: Giovanni Nunes – Fonte: Olinux.uol.com.br

No artigo passado, foi feita uma breve introdução sobre o que vem a ser sniffing , mostrando a teoria que há por trás e as potencialidades desta ferramenta (tanto para a administração de redes como para causar o caos nelas). Desta vez serei um pouco mais prático e falar sobre alguns programas de sniffing para GNU/Linux, aproveitar para simular um ataque e, claro, dar algumas dicas de proteção.

Programas

Como disse no artigo passado uma pesquisa rápida pela palavra “sniffer” mostra a abundância destas ferramentas tanto para GNU/Linux como também para outros sistemas. A tarefa de captura de pacotes, no mundo UNIX, é função da BPF (BSD Packet Filter), implementada principalmente nos BSD UNIX e da libpcap , nos demais. Esta biblioteca além de independente do sistema (leia: independente da forma com a qual o sistema operacional se relaciona com o dispositivo da rede) é compatível com a BPF.

Tanto ela quanto o tcpdump (um dos programas mais conhecidos para sniffing em GNU/Linux) são mantidos pelo “The Tcpdump Group” . Oa tcpdump é basicamente um programa que, como próprio nome diz, exibe na tela (ou direciona para um arquivo) o resultado daquilo que trafega em uma determinada interface. Sua saída é algo como isto (só por curiosidade isto acima é uma sessão de SSH, porta TCP 22):

22:38:48.827070 10.0.0.3.1023 > 10.0.0.1.22: F 3502340068:3502340068(0) ack 8033 57267 win 16060 <nop,nop,(452954 2426575 > (DF) [tos 0x10]
22:38:48.827203 10.0.0.1.22 > 10.0.0.3.1023: . ack 1 win 16060 >nop,nop,(2427891 452954 > (DF) [tos 0x10]
22:38:48.828988 10.0.0.1.22 > 10.0.0.3.1023: F 1:1(0) ack 1 win 16060 >nop,nop,(2427891 452954 > (DF) [tos 0x10]
22:38:48.829524 10.0.0.3.1023 > 10.0.0.1.22: . ack 2 win 16060 >nop,nop,(452954 2427891 > (DF) [tos 0x10]
22:38:51.253614 10.0.0.3.1022 > 10.0.0.1.22: S 3517906445:3517906445(0) win 16060 >mss 1460,sackOK,(453196[|tcp] > (DF)
22:38:51.254060 10.0.0.1.22 > 10.0.0.3.1022: S 928947415:928947415(0) ack351790 6446 win 16060 >mss 1460,sackOK,(2428133[|tcp] > (DF)

Para apenas ver o que está acontecendo na rede é ótimo mas muitas vezes apenas ver o que está trafegando na rede não é suficiente e a saída de um programa como o tcpdump pode parecer um pouco tediosa e chata após de um tempo de observação. Além de que tentar decodificar o que é um pedaço de arquivo, um trecho de uma mensagem fica bastante complicado.

Por esta razão que quando se procura por algo é melhor usar um analisador de pacotes. Estes programas (muitas vezes com função de sniffing embutidada) que interpretam aquilo que foi, ou está sendo, capturado e coloca da mais compreensível para humanos. Um analisador que eu gosto de usar é o ethereal , mas existem outros (alguns comerciais) basta procurar.

Apenas estes três programas já são mais do que suficientes para começar a fazer algumas experiências na sua rede. Sendo assim…

Ataque

Os protocolos mais vulneráveis a um ataque de sniffing são aqueles que transportam dados sem qualquer tipo de codificação, isto é, você digita “pato” e as letras “p”, “a”, “t” e “o” vão trafegar pela rede até seu destino final. Incluem-se nesta categoria Telnet, rlogin, HTTP, SNMP, SMTP, NNTP, POP, FTP, IMAP e além de serviços como talk, finger, whois, etc…

Sabendo disso pode-se, facilmente, simular um ataque de sniffing para exemplificar a vulnerabilidade de certas informações passando por eles. Assim montei uma rede de duas estações, ligadas por um cabo “cross-over” (um cabo de rede onde o Tx e o Rx de cada lado ligam-se, respectivamente, com o Rx e Tx do outro) para simplificar e para evitar a “poluição” gerada pelo tráfego de outros equipamentos.

Deixei o ethereal capturando os pacotes da rede na estação 10.0.0.1 . Enquanto que na 10.0.0.3 me comportei como um tranquilo usuário que, desconhecendo o que está acontecendo em sua rede, fez algo simples: baixar um arquivo via FTP de sua conta. Após ter baixado o arquivo, voltei até a máquina que deixei a estação com o sniffer e fui conferir os resultados.

A senha (“minhasenha”) que usei para me conectar no FTP foi devidamente interpretada pelo programa. E usando a opção “Follow TCP Stream” doEthereal pude recompor os pacotes TCP remontando a sessão:

220 artemis FTP server (Version wu-2.6.0(1) Fri Oct 22 00:38:20 CDT 1999) ready. 
USER giovanni 
331 Password required for giovanni. 
PASS minhasenha 
230 User giovanni logged in. 
SYST 
215 UNIX Type: L8 
(…) 
221-You have transferred 5556 bytes in 1 files. 
221-Total traffic for this session was 12566 bytes in 2 transfers. 
221-Thank you for using the FTP service on artemis 
221 Goodbye.

O resultado é que não só consegui obter a senha do usuário como pude recriar a sessão de FTP e saber de tudo o que ele fez, inclusive existem programas que fazem isto na rede! E a mesma coisa é válida para Telnet, HTTP, IRC, etc…

Proteção

Hardware

Evitar que uma rede local seja atacada assim é querer mexer naquilo que a faz funcionar, então o máximo que podemos fazer é complicar e dificultar um pouco. A primeira idéia que vem em mente é tentar usar adaptadores de rede que não entram em modo promíscuo . Alguns fabricantes até afirmam que possuem produtos assim mas a verdade é que de acordo com as recomendações do PC99 da Intel/Microsoft o modo promíscuo é uma característica obrigatória.

Assim, uma alternativa seria trocar a configuração da rede, substituíndo oshubs por switches . Mas porque? Ao contrário do hub , que é apenas uma emenda de barramento, o switch faz o papel de uma bridge , ou seja, ela faz uma ligação entre dois barramentos distintos, dividindo o tráfego da rede e deixando passar apenas o que realmente é para o outro lado.

Um frame que é enviado da máquina A para a máquina B será bloqueado, mas um frame de A (ou de B ) para C irá “atravessar a ponte” e chegar ao outro lado. Isto não impede o sniffing mas restringe o tráfego da rede para as partes onde ele é necessário. Com isto a quantidade de informação que pode ser adquiria pelo sniffing cai bastante.

Software

Mas também podem ser usadas soluções em software, duas que podem ser facilmente implementadas na rede são:

• Secure Shell (SSH): Foi inicialmente desenvolvido pela empresa finlandesa SSH e acabou se transformando na ferramenta padrão para administração remota em máquinas UNIX, substituíndo completamente o Telnet . Hoje já existem versões open-source e freeware tando do cliente quanto no servidor. No SSH todo o tráfego é encriptado significando que mesmo alguém capture os pacotes não conseguirá ver nada.
• Virtual Private Network (VPN): É uma solução para fugir dos curiosos. Uma VPN é implementanda com uma rede ponto-a-ponto virtual (túnel) ligando dois pontos através de uma rede pública (geralmente a Internet). A vantagem da VPN é possuir encriptação nas pontas, isto é, tudo o que passa pela rede pública é devidamente encriptado.

Além destas soluções outras podem ser implementadas (algumas não tão fáceis) como:

• Kerberos
• Secure Sockets Layer (SSL)
• PGP
• S/MIME
• SMB/CIFS
• Smart Cards
• Stanford SRP (Secure Remote Password)

Conclusão:

Com isto encerramos este artigo ficando para a última parte algo que, em teoria, é impossível: detecção de sniffing. Até a próxima semana e para os que querem se divertir um pouco:

• Appwatch , procurem por sniffing
• libpcap / tcpdump
• Ethereal

Autor: Giovanni Nunes – Fonte: Olinux.uol.com.br

O serviço FTP ou (File Transfer Protocol) é o serviço mais usado pra transferir arquivos entre computadores. Porém o FTP envia informações e o conteúdo dos arquivos pela Internet sem nenhuma encriptação! Essa não é uma maneira segura de comunicação. Secure Copy (SCP) e o SSH File Transfer Protocol (SFTP) resolvem esse problema encriptando toda a comunicação.

Ambos SCP e SFTP usam o SSH (Secure Shell) como seu protocolo. O SSH estabelece um canal de comunicação entre computadores usando autenticação e encriptação baseado em chaves de segurança.

O SSH é distribuído em todas as distribuições Linux. Ele possui diversas funções que não serão descritas nesse artigo.

O SCP e o SFTP

O SCP é diferente do FTP, você pode manter os atributos dos arquivos (data de acesso, modificação e as permissões). Além de transferir arquivos entre seu computador e um host remoto, SCP também pode transferir arquivos entre dois servidores remotos.

O SCP funciona com o SSH1 que já está em desuso. O SFTP trabalha com o protocolo mais atual: SSH2.

O SFTP implementa tudo que um FTP faz e outras operações mais.

O SFTP roda num SSH com a porta 22 por padrão. O nome do comando no Linux é sftp.

Para iniciar uma sessão faça:

sftp baptista.168.1.1

sftp vai pedir uma senha e depois de autenticado, apresenta um shell sftp>. No shell, é possível usar os mesmos comandos do ftp, tais como cd, lcd, ls, chmod, chgrp, get, put, rename, and rmdir. Para finalizar, digite exit. 

O Servidor SFTP

Para ter um servidor SFTP é necessário ter o SSH instalado e a seguinte linha no arqivo de configuração /etc/ssh/sshd_config :

Subsystem sftp /usr/libexec/openssh/sftp-server

Para restringir o acesso de outras máquinas basta editar o arquivo /etc/hosts.deny e colocar:

sshd: 192.168.2.1

Para bloquear uma rede, faça:

sshd: 192.168.2.0/24

ou

sshd: 192.168.2.0/255.255.255.0

Clientes gráficos pro SFTP

Os clientes de SFTP são vários, tais como o FileZilla, WinSCP e DataFreeway (para Windows) ou Nautilus e Konqueror (para Linux).

Você pode digitar o comando

sftp://david.168.1.1:/home/david

no Nautilus ou Konqueror.

O browser perguntará uma senha e depois listará os arquivos no servidor remoto. Você pode transferir os arquivos arrastando, alterar suas permissões ou abri-los.

Existe também um sistema de arquivos seguro (SSH File System) que permite que o cliente SFTP monte um diretório remotamente com segurança e de maneira transparente, mas isso fica pra uma próxima vez.

Abraços e até a próxima, PH 

Autor: Paulo Henrique B de Oliveira – Fonte: Olinux.uol.com.br

Neste artigo iremos falar sobre segurança em FTP (File Tranfer Protocol). O FTP é um protocolo da família do TCP/IP, assim como o Telnet, SMTP, SNMP etc. A sua função, especificamente, é a de transferência de arquivos entre um host e um cliente.

Como todos devem saber, hoje em dia tudo é passível de ser burlado e o FTP não foge a regra, por ser um protocolo antigo, já foram inventadas algumas formas de quebrá-lo.

Para evitar isso, ou dificultar, é necessário que ele seja configurado corretamente e é isso que vamos passar para vocês. Mãos na massa!

Configuração do WU-FTPD (nativo)

Os principais problemas de um servidor FTP são:

• Autenticação do servidor (username e senha) e todos os comandos enviados como texto, ou seja, com um sniffer é possível obter facilmente o username e a senha do usuário;
• Diversos Denial of Service existem para vários servidores FTP;
• Diversos exploits para servidores FTP;

Quando se fala em segurança em servidores FTP, não se pode ser feito muita coisa além de configurá-lo corretamente, estar bem documentado com logs, backup, versões atualizadas etc.

Se você inicializa o FTP pelo inetd (daemon no qual inicializa a maioria dos serviços de rede, como telnet, ftp, finger, ntalkd, smtp, login etc.), o que é o mais comum em todas as versðes de Linux, verifique no arquivo de configuração ( /etc/inetd.conf ) a linha que começa com ftp e coloque-a da seguinte forma:

ftp stream tcp nowait root /usr/sbin/tcpd wu.ftpd -l -L -i -o

A única diferença do atual em seu arquivo deve ser as síntaxes -l (cada sessão de FTP é logada no syslog), -L (todos os comandos enviados para o servidor são logados no syslog), -i (todos os arquivos recebidos pelo servidor são logados para o /usr/adm/xferlog), -o (todos os arquivos transmitidos do servidor são logados para o /usr/adm/xferlog). Vejamos como fica o syslog com uma simples sessão de ftp com o comando tail -f /var/log/messages :

    Oct 30 01:32:21 presario in.identd[8463]: reply to
    192.168.10.2: 1400 , 21 : USERID : UNIX :root
    Oct 30 01:32:21 presario wu.ftpd[8462]: connect from
    root@192.168.10.2
    Oct 30 01:32:30 presario ftpd[8462]: USER molder
    Oct 30 01:32:35 presario ftpd[8462]: PASS password
    Oct 30 01:32:35 presario ftpd[8462]: FTP LOGIN FROM
    presario.earth.com [192.168.10.2] , molder
    Oct 30 01:32:35 presario ftpd[8462]: SYST
    Oct 30 01:32:49 presario ftpd[8462]: TYPE Image
    Oct 30 01:32:49 presario ftpd[8462]: PORT
    Oct 30 01:32:49 presario ftpd[8462]: RETR Untitled
    Oct 30 01:32:53 presario ftpd[8462]: QUIT
    Oct 30 01:32:53 presario ftpd[8462]: FTP session closed

Nesta sessão foi feito o login, baixado o arquivo Untitled e fechada a sessão.

Outra arquivo de configuração é o /etc/ftpaccess . Existem três tipos de logins que o WU-FTPD dispõe:

• Anonymous FTP : que é usado normalmente na Internet, o usuário entra com o username anonymous e na senha o e-mail (ou deveria)
• Guest FTP : neste login o usuário usa uma conta e senha cadastrada realmente no servidor, mas ele fica amarrado ao seu diretório home (/home/user), é o mais indicado quando se quer trabalhar com uploads de arquivo;
• Real FTP : neste último o usuário entra com uma senha e username válidos e tem acesso a todo o disco, este é o menos seguro e indicado.

Todas estas configurações são feitas no ftpaccess , além de outras configurações como: a quantidade de falhas no login; quantidade de conexões quando for remoto ou local; mensagens de login, erro, limites e logout; permissões; diretórios para upload, entre outras coisas. Caso queira saber maiores opções nada como um man ftpaccess .

Obs.: para poder utilizar o arquivo ftpaccess , você terá que colocar a opção -a para habilitar no /etc/inetd.conf . Exemplo:

ftp stream tcp nowait root /usr/sbin/tcpd wu.ftpd -a -l -L -i -o

Existem outros arquivos de configuração para o WU-FTPD, como /etc/ftpusers (para bloquear usuários), ftpservers (para servidores virtuais) e /etc/ftphosts (para bloquear hosts).

Estas são algumas das implementações que podem ser feitas em um servidor FTP padrão, que são encontrados normalmente em qualquer distribuição Linux. Pois isto se aplica ao FTP Server WU-FTPD ( http://www.wuftpd.org ), o qual vem por default nas principais distribuições.

Alternativas para servidores FTP

Existem diversos outros servidores FTP. O WU-FTPD ainda é o mais utilizado, mas este quadro está mudando, pois ele possui muitos problemas de segurança, quando não implementado corretamente. Atualmente, o ProFTPD é o servidor FTP mais seguro e configurável.

ProFTPD

Uma das vantagens do ProFTPD é que toda sua configuração fica em um único arquivo, o /etc/proftpd , que se assemelha em muito com o esquema de configuração do Apache Web Server.

Como principais características do ProFTPD podemos citar:

• Um único arquivo de configuração, no qual sua configuração é intuitiva;
• Fácil configuração de múltiplos servidores de FTP virtuais e serviços de FTP anônimo;
• Pode ser carregado pelo inetd ou standalone;

Para obter uma lista completa das características do ProFTPD visite o site http://www.proftpd.net .

Basicamente o principal arquivo de configuração no ProFTPD é o arquivo /etc/proftpd.conf . Então vejamos um exemplo comentado:

    ServerName "FTP Server"
    ServerType standalone
    DefaultServer on
    ServerIdent off
    Port 21
    Umask 022
    MaxInstances 30
    User nobody
    Group nobody
    AllowOverwrite on

Como visto nesta configuração, o tipo de arquivo do ProFTPD é muito fácil de entender. Eu só queria falar sobre algumas opções que são interessantes a nível de segurança. Uma delas é o “ServerIdent”. Com esta opção habilitada e o “ServerName” com o nome default de instalação, teríamos algo como:

    Connected to presario.earth.com
    220 ProFTPD 1.2.0 Server (ProFTPD Default Installation)
    [presario.earth.com]
    Name (presario:root):

Como você pode notar, com um simples ftp (não precisa nem ter username nem senha), uma pessoa má intencionada já sabe qual é o seu FTP Server e a versão em que ele está. Isto basta para que se procure em algum site de segurança um Exploit ou Denial of Service para este FTP Server com esta versão.

Que tal colocar a opção “ServerIdent” desabilitada (off) e o “ServerName” sem o nome do Servidor? Ficaria assim:

    Connected to presario.earth.com
    220 presario.earth.com FTP server ready.
    Name (presario:root):

Já dificulta um pouco, né?

A opção “ServerType” pode ser inetd ou standalone. A opção de “Umask” é o padrão de permissão para arquivos recém criados. A opção “MaxInstances” controla o número de conexões que o servidor deixa abrir ao mesmo tempo.

Outra opção de segurança é controlar os Hosts que poderão se conectar a este servidor:

    [Limit LOGIN]
    Order Allow,Deny
    Allow from 10.1., 10.2., 192.168.
    Deny from all
    [/Limit]

Esta opção foi colocada fora do “[Anonymous]” ou “[VirtualHosts]” ,pois se fosse colocada dentro aplicaria somente para um ou para outro. Pode ser feito o inverso também. Exemplo:

    [Limit LOGIN]
    Order Allow,Deny
    Deny from 10.1., 10.2., 192.168.
    Allow from all
    [/Limit]

Isto fica de acordo com qual nível de segurança você deseja.

ProFTPD (continuação)

Vamos configurar o acesso anônimo:

    [Anonimous ~ftp]
    User ftp
    Group ftp
    RequireValidShell off
    UserAlias anonymous ftp
    MaxClients 10
    DisplayLogin welcome.msg
    DisplayFirstChdir .message
    [Limit WRITE]
    DenyAll
    [/Limit]
    [/Anonymous]

De acordo com esta configuração, associamos o “ftp user” para o provável diretório configurado para este usuário, o /home/ftp . O ProFTPD irá logar com o user ftp e grupo ftp quando o usuário conectar como anonymous e, além disso, o login como anonymous fica limitado para 10. Logo após o login irá aparecer a mensagem contida no arquivo welcome.msg, no dirtório que está se logando e, a cada mudança de diretório, irá aparecer a mensagem contida no arquivo .message (caso exista um). O Directory refere-se ao /home/ftp/ e irá proibir escrita neste diretório.

Vejamos agora como criar um diretório onde seja possível fazer o upload de arquivos:

    [Limit WRITE]
    AllowAll
    [/Limit]
    [Limit READ]
    DenyAll
    [/Limit]

Neste exemplo vamos criar um diretório incoming no /home/ftp e este vai aceitar envio de arquivos (“AllowAll”), mas não permitirá a leitura dos mesmos.

Após ter sido configurado, basta executar o comando proftpd e seu FTP Server seguro estará rodando.

Você deve ter percebido que o ProFTPD é muito mais fácil de ser configurado e mais simples.

Conclusão

Existem diversos outros servidores de FTP, alguns gratuitos, outros não, mas o que você deve ter em mente é que sempre haverá brechas de segurança, então mantenha seu servidor sempre na última versão (não importa qual você utilize) e não deixe de verificar notícias e avisos em sites como:

http://www.linuxsecurity.com.br
http://www.securityfocus.com
http://www.rootshell.com

Além disso, procure por exploits, Denial-of-Service, ou furos para seu FTP server e caso achar procure também a solução. Isto, é claro, se você realmente precisar proteger seus dados. Como dito no início do artigo, o FTP é um protocolo antigo e, atualmente, uma alternativa mais segura para a transferência de arquivos é o SSH.

Espero que tenham gostado do artigo, qualquer dúvida, crítica, comentário, entrem em contato. Adios amigos!

Autor: Nivaldo Godinho – Fonte: Olinux.uol.com.br

Desde já vou adiantando que condeno qualquer uso deste artigo para prejudicar alguém e gostaria que esta informação não fosse compartilhada pelos leitores com alguém que tenha más intenções. Agradeço a quem tiver esta preocupação.

Os exemplos abaixo são comuns em casos que precisamos da senha:

• Para continuar o trabalho de um administrador de rede que perdeu o serviço de manutenção de um servidor e não deu a senha de root. Já aconteceu comigo. Um administrador, querendo complicar minha vida, não deu a senha do root para o DONO DO COMPUTADOR, mas eu quebrei e ganhei o cliente (espero que ele leia este artigo, hehehe).
• Para resolver um problema de invasão, quando alguém descobre a senha do root, muda, e passa a brincar com o seu servidor;
• Quando você usou um teclado ruim para mudar a senha do root. Já aconteceu comigo também. Mudei uma senha de root remotamente num PC cujo teclado não funcionava a tecla 7. É claro que mesmo pedindo confirmação, digitei a senha errada (sem saber) duas vezes e assim ficou. No dia que tentei entrar diretamente no servidor a senha não funcionava;
• A mais comum: quando esquecemos a senha.

O processo

Na verdade, para quebrar a senha do root temos que editar o arquivo /etc/shadow e apagar os caracteres referentes a senha do root. É SÓ ISSO E PRONTO! O que disserem a mais é perda de tempo. Já vi vários artigos pela internet falando de outras coisas, mas o resumo é este: ALTERAR O /etc/shadow.

Para isso você deve dar o boot por uma distribuição live ou um disquete. Neste artigo vou dar o exemplo de uma distribuição live. Pode ser Ubuntu, Kurumin ou qualquer outra. No meu caso usei o Conectiva Live 10.

As distribuições live já montam a partição referente ao HD da máquina, mas a maioria monta como somente leitura, ou seja, você pode ver os arquivos mas não pode salvar nada. Temos então que alterar esta propriedade para permitir leitura/gravação. Ou você faz isso pelo modo gráfico facilmente, ou desmonta e monta de novo, que foi o que fiz. 

Para desmontar use o comando umount /dev/hda2 (troque o /dev/hda2 para a sua partição). Para montar use o comando:

# mount /dev/hda2 /mnt/hda2_linux (/mnt/hda2_linux pode ser qualquer outro diretório)

Após a partição montada você já poderá editar o arquivo shadow e apagar a senha criptografada do root. No meu caso, a partição do HD ficou em /mnt/hda2_linux. O caminho para editar o arquivo de senhas é /mnt/hda2_linux/etc/shadow.

ATENÇÃO: Não confundir com /etc/shadow. Com o CD live, esta é apenas uma pasta e um arquivo virtual. Como a partição do HD foi montada dentro de um diretório (/mnt/hda2_linux) você deve editar o arquivo da partição montada e não os da distribuição live. Leia um pouco sobre montagem de partições para maiores esclarecimentos.

Para apagar a senha criptografada do root, entre no arquivo shadow, procure a linha do root e apague todos os caracteres entre o primeiro : (dois pontos) e o último. Exemplo:

Linha original do arquivo:

root:458:13360:0:99999:7:::

Linha modificada (sem a senha):

root::13360:0:99999:7:::

Depois disso é só reiniciar o PC normalmente e logar como root. Ele não pedirá a senha. Você deve, é claro, definir sua senha logo após o login através do comando passwd.

Resumindo e repetindo o que eu disse no começo deste artigo, para remover a senha do root, basta editar o arquivo shadow e apagar os caracteres referentes a senha. Toda aquele processo de montagem e desmontagem é apenas para dar permissão de gravação no arquivo shadow.

Se você conhece outra maneira de fazer isso use-a como achar melhor. No meu caso achei este exemplo o mais simples e resolvi postar aqui pra ajudar a quem já teve dificuldades como eu tive. Quaisquer dúvidas estou à disposição.

Autor: Thiago Avelino – Fonte: Olinux.uol.com.br 

Para os adeptos de plantão, este artigo não é para gerar polêmica não, mas para servir de ALERTA!

Muito falamos a respeito da segurança do Sistema Operacional Linux, mas bem sabemos que o Linux também têm suas vulnerabilidades. Quais? As da Microsoft parece que todo linuxer sabe de cor, mas e as vulnerabilidades do próprio sistema operacional?

Pois é. Aqui vai o alerta. Um dia escutei a frase: O Sistema Operacional mais seguro é aquele que você mais domina., e tive que concordar plenamente. Pesquisando então sobre as vulnerabilidades do Linux, esperando encontrar pouca coisa, achei muita gente relatando seus problemas. Até que encontrei no site da SANS (http://www.sans.org/top20) uma pesquisa realizada pela própria SANS junto ao FBI e pude esclarecer esta minha dúvida. A pesquisa aborda as 20 maiores vulnerabilidades encontradas, 10 para servidores Windows e 10 para servidores Unix.

As brechas do Linux

Abaixo estão listadas as 10 maiores vulnerabilidades do Sistema Operacional Linux/Unix, traduzido de Outubro de 2003 e que são válidas ainda hoje:

1. BIND – O BIND é o principal serviço de ataque dos hackers. A maioria dos bugs já foram resolvidos mas a maioria das pessoas mantém as versões mais antigas por uma questão de funcionalidade e por não disporem de tempo para a migração.
2. RPC – O RPC é um serviço para a chamadas de procedimentos que serão executados remotamente. É extremamente importante para a funcionalidade da rede interna pois é utilizado para distribuição de carga, processamento distribuído, cliente/servidor, etc. O NFS, que é um dos compartilhamentos de rede mais conhecidos e utilizados, usa diretamente o RPC.
3. Apache – Sem dúvidas nenhuma é um Web Server bem mais robusto que o IIS, mas não deixa de estar exposto à internet. Vários ataques a sistemas operacionais NIX ocorrem pelo Apache, principalmente para servidores com execução de scripts e permissões de acesso à programas.
4. Contas de usuários – Esta vulnerabilidade ocorre principalmente sobre contas com senhas fracas ou nulas. Parece ridículo, mas tem pessoas que conseguem invadir sistemas descobrindo senhas pelo método da tentativa e erro, e, geralmente, as senhas são as mais óbvias possíveis. Não é o sistema que é hackeado mas a conta do usuário. Uma vez tendo acesso ao sistema, o hacker pode se tornar bastante incômodo.
5. Serviço de transferência em ASCII – FTP e e-mail são os programas diretamente relacionados a estes serviços. Tudo que passar por eles e for texto puro, não encriptado (o que ocorre na maioria das instalações), o conteúdo pode ser capturado. Basta alguma informação ou senha secreta para que a porta esteja aberta.
6. Sendmail – É, talvez, o pior serviço de e-mail do NIX, em comparação com os seus próprios concorrentes. Tende a ser lento e problemático. Mas é o mais utilizado, porque é extremamente operacional. É possível colocá-lo para funcionar rapidamente. Por isto é a maior fonte de furos existente na comunidade. Se puder, substitua.
7. SNMP – Uma excelente ferramenta administrativa, principalmente para grandes corporações. Mas por ser um projeto baseado na comunicação com a rede, está sujeito à vulnerabilidades. O serviço é ativado por default no sistema Linux, o que causa o esquecimento por parte dos usuários.
8. SSH – É a solução ideal para acesso remoto seguro, abolindo de vez o Telnet. No entanto, pode se tornar totalmente ineficaz se não for administrado corretamente. Escolha o nível de segurança mais desejado, lembrando que ele é diretamente proporcional ao trabalho para configurá-lo. E não esqueça de proteger chaves privadas dos usuários!
9. Compartilhamento de arquivos – Ocorre principalmente com NIS/NFS e Samba mal configurados. Podem comprometer a segurança abrindo brechas para ataques externos.
10. SSL’s – Embora sejam extremamente eficazes para criar conexões seguras entre cliente/servidor, os SSL’s permitem o acesso ao servidor por parte do cliente. Pode se tornar uma porta para o acesso de hackers

Como diminuir a vulnerabilidade

Um sistema bem administrado diminui enormemente a probabilidade de invasão. Segundo as vulnerabilidades aqui discutidas, vamos dar algumas dicas de segurança:

1. BIND – Procure adotar uma política de mascaramento das informações.
2. RPC – Use o serviço somente se necessário.
3. APACHE – Ajuste bem as configurações. Habilite somente scripts e programas com destino correto e que não comprometam de forma alguma o sistema.
4. Contas de usuários. Evite criar contas de usuários em demasia, principalmente contas para acesso multiusuário. Adote uma política de senhas seguras e jamais permita o acesso a serviços e contas de usuários SEM senha.5.
5. Serviços ASCII – Toda comunicação pode e deve ser feita de forma encriptada. Arquivos ASCII são muito vulneráveis e todos podem ter acesso ao seu conteúdo facilmente.
6. Sendmail – Atualize e configure corretamente. De preferência, gaste um pouco de tempo e implemente outro servidor.
7. SNMP – Não esqueça de estabelecer as regras de utilização do serviço. Não use se não for necessário.
8. SSH – Muitíssimo bom, mas configure-o da forma mais restrita possível. Restrinja o acesso somente a usuários do sistema. Se possível, restrinja o acesso ao X. Controle o acesso às chaves privadas. Bloqueie passphrases em branco, elas se tornam uma arma na mão dos hackers.
9. Compartilhamento de rede – Compartilhe somente o que for necessário e restrinja ao máximo o acesso dos usuários ao compartilhamento. De preferência use alguma ferramenta de autenticação.
10. SSL’s restritivas é a melhor opção quando não puder ficar sem elas.

Dicas gerais de segurança

• Rode somente os serviços necessários para a operação da sua rede. Serviços que não são muito utilizados caem no esquecimento do administrador.
• Verifique se os serviços estão rodando com privilégios de root, estas permissões geralmente causam os maiores furos na segurança. Se não for necessário, desabilite esta opção.
• Verifique se os serviços estão configurados adequadamente à sua rede. Tutoriais e How-To geralmente indicam o caminho de como configurar, mas na sua maioria não são muito específicos.
• Estabeleça uma política de segurança para a sua rede, como por exemplo, serviços de compartilhamento disponíveis, política de senhas, etc.
• Firewall. Estabeleça um filtro de tudo que entra na sua rede. De preferência feche todas as portas que não são necessárias para o funcionamento do servidor.
• Evite serviços de comunicação p2p, como servidores de músicas, vídeos e até chats e mensagens.
• Como última dica: monitore. Diz o ditado, O boi só engorda aos olhos do seu dono. Se você cuida da sua rede, dificilmente terá problemas de vulnerabilidade.

  Agradeço a atenção e espero que este artigo cause muita discussão por aí. Obrigado.

   

Autor: Thiago Avelino – Fonte: Olinux.uol.com.br