2017-02-18

Segurança da LAN doméstica com IPv6

Sua LAN está protegida, mas não é o NAT que faz isso.

Estou usando IPv6 em casa e no home office há alguns meses, e você provavelmente também pode usar já.

É curioso como a gente se sente seguro atrás do NAT do modem. Eu certamente me sentia mais tranquilo usando IPv4 com NAT feito pelo modem, sabendo que o NAT impedia que minhas máquinas dentro da LAN recebessem uma requisição de conexão vinda da Internet. Afinal, na Internet ninguém sabe o que há por trás do IP público que está no meu modem.

De onde vem o medo pelo fim do NAT que o IPv6 traz?

O medo vem do fato de que qualquer máquina na Internet (v6) pode mandar pacotes diretamente para o meu computador atrás do modem, pois ele é globalmente acessível no endereço xxxx:yyyy:zzzz:aaaa:bbbb:cccc:dddd:eeee. Isto é, todo host IPv6 é globalmente endereçável.

Mas lembre-se: globalmente endereçável ≠ globalmente acessível.

A sensação de segurança decorrente do NAT é falsa: [IPv6 Security Myth #3 – No IPv6 NAT Means Less Security]

Resumo do link acima: ao usar IPv4, quem dá segurança à sua LAN é o firewall SPI (stateful packet inspection) do modem, não o NAT.

Como seu modem oferece segurança à sua LAN

Veja a figura abaixo.

Quando seu computador na sua LAN doméstica se comunica com um host na Internet, ele manda o pacote ao modem, esse pacote é registrado pelo modem (quem mandou o pacote, de qual porta veio, pra qual porta vai, e pra qual IP (v4 ou v6) o pacote vai), e o modem encaminha o pacote ao IP (v4 ou v6) de destino.

O pacote de resposta vem da Internet e chega ao modem, que por sua vez verifica se o IP e a porta de origem do pacote de resposta casam com aquele pacote que saiu há pouco. Caso não casem, o modem bloqueia o pacote. Aí está a sua segurança. Este é o stateful packet inspection que o modem faz.

Veja como fica o firewall IPv6 do modem com Stateful Packet Inspection. Note que simplesmente retiramos a etapa de tradução do endereço de destino no retorno do pacote. Mas a segurança continua lá.

Exemplo da tela de configuração do meu modem Technicolor TD5336:

modem settings image
O modem já vem configurado para boquear todo e qualquer acesso à LAN vindo da WAN (isto é, da Internet).

Veja que prático, o modem já vem com a regra configurada: todo pacote pode sair da LAN para a Internet (WAN, no linguajar do modem), mas nenhum novo pacote pode vir da Internet para a LAN. Resolvido! \o/

Mais ou menos. Já ouviu falar da importância dos pacotes ICMP para o IPv6?

Modem fechado demais

No IPv6, os pacotes ICMP (chamados de ICMPv6) têm um papel central, mais do que no IPv4. Como no IPv6 a comunicação se dá diretamente entre seu laptop e o host na Internet, sem um NAT para intermediar, é o seu laptop que precisa receber os pacotes ICMP em caso de problemas nessa comunicação.

Veja aqui uma bela lista de todos os tipos de pacotes ICMPv6.

O mais importante e que normalmente vem desativado nos modems é o Packet too big, que os roteadores utilizam para informar que um pacote é maior que o MTU. [Mais detalhes]
Além, claro, dos tipos Echo request e Echo reply (ping e pong, respectivamente).

Um site que testa o sucesso dos pacotes ICMPv6 na sua conexão é este:

Abra seu modem

O primeiro passo nos meus dois modems após ativação da conexão IPv6 foi pedir ao firewall para permitir a entrada de todos os tipos de pacotes ICMPv6. Aqui está como ficou o filtro de IP no modem Technicolor TD5336:

A regra acima é bem simples: permitir todo pacote ICMPv6 vindo da WAN para a LAN.

É neste mesmo item de configuração que você pode abrir a comunicação com suas máquinas na LAN. Por exemplo, eu adicionei mais uma regra para permitir a comunicação com a porta TCP/22:

Note que basta não definir os IPs de origem e destino para que a porta TCP/22 seja permitida para toda a LAN.

Ainda não acredito que meu NFS/SMB/rsync/HTTP/DNS/FTP não está vazando para a Internet

Eu entendo. É difícil acreditar mesmo. Também custei a acreditar. Mas há uma forma fácil de testar: Eu uso o serviço de shell remoto devio.us há vários anos e ele foi minha principal ferramenta para testar a conectividade entre minha pacata LAN e a tempestuosa Internet.

Exemplo de teste:

  1. Abrir no modem uma determinada porta. Por exemplo, a porta TCP/9000
  2. Se não houver algum serviço escutando nessa porta, ponha o netcat para escutar: nc -l 9000
  3. ssh usuário@devio.us
  4. usuário@devio.us $ nc -vz meu:ip:v6:do:laptop 9000
  5. O resultado que indica sucesso é nc for Connection to meu:ip:v6:do:laptop 9000 port [tcp/*] succeeded!
  6. Agora experimente abrir no laptop mas não no modem alguma outra porta, por exemplo, a TCP/9001:
    nc -l 9001
  7. Entre no shell remoto e tente se conectar a essa porta:
    usuário@devio.us nc -vz meu:ip:v6:do:laptop 9001
  8. O resultado que indica sucesso agora é Connection timed out, pois o modem não está permitindo essa conexão.

E com isso nós provamos que o modem está protegendo sua LAN, mesmo quando você usa IPV6 e o seu laptop tem uma porta aberta. Se você não abrir a porta no firewall do modem, ninguém no mundo conseguirá se conectar a essa porta no seu laptop.

Próximos posts

Sabia que é possível conectar duas redes IPv4 através da Internet usando uma VPN IPv6? Os próximos posts vão mostrar como fazer isso usando OpenVPN. É assim que eu conecto minha rede de casa à do meu home office remoto.

E também:

  • Desempenho do IPv6 versus IPv4
  • Uma solução para associar de maneira estável o IPv6 dos hosts da sua LAN a um hostname (isso é complicado porque o provedor muda o prefixo IPv6 de tempos em tempos
  • Insira aqui uma sugestão de tema: _______________ :-)

Um abraço e até a próxima!

2016-12-25

Natal IPv6: acenda as luzes desta árvore só com IPv6

E aí, já tá acessando a Internet com IPv6?

Siga minha dica e conecte-se via IPv6!

Se sim, você já pode acender as luzes de um arvorezinha localizada na Bélgica.

Trivia: a Bélgica é líder mundial na adoção do IPv6. [Saiba por quê]

Funciona assim: você pinga somente via IPv6 um endereço que inclui o código RGB da cor que você deseja, aí uma das lâmpadas da árvore acende com a cor escolhida.

Alguns exemplos de cores:

$ # Para acender VERMELHO: $ ping6 2001:6a8:28c0:2017::FF:00:00 $ $ # Para acender VERDE: $ ping6 2001:6a8:28c0:2017::00:FF:00 $ $ # Para acender AZUL: $ ping6 2001:6a8:28c0:2017::00:00:FF $ $ # Para acender AMARELO: $ ping6 2001:6a8:28c0:2017::FF:FF:00 $ $ # Para acender na de código RGB 41-DF-A0: $ ping6 2001:6a8:28c0:2017::41:DF:A0

O site original está aqui.

2016-12-18

IPv6 + IPv4 (dual stack) com Live TIM

Estou escrevendo este longo post a partir do meu laptop, em casa, conectado ao Gmail e ao Blogger via IPv6 sem passar por túneis.

Em outra aba do navegador, estou conectado ao reddit via IPv4 também sem precisar de túneis.


Esta é a conectividade IPv4 + IPv6 em dual stack que eu vinha buscando há alguns anos. Finalmente consegui, e descrevo aqui o que foi necessário, além de relatar o que funciona e não funciona conforme esperado.


Como consegui IPv4 e IPv6 em dual stack com a Live TIM

Dual stack (pilha dupla) é como se chama a conectividade simultânea às redes IPv4 e IPv6, entregue pelo provedor direto ao modem, sem emprego de técnicas de transição como túneisCGNAT ou outras artimanhas.

(NOTA: Não recebi nem recebo nada da TIM para falar bem do serviço Live TIM.)

Sou um feliz usuário do acesso à Internet pela Live TIM há uns 2-3 anos em meus dois endereços na cidade do Rio de Janeiro: minha casa e meu escritório-doméstico-fora-da-minha-casa, carinhosamente apelidado de mamma's home office. ou M.H.O.


Meu acesso no M.H.O. (mamma's home office) tem velocidade de download de 70 Mbps e upload de 30 Mbps.

Em casa, o download é de 35 Mbps e o upload é de 20 Mbps.

Solicitação à Live TIM, uma novela com final feliz

Pedi à TIM para ativar conectividade IPv6 em casa. Porém, como não funcionou de primeira, foram feitos inúmeros contatos telefônicos, uma verdadeira novela, até eu conseguir a tão desejada conectividade IPv4 + IPv6 em dual stack.

A novela começou dia 6/setembro/2016, quando liguei pela primeira vez para o suporte técnico da Live TIM no 10341 e pedi para ativarem a conectividade IPv6 na minha conexão sem perder a conectividade IPv4. Para minha surpresa, disseram que “sim”. Eles me ligariam em até 5 dias úteis para configurar comigo o meu modem.

Ligaram.

Configuramos juntos o modem.

Não funcionou. :-(

Ferramentas e comandos que ajudam a inspecionar o funcionamento do IPv6:

  • ping6 ipv6.google.com (é o bom e velho ping, mas só utiliza IPv6.)
  • ip -6 address list (lista seus endereços IPv6.)
  • ip -6 route list (lista as rotas IPv6, inclusive a rota padrão.)
  • curl -6 uol.com.br (visitar a página principal do UOL via IPv6. Deve retornar um longo código HTML.)

Me pediram alguns dias para rever as configurações e também me pediram para visitar alguns sites de diagnóstico e enviar a eles os screenshots.

Sites de diagnóstico:

  • http://test-ipv6.com/
  • http://ipv6.google.com
  • http://ipv6-test.com/ (especial atenção a este aqui e ao que ele diz sobre ICMP! É você, cliente, quem tem que configurar seu modem para deixar passar ICMPv6.)

A cada nova ligação do suporte da TIM identificávamos mais uma dificuldade com a conexão, até que esgotamos todas e a TIM veio trocar meu modem por um Technicolor TD5336, que finalmente funcionou sem necessidade de alterar nenhuma configuração.

Modems que estou usando com sucesso com IPv6, ambos fornecidos pela TIM após 1 ou mais trocas:

  • Technicolor TD5336
  • Sagemcom F@st 5310

Modems que não funcionaram com IPv6:

  • Sagemcom F@st 4310 (não recebia um IPv6, ou não retransmitia pacotes IPv6 à LAN)
  • Technicolor TG589vn v3 (não recebia um IPv6)
  • Zyxel VMG8924-B10A (recebia um IPv6 e retransmitia para a rede interna, mas perdia a maioria dos pacotes ICMPv6 vindos da WAN)
Nota: o suporte técnico da Live TIM sempre foi excelente em todas as várias interações que tive com eles. Me telefonaram inúmeras vezes, sempre absolutamente cordiais e educados, além de dedicados a resolver meu problema. Muitos desses telefonemas foram às 20:00, 21:00. De verdade, ótimo serviço de suporte.

Habemus IPv6. Como a Live TIM entrega um IPv6

Com o novo modem, tudo funcionava conforme esperaddo: recebi um IPv4 (como de costume) e agora também um IPv6 sob o prefixo 2804:214:3:57cc::/64. Absolutamente lindo.

Imediatamente pedi a ativação da conectividade IPv6 na outra conexão, isto é, no M.H.O.

Em ambos, assim é a configuração:

Rede externa:

IPv6 na interface WAN recebido via SLAAC (Stateless Address Autoconfiguration). O modem recebe do provedor apenas as rotas via RA (Router Advertisement). ULA desativado.

Rede interna:

Com base nas rotas recebidas do provedor, o modem entrega à minha LAN os endereços IPv6 via DHCPv6. [Mais detalhes de DHCPv6 versus SLAAC]

SLAAC

Basicamente, um "servidor" SLAAC envia aos clientes a informação de prefixo IPv6 e também o gateway padrão. Nada mais. Nada de DNS, por exemplo. Se você quer que seu modem envie aos clientes o endereço dos servidores DNS, só o DHCPv6 te salvará: ative no seu modem o DHCPv6 interno e defina com ele os endereços dos servidores DNS que você quiser passar aos clientes.

DNS em IPv6 e em IPv4

Qualquer servidor DNS pode te retornar qual é o IPv6 da Wikipédia. E também o IPv4. Não importa se o seu servidor DNS está escutando na rede IPv4 ou IPv6, ele certamente consegue retornar o IPv4 (registro A) e também o IPv6 (registro AAAA) de www.wikipedia.org ou de qualquer URL.

Por exemplo, experimente:

$ host -t A www.wikipedia.org 8.8.8.8 www.wikipedia.org has address 208.80.154.224 $ $ # Agora o registro AAAA $ host -t AAAA www.wikipedia.org 8.8.8.8 www.wikipedia.org has IPv6 address 2620:0:861:ed1a::1

O servidor DNS público do Google, que responde no IPv4 8.8.8.8, sabe me dizer que o endereço IPv4 (registro Address) de www.wikipedia.org é 208.80.154.224, e também sabe me dizer que o IPv6 da mesma URL www.wikipedia.org é 2620:0:861:ed1a::1.

Ou seja, você não precisa fornecer servidores DNS na rede IPv6 para usar IPv6.

Como está minha LAN agora

Com essas configurações, o modem entrega aos computadores da minha LAN um IPv4 privado (rede 192.168.x.y) e também um IPv6 público. Cada computador também gera de forma autônoma um segundo endereço IPv6, este privado (local-only ou somente local, no prefixo fe80::/64.

O espaço de endereços IPv6 possui alguns prefixos já pensados desde o início para uso exclusivamente em redes privadas, isto é, incapazes de alcançar a Internet e portanto dedicados unicamente à comunicação dentro de uma rede privada como a da minha casa. O prefixo fe80::/64 é esse prefixo. [Mais]

Dado interessante: meu modem recebe na interface externa um IPv6 público fora do meu prefixo. Se meu prefixo dado pelo provedor é 2345:abcd:1234:5678::/64, o modem pode perfeitamente ter o IPv6 público 9876:5432:1111:2222:3333:4444:5555:6666.

Isso é possível porque meu modem não precisa ter um IPv6 público dentro do meu prefixo. Ele simplesmente encaminha à rede do provedor os pacotes que saem da minha LAN rumo à Internet.

No entanto, meu modem tem, sim, um IPv6 privado que só funciona na minha rede interna,fe80::2a0:12f:fc31:e2e8. Veja a rota que meu sistema atual mostra:

$ ip -6 r 2804:214:3:57cc::254 dev wlp3s0 proto kernel ⤾ ⤷ metric 256 expires 85483sec pref medium 2804:214:3:57cc::/64 dev wlp3s0 proto ra ⤾ ⤷ metric 600 pref medium fe80::fe52:8ddd:feb4:303b dev wlp3s0 proto static ⤾ ⤷ metric 600 pref medium fe80::/64 dev wlp3s0 proto kernel metric 256 ⤾ ⤷ pref medium default via fe80::fe52:8ddd:feb4:303b dev wlp3s0 ⤾ ⤷ proto static metric 600 pref medium

Veja que interessante: meu gateway padrão na rede IPv6 usa o prefixo somente local fe80::/64 (última linha do comando acima).

Os pacotes IPv6 que saem do meu sistema rumo à Internet têm como IPv6 de origem o meu endereço IPv6 público, mas são enviados ao meu modem por seu IPv6 somente local. Tudo bem, isso definitivamente não é um problema.

O que funciona nos meus acessos via IPv6

  • O acesso à Internet em IPv6 funciona maravilhosamente.
  • Todos os apps do Google (Drive, Docs, Sheets...), toda a Wikipédia, o site do UOL, o site da Red Hat. Estou acessando todos via IPv6.
    Dica: extensão para Google Chrome que indica se você está acessando um site via IPv4 ou IPv6: if IPv6.
  • Consigo descobrir o endereço público do meu laptop a partir do próprio laptop, sem precisar de comandos como curl [-4|-6] ifconfig.co para ir até a Internet descobrir meu IP público. Basta usar o tradicional comando ip:
    $ ip -6 addr list 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 state UNKNOWN qlen 1 inet6 ::1/128 scope host valid_lft forever preferred_lft forever 3: wlp3s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 ⤾ ⤷ state UP qlen 1000 inet6 2804:214:3:57cc:822c:4196:32b6:ea38/64 scope ⤾ ⤷ global noprefixroute valid_lft forever preferred_lft forever inet6 fe80::6212:3c69:21:f11a/64 scope link valid_lft forever preferred_lft forever $ $ # Confirmando com o curl $ $ curl -6 ifconfig.co 2804:214:3:57cc:822c:4196:32b6:ea38

O que não funciona


Meu IPv6 não é fixo! :-(

Em poucas palavras, o prefixo IPv6 que a TIM me entrega não é fixo.

Em mais palavras, meu prefixo inicial 2804:214:3:57cc/64 gerou para meu laptop o endereço 2804:214:3:57cc:9431:43ad:fa3:38ea, que eu rapidamente adicionei ao DNS do meu domínio particular, todo orgulhoso.

Eu realmente acreditei, por alguns momentos, que não precisaria mais de um DNS dinâmico como o dyndns para conseguir acessar meu servidor doméstico de qualquer lugar do mundo.


Depois do primeiro reboot do modem, a surpresa: o IPv6 do meu servidor doméstico tinha mudado! Sob inspeção mais meticulosa, descobri que o prefixo fornecido à minha conexão pela Live TIM havia mudado. :-(

Resultado: voltei a precisar de um DNS dinâmico. Desde então estou usando o ultra-simples dynv6.com com o script bem simples que ele próprio oferece. Meu servidor doméstico roda o script de atualização a cada 60 minutos e a vida segue. Um pouco triste, mas segue.

Dentro da minha LAN, uma possível saída é fazer referência ao IP somente local das máquinas em vez de usar o IP público. Isto é, meu DNS interno vai dizer que tralala.redeinterna aponta para fe80::63a7:32:ff82:23fc em vez de apontar para 2804:214:3:57cc:63a7:32:ff82:23fc. O endereço somente local das máquinas internas não muda. No entanto, isso significa que eu continuo tendo que usar um endereço diferente para me conectar a tralala.redeinterna se eu estiver dentro de casa ou fora de casa.


Não tenho IPv6 reverso

Veja estes comandos:

$ host -t AAAA www.uol.com.br homeuol.uol.com.br has IPv6 address 2804:49c:3103:401:ffff:ffff:ffff:1 $ $ # Agora a resolução reversa $ host 2804:49c:3103:401:ffff:ffff:ffff:1 Host 1.0.0.0.f.f.f.f.f.f.f.f.f.f.f.f.1.0.4.0.3.0.1.3.c.9.4.0.4.0.8.2.ip6.arpa not found: 3(NXDOMAIN)

Ainda não encontrei o motivo para a resolução reversa de IPv6 não ser levada a sério.

Segurança: a vida sem NAT

Esse aqui fica para o próximo post.


Até breve!

2013-08-13

Have SSH prompt your users twice for their password

The SSH service is a vital part of IT management operations. However, keeping intruders out while allowing password authentication can be a pretty hard challenge. In this scenario, passwords are usually the weakest link: since security and convenience run in opposite directions, misinformed users will always look for some way to improve convenience at the cost of "a little" security. That's where they choose weak passwords that can be easily guessed by brute force.

Brute-force guessing passwords is a simple challenge that's mostly time-bound. The attacker typically tries every one from a list of common passwords until they are allowed into the target system. Failed passwords don't allow the attacker to tell whether they got only two or ten characters wrong. The easier to guess the password, the earlier it appears in the attacker's list. And the quicker the attacker can try another password, the quicker they reach the correct one.

Stalling the attacker with a short interval before they are allowed to enter a new password seems like a good plan, but the password guessing attack can be easily parallelized. A much better alternative is to ask your users to enter their password twice: the unknowing attacker will never try the same password twice in a row — why would they? — so even a password of "123" could keep them out, while attackers who know about this strategy will at least be stalled.

This post explains how to implement this strategy on Red Hat Enterprise Linux 6.x systems. For that, all you need to do is edit the /etc/ssh/sshd_config and /etc/pam.d/sshd files.

sshd_config

OpenSSH is a flexible daemon. It can perform password authentication with or without talking to PAM (Pluggable Authentication Modules). By default, Red Hat Enterprise Linux 6.x will enable sshd's use of PAM (UsePAM yes on /etc/ssh/sshd_config) for password authentication, which is part of what you'll need. It will also enable password authentication (PasswordAuthentication yes on the same file) and disable challenge-response authentication (ChallengeResponseAuthentication no, same file), which is the opposite of what's needed to ask the user to enter the password twice. So, first of all you will need to change these settings:

#/etc/ssh/sshd_config
...
PasswordAuthentication no
...
ChallengeResponseAuthentication yes
...

(Documentation on sshd_config(5))

PAM configuration

The file controlling PAM's behavior when authenticating SSH users on Red Hat Enterprise Linux 6.x is /etc/pam.d/sshd and it looks like this by default:

#%PAM-1.0
auth       required     pam_sepermit.so
auth       include      password-auth
account    required     pam_nologin.so
...

This means that when sshd asks PAM to authenticate a user, PAM will first consult the pam_sepermit.so module, which checks the /etc/security/sepermit.conf file for users who should be allowed or denied authentication access by SELinux (pam_sepermit(8)). Then, PAM will open the /etc/pam.d/password-auth and read all lines starting with auth in order to know what to check next.

The /etc/pam.d/password-auth file looks like this:

#%PAM-1.0
# This file is auto-generated.
# User changes will be destroyed the next time authconfig is run.
auth        required     pam_env.so
auth        sufficient   pam_unix.so nullok try_first_pass
auth        requisite    pam_succeed_if.so uid >= 500 quiet
auth        required     pam_deny.so
...

These auth lines mean that PAM will use the pam_env.so module to set and unset environment variables defined in /etc/security/pam_env.conf (pam_env(8)). After that, the pam_unix.so module will perform the traditional password checks, i.e. /etc/shadow when using local files (pam_unix(8)), and PAM will consider this sufficient to authenticate the user.

If you duplicate the pam_unix.so line and change PAM's view of this check to required instead of sufficient, you will effectively ask PAM to check the traditional authentication sources twice.

Note, however, that the comments in /etc/pam.d/password-auth state that this file is auto-generated and that "changes will be destroyed the next time authconfig is run". Additionally, this file is used by many other programs and daemons when authenticating users and changing it would alter the behavior of authentication for all those other programs and daemons.

The only safe path is to copy the auth lines from this file to sshd's specific file, i.e. /etc/pam.d/sshd, and comment out the line that called /etc/pam.d/password-auth. This is what you get:

# /etc/pam.d/sshd
#%PAM-1.0
auth       required     pam_sepermit.so
# auth       include      password-auth
# The following lines have come from the password-auth file
auth       required     pam_env.so
auth       sufficient   pam_unix.so nullok try_first_pass
auth       requisite    pam_succeed_if.so uid >= 500 quiet
auth       required     pam_deny.so
# End of lines coming from password-auth

account    required     pam_nologin.so
...

Now you can duplicate the pam_unix.so line and ask PAM to require this check to pass before it is tested a second time:

# /etc/pam.d/sshd
#%PAM-1.0
auth       required      pam_sepermit.so
# auth       include       password-auth
# The following lines have come from the password-auth file
auth       required      pam_env.so
auth       required      pam_unix.so nullok try_first_pass
auth       sufficient    pam_unix.so nullok try_first_pass
auth       requisite     pam_succeed_if.so uid >= 500 quiet
auth       required      pam_deny.so
# End of lines coming from password-auth

account    required      pam_nologin.so
...

You are almost there. If you try to ssh to this machine right now, you'll only be prompted for the password once. That's because the try_first_pass argument to the pam_unix.so module tells the sufficient line to try the password that has just been given, which defeats the purpose of the duplicate password prompt.

So, remove the try_first_pass argument from the second line to make it actually ask for the password a second time:

# /etc/pam.d/sshd
#%PAM-1.0
auth       required      pam_sepermit.so
# auth       include       password-auth
# The following lines have come from the password-auth file
auth       required      pam_env.so
auth       required      pam_unix.so nullok try_first_pass
auth       sufficient    pam_unix.so nullok
auth       requisite     pam_succeed_if.so uid >= 500 quiet
auth       required      pam_deny.so
# End of lines coming from password-auth

account    required      pam_nologin.so
...

That's it. Try to ssh to the target system and check if everything goes as planned. Feel free to use ssh -v (repeated v's for more verbosity) if something goes wrong.

Further stalling the attacker

As the attacker may come prepared to try every single password twice, you can at least stall them by running /usr/bin/sleep 2 between password prompts. PAM allows you to do this with the pam_exec.so module (pam_exec(8)). Your /etc/pam.d/sshd file should then look like this:

# /etc/pam.d/sshd
#%PAM-1.0
auth       required      pam_sepermit.so
# auth       include       password-auth
# The following lines have come from the password-auth file
auth       required      pam_env.so
auth       required      pam_unix.so nullok try_first_pass
auth       optional      pam_exec.so quiet /usr/bin/sleep 2
auth       sufficient    pam_unix.so nullok
auth       requisite     pam_succeed_if.so uid >= 500 quiet
auth       required      pam_deny.so
# End of lines coming from password-auth

account    required      pam_nologin.so
...

Now your system is ready to offer the convenience of password authentication with reduced a risk of giving in to brute-force attacks.

2013-01-14

Suporte técnico da GVT: ruim na primeira impressão

Nota importante: Este post é de 2013. Desde a publicação deste post, a GVT já foi comprada e muita coisa provavelmente mudou, como a qualidade do serviço de acesso à Internet e também do suporte técnico.

Meu modem da GVT tem suporte a IPv6. No entanto, ele não recebe um endereço IPv6 da operadora. E eu queria acessar a rede IPv6.

Aqui está a interessante transcrição (só da minha memória) da minha conversa agora há pouco com o suporte técnico da GVT.

- Boa noite, Fulana falando.
- Boa noite. Por favor, eu gostaria de saber se é possível ativar o IPv6 no meu acesso banda larga e se eu preciso pagar alguma coisa por isso.
- Senhor, isso o senhor precisa verificar com o seu consultor, não com a GVT.
- Por quê?
- Quem dá acesso a IPv6 é o Windows. Se o senhor tiver o Windows Vista, aí é IPv6. Se for o Windows 7, aí tem que ver.
- Desculpe, mas a senhora está enganada. Eu trabalho com isso e sei do que estou falando (É tão satisfatório poder dizer isso, né?). Eu gostaria de acessar a Internet por IPv6 e, para isso, a GVT precisa me fornecer conectividade IPv6.
- Senhor, a GVT não oferece suporte a IPv6. (surpreendente como de repente ela sabia do que se tratava, né? Aposto que não sabia.)
- Mas o suporte a IPv6 não era obrigatório a partir de janeiro de 2012? (tá bom, inventei um pouco nesse aspecto de obrigatoriedade, mas o objetivo era forçar um pouco a barra)
- Não tenho esta informação. Nada nos foi passado em treinamentos.
- Bom, está bem então. Obrigado.

E assim terminou.
Puxa vida, assinei a GVT com tanto gosto, justamente em virtude dos ótimos relatos que sempre ouvi sobre o respeito que a empresa tem pelos clientes. Não achei esse suporte satisfatório.