Início / user-180506

pacoverflow's questions

Martin Hope
pacoverflow
Asked: 2023-12-06 00:56:28 +0800 CST
  • 5

Temos um aplicativo que envia uma solicitação para uma API REST ObjectServer do servidor IBM Tivoli Netcool/OMNIbus 8.1. Na solicitação, há um Authorizationcabeçalho HTTP definido como Basic <base64-encoded string>, onde a string codificada em base64 representa admin:password. A API REST retorna as informações solicitadas, o que significa que a aplicação está enviando a senha correta para o adminusuário.

Agora quero alterar a senha que é enviada e não sei onde o adminusuário está configurado. Como você pode ver no console de gerenciamento IBM, não há nenhum adminusuário listado:

insira a descrição da imagem aqui

Tentei alterar o aplicativo para enviar a string codificada em base64 para obadmin:password(um dos usuários mostrados na captura de tela acima) no Authorizationcabeçalho HTTP, e a API REST respondeu com um erro "401 - Autorização necessária", então parece que o REST A API não autentica nenhum usuário listado nessa captura de tela.

Como posso alterar a senha do adminusuário?

password
Martin Hope
pacoverflow
Asked: 2023-12-01 05:55:02 +0800 CST
  • 6

Temos um aplicativo que envia uma solicitação para uma API REST ObjectServer do servidor IBM Tivoli Netcool/OMNIbus 8.1. Ele envia uma solicitação GET http://1.2.3.4/objectserver/restapi/alerts/status?filter=Severity=5%20and%20Manager%20not%20like%20'^.*Watch$'com os seguintes cabeçalhos HTTP:

Authorization: Basic DHCteF92S53fhUY6jlF=
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Content-Type: application/json

A solicitação funciona bem em nosso ambiente de desenvolvimento e a API REST retorna as informações de alerta solicitadas. No entanto, em nosso ambiente de teste, a API REST retorna um erro “401 – Autorização necessária”.

O DHCteF92S53fhUY6jlF=valor no cabeçalho Authorization parece ser algum tipo de token de autenticação e está codificado em nosso aplicativo. O desenvolvedor que escreveu esse código já se foi e não tenho ideia de como esse valor é gerado. Talvez esteja incorreto para nosso ambiente de teste e, portanto, o erro 401. Como esse token de autenticação é gerado?

authentication
Martin Hope
pacoverflow
Asked: 2021-07-17 06:49:11 +0800 CST
  • 0

Temos um servidor OpenVPN com o seguinte server.conf:

local x.x.x.x
port 1194
proto tcp
dev tap
ca ca.crt
cert server.crt
key server.key
dh dh.pem
auth SHA512
tls-crypt tc.key
topology subnet
server 10.8.0.0 255.255.0.0
ifconfig-pool-persist ipp.txt
client-config-dir /etc/openvpn/ccd
client-to-client
keepalive 10 120
cipher AES-256-CBC
user nobody
group nogroup
persist-key
persist-tun
status openvpn-status.log
verb 3
crl-verify crl.pem

Também tínhamos uma instância do Linux na AWS executando um cliente OpenVPN e atribuímos com sucesso um endereço IP estático de 10.8.0.2 a ela adicionando um arquivo com o nome comum do cliente ao /etc/openvpn/ccddiretório do servidor OpenVPN com o seguinte conteúdo:

ifconfig-push 10.8.0.2 255.255.0.0

Agora queremos substituir essa instância do Linux por uma instância do Windows Server 2019 e fornecer o mesmo endereço IP estático 10.8.0.2. Então fizemos o seguinte:

  • excluiu a instância do Linux na AWS
  • usou o script Nyr OpenVPN openvpn-install.sh no servidor OpenVPN para revogar o cliente Linux
  • /etc/openvpn/server/easy-rsa/pki/index.txtexcluiu o cliente Linux do arquivo do servidor OpenVPN
  • /etc/openvpn/server/easy-rsa/pki/revoked/certs_by_serialexcluiu o certificado do cliente Linux do diretório do servidor OpenVPN
  • /etc/openvpn/ccdexcluiu o arquivo do cliente Linux no diretório do servidor OpenVPN
  • excluiu o arquivo do servidor OpenVPN /etc/openvpn/server/ipp.txt(já que tinha uma associação de 10.8.0.2 ao cliente Linux)
  • adicionou um novo arquivo no diretório do servidor OpenVPN /etc/openvpn/ccdpara a instância do Windows Server 2019 comifconfig-push 10.8.0.2 255.255.0.0
  • criou uma instância do Windows Server 2019 na AWS
  • instalou o OpenVPN 2.4.9 na instância do Windows Server 2019

A instância do Windows Server 2019 tem o seguinte arquivo de configuração do cliente OpenVPN:

client
dev tap
proto tcp
remote x.x.x.x 1194
resolv-retry infinite
nobind
persist-key
persist-tun
remote-cert-tls server
auth SHA512
cipher AES-256-CBC
ignore-unknown-option block-outside-dns
block-outside-dns
verb 3

Quando iniciamos o cliente OpenVPN na instância do Windows Server 2019, o seguinte aparece no arquivo de log do cliente OpenVPN:

Wed Jul 14 01:15:02 2021 [server] Peer Connection Initiated with [AF_INET]x.x.x.x:1194
Wed Jul 14 01:15:03 2021 SENT CONTROL [server]: 'PUSH_REQUEST' (status=1)
Wed Jul 14 01:15:03 2021 PUSH: Received control message: 'PUSH_REPLY,route-gateway 10.8.0.1,ping 10,ping-restart 120,ifconfig 10.8.0.2 255.255.0.0,peer-id 0,cipher AES-256-GCM'
Wed Jul 14 01:15:03 2021 OPTIONS IMPORT: timers and/or timeouts modified
Wed Jul 14 01:15:03 2021 OPTIONS IMPORT: --ifconfig/up options modified
Wed Jul 14 01:15:03 2021 OPTIONS IMPORT: route-related options modified
Wed Jul 14 01:15:03 2021 OPTIONS IMPORT: peer-id set
Wed Jul 14 01:15:03 2021 OPTIONS IMPORT: adjusting link_mtu to 1658
Wed Jul 14 01:15:03 2021 OPTIONS IMPORT: data channel crypto options modified
Wed Jul 14 01:15:03 2021 Data Channel: using negotiated cipher 'AES-256-GCM'
Wed Jul 14 01:15:03 2021 Outgoing Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
Wed Jul 14 01:15:03 2021 Incoming Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
Wed Jul 14 01:15:03 2021 interactive service msg_channel=0
Wed Jul 14 01:15:03 2021 open_tun
Wed Jul 14 01:15:03 2021 TAP-WIN32 device [Local Area Connection] opened: \\.\Global\{526EF9D3-DC84-41B0-B139-F1D4BAEFBF4F}.tap
Wed Jul 14 01:15:03 2021 TAP-Windows Driver Version 9.24 
Wed Jul 14 01:15:03 2021 Notified TAP-Windows driver to set a DHCP IP/netmask of 10.8.0.2/255.255.0.0 on interface {526EF9D3-DC84-41B0-B139-F1D4BAEFBF4F} [DHCP-serv: 10.8.0.0, lease-time: 31536000]
Wed Jul 14 01:15:03 2021 Successful ARP Flush on interface [11] {526EF9D3-DC84-41B0-B139-F1D4BAEFBF4F}
Wed Jul 14 01:15:03 2021 Block_DNS: WFP engine opened
Wed Jul 14 01:15:03 2021 Block_DNS: Using existing sublayer
Wed Jul 14 01:15:03 2021 Block_DNS: Added permit filters for exe_path
Wed Jul 14 01:15:03 2021 Block_DNS: Added block filters for all interfaces
Wed Jul 14 01:15:03 2021 Block_DNS: Added permit filters for TAP interface
Wed Jul 14 01:15:08 2021 TEST ROUTES: 0/0 succeeded len=-1 ret=0 a=0 u/d=down
Wed Jul 14 01:15:08 2021 Route: Waiting for TUN/TAP interface to come up...
Wed Jul 14 01:15:13 2021 TEST ROUTES: 0/0 succeeded len=-1 ret=0 a=0 u/d=down
Wed Jul 14 01:15:13 2021 Route: Waiting for TUN/TAP interface to come up...
Wed Jul 14 01:15:14 2021 TEST ROUTES: 0/0 succeeded len=-1 ret=0 a=0 u/d=down
Wed Jul 14 01:15:14 2021 Route: Waiting for TUN/TAP interface to come up...
Wed Jul 14 01:15:15 2021 TEST ROUTES: 0/0 succeeded len=-1 ret=0 a=0 u/d=down
Wed Jul 14 01:15:15 2021 Route: Waiting for TUN/TAP interface to come up...
Wed Jul 14 01:15:16 2021 TEST ROUTES: 0/0 succeeded len=-1 ret=0 a=0 u/d=down
Wed Jul 14 01:15:16 2021 Route: Waiting for TUN/TAP interface to come up...
Wed Jul 14 01:15:17 2021 TEST ROUTES: 0/0 succeeded len=-1 ret=0 a=0 u/d=down
Wed Jul 14 01:15:17 2021 Route: Waiting for TUN/TAP interface to come up...
Wed Jul 14 01:15:18 2021 TEST ROUTES: 0/0 succeeded len=0 ret=1 a=0 u/d=up
Wed Jul 14 01:15:18 2021 WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
Wed Jul 14 01:15:18 2021 Initialization Sequence Completed

Como você pode ver, o cliente OpenVPN na instância do Windows Server 2019 está recebendo o endereço IP 10.8.0.2 do servidor OpenVPN. No entanto, estou executando repetidamente ipconfigem uma janela de linha de comando e vejo o seguinte acontecer a cada 15 segundos:

  • O adaptador de rede OpenVPN (chamado "Adaptador TAP-Windows V9") obtém um endereço IP de 169.254.211.103 por alguns segundos.
  • Em seguida, o adaptador de rede OpenVPN obtém um endereço IP de 10.8.0.2 por cerca de um segundo. Durante esse segundo, um ping de 10.8.0.1 (o servidor OpenVPN) será bem-sucedido. Fora desse segundo, um ping de 10.8.0.1 falhará.
  • Em seguida, o adaptador de rede OpenVPN perde o endereço IP 10.8.0.2 e não possui nenhum endereço IP pelos próximos 12 segundos.
  • Esse processo de obter o endereço 169.254.xx e, em seguida, obter e perder o endereço 10.8.0.2 continua se repetindo a cada 15 segundos.

Então decidi ver o que aconteceria se eu tentasse dar ao Windows Server 2019 um endereço IP estático diferente que nunca havia sido usado antes. Modifiquei o arquivo do Windows Server 2019 no diretório do servidor OpenVPN /etc/openvpn/ccdpara fornecer um endereço IP estático de 10.8.0.11:

ifconfig-push 10.8.0.11 255.255.0.0

Então reiniciei o cliente OpenVPN na instância do Windows Server 2019 e funciona! O cliente está usando com sucesso o endereço IP 10.8.0.11 e não o está perdendo.

Então, por que a instância do Windows Server 2019 continua perdendo o endereço 10.8.0.2, que havia sido usado anteriormente pelo cliente Linux? Como você pode ver nas etapas listadas acima, revoguei o cliente Linux do servidor OpenVPN e excluí todos os vestígios do nome comum do cliente Linux que pude encontrar no servidor OpenVPN.

Preferimos que a instância do Windows Server 2019 use o endereço 10.8.0.2, porque já escrevemos scripts assumindo que 10.8.0.2 será o IP estático e enviamos esses scripts para terceiros. Será mais fácil ficar com 10.8.0.2, se possível.

ATUALIZAR:

Não olhei para a instância do Windows Server 2019 por alguns dias e agora acabei de olhar novamente. Surpreendentemente, ele tinha o endereço IP 10.8.0.2 e nunca desapareceu. Tudo estava funcionando como esperado. Não sei por que, pois não mudei nada.

Então reiniciei o cliente OpenVPN na instância do Windows Server 2019 para ver o que aconteceria, e agora ele voltou ao comportamento de obter um endereço 169.254.xx e depois obter e perder o endereço 10.8.0.2 a cada 15 segundos.

windows networking openvpn ip-address