O US-CERT – Centro de Resposta a Incidentes de Segurança para a Internet dos EUA – alertou na última segunda-feira (21) para a liberação de uma atualização do protocolo NTP (Network Time Protocol), responsável pela “sincronização dos relógios de dispositivos em uma rede como servidores, estações de trabalho, roteadores e outros equipamentos”.

A atualização (NTP 4.2.8.p9) traz múltiplas correções de segurança; a mais grave delas afeta dispositivos Windows e, caso explorada, permite que atacantes realizem ataques DDoS contra a rede afetada.

O pacote corrige ainda duas vulnerabilidades de nível médio, duas de nível médio-baixo e 5 de nível baixo, além de 28 melhorias não relacionadas a segurança.

A atualização do protocolo está disponível neste link. E uma listagem detalhada das vulnerabilidades corrigidas está disponível aqui.

Recentemente, a Amazon lançou uma livraria física nos Estados Unidos, e agora está lançando um supermercado em que os clientes podem comprar e não precisam passar por nenhuma fila ou mesmo terem que ser atendidos por qualquer pessoa. Os clientes precisam apenas se identificar na entrada com o seu smartphone e após, pegar o que precisam nas prateleiras. Após isso, é preciso apenas sair da loja e a conta é cobrada no cartão.

Através da loja, chamada de Amazon Go, a Amazon pretende fazer com que as pessoas comprem de maneira simples, sem ter que passar por filas. O local é totalmente automatizado, sendo que as prateleiras possuem visão computacional, com fusão de sensores e aprendizado de máquina profundo. Em suma, o cliente, ao pegar algo, acaba sendo identificado pelo sistema e os sensores captam exatamente o que foi retirado da prateleira.

Amazon Go não possui atendentes, bem como caixas. Os clientes podem pegar o que desejarem e a conta vem através do cartão de crédito.

Continue a leitura...

tô velha msm! 100or!! *_*

Pode desligar seu computador tranquilo pois você já viu tudo que deveria ver hoje na internet. De nada.

O cartão SDXC de 1 terabyte (TB) da SanDisk busca atender a crescente demanda por conteúdos de alta resolução, como 4K e 8K, a empresa continua a forçar os limites da tecnologia com soluções que oferecem suporte ao crescimento exponencial de demandas de produção com uso intenso de dados, a empresa continuar a inovar e definir o ritmo para o setor de imagem. O protótipo do cartão SD de 1 TB da SanDisk representa mais uma realização significativa como o crescimento de conteúdos de alta resolução, e aplicativos com uso intenso da capacidade como realidade virtual, vigilância por vídeo e vídeo 360.

Cartões de maior capacidade aumentam as possibilidades para fotógrafos e cinegrafistas profissionais, oferecendo a eles uma capacidade ainda maior de criar mais conteúdos da mais alta qualidade, sem a interrupção da troca de cartões.

Com a crescente demanda por aplicativos como VR, poderá ser usado um cartão de 1 TB para fazer vídeos contínuos de alta qualidade.  Cartões de alta capacidade permitem capturar mais sem interrupções, otimizando o fluxo de trabalho e eliminando a preocupação de poder perder um momento por ter que parar para trocar os cartões.

O post Cartão SDXC de 1 Terabyte da Sandisk apareceu primeiro em Geek Chic.

Maneiro e talz, só não entendi o que leva uma pessoa a treinar algo tão especifico!

Aposto que nenhum deles é um cluster de Raspberry Pi ;-)

O predomínio do Linux como sistema operacional dos supercomputadores mais rápidos do mundo já não é novidade faz tempo. O que a lista atual tem de diferente: os 2 integrantes do Top 500 que não estão rodando Linux rodam AIX, a China e os EUA agora estão empatados em quantidade de supercomputadores do top 500 (171 computadores cada - no ano passado o placar era 200 a 108 para os EUA), e o topo da lista é ocupado por 2 supercomputadores chineses: Sunway TaihuLight e Tianhe-2. (via fossbytes.com - “498 Out Of The 500 Fastest Supercomputers In The World Are Running Linux”)

O artigo "498 dos 500 supercomputadores mais rápidos do mundo estão rodando Linux" foi originalmente publicado no site BR-Linux.org, de Augusto Campos.

Projetada para ser uma distribuição híbrida, que usa a base do SUSE Linux Enterprise – SLE (versão comercial e com suporte técnico da SUSE), a segunda grande atualização do openSUSE Leap 42 está disponível oficialmente depois de ficar em desenvolvimento nos últimos seis meses. Hoje, 16 de novembro de 2016, o openSUSE Leap 42.2 é oficialmente liberado para computadores pessoais.

openSUSE Leap 42

O Leap (“salto”) é uma distribuição híbrida, distribuída gratuitamente, que usa a base do SUSE Linux Enterprise – SLE (versão comercial e com suporte técnico do SUSE). Por ter como base uma distribuição empresarial (SLE, no caso), a estabilidade do sistema aumenta significativamente; chegando a ser difícil encontrar outra distro Linux que possa “competir” nesse quesito. Em resumo, o openSUSE Leap uni o desenvolvimento com a comunidade openSUSE e a base de pacotes do SLE – no passado, o desenvolvimento do SLE e do openSUSE era separado

Assim, o Leap pôs fim ao o ciclo 13.x (13.1 e 13.2), onde as versões 13.1 possuem suporte até Nov/2016 (Evergreen – suporte estendido) e a 13.2 até JAN/2017. Por curiosidade, a estratégia de nomenclatura é SLE 12 + 30 = openSUSE 42 Leap via fonte

A primeira versão do Leap 42 (a 42.1) foi divulgada em novembro de 2015 e a seis meses estava sendo desenvolvida a versão 42.2. Com o lançamento do openSUSE Leap 42.2, conforme portal oficial do Leap, o Leap terá lançamentos em tempos menores e espera-se que os usuários atualizem para a versão mais recente dentro de no máximo 6 meses depois da divulgação de nova versão.

Estima-se que o suporte de cada versão será mantido da seguinte maneira:

• Leap 42.1 – até 6 meses depois da 42.2 (segundo trimestre de 2017)
• Leap 42.2 – até 6 meses depois da 42.3 (segundo trimestre de 2018)

Por fim, o objetivo da comunidade openSUSE é fornecer uma opção mais estável para seus usuários. Ao basear o openSUSE Leap ao SLE (SUSE Linux Enterprise), o núcleo do Leap será mantido pelos engenheiros da SUSE. Isso significa que receberão correções e atualizações de segurança do SLE. O OpenSUSE Leap também irá complementar melhor o Tumbleweed. Pois, o openSUSE Tumbleweed é ideal para aqueles que querem um software mais recente.

Novidades

Para esta versão, o openSUSE Leap vem com o kernel da série Linux 4.4 LTS (suporte prolongado), fornecendo aos usuários uma plataforma mais segura, confiável e estável. Tornando-se ideal para desenvolvedores, administradores de sistemas e usuários; e para pequenas e médias empresas.

“OpenSUSE Leap 42.2 representa o esforço combinado de milhares de desenvolvedores que participam de nossas distribuições e projetos. Nós acreditamos que o Leap é uma distribuição Linux ideal para desenvolvedores, administradores de sistemas e usuários.”

, conforme notícia do Softpedia.

Entre as novas versões de pacotes e tecnologias incluídas no openSUSE Leap 42.2, destaco:

– um grande número de melhorias no YaST (Yet another Setup Tool);
– melhoria nos recursos com snapshot snapper que são baseados no sistema de arquivos Btrfs;
– ambiente GNOME 3.20 e KDE Plasma 5.8 LTS, que são acompanhados pelo LXQt 0.11.0. No entanto, você também poderá experimentar os desktops Xfce, MATE, Cinnamon ou Enlightenment. – Qt 5.6, GTK + 3.20, Python 2.7, Ruby 2.1, Perl 5.18, GCC 6.1.1, 5.3.1 e 4.8.5, OpenSSL 1.0.2h, OpenSSH 7.2p2, libvirt 2.0 e Glibc 2.22.
– aplicativos de virtualização QEMU 2.6.1 e VirtualBox 5.0.24;
– software de compartilhamento de arquivos Samba 4.4.2;
– banco de dados MySQL 5.1.35;
– suíte de escritório do LibreOffice 5.2;
– suporte ao LXC e containers Linux baseados em Docker (1.12);
– suporte para plataformas AArch64 (ARM64) ARMv7 e, e suporte para virtualização aninhada através de KVM.

Obter o openSUSE LEAP 42.2

O download do openSUSE Leap 42.2 pode ser feito em software.opensuse.org. É recomendamo que consulte as notas da versão antes de uma atualização ou instalação.

Os usuários do openSUSE Leap 42.1 podem atualizar para o openSUSE Leap 42.2 através das instruções neste link.

Via | Softpedia | News openSUSE

O post openSUSE Leap 42.2 disponível – versão promete ser ideal para usuários, desenvolvedores e administradores de sistemas apareceu primeiro em Linux Descomplicado.

Até o gambá entrou na bebedeira. Aliás, ele se apaixonou pela garrafa. Não sabemos se aquilo é vômito ou mijo alheio na roupa dela, mas de qualquer forma a noite valeu 100%.

Post original por Jeff Barr | em 24 outubro 2016

Gosto de usar a foto histórica à direita para enfatizar uma situação que muitos de nossos clientes enfrentam. Eles precisam mover sua infraestrutura de TI existente para a nuvem AWS sem programar períodos de manutenção prolongados para a migração de dados. Como muitas destas aplicações são de missão crítica e são fortemente orientada a dados, deixar sistemas off-line para mover gigabytes ou terabytes de dados armazenados simplesmente é impraticável.

Novo serviço

Hoje eu gostaria de falar sobre o AWS Server Migration Service.

Este serviço simplifica e agiliza o processo de migração de aplicações virtualizadas existentes para o Amazon EC2. Para prestar o suporte equivalente de TI do caso de uso ilustrado na foto, ele permite que você replique de forma incremental máquinas virtuais (VMs) ao vivo para a nuvem sem a necessidade de um período de manutenção prolongada. Você pode automatizar, agendar e controlar a replicação incremental dos seus volumes do servidor ao vivo, simplificando o processo de coordenação e implementação de migrações em grande escala que se estendem por dezenas ou centenas de volumes.

Você terá o controle total do processo de replicação, a partir do AWS Management Console, AWS Command Line Interface (CLI) e através de um conjunto de APIs de migração. Depois de escolher os servidores Windows ou Linux para migrar, você pode escolher a frequência de replicação que melhor corresponda ao padrão de uso do seu aplicativo e minimiza a largura de banda de rede. Nos bastidores, o AWS Server Migration Service replicará os volumes do seu servidor para a nuvem, criando uma nova Amazon Machine Image (AMI) para cada volume. Você pode acompanhar o status de cada tarefa de replicação do console.  Cada sincronização periódica gera uma nova AMI, o que permite testar os volumes migrados antes do seu corte final.

Tour pelo Migration Service

Antes de iniciar o processo de migração real, você precisa baixar e implantar o AWS Server Migration Service Connector. O Connector é executado dentro do seu ambiente virtualizado existente, e permite que a própria migração seja feita sem agente, poupando-lhe a dificuldade de instalar um agente em cada servidor existente. Se você comanda uma grande organização e/ou tem vários ambientes virtualizados, você pode implantar várias cópias do Connector.

O Connector tem uma interface web que você acessará de dentro do seu ambiente existente. Depois de clicar no contrato de licença, você será solicitado a criar uma senha, configure as configurações de rede local e finalize com a escolha de algumas preferências. Em seguida, você precisará fornecer ao Connector um conjunto de conta AWS ou credenciais de usuário IAM para que ele possa acessar o SMS, S3 e APIs do SNS. Se você usar um usuário IAM, você também precisará criar uma função de IAM apropriado (o User Guide contém um exemplo).

Com o Connector instalado e funcionando, você pode efetuar login no AWS Management Console, naveguar para o Service Management Server e ver uma lista de todos os conectores que foram registrados com o serviço. De lá, você pode importar o catálogo do servidor de cada conector e inspecionar o inventário de servidores:

Então, você pode escolher alguns servidores para replicar, selecione-os e clique em Create replication jobs. Em seguida, você configura o tipo de licença (AWS ou Bring Your Own) para o servidor:

Feito isso, você pode escolher iniciar a replicação imediatamente ou numa data e hora no futuro. Você também pode escolher o intervalo de replicação:

Depois de analisar e aprovar as configurações, você pode visualizar todos os seus trabalhos de replicação no painel:

Você também pode examinar trabalhos individuais:

E você pode ver as AMIs criadas após cada execução incremental:

A partir daí você pode clicar em Launch instance, escolher um tipo de instância EC2 e realizar testes de aceitação no servidor migrado.

Já disponível

O AWS Server Migration Service já está disponível nas Regiões Leste dos EUA (Norte da Virgínia), Europa (Irlanda) e Ásia-Pacífico (Sydney) e você pode já começar a usá-lo. Não há nenhum custo para o uso do serviço; você paga pelo armazenamento do S3 usado durante o processo de replicação e pelos snapshots do EBS criados quando a migração estiver concluída.

Deixe suas dúvidas e/ou comentários aqui ou escreva diretamente para o nosso colega Jeff Barr (em inglês).

Post original por Jeff Barr | em 01 novembro 2016

O Amazon Linux AMI é projetado para fornecer um ambiente estável, seguro e de alto desempenho de execução de aplicativos em execução no EC2. Com acesso remoto limitado (sem login root e pares de chaves obrigatórias SSH) e um número muito pequeno de pacotes não críticos instalado, a AMI tem um perfil de segurança muito respeitável.

Muitos dos nossos clientes nos pediram para tornar esta imagem Linux disponível para uso local, muitas vezes como parte de suas cargas de trabalho de desenvolvimento e testes.

Hoje tenho o prazer de anunciar que estamos tornando a imagem Amazon Linux Container disponível para uso local e na nuvem. A imagem está disponível a partir do EC2 Container Registry (leia Pulling an Image para saber como acessá-lo). Ela é construída a partir do mesmo código fonte e pacotes como o AMI e lhe dará um caminho suave para a adoção do container. Você pode usá-la como está ou como base para suas próprias imagens.

A fim de testar isso, lancei uma nova instância EC2, instalado Docker e em seguida, puxei e executei a nova imagem. Então eu instalei cowsay and lolcat (e as dependências) e criei a imagem acima.

Para saber mais sobre esta imagem, leia Amazon Linux Container Image.

Você também pode usar a imagem com o Amazon EC2 Container Service. Para saber mais, leia Using Amazon ECR Images with Amazon ECS.

Deixe suas dúvidas e/ou comentários aqui ou escreva diretamente para o nosso colega Jeff Barr (em inglês).

ANTÔNIO ESTARQUE, o Homem de Ferro brasileiro não tem aparatos tecnológicos, computador de bordo, nem sabe voar, mas ele chega fazendo barulho, e mostrando pra galera como é ser um vingador.

COLONIZA + AI CUZAOM

The post Brasileiro destrói estátua de 300 anos em Portugal appeared first on Le Ninja.

Post original por Jeff Barr | em 06 setembro 2016

O AWS Community Hero Onur Salk escreveu o guest post abaixo, para contar como ele ajudou o seu empregador a se deslocar para uma arquitetura sem servidor.

— Jeff;

Sou Onur Salk, AWS Community Hero, AWS Certified Solutions Architect – Professional e organizador do grupo de usuários da AWS na Turquia. Como um Herói, eu gostaria de compartilhar minha experiência e conhecimento sobre a AWS com a comunidade no meu blog pessoal e através de encontros com a comunidade. Hoje eu quero compartilhar a história da Yemeksepeti e nossa mudança para a arquitetura sem servidor.

A história da Yemeksepeti

A Yemeksepeti é a maior empresa de encomendas online de alimentos na Turquia. Ele permite aos usuários fazer pedidos de comida de restaurantes de redes afiliadas sem cobrar qualquer taxa extra. Na Yemeksepeti, precisávamos criar um serviço globalmente distribuído que fosse escalável, de alto desempenho e econômico. Acreditamos que, ao projetar uma arquitetura sem servidor, não teremos que nos preocupar em como gerenciar nossos servidores e assim podemos remover um monte de encargos operacionais da nossa equipe. Isto significa que podemos nos concentrar na execução do nosso código em grande escala.

No Yemeksepeti.com, foi desenvolvido um sistema de descontos em tempo real chamado Joker há cerca de quatro anos. O objetivo deste sistema é o de sugerir descontos para clientes que normalmente não é possível encontrar em restaurantes. A plataforma Joker original foi desenvolvida em .NET e, em seguida, integrada com o site e dispositivos móveis usando sua API REST. Fomos convidados a abrir API da plataforma para a nossas empresas irmãs operando em 34 países, para que eles também possam fornecer descontos Joker em tempo real para os seus clientes.

Inicialmente, pensávamos que iríamos compartilhar o nosso código e deixá-los integrar suas aplicações. No entanto, a maioria dos outros países estavam usando um conjunto de tecnologia diferente (linguagens de programação, banco de dados e assim por diante). Embora o uso de nosso código pudesse acelerar o seu desenvolvimento a princípio, eles teriam que manter um sistema desconhecido. É necessário encontrar um método de integração que fosse mais fácil de implementar e mais barato de manter.

Nossos Requisitos

Este foi um projeto global, e estes eram as nossas cinco áreas de enfoque:

• Facilidade de gerenciamento
• Alta disponibilidade
• Escalabilidade
• Uso em várias regiões
• Vantagem de custo

Nós avaliamos essas áreas de enfoque em vários modelos de processamento diferentes e chegamos à seguinte matriz:

Decidimos usar Faas (Functions as a Service). Começamos o nosso projeto na região Europa (Irlanda) usando os seguintes serviços:

• Amazon Virtual Private Cloud
• Amazon API Gateway
• AWS Lambda
• Amazon Relational Database Service (RDS)
• Amazon Simple Storage Service (S3)
• Amazon CloudWatch
• Amazon Elasticsearch Service

Arquitetura

Nossa arquitetura se parece com isso:

Amazon VPC: Nós usamos o Amazon VPC para lançar os nossos recursos em nossa rede privada.

Amazon API Gateway: Durante a fase de desenvolvimento, começamos a desenvolver o serviço na região Europa (Irlanda). Naquela época, o AWS Lambda não estava disponível na Europa (Frankfurt). Criamos duas APIs: uma para a integração web e outro para a interface de administração. Usamos autorizadores personalizados com JSON Web Tokens (JWT) para permitir a autorização baseada em tokens para os nossos APIs. Usamos modelos de mapeamento para passar nossas variáveis ​​às nossas funções lambda.

Na fase de desenvolvimento, houve apenas uma fase de teste para cada API.

Durante a fase de produção, o AWS Lambda se tornou disponível em Frankfurt. Decidimos mover o serviço lá para nos beneficiarmos do acesso com baixa latência a partir da Turquia. Nós usamos o recurso API do API Gateway Export para exportar a nossa configuração no formato Swagger, em seguida, importou para Frankfurt. (Antes da importação, nós mudamos as definições de região no arquivo exportado para a eu-central-1). Depois disso, foi criada uma fase de produção e utilizadas variáveis ​​de palco para parametrizar as nossas definições de banco de dados das instâncias do Amazon RDS (como host, nome de usuário e assim por diante). Também queríamos usar o nosso nome de domínio personalizado. Depois que compramos um certificado SSL para o nosso domínio, criámos um nome de domínio personalizado no console Amazon API Gateway e criamos um alias para o nosso nome da distribuição do CloudFront (o Amazon API Gateway utiliza o Amazon CloudFront no fundo). Finalmente, criamos uma função IAM para habilitar o registro do Amazon CloudWatch para chamadas de API, latência e mais.

Métricas para recursos Get_Joker_offer:

AWS Lambda: Durante a fase de desenvolvimento, usamos Python para desenvolver o nosso serviço e criamos 65 funções para integrar os nossos métodos de API e tarefas agendadas utilizando triggers Lambda do CloudWatch Events. A integração do Lambda VPC tornou-se disponível durante a fase de produção, de modo que nos carregamos nossas funções para a região de Frankfurt e as integramos com o VPC.

Contagem de invocação da função Get_joker_offer Lambda (Os picos correspondem aos horários de almoço e jantar (quando as pessoas estão com fome)):

Amazon RDS: Durante a fase de desenvolvimento, optamos por usar o Amazon RDS para o PostgreSQL. Criamos uma instância single-AZ RDS para testar o nosso serviço. Durante a fase de produção, precisamos mover o nosso banco de dados porque migramos nossos APIs e funções para Frankfurt. Nós criamos um snapshot da nossa instância e usamos o recurso Copy snapshot do RDS, nós nos mudamos com sucesso o nosso banco de dados. Lançamos duas instâncias no nosso VPC: uma instância multi-AZ para a produção e uma instância single-AZ para fins de teste. Em nossas variáveis ​​de estágio API, definimos os nomes dos endpoints e das nossas instâncias RDS para mapear a migração de dados para a instância apropriada. Nós também permitimos backups automatizados para ambas as instâncias.

Amazon S3: A plataforma Joker tem um painel de administração que é usado para o gerenciamento e relatórios de ofertas do Joker. Para hospedar esta interface de administração, que é basicamente uma Single Page Application (SPA) com AngularJS, foi utilizado o recurso de hospedagem de sites estático do Amazon S3. Toda a lógica e funcionalidade é fornecida através de métodos que funcionam no Lambda, por isso, não é preciso de um servidor para a interface admin:

Amazon CloudWatch: Nós usamos o serviço para monitorar o uso dos nossos ativos importantes e para receber alertas se algo der errado. Nós criamos um painel personalizado para monitorar a CPU do nosso banco de dados de produção, contagem de conexão, latências API críticas e as contagens de função e durações.

No nosso código Python, nós registramos as durações de cada método interno na CloudWatch para acompanhar o desempenho e encontrar os gargalos:

Aqui está o nosso painel no CloudWatch:

Amazon ElasticSearch: Durante a fase de desenvolvimento, o streaming do CloudWatch Logs para Amazon ES tornou-se disponível na região da Irlanda. Usando esse recurso, criamos um painel Kibana para monitorar algumas outras métricas a partir dos logs que geramos a partir de nosso código. Assim que o Amazon ES estiver disponível na região de Frankfurt, vamos usá-lo novamente.

Resultados iniciais

O sistema de Joker está em produção agora, como um piloto para uma pequena região de um país. Como você pode ver no gráfico seguinte, o crescimento do número de pedidos é promissor. Ao alavancar a arquitetura sem servidor, não tivemos de instalar e gerenciar um sistema operacional e dependências. Usando Amazon API Gateway AWS Lambda, Amazon S3 e Amazon RDS, nossa arquitetura é executada em um ambiente altamente disponível. Nós não precisamos aprender e gerenciar quaisquer recursos de replicação mestre-escravo ou ferramentas de terceiros. Como o nosso serviço recebe mais pedidos, o AWS Lambda acrescenta mais instância Lambda, para que ele funcione em qualquer escala. Nós somos capazes de copiar o nosso serviço para outra região usando os recursos de serviços da AWS, como fizemos antes de entrar em produção. Finalmente, nós não executar todos os servidores, por isso, beneficiar da vantagem de custo da arquitetura sem servidor.

Aqui está uma representação do número de encomendas feitas através do Joker:

O que vem agora?!

Esperamos que este serviço se espalhe para todas as 34 empresas-irmãs dentro da Delivery Hero Holding. Como o serviço é implementado globalmente, vamos implantar em outras regiões da AWS. Pretendemos escolher a região mais próxima à empresa. Para otimizar nossos custos, vamos comprar instâncias reservadas para as nossas instâncias RDS. Além disso, como nós monitoramos nossos métodos internos de duração, podemos refatorar e otimizar o nosso código e para que possamos diminuir o tempo de execução das nossas funções Lambda.

Acreditamos que o futuro da nuvem é FaaS. Nós gostaríamos de experimentar mais a medida que outros recursos, serviços e funções se tornarem disponíveis.

Como um AWS Community Hero, estou ansioso para compartilhar a história da Yemeksepeti com o grupo de usuários AWS na Turquia. Eu gostaria de ajudar as pessoas a explorar e alavancar a arquitetura sem servidor.

— Onur Salk

Deixe suas dúvidas e/ou comentários aqui ou escreva diretamente para o nosso colega Jeff Barr (em inglês).

aehooooo

VAI PERDER O IPHONE!!!

The post Essa juventude politizada appeared first on Le Ninja.

• Modsecurity :: Configurando regras de detecção de ataques
• Modsecurity :: Configurando regras de bloqueio de SQL Injection e XSS

Instalando o Mod_Evasive

 # sudo apt-get update ; sudo apt-get install libapache2-mod-evasive  

 root@servidor:~# sudo apachectl -M | grep evasive  
  evasive20_module (shared)  
 root@servidor:~#   

 # vim /etc/apache2/mods-enabled/evasive.conf  

 <IfModule mod_evasive20.c>  
   DOSHashTableSize  3097  
   DOSPageCount    5  
   DOSSiteCount    50  
   DOSPageInterval   1  
   DOSSiteInterval   1  
   DOSBlockingPeriod  30  
   
   DOSEmailNotify   teste@admin.com  
   DOSLogDir      "/var/log/apache2/"  
   #DOSSystemCommand  "su - someuser -c '/sbin/... %s ...'"  
 </IfModule>  
   

• DOSPageCount : Contador de requisições de uma só página 
• DOSSiteCount: Contador de requisições feitas para todo o site
• DOSPageInterval: Intervalo aceitável entre as requisições feitas em páginas específicas 
• DOSSiteInterval:  Intervalo aceitável entre as requisições feitas em todo o site 
• DOSBlockingPeriod: Período de bloqueio do IP em segundos

 # service apache2 restart  

 sudo perl /usr/share/doc/libapache2-mod-evasive/examples/test.pl  

Somente EDMAR o motorista super show pega os passageiros dentro de casa, para que eles não precisem sair na chuva. Que profissional.

PO JONTUIRSON, TU CONVIDOU TEU AMIGO DA ROTAM DE NOVO, CARA?

TU SABE QUE ELE SEMPRE ESTRAGA OS CHURRASCO…