O cliente NTP no CentOS 5 falha por trás do firewall Cisco ASA

Question

O cliente NTP no CentOS 5 falha por trás do firewall Cisco ASA

#1 resposta do (1 votos)
#2 resposta do (0 votos)

3

Eu tenho um servidor CentOS no qual eu quero configurar um cliente NTP para obter um tempo preciso para o servidor. O servidor está em uma sub-rede local com NAT atrás de um firewall ASA 5505, que atua como roteador NAT e, por sua vez, conecta-se diretamente ao modem DSL da Internet, sem outro roteador.

O problema é que o cliente NTP no servidor CentOS simplesmente nunca consegue sincronizar com qualquer servidor NTP que eu escolha. Configurando o ASA 5505 como cliente NTP funciona completamente bem no entanto. Usar os mesmos endereços IP no servidor CentOS ainda não me dá nenhuma sincronização, mesmo quando estou esperando por horas.

O ntp.conf é:

restrict 127.0.0.1
restrict -6 ::1

server  127.127.1.0     # local clock
fudge   127.127.1.0 stratum 10

driftfile /var/lib/ntp/drift

keys /etc/ntp/keys

server 89.109.251.21
server 176.9.47.150
server 63.15.238.180

Usar o ntpq me diz que nenhum desses servidores está sendo acessado (enquanto pelo menos dois deles são acessados a qualquer momento pelo ASA, então eles estão bem):

peers
     remote           refid      st t when poll reach   delay   offset  jitter

*LOCAL(0)        .LOCL.          10 l   25   64  377    0.000    0.000   0.001
 89.109.251.21   .INIT.          16 u    - 1024    0    0.000    0.000   0.000
 odin.tuxli.ch   .INIT.          16 u    - 1024    0    0.000    0.000   0.000
 63.15.238.180   .INIT.          16 u    - 1024    0    0.000    0.000   0.000

No momento em que mostra .INIT. no refid, leva cerca de uma hora antes que isso mude para outra coisa, mas ainda assim o contador "reach" continua em 0.

o comando "as" fornece o seguinte:

ind assID status  conf reach auth condition  last_event cnt

  1 40263  9614   yes   yes  none  sys.peer   reachable  1
  2 40264  8000   yes   yes  none    reject
  3 40265  8000   yes   yes  none    reject
  4 40266  8000   yes   yes  none    reject

Isso não muda mesmo depois de 24h, é sempre "rejeitar".

Consultar com "rv" sempre recebe a resposta "peer_unfit" e "peer_stratum", o que é natural, já que o estrato permanece em 16 o tempo todo.

Soa como um problema de rede, mas não encontro o problema.

Eu não tenho nenhuma regra no ASA restringindo ou permitindo a porta 123 para NTP. Mas, teoricamente, eu não deveria precisar dele - para o UDP, o firewall deve saber que o pacote de resposta está relacionado / estabelecido, então ele deve deixar passar, ou estou errado aqui?

Ou é o problema relacionado a alguma configuração de autenticação - a linha chave ntp no confi g tem algo a ver com isso?

EDITAR: FIREWALL ASA 5505 CONFIG (abreviado):


ASA Version 8.2(5)
!
names
!
interface Ethernet0/0
 switchport access vlan 2
!
interface Ethernet0/1
!
interface Ethernet0/2
!
interface Ethernet0/3
!
interface Ethernet0/4
!
interface Ethernet0/5
 switchport access vlan 3
!
interface Ethernet0/6
 switchport access vlan 3
!
interface Ethernet0/7
 switchport access vlan 3
!
interface Vlan1
 nameif inside
 security-level 100
 ip address 10.111.11.251 255.255.255.0
!
interface Vlan2
 nameif outside
 security-level 0
 ip address 192.168.1.2 255.255.255.252
!
interface Vlan3
 no forward interface Vlan1
 nameif dmz
 security-level 50
 ip address 192.168.240.254 255.255.255.0
!
!
ftp mode passive
clock timezone CEST 1
clock summer-time CEST recurring last Sun Mar 2:00 last Sun Oct 2:00
object-group network XenServer
 network-object host 192.168.240.240
 network-object host 192.168.240.241
 network-object host 192.168.240.242
access-list MAILSERVER extended permit tcp any any eq www
access-list MAILSERVER extended permit tcp any any eq https
access-list MAILSERVER extended permit tcp any any eq smtp
access-list MAILSERVER extended permit tcp any any eq ftp
access-list MAILSERVER extended permit tcp any any eq ftp-data
access-list MAILSERVER extended permit icmp any any echo-reply
access-list MAILSERVER extended deny ip any any log
access-list NEPLAN extended permit tcp any host 192.168.240.231 eq 10000
access-list NEPLAN extended permit tcp any host 192.168.240.231 eq https
access-list NEPLAN extended permit tcp any host 192.168.240.253 eq 10000
access-list NEPLAN extended permit tcp any host 192.168.240.253 eq https
access-list NEPLAN extended permit tcp any object-group XenServer eq https
access-list NEPLAN extended permit tcp any object-group XenServer eq ssh
access-list NEPLAN extended permit tcp any host 192.168.240.231 eq www
access-list NEPLAN extended permit tcp any host 192.168.240.238 eq www
access-list INTERNET extended permit ip 192.168.240.0 255.255.255.128 any
access-list INTERNET extended permit ip host 192.168.240.136 any
access-list INTERNET extended permit ip host 192.168.240.230 any
access-list INTERNET extended permit ip host 192.168.240.220 any
access-list INTERNET extended permit ip host 192.168.240.221 any
access-list INTERNET extended permit ip host 192.168.240.222 any
access-list INTERNET extended permit ip host 192.168.240.210 any
access-list INTERNET extended permit ip host 192.168.240.211 any
access-list INTERNET extended permit icmp any any echo-reply
access-list INTERNET extended permit ip object-group XenServer any
access-list INTERNET extended deny ip any any log
mtu inside 1500
mtu outside 1500
mtu dmz 1500
icmp unreachable rate-limit 1 burst-size 1
arp timeout 14400
global (outside) 91 interface
global (dmz) 92 interface
nat (inside) 92 10.111.11.0 255.255.255.0
nat (dmz) 91 192.168.240.0 255.255.255.0
static (dmz,outside) tcp interface https 192.168.240.136 https netmask 255.255.255.255
static (dmz,outside) tcp interface smtp 192.168.240.136 smtp netmask 255.255.255.255
static (dmz,outside) tcp interface ftp 192.168.240.136 ftp netmask 255.255.255.255
static (dmz,outside) tcp interface ftp-data 192.168.240.136 ftp-data netmask 255.255.255.255
static (dmz,outside) tcp interface www 192.168.240.136 www netmask 255.255.255.255
access-group NEPLAN in interface inside
access-group MAILSERVER in interface outside
access-group INTERNET in interface dmz
route outside 0.0.0.0 0.0.0.0 192.168.1.1 1

ntp server 89.109.251.21
ntp server 176.9.47.150
ntp server 63.15.238.180

webvpn

!
class-map inspection_default
 match default-inspection-traffic
!
!
policy-map type inspect dns preset_dns_map
 parameters
  message-length maximum client auto
  message-length maximum 512
policy-map global_policy
 class inspection_default
  inspect dns preset_dns_map
  inspect ftp
  inspect h323 h225
  inspect h323 ras
  inspect ip-options
  inspect netbios
  inspect rsh
  inspect rtsp
  inspect skinny
  inspect esmtp
  inspect sqlnet
  inspect sunrpc
  inspect tftp
  inspect sip
  inspect xdmcp
!
service-policy global_policy global
prompt hostname context
no call-home reporting anonymous
call-home
 profile CiscoTAC-1
  no active
  destination address http https://tools.cisco.com/its/service/oddce/services/DDCEService
  destination address email [email protected]
  destination transport-method http
  subscribe-to-alert-group diagnostic
  subscribe-to-alert-group environment
  subscribe-to-alert-group inventory periodic monthly
  subscribe-to-alert-group configuration periodic monthly
  subscribe-to-alert-group telemetry periodic daily
Cryptochecksum:590d5cd7306d6a21eb875098d3b33661
: end
NEP-ASA-SL20-1#

Os servidores que têm problemas com o NTP são 192.168.240.240 e 192.168.240.241 (grupo de objetos de rede XenServers - este é um XenServer DomU. Já tentou outro servidor autônomo - o mesmo problema para não parecer relacionado ao Xen).

firewall linux centos cisco-asa

por nepdev 03.06.2013 / 15:12

2 respostas

1

Você não tem o ASA configurado para permitir o tráfego NTP de saída, portanto não tem. O tráfego "Relacionado / estabelecido" refere-se ao tráfego em andamento, como respostas de entrada de servidores NTP, e não tráfego recém-iniciado, por isso não se aplica aqui.

Para resolver o problema, adicione regras para os grupos apropriados para permitir o tráfego NTP de saída. Por exemplo:

access-list NEPLAN extended permit udp any any eq 123

por 03.06.2013 / 18:43

Tags firewall linux centos cisco-asa

Resolução de DNS do nome do “DNS público” para a instância EC2 na mesma região que retorna o IP público Recuperar o array RAID 10 do mdadm: listando todos como peças de reposição

score 0 · Accepted Answer

A solução para isso é adicionar uma entrada NAT estática para pacotes UDP com porta de destino 123 (além de abrir essa porta de entrada especificamente):

static (dmz,outside) udp interface ntp 192.168.240.240 ntp netmask 255.255.255.255

Sim, eu sei, isso não deveria ser necessário. Abrir a porta de entrada 123 especificamente não a manipula - ela requer a entrada NAT estática. Isso também mostra que os pacotes UDP enviados pelo meu servidor CentOS têm o destino e a porta de origem configurados como 123 para o NTP.

Alguém pode esclarecer por que o firewall se recusa a classificar esse tráfego como tráfego relacionado? Isso ocorre porque a porta de origem é uma porta "privilegiada", ou seja, < 1023? Não consigo encontrar nenhuma documentação ou referência em nenhum lugar sobre isso.