[GTER] servidor ntp atrás de rede filtrada - como?

[Patrick Tracanelli]

Bom dia.

Existe sim o que você quer mas não oficialmente.

Historicamente, existe uma gambiarra que ainda que feia, é mais comum do que a gente pensa, que é ajustar o horário do servidor com base no header Date: de um webserver que você, a seu critério (hehehe) julgue confiável. Tem scripts perl, python e uma pancada de gambiarras por ai, no fim é algo assim em BSD

date -f "%d %B %Y %H:%M:%S" "$(curl -sD - www.ntp.br | grep ^Date: | cut -d' ' -f3-6)”

E algo assim em Linux:

date -s "$(curl -sD - www.ntp.br | grep ^Date: | cut -d' ' -f3-6)”

Feio, terrível, mas funcional pra quem quer só ajustar a hora com uma referência e tudo que voce tem é http - conexões residenciais ou afins com bem mais bloqueios do que o udp/123 que você está sofrendo.

Bom a ideia horrível é funcional e conhecida, e não seria de todo mal se fosse algo um pouco mais elaborado, ao menos na cabeça do Reyk, um dos principais desenvolvedores do OpenBSD e um dos pais do OpenNTP, então o que você ouviu falar de alguma forma foi implementado há pouco tempo e está discutido nessa thread:

http://comments.gmane.org/gmane.os.openbsd.tech/40825

Basicamente o que o recurso “constraints from url” faz é, em primeiro lugar, exigir que a URL esteja sob TLS, então no exemplo acima www.ntp.br não serviria pois não tem SSL/TLS. Então teria que usar outro webserver, qualquer um, https://www.google.com, https://www.freebsd.org, https://www.registro.br/ ou qualquer outro que você, sob seu exclusivo critério, considere confiável.

Ai o que o OpenNTP faz é olhar todos IPs para os quais aquela URL resolva (no caso do google por exemplo, ao menos 5 endereços IP), o OpenNTP calcula a referência média entre todos eles e passa a ter sua própria média final. As respostas do que o NTP Daemon obteve dos servidores NTP consultados serão comparadas com essa referência HTTP, e os servidores NTP que ficarem dentro de um range médio do constraint considerado será descartado.

Como o protocolo NTP é UDP ele é mais frágil de ser spoofado, não requer handshake, ack, não requer sniffing pra pegar ack# e seq#, ou seja um mero flood de respostas em proporção diferente as solicitadas vai ter uma grande margem de sucesso em atacar por spoof ou MITM um servidor NTP e fazer ele ter uma referência alienígena qualquer de horário. Pra evitar isso, isso o OpenNTP tenta “confiar” no header Date de um servidor http devidamente autenticado (chain de confiança) e autorizado (instalado no webserver).

O proprio Google é a referência da manpage:

constraints from "https://www.google.com/search?q=openntpd”

Acontece que o OpenNTP continua usando servidores NTP pra sincronizar o tempo e o HTTP sob TLS pra uma “contra prova” racional. Legal, etc, mas todo o trabalho pro OpenNTP usar de fato os dados do HTTP ao invés do OpenNTP está feito, calculado, só não é aplicado.

Ai o que rola, se você seguir a thread e continuar lendo sobre outras conversas derivadas dela você vai ver que tem gente que acredita que é mais moderno, adequado e uma melhor ideia mesmo sincronizar sobre HTTP, seja dessa forma, seja usando uma extensão pro HTTP so pra isso, ou headers adicionais etc, etc, várias ideias.

E por fim se vc pesquisar verá um dirty hack de apenas 6 linhas no código do ntp.c que permite ALIMENTAR o OpenNTP a partir das informações de horário obtidas dos constraint servers e não dos NTP servers. E tem quem curtiu a ideia e adotou. O Dirty Hack em questão esta ai, mas não deve entrar no OpenNTP nunca (chuto eu, mas vai saber ne…) ja que é totalmente alheio a qualquer RFC ou uma discussão mais elaborada sobre isso. É só de fato, um hack… feito de forma simples em cima de algo maior e com outra intenção que é o HTTP/TLS constraints do OpenNTP.

Ou seja o que você procura, existe de alguma forma.

Usar ou não usar é outra questão. 

Agora antes de tentar seguir com gambiarra, seja fazendo shell scripts com date + curl + https seja alimentando o ntpd (ou ntpdate) de origens doidas como https ou pior, o que eu tenho visto são as operadoras bloquearem udp/123 de ORIGEM.

Não sei se é o caso da Oi como você diz mas a Vivo (vivozap) bloqueia, nos EUA a AT&T bloqueia (e bloqueia 5060 também hehehe), a Orange bloqueia, existe até algumas considerações sobre essa prática em:

Nota bene portanto, é provável que voce esteja sendo bloqueado source udp/123 e não dst udp/123. Isso evita respostas de amplificação NTP mas sem querer evita requests. O protocolo NTP pela RFC tem o comportamento padrão de fazer os requests usando surce 123 e não source aleatória acima da 1023 como boa parte dos serviços.

- A notícia mais ou menos: o ntpdate tem o argumento -u (unprivileged ports) que permite forçar portas altas. Teste consultar o a.ntp.br ou afins, dessa fora, e veja se funciona.
- A ma noticia: o ntp do Linux, dos BSD, é velho, feio, gordo e poucos se tentam entende-lo ou se importam em melhora-lo, mas como tudo que é velho e serviu bem por muitos e muitos anos, tem experiência de sobra (recursos), é um mais feature-ful dos daemon NTP por ai, mas infelizmente não tem opção equivalente pra forçar source port unprivileged, e ele vai ser bloqueado tal qual ntpdate sem -u.
- A boa notícia: daemons mais modernos como o ntimed-client (recomendo fortemente) e o OpenNTP automaticamente alternam entre source port unprivileged ou source-port 123 (se rodando como root ou se permitido via POSIX.1e MAC Portacl no caso do FreeBSD).

Então testa com ntpdate -u, se funcionar tem solução elegante.

Se realmente continuar o bloqueio você tem mil opções de gambiarra, as feias e as horríveis. Túneis (que vc ja esta fazendo), desvio de porta (redireciona o que vier do seu servidor NTP com destino a any 123 pra destino XXX123 e lá no servidor que voce tem na nuvem redireciona do XXX123 pra 123 de volta, mole de fazer com ipfw/fwd ou pf/rdr nos BSD, com iptables ou mikrotik), ou essa gambiarra que voce e outros mundo afora mostraram interessados, alimentar o daemon NTP usando header Date do http.

Boa diversão.

--
Patrick Tracanelli

FreeBSD Brasil LTDA.
Tel.: (31) 3516-0800
316601 at sip.freebsdbrasil.com.br
http://www.freebsdbrasil.com.br
"Long live Hanin Elias, Kim Deal!"



> On 10/03/2015, at 10:49, Marcelus Trojahn <mtrojahn at gmail.com> wrote:
> 
> Na Internexa eu pedi pra bloquear 123 entrante porque estávamos sofrendo
> ataque constante em IPs aleatórios... Blacklist não adiantava...
> 
> Suponho que este mesmo tipo de problema deve ter feito eles bloquearem só
> que obviamente, ao contrário... Mas talvez nem tão obviamente assim já que
> a própria rede deles pode ser o atacante...
> 
> Eles disseram alguma coisa? Você é AS? Entendo que eles até teriam algum
> tipo de "razão" se os IPs forem deles... Mas se você for AS eles
> definitivamente tem que liberar seu tráfego.
> 
> On Tue, Mar 10, 2015, 7:24 AM Raimundo Santos <raitech at gmail.com> wrote:
> 
>> 2015-03-09 16:07 GMT-03:00 João Vitor S <jvitorshl at gmail.com>:
>> 
>>> A opção do OpenNTPd que permite usar uma URL https resolve meu problema?
>>> ele sincroniza horario por HTTPS? se sim alguem pode me ajudar pois não
>>> consegui, sempre que dou ntpctl status ficam clock unsynced
>>> 
>> 
>> Isso é coisa recente no OpenNTPD:
>> 
>> http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/
>> man5/ntpd.conf.5?query=ntpd%2econf
>> 
>> repare na versão do SO a que se refere tal man page: OpenBSD-current.
>> Troque para OpenBSD-5.6 (depois clique em submit) no mesmo menu e verá que
>> a cosntraint pra HTTPS não existe ainda.
>> 
>> []s
>> Raimundo Santos
>> --
>> gter list    https://eng.registro.br/mailman/listinfo/gter
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter