Installing Dataprotector 9 Agents on Debian 8

For some reason, dataprotector agents are released as an ISO image, with a +3000 lines shell script omnisetup.sh.

sudo ./omnisetup.sh -server myserver.myorg.es -install da

This lengthy script install dataprotector clients or server in several architectures:

  • osf1

  • hp-ux

  • SunOs and Solaris

  • AIX,

  • Linux x86, linux ia64

  • sco_sv

  • Darwin

  • PowerPC

For linux, it relays con rpm configuration. For Debian, the way to go would be alien.

Packages needed for Dataprotector agents (DA):

The only packages that are needed for the agents are:

  • OB2-TS-CORE-A.09.00-1.x86_64

  • OB2-CORE-A.09.00-1.x86_64

  • OB2-DA-A.09.00-1.x86_64

So, our first and naive aproach was a conversion with Alien and install them via dpkg -i.

for RPM in *.rpm; do sudo alien -c -k -d --fixperms $RPM; done

This led to an error as this three packages couldn’t be installed because we lacked some util called omnicc.

At this point, I tried running omnicc with bash -x, so that I could see what the long omnisetup was trying to do in my Debian machine.

bash -x ./omnisetup.sh -server myserver.myorg.es -install da

And then I noticed that, though only the above packages were installed, some others were uncompressed and used:

rpm2cpio /usr/local/share/Software_HP_DP_9.00_for_Linux_TD586-15021/linux_x86_64/DP_DEPOT/OB2-CORE-IS-A.09.00-1.x86_64.rpm 

cpio -id ./opt/omni/databases/utils/gpl/x86_64/linux-x86-64/utils.tar

cp ./opt/omni/databases/utils/gpl/x86_64/linux-x86-64/utils.tar .
(...)
rpm2cpio /usr/local/share/Software_HP_DP_9.00_for_Linux_TD586-15021/linux_x86_64/DP_DEPOT/OB2-TS-CFP-A.09.00-1.x86_64.rpm

cpio -id ./opt/omni/databases/vendor/ts_core/gpl/x86_64/linux-x86-64/A.09.00/packet.Z

PacketFullPath=/tmp/omni_tmp/opt/omni/databases/vendor/ts_core
/gpl/x86_64/linux-x86-64/A.09.00/packet.Z

(...)

rpm2cpio /usr/local/share/Software_HP_DP_9.00_for_Linux_TD586-15021/linux_x86_64/DP_DEPOT/OB2-DAP-A.09.00-1.x86_64.rpm

cpio -id ./opt/omni/databases/vendor/da/gpl/x86_64/linux-x86-64/A.09.00/packet.Z

PacketFullPath=/tmp/omni_tmp/opt/omni/databases/vendor/da/gpl/x86_64/linux-x86-64/A.09.00/packet.Z

(...)

At this point, I decided to stick to rpm installation, and use the omnisetup.sh script.

These are the files from the ISO image that we need to distribute to our Debian machines:

linux_x86_64 
│   ├── DP_DEPOT
│   │   ├── gpg-hpPublicKey.pub
│   │   ├── OB2-CFP-A.09.00-1.x86_64.rpm
│   │   ├── OB2-CORE-IS-A.09.00-1.x86_64.rpm
│   │   ├── OB2-DA-A.09.00-1.x86_64.rpm
│   │   ├── OB2-DAP-A.09.00-1.x86_64.rpm
│   │   ├── OB2-TS-CFP-A.09.00-1.x86_64.rpm
│   │   ├── OB2-TS-CORE-A.09.00-1.x86_64.rpm
│   │   └── OB2-TS-CS-A.09.00-1.x86_64.rpm
│   ├── scripts_linux_x86_64
│   │   ├── verify_gpg_lnx.sh
│   │   └── verify_gpg_lnx.sh.sig
│   └── SIG
│   └── DP_DEPOT
│   ├── OB2-CFP-A.09.00-1.x86_64.rpm.sig
│   ├── OB2-CORE-IS-A.09.00-1.x86_64.rpm.sig
│   ├── OB2-DA-A.09.00-1.x86_64.rpm.sig
│   ├── OB2-DAP-A.09.00-1.x86_64.rpm.sig
│   ├── OB2-TS-CFP-A.09.00-1.x86_64.rpm.sig
│   ├── OB2-TS-CORE-A.09.00-1.x86_64.rpm.sig
│   └── OB2-TS-CS-A.09.00-1.x86_64.rpm.sig
├── LOCAL_INSTALL
│   └── omnisetup.sh
├── Readme.txt

Manual installation:

apt-get install -y liblua5.1-0 xinetd rpm2cpio rpm 
sudo ./omnisetup.sh -server myserver.myorg.es -install da

Reconfigure xinetd to serve omni

cat /etc/xinetd.d/dataprotector 

omni stream tcp nowait root /opt/omni/lbin/inet inet -log /var/opt/omni/log/inet.log

Puppet installation

I am proud to present my own dataprotectoragent puppet module to avoid manual installation of this agent

puppet module install esterniclos-dataprotector agent

class {"dataprotectoragent":
      dataprotectorserver => "dataprotector.my.com",
    }

Available from

Troubleshooting

During this project, I encountered The package needs to be reinstalled, but I can’t find an archive for it error, and, luckily,  IhaveaPC awesome tutorial to get rid of it.

Puppet: Instalación de servidor en debian

Captura

Es la segunda vez que nos enfretamos al reto de construir un servidor puppet, esta vez sobre un servidor Debian.

Recomendamos leer how puppet works

Consideraciones iniciales

No vamos a usar una configuración asociada a un git. Vamos a usar un puppet master.

Nuestro objetivo será mantener igual en todos los equipos de nuestra infraestructura los siguientes elementos:

  • Configuración de usuarios de apache
  • Configuración GLPI
  • Certificados SSH de cliente
  • Configuración snmp

Instalación base de servidor

Debian Versión 7.7

/etc /apt/sources.list

deb http://ftp.es.debian.org/debian/ wheezy main contrib non-free
deb-src http://ftp.es.debian.org/debian/ wheezy main contrib non-free

deb http://security.debian.org/ wheezy/updates main contrib non-free
deb-src http://security.debian.org/ wheezy/updates main contrib non-free

deb http://ftp.es.debian.org/debian/ wheezy-updates main contrib non-free
deb-src http://ftp.es.debian.org/debian/ wheezy-updates main contrib non-free
deb http://backports.debian.org/debian-backports squeeze-backports main


Instalación puppet en servidor

apt-get install puppetmaster puppetmaster-passenger

Al instalar passenger, hemos tenido un problema con apache y sus logs.

no listening sockets available, shutting down
 Unable to open logs

Hemos cambiado los permisos del directorio de apache, para que ya pueda iniciar.

chown www-data:www-data /var/log/apache2

Y hemos reiniciado, por que no había nada en el puerto 80.

Instalación de puppet-dashboard en servidor

Hemos seguido al pie de la letra el tutorial de wiki.debian.org, pero hemos tenido algún problemilla más:

:~# tail /var/log/apache2/dashboard.example.com_error.log
 (...) Directory index forbidden by Options directive: /usr/share/puppet-dashboard/public/
 

Para resolverlo hemos tenido que cambiar la configuración de apache para el servidor de puppet-dashboard.

Una consideración inicial, es que hemos optado por que la configuración de este servidor, sea, por defecto el puppet dashboard. Es decir, al entrar en el raíz del servidor, por el puerto 80, saldrá directamente puppet dashboard.

# /etc/apache2/sites-enabled/puppet-dashboard

<VirtualHost *:80>
        ServerName miservidor.com
        DocumentRoot /usr/share/puppet-dashboard/public/
        <Directory /usr/share/puppet-dashboard/public/>
                Options -Indexes +FollowSymLinks MultiViews
                Order allow,deny
                allow from all
        </Directory>

        PassengerHighPerformance on
        PassengerMaxPoolSize 12
        PassengerPoolIdleTime 1500
        PassengerStatThrottleRate 120
        RailsAutoDetect On
  ErrorLog /var/log/apache2/dashboard.example.com_error.log
  LogLevel warn
  CustomLog /var/log/apache2/dashboard.example.com_access.log combined
  ServerSignature On
</VirtualHost>

Configuramos también settings.yml:

[root@server~]# grep ca_server /etc/puppet-dashboard/settings.yml
ca_server: 'server.org'

En el fichero de configuración de puppet, especificamos la url donde queremos que queden los reports

[master]
    report=true
    reports = store, http
    reporturl = http://servers/reports/reports/upload

Al poner puppet dashboard en el puerto 80, y no en el 3000 que es lo normal, hemos tenigo qeu cambiar /opt/puppet-dashboard/bin/external_node

DASHBOARD_URL = http://localhost

Esta es la vista del servidor web

 

puppet-dashboard-01

Ejecutar puppetmaster:

 /etc/init.d/puppetmaster start

Si nos da este error:

 service puppet-dashboard start
[warn] Starting Puppet Dashboard:[....] Not starting Puppet Dashboard, disabled via /etc/default/puppet-dashboard ... (warning).
. ok

Editar /etc/default/puppet-dashboard-workers:

###START=no
START=yes

Colorear en emacs puppet

[root@server puppet]# apt-get install puppet-el

Instalación de agentes puppet en cliente: Facter y puppet

Facter es el componente de cliente encargado de mostrar la información de cada máquina. Se debe instalar en cada máquina que vayamos a gestionar con puppet.

apt-get install -y puppet facter

Prueba de comunicación con el servidor:

root@client:~# puppet agent --server puppet.server.com --no-daemonize --verbose

En la primera ejecución, se crea un certificado que tenemos que firmar en el servidor. Podéis revisar slashdot.in para más información.

[root@server~]#  puppet cert  --list
 "client.org" (...)
 [root@server~]# puppet cert--sign client.org

 

Snort: Consultas a la base de datos

Abrimos conexión con la base de datos

mysql -u root -p

En la base de datos de snort,

use snort;

Para ver el diagrama entidad relación de la base de datos:

Buscamos el identificador del evento que necesitamos:

select sig_id,sig_name from signature;

En mi caso, es

223 | COMMUNITY WEB-MISC mod_jrun overflow attempt

Seleccionamos los eventos de mi  signature:

select * from event where signature = 223;

En la tabla de eventos, tenemos las alertas con origen y destino

SELECT timestamp, inet_ntoa(ip_dest), inet_ntoa(ip_src) FROM iphdr WHERE  inet_ntoa(ip_src)="192.168.5.125";

 

Finalmente, hacemos el join entre ambas tablas, y ya podemos sacar el resultado a un fichero de texto:

select inet_ntoa(ip_src), inet_ntoa(ip_dst) from event,iphdr  where iphdr.cid=event.cid and event.sid=iphdr.sid and event.signature = 223  and inet_ntoa(ip_dst)="195.23.2.123" GROUP BY ip_src ORDER BY ip_src  INTO OUTFILE '/tmp/res.txt';

Sobre el acceso a snort a través de la base de datos, tienen un post estupendo en everything about nothing.

Paypal caido, ¿por el fallo de seguridad?

Hace unos días, the Inquirer hacía eco de un exploit en la seguridad del sitio de paypal, y hoy (a las 19:15 GMT+1), justo cuando me disponia a realizar el pago online de una licencia de software, me encuentro con esto:

Paypal caido

Por lo que leí, el fallo en su pasarela permitía lanzar una ejecución en su site con código javascript malicioso, el cual podría permitir el desvio de datos (por ejemplo credenciales de autenticación) a otros servidores de internet.

Supongo que las pérdidas en transacciones para miles de compras solo las puede justificar la corroboración de dicho problema, y que estén trabajando en ello.

Un fallo de seguridad así es terrible, y más en un sistema de pagos con tanta difusion como paypal. Paypal siempre ha presumido de invertir ampliamente en la seguridad de sus sistemas, pero parece que no ha sido suficiente. ¿O simplemente es que la seguridad total es inalcanzable?.

Mi compra tendrá que esperar…