Instalando e configurando MariaDB no Debian 9

O SGDB MariaDB é um fork do MySQL, feito pelo mesmo autor deste, após a sua aquisição pela Oracle. Neste post, veremos como se faz a instalação e a configuração básica do mesmo no Debian Stretch. Antigamente, bastava instalar o MySQL via APT, fornecendo uma senha de administrador durante tal instalação. Hoje em dia, alguns passos extras são necessários.

A instalação

A instalação do MariaDB poderá ser feita com o comando:

# apt-get install mariadb-server

Com isso, o serviço será instalado e nenhuma pergunta será feita. No caso deste post, foi instalada a versão 10.1.26. Uma configuração básica será necessária para o seu uso inicial.

A configuração básica

O primeiro passo da configuração básica será fazer os ajustes iniciais no MariaDB. Para isso, execute o comando:

# mysql_secure_installation

A não ser que você saiba o que está fazendo, responda às perguntas da seguinte forma:

• Enter current password for root (enter for none): pressione Enter.
• Set root password? [Y/n]: pressione Enter.
• New password: digite uma senha forte para o ser usada pelo root do MariaDB.
• Remove anonymous users? [Y/n]: pressione Enter.
• Disallow root login remotely? [Y/n]: responda de acordo com a sua necessidade. A melhor resposta, caso não saiba o que fazer, será Y.
• Remove test database and access to it? [Y/n]: pressione Enter.
• Reload privilege tables now? [Y/n]: pressione Enter.

Agora, tente entrar no SGDB via linha de comando:

# mariadb -u root -p

Se tudo deu certo, você entrará no sistema e receberá um prompt, depois de um texto inicial.Veja:

Welcome to the MariaDB monitor. Commands end with ; or \g.
Your MariaDB connection id is 10
Server version: 10.1.26-MariaDB-0+deb9u1 Debian 9.1

Copyright (c) 2000, 2017, Oracle, MariaDB Corporation Ab and others.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

MariaDB [(none)]>

Para sair do ambiente do SGDB, digite quit.

Possíveis erros e soluções

Existe a possibilidade de ocorrerem alguns erros no momento do acesso do banco de dados por aplicações, como o phpmyadmin. O principal deles é o #1698. Veremos a seguir como resolver esse problema.

#1698 – Access denied for user ‘root’@’localhost’

Para sanar esse erro, execute os seguintes comandos:

# mariadb -u root -p
> use mysql;
> update user set plugin='' where User='root';
> flush privileges;
> exit

Vá em frente

Agora que você tem o MariaDB instalado, use-o!

[]s

Tags:Debian, Linux, MariaDB, MySQL

Como migrar do Debian Jessie para o Stretch

Bem vindo ao Debian Stretch!

Ontem, 17 de junho de 2017, o Debian 9 (Stretch) foi lançado. Eu gostaria de falar sobre alguns procedimentos básicos e regras para migrar do Debian 8 (Jessie).

Passos iniciais

• A primeira coisa a fazer é ler a nota de lançamento. Isso é fundamental para saber sobre possíveis bugs e situações especiais.
• O segundo passo é atualizar o Jessie totalmente antes de migrar para o Stretch. Para isso, ainda dentro do Debian 8, execute os seguintes comandos:

# apt-get update
# apt-get dist-upgrade

Migrando

• Edite o arquivo /etc/apt/sources.list e altere todos os nomes jessie para stretch. A seguir, um exemplo do conteúdo desse arquivo (poderá variar, de acordo com as suas necessidades):

deb http://ftp.br.debian.org/debian/ stretch main
deb-src http://ftp.br.debian.org/debian/ stretch main
                                                                                                                                
deb http://security.debian.org/ stretch/updates main
deb-src http://security.debian.org/ stretch/updates main

• Depois, execute:

# apt-get update
# apt-get dist-upgrade

Caso haja algum problema, leia as mensagens de erro e tente resolver o problema. Resolvendo ou não tal problema, execute novamente o comando:

# apt-get dist-upgrade

Havendo novos problemas, tente resolver. Busque soluções no Google, se for necessário. Mas, geralmente, tudo dará certo e você não deverá ter problemas.

Alterações em arquivos de configuração

Quando você estiver migrando, algumas mensagens sobre alterações em arquivos de configuração poderão ser mostradas. Isso poderá deixar alguns usuários pedidos, sem saber o que fazer. Não entre em pânico.

Existem duas formas de apresentar essas mensagens: via texto puro em shell ou via janela azul de mensagens. O texto a seguir é um exemplo de mensagem em shell:

Ficheiro de configuração '/etc/rsyslog.conf'
 ==> Modificado (por si ou por um script) desde a instalação.
 ==> O distribuidor do pacote lançou uma versão atualizada.
 O que deseja fazer? As suas opções são:
 Y ou I : instalar a versão do pacote do maintainer
 N ou O : manter a versão actualmente instalada
 D : mostrar diferenças entre as versões
 Z : iniciar uma shell para examinar a situação
 A ação padrão é manter sua versão atual.
*** rsyslog.conf (Y/I/N/O/D/Z) [padrão=N] ?

A tela a seguir é um exemplo de mensagem via janela:

Nos dois casos, é recomendável que você escolha por instalar a nova versão do arquivo de configuração. Isso porque o novo arquivo de configuração estará totalmente adaptado aos novos serviços instalados e poderá ter muitas opções novas ou diferentes. Mas não se preocupe, pois as suas configurações não serão perdidas. Haverá um backup das mesmas. Assim, para shell, escolha a opção “Y” e, no caso de janela, escolha a opção “instalar a versão do mantenedor do pacote”. É muito importante anotar o nome de cada arquivo modificado. No caso da janela anterior, trata-se do arquivo /etc/samba/smb.conf. No caso do shell o arquivo foi o /etc/rsyslog.conf.

Depois de completar a migração, você poderá ver o novo arquivo de configuração e o original. Caso o novo arquivo tenha sido instalado após uma escolha via shell, o arquivo original (o que você tinha anteriormente) terá o mesmo nome com a extensão .dpkg-old. No caso de escolha via janela, o arquivo será mantido com a extensão .ucf-old. Nos dois casos, você poderá ver as modificações feitas e reconfigurar o seu novo arquivo de acordo com as necessidades.

Caso você precise de ajuda para ver as diferenças entre os arquivos, você poderá usar o comando diff para compará-los. Faça o diff sempre do arquivo novo para o original. É como se você quisesse ver como fazer com o novo arquivo para ficar igual ao original. Exemplo:

# diff -Naur /etc/rsyslog.conf /etc/rsyslog.conf.dpkg-old

Em uma primeira vista, as linhas marcadas com “+” deverão ser adicionadas ao novo arquivo para que se pareça com o anterior, assim como as marcadas com “-” deverão ser suprimidas. Mas cuidado: é normal que haja algumas linhas diferentes, pois o arquivo de configuração foi feito para uma nova versão do serviço ou aplicativo ao qual ele pertence. Assim, altere somente as linhas que realmente são necessárias e que você mudou no arquivo anterior. Veja o exemplo:

+daemon.*;mail.*;\
+ news.err;\
+ *.=debug;*.=info;\
+ *.=notice;*.=warn |/dev/xconsole
+*.* @sam

No meu caso, originalmente, eu só alterei a última linha. Então, no novo arquivo de configuração, só terei interesse em adicionar essa linha. Bem, se foi você quem fez a configuração anterior, você saberá fazer a coisa certa. Geralmente, não haverá muitas diferenças entre os arquivos.

Outra opção para ver as diferenças entre arquivos é o comando mcdiff, que poderá ser fornecido pelo pacote mc. Exemplo:

# mcdiff /etc/rsyslog.conf /etc/rsyslog.conf.dpkg-old

Problemas com ambientes e aplicações gráficas

É possível que você tenha algum problema com o funcionamento de ambientes gráficos, como Gnome, KDE etc, ou com aplicações como o Mozilla Firefox. Nesses casos, é provável que o problema seja os arquivos de configuração desses elementos, existentes no diretório home do usuário. Para verificar, crie um novo usuário no Debian e teste com ele. Se tudo der certo, faça um backup das configurações anteriores (ou renomeie as mesmas) e deixe que a aplicação crie uma configuração nova. Por exemplo, para o Mozilla Firefox, vá ao diretório home do usuário e, com o Firefox fechado, renomeie o diretório .mozilla para .mozilla.bak, inicie o Firefox e teste.

Outros possíveis problemas

É possível que alguns pacotes fiques “engasgados”. Isso ocorrerá, principalmente, se você tiver misturado pacotes, instalando algumas coisas que não tenham vindo dos repositórios oficiais do Debian. Após tentar o comando apt-get dist-upgrade umas duas vezes sem sucesso, observe as mensagens de erro, remova o pacote problemático (com apt-get remove) e tente o apt-get dist-upgrade novamente.

Está inseguro?

Caso você esteja muito inseguro, instale um Debian 8, com ambiente gráfico e outras coisas, em uma máquina virtual e migre para Debian 9 para testar e aprender. Sugiro VirtualBox como virtualizador. Depois de uma pequena experiência, provavelmente, você estará apto a fazer a migração do seu sistema.

Divirta-se!

Tags:Debian, Debian 8, Debian 9, Debian Jessie, Debian Stretch, migração, migration

Debian Developers living in South America

Well, I made this map using data from http://db.debian.org. As an example, currently, there are 27 Brazilian DDs. However, there are 23 DDs living in Brazil.

Tags:América do Sul, dd, Debian, Debian Developer, Desenvolvedores Debian, Planet en, South America

OpenVAS 9 from Kali Linux 2017.1 to Debian 9

The OpenVAS

OpenVAS is a framework of several services and tools offering a comprehensive and powerful vulnerability scanning and vulnerability management solution. The framework is part of Greenbone Networks’ commercial vulnerability management solution from which developments are contributed to the Open Source community since 2009.

OpenVAS is composed of some elements, as OpenVAS-Cli, Greenbone Security Assistant, OpenVAS Scanner and OpenVAS Manager.

The official OpenVAS homepage is http://www.openvas.org.

From Kali Linux 2017.1 to Debian 9

Ok, this is a temporary solution. Now (June 2017), Debian 9 wasn’t released yet and OpenVAS 9 is not available in Debian in good conditions (it is in Experimental but a bit problematic). I think that we will have OpenVAS in backports soon.

The OpenVAS 9 from Kali is working perfect for Debian 9. So, to take advantage of this, adopt the following procedures:

1. Add a line to end of /etc/apt/sources.list file:

deb http://http.kali.org/kali kali-rolling main

2. Run:

# apt-get update
# apt-get install -t kali-rolling openvas

(if you want to simulate before install, add a -s option before -t)

3. Rermove or comment the previous line added to /etc/apt/sources.list file to avoid future problems in your Debian.

4. Run the following command to configure the OpenVAS and to download the initial database:

# openvas-setup

This step may take some time. Note that the initial password for user admin will be created and shown.

5. Finally, open a web browser and access the address https://127.0.0.1:9392 (use https!!!). Alternatively, you can call http://127.0.0.1 to be automagically redirected to https://127.0.0.1:9392.

The default user is admin and the password was shown in the last step. You will can change this password inside OpenVAS (menu Administration > Users > Edit User, which is an blue icon).

If your password was lost, you will be able to create a new administrative user via shell command. See the section “Some tips” below.

6. To see the packages installed from Kali Linux, use the command:

$ dpkg -l | grep kali

Some tips

To create a new administrative user called test:

# openvasmd --create-user test --role Admin

To update the database (NVTs):

# openvasmd --update
# openvasmd --rebuild
# service openvas-scanner restart

To solve the message “Login failed. Waiting for OMP service to become available”:

# openvas-start

To make OpenVAS listen all network interfaces, allowing one to call the service in a remote web browser (http://remote-server, port 80 only), edit the /lib/systemd/system/greenbone-security-assistant.service and change:

ExecStart=/usr/sbin/gsad --foreground --listen=127.0.0.1 --port=9392 --mlisten=127.0.0.1 --mport=9390

to

ExecStart=/usr/sbin/gsad --foreground --listen=0.0.0.0 --port=9392 --mlisten=127.0.0.1 --mport=9390

After the change, reload the configuration and restart the service:

# systemctl daemon-reload
# systemctl restart greenbone-security-assistant

Quick start for beginners

If OpenVAS isn’t familiar for you, I have a suggestion for a quick test. Firstly, download Ubuntu Server 8.04 from this page and install it inside a virtual machine, selecting all services as LAMP, SSH etc. I used the i386 version and VirtualBox. After this, use OpenVAS to scan the Ubuntu (menu Scans > Tasks > a pink icon with a magic wand in the upper left corner). After the scan, click over the blue bar where we will can see the word “Done”.

Enjoy!

Tags:Debian, hacker, hardening, Internet, nessus, network, OpenVAS, pentest, Planet en, Rede, security, Segurança, Stretch

Debian with three monitors under low cost graphics interface

Since 2008 I use two monitors in my desktop. Yesterday I bought a new graphics interface and a third monitor. Some time I was looking for a low cost graphics interface. Ok, I am using GeForce GT 740 which has three output ports: VGA, DVI and HDMI. In Brazil this interface card can be found around R$ 400 (US$ 117, but my card was US$ 87 in Brazilian Black Friday). In Amazon.com, it is between US$ 51 and US$ 109. The chosen manufacturer was Zotac, but all GT 740 and 750 will work fine (I tested the GT 750 too).

The GeForce GT 740 was imediatelly recognised by Debian Jessie with kernel Linux 4.7.0 from Backports (it is my default, so I didn’t test with original 3.16 kernel). The driver used was the default X.Org Nouveau. I use KDE and the management was easy.

I hope this post can help people interested in use 3 monitors. Enjoy!

Tags:3 monitors, computador, Debian, GT 740, GT 750, hardware, Linux, monitor, monitores, Nouveau, nVidia, Planet en, three monitors, três, X.Org

Statistics to Choose a Debian Package to Help

In the last week I played a bit with UDD (Ultimate Debian Database). After some experiments I did a script to generate a daily report about source packages in Debian. This report is useful to choose a package that needs help.

The daily report has six sections:

• Sources in Debian Sid (including orphan)
• Sources in Debian Sid (only Orphan, RFA or RFH)
• Top 200 sources in Debian Sid with outdated Standards-Version
• Top 200 sources in Debian Sid with NMUs
• Top 200 sources in Debian Sid with BUGs
• Top 200 sources in Debian Sid with RC BUGs

The first section has several important data about all source packages in Debian, ordered by last upload to Sid. It is very useful to see packages without revisions for a long time. Other interesting data about each package are Standards-Version, packaging format, number of NMUs, among others. Believe it or not, there are packages uploaded to Sid for the last time 2003! (seven packages)

With the report, you can choose a ideal package to do QA uploads, NMUs or to adopt.

Well, if you like to review packages, this report is for you: https://people.debian.org/~eriberto/udd/help_a_package.html. Enjoy!

Tags:.deb, debhelper, Debian, empacotamento, NMU, packaging, pacote, Planet en, QA, Sid, UDD, Ultimate Debian Database, unstable

Debian: GnuPG 2, chroot and debsign

Since GPG 2 was set as default for Debian (Sid, August 2016), an error message appeared inside jails triggered by chroot, when using debuild/debsign commands:

clearsign failed: Inappropriate ioctl for device

The problem is that GPG 2 uses a dialog window to ask for a passphrase. This dialog window needs a tty (from /dev/pts/ directory). To solve the problem, you can use the following command (inside the jail):

# mount devpts -t devpts /dev/pts

Alternatively, you can add to /etc/fstab file in jail:

devpts /dev/pts devpts defaults 0 0

and use the command:

# mount /dev/pts

Enjoy!

Tags:.deb, chroot, clearsign, Debian, debsign, debuild, devpts, empacotamento, GnuPG, GnuPG2, GPG, gpg2, ioctl, packaging, pacote, Planet en, tty

Debian: how to use blhc to solve hardening issues when packaging

UPDATE: this post was originally published on Sep. 7, 2015. I did a full review on Sep. 5, 2017. This revision is full compliant with Debian 9 and dpkg 1.18.13 or latter.

Implementing the hardening

When packaging in Debian, is very common to see some lintian messages as ‘hardening-no-relro‘ and ‘hardening-no-fortify-functions‘ in softwares written in C or C++. To solve these issues, we can use the ‘blhc‘ tool (apt-get install blhc).

Please, get the revision 1.11-9 of the icmpinfo package. You can get this revision from http://snapshot.debian.org or from http://eriberto.pro.br/debian/icmpinfo. As a shortcut, you can use the following command:

$ dget -u http://eriberto.pro.br/debian/icmpinfo/icmpinfo_1.11-9.dsc

The icmpinfo 1.11-9 is almost clean for lintian (in 2015-09-07, Standards-Version 3.9.6). The most relevant problem is:

W: icmpinfo: hardening-no-relro usr/sbin/icmpinfo

To track the problem I will use blhc over the .build file:

$ blhc icmpinfo_1.11-9_amd64.build
LDFLAGS missing (-Wl,-z,relro): cc -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -o icmpinfo recvping.o print.o err.o icmpinfo.o pid.o

Note that the problem is some missing options (-Wl,-z,relro) for LDFLAGS when building icmpinfo (for newbies, in GCC, -o is used to indicate the name to be used for the final binary after the compilation). If you are using the DebHelper compat 9 (debian/compat=9) and the DebHelper 9 (debhelper >= 9 in Build-Depends field in d/control), some variables as CFLAGS, LDFLAGS, CPPFLAGS and CXXFLAGS will be automatically passed during calls to dh_auto_* programs (yes, you should use the new and reduced debian/rules format – as an example, see the debian/rules of the icmpinfo 1.11-9; if you still having doubts, $ man dh).

Now, we need discover the reason why the LDFLAGS is being changed between its generation by the Debian build system and its utilization by the upstream’s source code. So, we need to check the upstream’s Makefile.

There is inside Makefile (after a ‘quilt push -a’, to apply all current patches):

LDFLAGS= $(CFLAGS)

OBJECTS= recvping.o print.o err.o icmpinfo.o pid.o
TARGET = icmpinfo

$(TARGET): $(OBJECTS)
 $(CC) $(LDFLAGS) -o $@ $(OBJECTS) $(LDLIBS)

Hummm… The LDFLAGS content generated by Debian is being dropped by Makefile because it is saying that “LDFLAGS = CFLAGS content”. This line is a problem because the upstream Makefile needs to take and use the CFLAGS and LDFLAGS independently. To fix the issue, you can use this patch:

--- icmpinfo-1.11.orig/Makefile
+++ icmpinfo-1.11/Makefile
@@ -20,13 +20,13 @@ VERS = 1.11
 
 RM = rm -f
 
-LDFLAGS= $(CFLAGS)
+#LDFLAGS= $(CFLAGS)
 
 OBJECTS= recvping.o print.o err.o icmpinfo.o pid.o
 TARGET = icmpinfo
 
 $(TARGET): $(OBJECTS)
- $(CC) $(LDFLAGS) -o $@ $(OBJECTS) $(LDLIBS)
+ $(CC) $(LDFLAGS) $(CFLAGS) -o $@ $(OBJECTS) $(LDLIBS)
 
 tgz: clean
 rm -f CHECKSUMS.asc

After a ‘debuild’, we have a new lintian:

I: icmpinfo: hardening-no-bindnow usr/sbin/icmpinfo

There is a simple way to fix this message. We

needed to add the following line to debian/rules:

export DEB_BUILD_MAINT_OPTIONS = hardening=+all

If you still seeing lintians about the hardening, use the following options in blhc (>= 0.07+20170817+gita232d32) to get a deep analysis:

blhc --all --debian --arch=amd64 ../icmpinfo_1.11-9_amd64.build

For more details, see the bug #845339 on Debian.

More examples

Let me to show other example. I will use the mac-robber 1.02-5 (however, I disabled the Makefile.patch in debian/patches/series). After a debuild, the following lintian messages are presented:

I: mac-robber: hardening-no-fortify-functions usr/bin/mac-robber
I: mac-robber: hardening-no-bindnow usr/bin/mac-robber

Using blhc:

$ blhc ../mac-robber_1.02-5_amd64.build 
CFLAGS missing (-g -O2 -fstack-protector-strong -Wformat -Werror=format-security): gcc -D_FILE_OFFSET_BITS=64 -o mac-robber mac-robber.c
CPPFLAGS missing (-D_FORTIFY_SOURCE=2): gcc -D_FILE_OFFSET_BITS=64 -o mac-robber mac-robber.c
LDFLAGS missing (-Wl,-z,relro): gcc -D_FILE_OFFSET_BITS=64 -o mac-robber mac-robber.c

We need to verify what is the problem in Makefile with CFLAGS, CPPFLAGS and LDFLAGS when generating the binary ‘mac-robber’ (just recalling, -o mac-robber in GCC command). See:

linux_notstatic: 
 $(CC) -D_FILE_OFFSET_BITS=64 -o mac-robber mac-robber.c

There are no references to CFLAGS, CPPFLAGS and LDFLAGS. To solve the problem, we need patch the Makefile to make this:

linux_notstatic: 
 $(CC) $(CFLAGS) $(LDFLAGS) $(CPPFLAGS) -D_FILE_OFFSET_BITS=64 -o mac-robber mac-robber.c

As last example, is possible that the Makefile is overriding the content sent by DebHelper when building. See this line from a hypothetical Makefile:

CFLAGS = -g -Wall

As you can see, the Makefile is redefining CFLAGS; consequently, it is discarding any previous content sent by DebHelper. To solve this issue, we can use the following patch:

-CFLAGS = -g -Wall
+CFLAGS += -g -Wall

So, the content received from DebHelper will be added to ‘-g -Wall’.

Default parameters

As curiosity, to see the basic parameters created by DebHelper as hardening, use the command:

$ dpkg-buildflags

To see the all parameters, use the command:

$ DEB_BUILD_MAINT_OPTIONS=hardening=+all dpkg-buildflags

More information

More information about the hardening can be viewed at two places:

https://wiki.debian.org/Hardening

https://wiki.debian.org/HardeningWalkthrough

I hope this help. Enjoy!

Tags:blhc, CFLAGS, CPPFLAGS, debhelper, Debian, dpkg, empacotamento, G++, GCC, hardening, hardening-no-fortify-functions, hardening-no-relro, LDFLAGS, Linux, packaging, pacote, Planet en

Upload to jessie-backports from Debian Jessie stable

Today, trying upload to jessie-backports from a Jessie jail, I got this message from dput-ng:

 $ dput netdiscover_0.3beta7~pre-2~bpo8+1_amd64.changes
Uploading netdiscover using ftp to ftp-master (host: ftp.upload.debian.org; directory: /pub/UploadQueue/)
running allowed-distribution: check whether a local profile permits uploads to the target distribution
`jessie-backports' not in the codename group

To solve this problem, you can edit the /usr/share/dput-ng/codenames/debian.json file and add jessie-backports here:

 "backport": [
 "stable-backports",
 "oldstable-backports",
 "jessie-backports",
 "wheezy-backports",
 "squeeze-backports"
 ],

I hope this help someone.

Tags:backports, Debian, empacotamento, Jessie, Planet en

SSL inspection em firewalls: será que isso é lícito?

O SSL inspection é uma técnica de firewall, criada há poucos anos, utilizada para verificar o conteúdo de tráfego de rede criptografado.

Em uma conexão criptografada, apenas o usuário envolvido e o servidor de rede final conseguem visualizar o conteúdo do tráfego. Esse é o fator que propicia a segurança desejada pelo usuário ao acessar sites que requeiram a utilização de dados pessoais ou a visualização de informações sigilosas. Um exemplo é o acesso a um sistema de Internet banking, onde o usuário disponibiliza sua senha pessoal e acessa dados pessoais e sigilosos. Outra situação correlata é uma compra pela Internet, na qual todos os dados de cartão de crédito serão digitados. Esses são casos clássicos de utilização de criptografia na conexão para proteger os usuários. No acesso via página, por exemplo, quando se quer segurança, é utilizado o protocolo HTTPS em vez de HTTP. O “S” se refere a “secure”. Em resumo, o uso de criptografia provê segurança ao usuário; no entanto, isso cega o sistema de firewall, fato que ocorre, naturalmente, em todas as redes em prol da segurança pessoal de quem as utiliza.

A técnica de SSL inspection foi desenvolvida para uso em casos específicos, pois da mesma forma que uma conexão criptografada pode ser utilizada em prol da segurança dos usuários, ela também pode ser empregada para o tráfego de arquivos maliciosos, que afetariam sistemas externos à instituição que detém o firewall. Assim, tal instituição poderá, em casos específicos e mais raros, adotar o SSL inspection para verificar determinadas conexões, oriundas de uma máquina da rede suspeita de ações incompatíveis. Para tanto, com o SSL inspection, o administrador da rede poderá “quebrar” a criptografia entre o usuário e o servidor de destino e analisar tudo que estiver trafegando entre os dois.

Vários sistemas de firewall comerciais modernos disponibilizam a técnica de SSL inspection. No entanto, o uso indiscriminado de tal técnica consiste em violação de privacidade, configurando crime, de acordo com a lei do país onde ocorra e que trate tal assunto como irregular. Geralmente, o uso do SSL inspection está vinculado a determinações judiciais ou testes em ambientes de pesquisa de malwares, como empresas de produção de antivírus. É necessário lembrar que existem alguns entendimentos errôneos sobre o que se pode ou não fazer dentro de uma empresa. Um desses entendimentos criou uma “lenda” que diz que “tudo o que circula dentro de uma empresa pertence à mesma”. No entanto, a lei, geralmente, aplica ao mundo virtual o mesmo que aplica ao mundo real, uma vez que o virtual sempre segue o que o real pratica. Em outras palavras, tudo no mundo virtual é feito da mesma forma como ocorre no mundo real. Então, no caso de um telefone funcional, provido a um empregado da empresa, poderia tal empresa grampear o aparelho e escutar todas as conversas telefônicas? É sabido que não. Então, dentro da mesma analogia, ninguém pode praticar SSL inspection sem prévia e competente autorização, ou seja, uma ordem judicial. Uma exceção conhecida é a dos e-mails corporativos, desde que haja uma cláusula expressa nos contratos de trabalho, informando que tal e-mail não deverá ser utilizado para fins pessoais e que poderá ser monitorado. Mesmo assim, há diversos casos na história jurídica de monitoramentos inadequados e por motivos irrelevantes, que geraram decisões a favor de empregados de empresas em processos judiciais. É algo análogo a um policial que, sem motivo, algema uma pessoa na rua porque ela possui braços e pode cometer um crime. Assim, uma empresa que monitore o e-mail funcional de um empregado sem um motivo aparente, poderá ser processada pelo mesmo e perder a causa, vindo a ter que indenizá-lo.

Em uma conexão criptografada é utilizado um certificado digital instalado no servidor de rede que contém os dados a serem protegidos durante a sessão. Esse certificado deverá ser homologado por uma autoridade certificadora, como Verisign[1],  Certsign[2] ou a ICP-Brasil[3], que é reconhecida por todos os navegadores de páginas e, em consequência, tem poder para atestar a veracidade do servidor e o sigilo da comunicação. No caso do SSL inspection, o certificado da autoridade certificadora é trocado por um certificado do firewall durante o tráfego, e com isso, como uma espécie de “grampo telefônico”, esse firewall da rede passa a entender tudo o que trafega, uma vez que está violando o sigilo da conexão. Neste ponto, por exemplo, todas a senhas, incluindo as bancárias, poderão ser vistas pelo administrador de rede. O problema é que os navegadores relatarão que a conexão não parece ser íntegra, uma vez que o certificado do firewall não será reconhecido. Há duas soluções para isso: instalar o certificado do firewall em cada navegador da rede ou instalar um programa “agente” do firewall, que burle as regras. Qualquer uma das duas condições propiciará a violação do sigilo da conexão sem um alerta ao usuário envolvido.

Um indício de uso de SSL inspection é a alteração de certificados digitais. A figura a seguir mostrará o certificado digital obtido via conexão 3G.

É possível observar os campos “Issued To” e “Issued By”. No Issued To há os dados do certificado instalado no servidor de páginas do site GitHub. Já no campo “Issued By”, é possível ver os dados providos pela autoridade certificadora DigiCert[4].

Na próxima figura há o mesmo site, acessado logo em seguida, mas utilizando uma rede que pratica o SSL inspection.

Além do site desfigurado, vários dados do certificado foram removidos ou alterados. O navegador Internet Chromium, que estava sendo utilizado, é um dos programas que mostra claramente esse tipo de ocorrência. Nota-se, inclusive, o protocolo HTTPS riscado, indicando que o mesmo foi violado. Outros navegadores, como o Firefox, permitirão “adicionar uma exceção de segurança”, fazendo com que o site possa ser acessado sem a homologação de certificado, criando a possibilidade de captura de todos os dados que trafegam. É importante relembrar que, caso um agente do firewall estivesse instalado na máquina do usuário, o site apareceria normalmente, sem qualquer anomalia, apesar de haver grande a possibilidade do certificado mostrar dados não originais.

É importante ressaltar que o SSL inspection foi desenvolvido para “vasculhar” conexões de usuários internos e somente em casos especiais. Com outras técnicas mais adequadas, as conexões de usuários externos com os servidores internos poderão ser analisadas de forma mais profissional e menos intrusiva, via proxies reversos.

Conclui-se que é extremamente importante haver um cuidado com excessos no uso do SSL inspection. O simples fato de o recurso existir em um equipamento de firewall adquirido não permite o seu uso indiscriminado. Além disso, em qualquer caso, todos os funcionários e alunos de uma instituição deverão ser alertados, se for o caso, da possibilidade de tal ação na rede interna. Mesmo assim, ordens judiciais ou motivos de força maior não corriqueiros deveriam existir antes do acionamento do recurso contra uma máquina específica, por tempo determinado. Assim sendo, o uso ininterrupto de SSL inspection em toda a rede sempre será considerado como abusivo, podendo constituir crime.

[1] http://www.verisign.com.br
[2] http://www.certisign.com.br
[3] http://www.iti.gov.br/icp-brasil
[4] http://http://www.digicert.com

Tags:abuso, contravenção, crime, dados, firewall, ilegal, ilícito, Internet, invasão, legalidade, legislação, lei, lícito, pessoais, privacidade, proibido, redes, Segurança, senhas, SSL inspection