Segurança contra invasões e outras ameaças

Configuração PHP / Ambiente / Performance
#1

Recentemente me esmerei em responder um tópico que foi apagado.
Não julgo a pessoa que o apagou. Ela tem seus motivos e é dona do tópico.
Aqui neste fórum tenho postagens que me arrependo da forma como postei ou respondi.
Mas deixo como um histórico de minha evolução pessoal e para aprendizado dos newbie.
Eu já consegui ajuda neste fórum mesmo em tópicos desvirtuados.
Apagar um tópico é uma afronta a quem deu seu tempo para respondê-lo. Quer a resposta seja a esperada ou não.

Logo, deixo minha resposta sobre a segurança do sc e do sistema para que outras pessoas possam ler.

Boa tarde,
Mais de 50% dos ataques são por engenharia social.
É a técnica mais antiga do mundo.
http://www.tecmundo.com.br/seguranca/8445-engenharia-social-o-malware-mais-antigo-do-mundo.htm
Este tipo de ataque acaba com muita gente e servidores também.
O resto fica por conta… digamos 30% Lammers.
http://canaltech.com.br/o-que-e/hacker/O-que-e-um-Lammer/
Usam ferramentas de terceiros e se vangloriam pela net por terem invadido sistemas e etc que possuem vulnerabilidades conhecidas desde a década passada.
Ai vem 10% como defaced.
http://pt.wikipedia.org/wiki/Defacement
Usam scripts com desenvolvimento próprio ou de terceiros. Geralmente injeção de código.
Vítimas comuns: xoops, magento, oscommerce, joomla e todos os outros gratuitos.
Como tem seu código fonte exposto e a maioria das pessoas não atualizam nada depois de instalados.
São alvo comum. Eu evito este tipo de software.
Por que? Porque já fui vítima deste tipo de invasão e alguns clientes meus que não atualizam gerenciadores de conteúdos também foram.
Não adianta deixar desatualizado e depois querer chorar. Usar um código fonte que todo mundo tem acesso e depois querer se lamentar.
Os sites invadidos com esta técnica geralmente são expostos em lugares como o http://www.zone-h.com.br (clique em onhold). Em ver cópia podem ver o que o invasor fez. Mas não aconselho a entrar. O zone-h é conhecido por propagar ataques e pragas virtuais pela cópia dos sites invadidos. Seu antivírus irá confirmar isto ao tentar.
Os últimos 10% são divididos entre hacker e crackers.
Os hacker são do bem. Invadem e não destroem nada.
Se preocupe com os crackers.
Diferença entre os dois -> http://olhardigital.uol.com.br/noticia/qual-a-diferenca-entre-hacker-e-cracker/38024
Geralmente você acha hackers e crakers em usenet, irc e a deep web.
Lá é o local certo para fazer amizade e perguntar sobre segurança a um hacker.
Enfim, começar a tomar conhecimento sobre as coisas. Se tornar um escovador de bits.
Tome cuidado com o pessoal lá. Eles irão tentar te ferrar primeiro.
Mas, há grupos que, após feita amizade, podem te ajudar a melhorar e testar a segurança do seu site/servidor.
As vezes eles pedem algum conhecimento seu em troca. Ou o reconhecimento da ajuda do grupos destacado na sua página.
Lembre-se: o que você vê lá, morre lá.
Por exemplo, se conversar com bankers (http://pt.wikipedia.org/wiki/Banker) ou algum “proprietário de servidores do governo” (servidores invadidos).
Sai fora, você pode acabar sendo associado a estes tipos de “cracker/hacker” e ter seu nome fichado.
É claro que existe empresas e profissionais de consultoria sobre segurança. Mas ai a moeda de troca será dinheiro.
E o conhecimento será sempre um pouco defasado com o que esta na usenet, irc e deep web.
A segurança em servidores vai muito além de manter pacotes/software atualizados.
É necessário manter softwares de segurança instalados e saber como e por onde eles entram.
Ter serviços apache, ssh, ftp e etc enjaulados.
Isto é somente a ponta do iceberg. Segurança e muito, muito mais.
Por dia eu recebo relatório de no mínimo 120 tentativas de invasão no meu servidor onde o ip atacante foi bloqueado.
Eu sempre estou preocupado com isto.
Se preocupar com arquivos chmod 777 é bom. Irá te livrar de alguns defaced e lammers.
Mas não resolve nem 10% dos outros métodos de invasão.
Espero ter elucidado mais que complicado.

PS: Se procurar fazer amizade na usenet, irc e deep web saiba fazer perguntas inteligentes.
E não haja como um sugador de conhecimento.

Quem puder dar continuidade ao tópico sobre segurança contra invasões e outras ameaças eu agradeço.

Dicas para novatos no Scriptcase. Eu uso tanto quanto eu posso
Tópico de Segurança - Ontem (13/07/2020)
#2

Foi a ‘NSA’ que apagou o POST… hhehee

http://www.scriptcase.com.br/forum/index.php/topic,10138.new.html#new

#3

Verdade jailton,
A NSA é poderosa.
Gente! Se vocês fazem algo para aumentar a segurança no SC / Sistema contribua com estes tópico

#4

Conteúdo tão rico e o pessoal ainda apaga? Vai entender né… (risos). Concordo plenamente com o Alexandre. Segurança a cada dia deve ser revisado e atualizado, pois a cada segundo tem um “chinês”/“Indiano”/“Brasileiro”/Etc… hacker estudando técnicas hacker (invasões, vírus, spans, etc) … “Enquanto você dorme um chinês trabalha”… Vi isso em uma faixa de caminhão, e pensei: Lógico, lá é dia e aqui é noite! Apesar que o sentido do autor não era o que minha lógica dizia. hehehe…

#5

Uma das coisas que me preocupa o temporário da _lib.
Eu agora faço publicação avançada com outro nome para o diretório _lib.
Pois todo relatório pdf por mais secreto que seja cai nesta pasta.
E fica lá pelo período determinado para ser limpo.
Neste meio tempo!?
Já postei isto no fórum, mas o tópico foi moderado nos links de exemplo e agora não encontro mais.

#6

Encontrei o tópico:
http://www.scriptcase.com.br/forum/index.php/topic,6103.msg28118.html#msg28118
Verifiquem se o servidor de vocês faz listagem de pasta.
Se o negócio do seu cliente é secreto ele não vai querer deixar documentos expostos.
O scriptcase tem um tempo certo para fazer limpeza da pasta tmp.
Mas até estes tempo passar, se a listagem estiver habilitada.
Qualquer um pode ter acesso aos documentos gerados em pdf e etc.
Isto vale para qualquer versão do SC.

#7

Pessoal,
Hoje fico com medo de deixar o scriptcase desenvolvimento direto na web.
Temos pasta sem proteção.
Exemplo:

  1. http://seudominio.com.br/pastaondescritpcasedesenvolvimentoestainstalado/config.php
    Ele mostra onde e que banco de dados você está usando e permite mudar os parâmetros de conexão.
    Totalmente sem proteção. Qualquer um na web pode mudar.
  2. http://seudominio.com.br/pastaondescritpcasedesenvolvimentoestainstalado/prod
    Não sei oque acontece se o sujeito mudar tudo ai.
    Mas totalmente sem proteção. Senha padrão: scriptcase.

A netmake pode se posicionar sobre estas situações?

Obrigado

Segurança - Invasão
#8

Fiz teste no meu em produção aqui e não deu acesso.
IIS com listagem desabilitada.

#9

Tambem fiz teste no prod e mesma coisa. não aceita a senha scriptcase.

#10

Eu não costumo deixar meu ambiente de desenvolvimento na web. Fica no meu computador mesmo.

#11

Eu deixo por questão de mobilidade. No entanto é em servidor próprio onde eu mesmo cuido da segurança.
Em 3 anos usando SC ainda não tive nenhum incidente.

#12

Jean,

A minha mobilidade é o meu notebook… rsrsrs mas entendi tua posição.

#13

Jean com a listagem desabilitada não tem perigo.

#14

Somente para centralizar os assuntos sobre segurança. Resposta ao tópico: http://www.scriptcase.com.br/forum/index.php/topic,10830.0.html
Para injeção de código temos a macro sc_sql_injection.
Esta macro é usada para proteger o campo/variável contra “sql injection”.
http://www.scriptcase.com.br/docs/pt_br/v8/macros-scriptcase/macros-scriptcase#sc_sql_injection
cito: http://www.scriptcase.com.br/forum/index.php/topic,6067.msg28006.html#msg28006 e http://www.scriptcase.com.br/blog/o-que-e-sql-injection/
Agora fica a pergunta… E quando a injeção de código é com outras finalidades?
O scriptcase fornece proteção.
Por exemplo a injeção de código para fazer um deface em uma página. Tem proteção?

#15

Cito: http://www.scriptcase.com.br/blog/tela-login-scriptcase/
Sera que tem proteção contra todos estes injections?
Contrariando o blog do scriptcase:
“A melhor parte do módulo de segurança é que todas as aplicações de seu sistema e seu banco de dados estrão protegidos 100% contra qualquer tipo de ataque, a senha do módulo de segurança por padrão é encriptografada usando MD5, que é um algoritmo que utiliza uma função hash amplamente utilizado.”
Acho que nenhum sistema é 100% seguro.

#16

Alguns links sobre o assunto:
http://php.net/manual/pt_BR/security.database.sql-injection.php
http://pt.slideshare.net/rafajaques/construindo-uma-aplicao-php-prova-de-balas
http://pt.kioskea.net/faq/7326-php-erros-comuns-injecao-sql-xss-upload
http://wiki.locaweb.com/pt-br/Protegendo_seu_site_e_seus_formulários
http://www.assimsefaz.com.br/sabercomo/como-fazer-php-injection
http://www.webmaster.pt/blindando-codigo-php-638.html
http://finslab.com/enciclopedia/letra-a/a-injecao-de-codigo.php
http://www.devmedia.com.br/evitando-sql-injection-em-aplicacoes-php/27804
http://en.wikipedia.org/wiki/Code_injection

#17

[size=12pt]Atualizando o tópico pois corre no grupo do whatsapp um relato sobre conseguir tudo que foi desenvolvido no Scriptcase quando é usada a instalação padrão com sqlite com um servidor disponível na internet.[/size]

Isto não é uma falha de segurança do SCRIPTCASE e sim do administrador do site que deixou esta falha de segurança em aberto.
Há maneiras de proteger um banco sqlite num servidor web.
Mas fica a sugestão a netmake de podermos escolher o diretório onde instalar o arquivo sqlite do scriptcase IDE.

Suponho que o relato no grupo do whatsapp seja o método de baixar a base principal do Scriptcase: XX_XXXXXXXXXX.db. Que está em sqlite.
Bem, quando usamos sqlite o ideal e deixar a base num lugar inacessível no servidor. Mas o scriptcase não permite escolher o lugar onde irá ficar sua base sqlite.
Ou seja se a pessoa colocar o link certo baixará toda a base do scriptcase com senhas, projetos e tudo o mais.

[size=12pt][b]Como resolver sem ter que instalar o scriptcase novamente usando outro banco de dados?

Use .htaccess[/b][/size]

[size=12pt]Em nosso servidor nossos usuários tem como proteger diretórios de forma simples pelo ISPCONFIG. E podemos auxiliar nossos usuários nesta configuração[/size]

Ao tentar acessar o aplicativos ou mesmo fazer download da base XX_XXXXXXXXXX.db o acesso será bloqueado e somente liberado mediante usuário e senha específico.

Eu mesmo uso este tipo de proteção no meu scriptcase desenvolvimento pois prefiro sqlite que facilita o backup.
Não vou ensinar como fazer .htaccess para autenticação de forma manual pois tem vários tutoriais na internet como este http://www.devin.com.br/htaccess/

Observação: .htaccess somente funciona com Apache.
No Nginx tem como fazer mas não é tão simples e somente usando módulos de terceiros.
Logo, não tem como garantir a segurança. No nginx use o Scriptcase IDE instalado com MySQL por exemplo.

#18

Parabéns pela dica Alexandre.

#19

Pois é Fui eu quem levantou a questão , e demonstrei o problema rsrs “gerei panico na galera”.

Mas sim vale lembrar que é problema do ADMINISTADOR e não do Scritpcase.

Tem outras coisas , por exemplo é possível alterar o nome do SQLITE da Instalação sem perder os dados, ou ate mesmo (pra quem é mais entendido de DBA) pode migrar o SQLITE para MySQL , e sem precisar reinstalar o Scriptcase é possível alterar a conexão dele.

#20

No nginx tem como evitar o download de alguns arquivos. Isso já inibe alguns acessos. Ex:

server {
...
       # Evita download de .zip
        location ~ \.zip$ {
             rewrite / permanent;
       }

      # Evita o download de qualquer arquivo da pasta files
       location ~ ^/(?P<files>.*)/ {
            rewrite / permanent;
       }

      # Evita o download de extensões zip e abc dentro da pasta files
       location ~ ^/(?P<files>.*)/(.*?)\.(zip|abc)$ {
            rewrite / permanent;
       }

}