FAQs

VSA - VitalSigns SIEM Agent para z/OS

Pré-requisitos para instalação do VSA


Baixe aqui o PDF com as informações solicitadas




Guia de Instalação do VSA - na versão 4.1 (EN)


Baixe aqui o PDF do Guia de Instalação da versão 4.1




Novidades implementadas na versão 4.1 do VSA (EN)


Baixe aqui o PDF com as Novidades da versão 4.1




É possível que o VSA grave um arquivo no formato SMF, ao invés de encaminhar eventos através de Syslog ao servidor?  O SIEM já possui um interpretador (parser) para o formato flat-file e não para o Syslog. Neste caso, o evento gerado pelo VSA seria idêntico para ambas as saídas (syslog ou arquivo)?


Certamente! Tal orientação encontra-se no manual de Configuração do VSA.
Se o parâmetro ALERTStoMVS estiver configurado como YES, então o evento será enviado, via rede, e também será gravado em arquivo.
Alternate Destinations for Alerts CONFGIN File Parms UDPPORT2= (Deprecated; in ASCII) UDPADDR2= (Deprecated; in ASCII) SRV2ADDR= (in ASCII) SRV2PORT= (in ASCII) SRV2PROTO= (in ASCII) You may want to have a second device (desktop or server) capture VSA alerts as well as your primary. Refer to Using the Mainframe Agent for setting up a second device. ALERTStoMVS= Yes | No | Only (absent = No), where: (in EBCDIC) Yes Writes alerts to a physical sequential file on MVS No Does not write alerts to an MVS dataset Only Writes alerts to a physical sequential file on MVS (but prevents TCP or UDP SENDs) To define the AlertFile: you must tailor and submit job DEFALRT. ALERTStoMVShdr= SysLog | LEEF | CEF SYSLOG (default) and segments alerts into 1k records LEEF Log Event Extended Format (without segmentation) CEF Common Event Format (without segmentation) //ALRTMVS DD DSN=&HLQ..&PRODUCT..ALRTMVS,DISP=SHR,DCB=BUFNO=10 When used, requires flat file: BLKSIZE=32760, RECFM=VB. Not recommended for a high volume of alerts. It needs lots of storage, perhaps a GDG, and issues PUTs (QSAM). NOTA: O uso de arquivo para importação gera um delay na consolidação dos eventos no SIEM. O VSA pode enviar eventos nos formatos abaixo:

SYSLOG = Standard Syslog header and format (the default)

LEEF = Log Event Extended Format (LEEF) (IBM’s QRadar)

CEF = Common Event Format (MicroFocus/HP/ArcSight) 1.

A recomendação do fabricante é que para o LogRythm, por exemplo, a customização dos 'parses' é interpretar os eventos do VSA, considerando o formato LEEF.

Em relação ao evento gerado pelo VSA ser idêntico para as saídas syslog ou arquivo, segue abaixo um trecho do evento registrado no arquivo:

Menu Utilities Compilers Help

BROWSE SDSQ.O31.VSA33008.ALRTMVS Line 0000000000 Col 001 080

Command ===> Scroll ===> CSR ********************************* Top of Data **********************************

<113>Jan 22 07:30:56 10.31.0.1 VNCDMAGTÝFF01FB9B1090|O31 |2020012207305369

<113>Jan 22 07:30:56 10.31.0.1 VNCDMAGTÝFF01FB9B1090|O31 |2020012207305376




Regras sugeridas para monitoração do LOGON e LOGOFF do usuário com o VSA.


Habilitar a monitoração das mensagens EZZ603*, ICH408* , IEF12*.

Sobre essas mensagens:

EZZ603* ==> Sempre que um usuário estabelecer uma conexão ao servidor TN3270 (emulador), essa mensagem será exibida indicando o IP do usuário e a LU (sessão) atribuída a ele.

ICH408* ==> Mensagens de tentativa de logon sem sucesso

IEF12* ==> Mensagens de LOGON e LOGOFF

Para Verificar a conectividade com o SIEM, abaixo algumas dicas:

a) Na log do VSA, a informação indicando que há conectividade é a abaixo:

T80ITM0021: HOST-IP=xx.xx.xx.xx

T80ITM0900: EISTMART SOCKET

T80ITM0900: EISTMART CONNECT

T80IDR9807: SSI is Connected

T80IDR1000: <<== SMART OPEN FOR BUSINESS ==>>

b) Além disso, através do comando do TCPIP, todas as conexões podem ser listadas.

* /D TCPIP,NOME DA PILHA,NETSTAT,CONN

VSA 00000036 IPMAINFRAME..PORTALOCAL IPSIEM..PORTASIEM ESTBLSH

>> indica que o mainframe está conectado no SIEM

c) É possível ainda registrar os eventos enviados ao SIEM na sysout do VSA.

Alterar no arquivo de configuração o parâmetro WTOTOCON para YES e restartar o VSA

WTOTOCON=Yes




Uma vez que já possua o IP do Host que enviará os logs para o SIEM LogRythm, quais são as portas/protocolo que são necessários para a comunicação para que possa abrir as regras de firewall? Podemos abrir a regra utilizando, por exemplo, TCP/514?


O VSA enviará os eventos para a porta configurada no SIEM LogRythm.
Uma vez que já esteja “ouvindo” a porta TCP 514, por padrão, a liberação do firewall será:

Sentido Mainframe (cliente) -> SIEM (server)

Protocolo => TCP

IP / Porta Origem => IpMainframe / 1024 – 65535

IP / Porta Destino => IpSIEM / 514




Guia de Configuração LEEF no VSA (EN)


Baixe o guia para ter acesso às configurações do LEEF no VSA




Manual de Configuração do VSA - Versão 3.4 (EN)


Baixe o manual de configuração, acessando aqui.




Monitoração de eventos z/OS


Baixe aqui o documento que apresenta os tipos de eventos monitorados pelo VSA, além de exemplos enviados ao SIEM em formato SYSLOG





WQSNG - Windows/Linux

Procedimentos de testes para homologação do WQSNG com o Gravames


Etapas:
1) O WQSNG pode ser usado para validar a comunicação com o Gravames, caso o link (ou VPN) já esteja operacional.

Caso não esteja, é possível iniciar os testes da sua aplicação de negócios através de strings para o componente 'rebatedor' do próprio WQSNG.
Note que esse 'rebatedor' não validará a aplicação (ex: transação 761); apenas validará o

envio/recebimento de strings pelo WQSNG.

Nesse caso, a configuração será feita para que o WQ conecte-se localmente e “ecoe” de volta, todas as strings que ele receber da sua aplicação de negócios.

2) Após descompactar o arquivo de instalação do WQSNG no raiz do disco C, execute o command prompt (modo administrador) e as BATs, na sequência:

a. Start WQ.bat >>> Inicia o WQ em modo teste (limitado a 100 transações);

b. Simulador.bat >>> Inicia o simulador que é um rebatedor;

c. Monitor.bat >>> Inicia o monitor de instâncias.

Obs: A BAT chamada TESTE_SNG.bat envia strings para o rebatedor. O objetivo desse teste é validar que o WQClient e Server estão funcionando.

Após liberado o Link com o Gravames, será possível usá-la (com suas strings) para validar a comunicação em paralelo ao teste da aplicação de negócios de sua empresa.

As LOGs estarão sendo gravadas em (por exemplo para a versão 4.41 do WQSNG):

C:\WQ441\SNG\Logs

O arquivo de configuração é: C:\WQ441\SNG\WQ.ini

Após disponibilizado o Link de acesso ao Gravames, será necessário fazer os ajustes necessários para que seja apontado ao IP do SNG.

3) Uma vez que os testes locais (com 'rebatedor') estejam Ok e que já tenha sido estabelecido o link com o SNG, será necessário confirmar:

* Conectividade com o sistema SNG
* IP e porta do SNG para conexão com o CICS de homologação remoto

* Teste de Telnet

Do servidor (onde o WQSNG está instalado), comandar >> telnet IPCICS PORTACICS (ex: telnet 192.168.101.148 3501).
Se o Telnet funcionar OK, significa que foi bem sucedida a conectividade com o CICS.
Daí, basta configurar o WQSNG para a conexão ao ambiente de homologação do SNG, testando as transações de negócio (ex: inclusão, baixa, consulta etc...)

Essas strings serão enviadas ao SNG para serem processadas e devolvidas à sua aplicação.




Requisitos de hardware e sistema para instalação do WQSNG?


Requisitos do Equipamento (“Hardware”):

• PENTIUM IV ou equivalente com Processador acima de 2.4GHz;

• Memória de pelo menos 512MB;

• Espaço livre em disco de 1GB para instalação do WQSNG e para gravação dos arquivos

LOG e AUDIT, além do espaço livre necessário para o Sistema Operacional.

Requisitos de Sistema Operacional (“Software”):

Windows 64 bits, nas versões: Vista, 7, 8 ou 10 para o WQSNG de 64Bits;

Linux (pelo menos Fedora 12 ou Ubuntu 12.04 para 64 Bits), instalado

preferencialmente com desktop KDE;

• Compilador GCC versão 4.4 ou superior, incluindo suas bibliotecas (para 64Bit);

• Bibliotecas do GTK2 atualizadas (2.18 ou superior, para 64Bits)

• Bibliotecas do OpenSSL atualizadas (1.0.0b ou superior)

>> Após atender aos requisitos acima, devem ser executados os comandos abaixo para validação da instalação:

Observação: Os comandos foram emitidos numa distribuição CentOS antiga. Logo, as versões mais atuais poderão ser diferentes. Entretanto, o objetivo é validar se o GCC, o GTK2 e o OPENSSL estão instalados

[usuario@localhost WQ]$ gcc -v

Using built-in specs.Target: x86_64-redhat-linux

Configured with: ../configure --prefix=/usr --

mandir=/usr/share/man --infodir=/usr/share/info --withbugurl=

http://bugzilla.redhat.com/bugzilla --enable-bootstrap

.............................................................

--enable-java-maintainer-mode --with-ecjjar=/

usr/share/java/eclipse-ecj.jar --disable-libjava-multilib -

-with-ppl --with-cloog --with-tune=generic --with-arch_32=i686 -

-build=x86_64-redhat-linux

Thread model: posix

gcc version 4.4.2 20091027 (Red Hat 4.4.2-7) (GCC)

[usuario@localhost WQ]$ yum list gtk2

Loaded plugins: dellsysidplugin, dellsysidplugin2,

fastestmirror, presto, refresh- : packagekit

adobe-linux-i386

2/2

Installed Packages

gtk2.x86_64 2.18.3-19.fc12 @anaconda-InstallationRepo-200911081904.x86_64

Available Packages

gtk2.i686 2.18.9-3.fc12 updates

gtk2.x86_64 2.18.9-3.fc12 updates

[usuario@localhost WQ]$ openssl version

OpenSSL 1.0.0b-fips 16 Nov 2010

[usuario@localhost WQ]$




O WQSNG está disponível nos ambientes Windows e Linux, correto certo? Neste caso, é possível instalar o WQSNG no Linux, enquanto o componente WQ Conector e a Aplicação que acessa ao SNG serem instaladas no Windows?


Certo! O WQSNG está disponível tanto para o sistema Windows quanto o sistema Linux!

E sem problemas, quanto a instalação do WQSNG e do componente WQ Conector serem instalado em sistemas distintos, ou seja, o WQSNG pode ser instalado no Linux e o WQ Conector no Windows.




O componente WQ Conector pode ser utilizado para fins de redundância? É que o ambiente aonde estão as Aplicações são duplicados. Desta forma, teríamos 2 WQ Conectors em 2 ambientes distintos


O modelo de licenciamento do WQSNG prevê as seguintes licenças:
* Produção: 01 WQ e 01 WQ Conector,

* Homologação: 01 WQ e 01 WQ Conector,

* Disater Recovery (DR): 01 WQ e 01 WQ Conector,


No ambiente DR as licenças ficam em 'Standby' e serão utilizadas, exclusivamente, em casos de emergência, substituindo as licenças que estavam ativas na produção.


Caso a redundância seja no modo 'Ativo', ou seja, prevendo a alta disponibilidade (02 WQ Conectores enviando pedidos para 01 ou mais WQSNG) será necessário o contato comercial com a Workers Informática para ajuste financeiro do contrato de uso das licenças da solução




Algumas mensagens de retorno por parte do SNG informam:  "025 – Sistema remoto sobrecarregado, não foi possível enviar dados para a aplicação remota devido à sobrecarga da ligação de destino." Seriam esses erros referentes a infraestrutura? Ou seria necessário fazer 'retry' nesses casos?


Os Return Codes (RCs) de processamento do SNG podem ocorrer por conta dos acessos que este sistema faz, remotamente, a um Detran para executar uma operação. Esse específico é um RC de aplicação.
Já os RCs de infraestrutura, que são emitidos pelo WQSNG, são sempre 'negativos' e gerados pelas funções:
StartConector, EndConector, SendRequestToSR, SendAsyncRequestToSR, ReceiveSRRequest e SendSRResponse.

Os RCs do WQSNG estão descritos no Manual do Desenvolvedor

É recomendável que pelo menos seja registrado na LOG o motivo do não processamento e, dependendo da situação, seja feita uma nova tentativa de acesso após algum tempo.

Ainda sobre o erro mencionado (“025 – Sistema remoto sobrecarregado, não foi possível

enviar dados para a aplicação remota devido à sobrecarga da ligação de destino.”), é possível que seja uma situação temporária, já que o SNG não consegue repassar a sua operação ao parceiro dela (ex: Serpro ou Detran) por um problema que pode ser de rede ou de carga no parceiro.

Neste caso, se faz interssante que sua empresa realize um alinhamento sobre a tratativa de situações como essas, diretamente com o seu contato ao SNG.




Ao testar a integração da minha API com o WQSNG, com o rebatedor, notei que ao enviar uma transação do tipo baixa de gravame, retorna -15 (timeout).


A análise das Logs do WQSNG do dia do evento são fundamentais para a solução desse tipo de problema:

* WQ_LOG e WQ_AUDIT (ambos do Servidor WQSNG)

* WQ_CONECTOR (do Servidor de Aplicação)

Pode ser interessante 'Restartar' todo o WQSNG, incluindo o aplicativo de testes TstSNG.exe. Verifique se o processo “TstSNG.exe”, iniciado pelo SIMULADOR.BAT, esteja executando. Teste o processo de consulta novamente!

Certifique-se que o antivírus na máquina que executa o WQSNG não esteja impedindo a execução correta do TstSNG.exe. Caso não haja tráfego por mais de 5 minutos o 'rebatedor' desconecta o WQSNG.


Outra situação possível é que a Aplicação tenha registrado um determinado tamanho do pedido (Parte Fixa do SNG), mas envia, de fato, um tamanho diferente.

O TstSNG ficará esperando o restante do conteúdo até o Timeout.




Após testes, via Telnet, e a execução das configurações necessárias, a tela do WQ que se refere ao 'Comunicador Servidor' não ficou azul (como ficava quando em simulação)


A parte de baixo da tela (Comunicador Servidor) não ficou azul porque foi configurado apenas a conexão CLIENTE do WQSNG para a conexão ao servidor do CICS, sentido EMPRESA -> SNG.

Caso seja necessário que o WQSNG seja Servidor, então será necessário também informar o seu endereço IP para a conexão no sentido EMPRESA -> SNG.

Além disso, será necessário configurar a sessão CLSERVER no arquivo WQ.ini

[CLSERVER]

APPNAME=C:\WQ551\TstCLIENT >>> Indicar a aplicação que será inicializada quando uma string de dados for recebida do SNG

IP=localhost >>> IP do Servidor (esse ip “nateado” será

informado ao SNG)

PORT=3502 >>> Porta do Servidor (essa porta será passada ao SNG)

Contudo, geralmente as EMPRESAS atuam como CLIENTE, apenas enviando strings ao SNG.




Para receber respostas do SNG, quando se encaminha, por exemplo, uma inclusão de restrição financeira ou baixa do gravame é necessário configurar o WQSNG como Servidor?


Não há essa necessidade.

O Servidor é necessário quando o SNG envia ao oarceiro uma string para

processamento.

Daí, sua Aplicação encaminha uma string ao SNG, que processa o pedido e retorna com a resposta na mesma conexão CLIENTE.

Geralmente, quem implementa a função Servidor são os Detrans, por conta do SNG acessar suas bases de dados.




Gostaríamos de catalogar  em nossa base de dados possíveis condições de erro previstas no WQSNG. Onde consultar esses os códigos de retorno  (RC) para o erro -4nn?


Os Return Codes (RCs) disposníveis no WQSNG, como o -4nn, estão disponíveis para eventuais consultas, incluindo suas possíveis combinações, no manual “Interface WQ - Guia de Referência Rápida - Desenvolvedor.pdf”

Abaixo, a descrição de como interpretar o RC -4nn:

A tentativa de conexão com o Gerenciador de Filas foi realizada com sucesso, porém falhou no processo de envio de autenticação ou no recebimento da resposta enviada.
O código “nn” corresponde a um dos valores negativos abaixo que indicará a causa da falha. Ex.: Para -414 ver erro –14.

-4 >> indica que houve um erro na escrita ou leitura do pedido no gerenciador de filas.

nn >> O código “nn” corresponde a um dos valores negativos abaixo que indicará a causa da falha.


1) Para -414 ver erro –14.... Erro -14 : O tempo máximo para leitura dos dados ou o comando expirou.

-40 A conexão com o Gerenciador de Filas foi encerrada porque foi rejeitada pelo mesmo. Esta rejeição pode ocorrer porque a versão do Conector WQ não é a mesma do Gerenciador de Filas, ou porque o Comunicador não está ativo e conectado com o WQ Remoto.

2) O erro -440 , de acordo com o manual, pode estar ocorrendo pq a máquina foi “restartada” e a conexão ainda não estava ativa qdo a aplicação enviou o pedido.

As possibilidades de ocorrências dessas mensagens -4:
-412, -413, -414, -415, -416, -417, -418 -440,




Após o período de Homologação, estamos em vias de subir o WQ para Produção. Quais passos são necessários para “mover” o WQ em Homologação para Produção?


Recomendações para migração do ambiente de Homologação para Produção:

a. Copiar todo o diretório do servidor de homologação para o servidor de produção

b. Alterar as configurações de IP e Porta nas sessões :

** [QUEUEMANAGER] >> Informar o IP do servidor da produção e a porta que o WQ receberá conexão da sua aplicação (default é 9001)

** [REMOTESYSTEM] >> Informar o IP e a porta do CICS de produção do SNG

c. Ajustar, se necessário, o (DEBUGLEVEL) para reduzir ou aumentar registros na log (parâmetro está descrito no manual)

d. Ajustar o número de bytes das strings de negócio (AUDITDATALENGTH) que serão armazenadas no audit. Por serem dados sensíveis ao negócio, é recomendável iniciar com tamanho grande para analisar os envios e respostas e depois diminuir por segurança

Como é possível copiar de um servidor para outro, a estrutura de pastas será mantida.

NOTA: Antes de se 'startar' o WQSNG no servidor da produção a 1ª vez, exclua os logs. Após o 'start', será necessário encaminhar a LOG para que a Workers gere a chave de ativação da licença da produção.

Observação: Planejar rotina para backup e limpeza de LOGs para evitar que o servidor fique sem espaço em disco no futuro.





WQ - Windows/Linux/CICS

Scripts básicos da instalação do WQ CICS e WQ Linux


Os passos básicos para a instalação do WQ no ambiente CICS é realizar o upload do xmit e executar alguns jobs para linkedição do WQ, de carga de transações, programas e arquivos no CICS.

O Script de instalação é basicamente descompactar o WQ e executar o start do WQADMIN

No caso do WQ no ambiente Linux é importante providenciar a instalação das dependências abaixo:

  • Compilador GCC versão 4.4 ou superior, incluindo suas bibliotecas (para 64Bit);
  • Bibliotecas do GTK2 atualizadas ( 2.18 ou superior, para 64Bits)

  • Bibliotecas do OpenSSL atualizadas (1.0.0b ou superior)




Procedimentos para migrar o ambiente de Homologação para o ambiente Produtivo


Para a migração da instalação do WQCICS para o ambiente de Produção, o procedimento a ser executado pela equipe de suporte é:

  • Copiar a loadlib SWD.WQ.V215.JOBLIB
  • Copiar o arquivo VSAM de configuração

XYZ.WQ.V215.CNFWQ

XYZ.WQ.V215.CNFWQ.DATA

XYZ.WQ.V215.CNFWQ.INDEX

  • Extrair do CSD do Seratest do MVS3 os programas, transações e TDs do grupo WQCICS, ou executar novamente o JCL de carga dos programas e transações SWD.WQ.V215.JOBLIB(@6LODCSD)
  • Se for refeita a carga do CSD, as TDs da instância WH deverão ser recriadas.
  • Após o grupo WQCICS com o arquivo, programas, transações e TDs tiver sido instalado, executar a transação wqcf wh e alterar o endereço IP.

Caso no ambiente Linux, o servidor seja mantido o mesmo, basta reconfigurar o endereço IP que aponta para o novo CICS.

Entretando, caso o WQLinux seja migrado para outro servidor, será necessário ainda gerar uma nova licença. Nesse caso, basta copiar o diretório /opt/wq451 para o novo servidor e instalar o XVFB para start por console.

Após o 1º start do WQLinux enviar a LOG para geração da chave de ativação da licença.





VFTP - VitalSigns for FTP

Pré-Instalação e Check List do VFTP


Baixe aqui o Guia da Pré-Instalação do VFTP




Guia de Instalação do VFTP


Baixe aqui o Guia de Instalação do VFTP.