Ir para conteúdo
  • Cadastre-se

FernandoM

Membro
  • Postagens

    24
  • Registro em

  • Última visita

Sobre FernandoM

  • Data de Nascimento 25/12/1995

Informações pessoais

  • Nome
    Fernando Miranda

Últimos Visitantes

841 visualizações
  1. Olá, Recentemente por necessidade precisei desenvolver um módulo para o blockchain com retorno automático para o WHMCS 7.x, funcional e testado em ambiente de produção. Se algum dos colegas possuir interesse posso estar disponibilizando o módulo por um valor simbólico, contate-me via MP. O módulo utiliza MySQL para armazenar alguns dados da transação, pode-se utilizar uma database externa ao WHMCS. Disponibilizo o código fonte. Um abraço.
  2. Colegas, boa noite. Percebi que o módulo parou de funcionar já alguns dias, eu consegui resolver o problema de uma maneira bem simples. Aparentemente a função GetStatus do módulo envia requisições POST, não sei o motivo sendo que a API trabalha com GET. Efetuei alguns testes via curl e cheguei a conclusão que o protocolo estava incorreto e que a requisição deveria ser realmente via GET. Enfim, fiz a alteração no arquivo chamado via função "include_once", no meu sistema o nome do arquivo era "lib.php". Procurem a linha "$retorno = $this->DoPost($opt = null, $url, $header, "200", "none", "post");" e alterem para "$retorno = $this->DoPost($opt = null, $url, $header, "200", "none", "get");" dentro da public "GetStatus($id)". Função GetStatus já com a correção: public function GetStatus($id) { $this->getAccessToken(); logTransaction("MERCADOPAGO LIB", $this->accesstoken, "Unsuccessful"); $url = "https://api.mercadolibre.com/collections/notifications/" . $id . "?access_token=" . $this->accesstoken; $header = array( "Accept: application/json", "Content-Type: application/x-www-form-urlencoded" ); $retorno = $this->DoPost($opt = null, $url, $header, "200", "none", "get"); return $retorno; } Me contem se resolveu para vocês, aqui já está funcionando o retorno e inserção nas transações. Ressaltando que o meu problema não estava relacionado a versão 7.6 e sim ao retorno automático após o dia 26. Vocês podem remover a linha "logTransaction("MERCADOPAGO LIB", $this->accesstoken, "Unsuccessful");", havia adicionado apenas para debug e não consegui editar o post anterior.
  3. Pode ser problema na configuração, checa com tcpdump, iptraf ou outro monitor se os pacotes GRE são entregues e recebidos pela sua placa de rede. Já teve um cliente aqui na empresa hospedado na Choopa que utilizou um túnel GRE conosco no cPanel. Os comandos abaixo podem verificar o suporte de GRE na Kernel do Linux. modprobe ip_gre lsmod | grep "gre"
  4. Tenta ligar pra OVH, falar com eles por telefone é mil vezes melhor e são mais atenciosos quanto a resolver alguns problemas causados falhas deles mesmos. Eu usei ReliableSite, tive problemas com ataques NTP, SNMP, Chargen e até SFTP, basicamente qualquer ataque volumétrico eles colocam null-route no sistema, a única coisa que eles mitigavam bem sem jogar em NR era TCP. Eu testei os ataques em outro datacenter e a marca foi de 5 à 9Gbps e a eles dizem oferecer 10Gbps. Não tive problemas com DNS Amplification, apenas na OVH pois estavam bloqueando o tráfego legítimo junto com o ataque porém já foi resolvido uns meses atrás. Eu acredito que a proteção da Choopa seja diferente da ReliableSite, acredito que seja até melhor nesse caso de amplificações. Mas novamente eu repito: a proteção necessária vai variar pra cada pessoa e serviço que ela oferece.
  5. Realmente a proteção deles é boa, porém quando você recebe ataques na aplicação eles bloqueiam 50% do tráfego legitimo (ou seja, usuários reais sendo prejudicados). Tanto que nos servidores game que tenho eu jogo o perfil "Other" que libera tudo e filtro eu mesmo os ataques. Único perfil de mitigação legal que a OVH oferece é Minecraft, pelo menos na MINHA opinião. A mitigação UDP da Sharktech é boa (ideal para jogos), porém eles não se dão muito bem com TCP, tem que pedir eles pra "melhorar" o Firewall quando compra o serviço afim de mitigar os ataques do protocolo.
  6. @Jorge Marcelino para meu uso a Choopa não funcionou muito bem. Pois eles não fizeram o controle de IP Flood, o que matou em alguns ataques onde o link ultrapassava o contratado. Porém eu só uso a OVH pra mitigar TCP, o resto eu mesmo gerencio e bloqueio. O único motivo pra eu ter alguns servidores na OVH é que eles conseguem diminuir bem a quantidade de pacotes por segundo que meus clientes recebem com ataques spoofados no protocolo UDP. Mas como eu disse anteriormente, eu recomendo sim tanto a reliable quanto a choopa se o cara não tiver muita exigência quanto a isto. @Henriquegs a proteção da OVH gamer tem algumas falhas, meios de contornar, mas não é qualquer pessoa que consegue passar por ela. Basicamente eles aplicam limites nos pacotes UDP para regiões, TTL e portas. Porém ter a proteção e não ter suporte ou up-time não dá.
  7. Sharktech em Chicago, a rede me pareceu boa durante os testes porém não havia o hardware disponível que eu precisava. Mas eles não costumam fazer descontos por usuários como a ReliableSite, o preço que tá no site é o que você vai pagar. Se você citar com a ReliableSite que tem um servidor com 20, 25TB de tráfego em outra empresa eles costumam liberar esse tráfego sem custo pra você. Se você não recebe muitos ataques vai de Choopa/ReliableSite mesmo, pois possuem um ótimo ping para o Brasil e mitigam bem os ataques mais comuns a um preço acessível.
  8. Não sei te dizer, eu usei os servidores da ReliableSite por um tempo e não consegui ficar neles devido o sistema de mitigação não funcionar em alguns casos, principalmente com UDP. Porém eu sei que eles dão null-route por qualquer coisinha (amplificada) mesmo que não bata realmente os 10Gbps, porém a sua necessidade e experiência com eles vai depender com o que você trabalha.
  9. @rodrigo286 se você não recebe ataques muito grandes a Choopa irá lhe server muito bem, mas eu acredito que a proteção da Reliablesite seja melhor. Porém basicamente a mitigação deles só funcionam com ataques TCP e Amplificações, raramente irão bloquear um ataque Layer 7 no nível da aplicação tanto UDP quanto TCP. É normal OVH responder isso, aqui comigo é sempre assim, por isso as vezes eu ligo pra eles ao invés de tentar resolver via ticket.
  10. Realmente o suporte deles é horrível @Jorge Marcelino. Meu servidor voltou a funcionar por volta dás 22 horas de ontem, eu também criei um ticket perguntando sobre o problema e a resposta que tive foi uma pergunta sobre: resultado de ping, testes de MTR e isto 2 horas depois que o problema havia sido resolvido. O suporte da OVH sempre vacilou comigo, tanto que estou migrando alguns clientes pra outros DCs. Na OVH abrir-se ticket é aguardar uma resposta automática ou robotizada, infelizmente.
  11. Já entrou em contato com eles? Não sei no caso de vocês, porém o meu IP responde alguns pacotes TCP e outros não (tcping vs ssh client), e há presença de packet-loss em um segundo IP no qual o Firewall é forçado.
  12. Aqui também a mesma coisa @felipe12.
  13. Dependendo de quanto for pagar no dedicado é melhor um Cloud. Porém sempre tenha em mente de que o hardware do dedicado terá um desempenho superior ao de um cloud dependendo do processador, memória e discos.
  14. Não @joaotrd, o Cisco não mitiga ataques Layer 7 UDP.
  15. Por padrão eu deixo a mitigação no modo automático para prevenir problemas de queda no tráfego/filtragem do tráfego legitimo (ocorre muitos incidentes parecidos na OVH), a proteção não leva mais do que 1 minuto pra ser ativada quanto recebe-se um ataque. A respeito das regras, no Firewall da OVH você apenas vai conseguir bloquear as portas, você pode bloquear as portas mais comuns usadas para amplificação (como NTP, SSDP, RIP, etc). Porém o Firewall da OVH já mitiga automaticamente quando este tipo de ataque é recebido.
×
×
  • Criar Novo...

Informação Importante

Concorda com os nossos termos?