10.1. Keep your system secure
You should strive to keep your system secure by monitoring its usage and also the vulnerabilities that might affect it, patching them as soon as patches are available. Even though you might have installed a really secure system initially you have to remember that security in a system degrades with time, security vulnerabilities might be found for exposed system services and users might expose the system security either because of lack of understanding (e.g. accessing a system remotely with a clear-text protocol or using easy to guess passwords) or because they are actively trying to subvert the system's security (e.g. install additional services locally on their accounts).
10.1.1. Tracking security vulnerabilities
Although most administrators are aware of security vulnerabilities affecting their systems when they see a patch that is made available you can strive to keep ahead of attacks and introduce temporary countermeasures for security vulnerabilities by detecting when your system is vulnerable. This is specially true when running an exposed system (i.e. connected to the Internet) and providing a service. In such case the system's administrators should take care to monitor known information sources to be the first to know when a vulnerability is detected that might affect a critical service.
Concious administrators can use that information to determine which security bugs might affect the system they are managing, determine the severity of the bug and apply (if available) temporary countermeasures before a patch is available fixing this issue.
Notice, however, that the information tracked by the Debian Testing Security Team only involves disclosed vulnerabilities (i.e. those already public). In some occasions the Debian Security Team might be handling and preparing DSAs for packages based on undisclosed information provided to them (for example, through closed vendor mailing lists or by upstream maintainers of software). So do not be surprised to find security issues that only show up as an advisory but never get to show up in the security tracker.
10.1.2. Atualizando continuamente o sistema
10.1.2.1. Verificando manualmente quais atualizações de segurança estão disponíveis
O Debian oferece uma ferramenta específica para verificar se o sistema precisa de atualização (veja o programa Tiger abaixo), mas muitos usuários preferem verificar manualmente se as atualizações de segurança estão disponíveis.
Se você configurou o seu sistema como descrito em
Seção 4.2, “Executar uma atualização de segurança” você só precisa fazer:
# apt-get update
# apt-get upgrade -s
[ ... review packages to be upgraded ... ]
# apt-get upgrade
# checkrestart
[ ... restart services that need to be restarted ... ]
O primeiro comando baixa a lista de pacotes disponíveis nos sources de pacotes configurados. A opção
-s faz somente uma simulação, isto é,
não baixa ou instala os pacotes e sim diz quais devem ser baixados/instalados. Você poderá saber que pacotes foram consertados pelo Debian e estão disponíveis para atualização. Por exemplo:
# apt-get upgrade -s
Reading Package Lists... Done
Building Dependency Tree... Done
2 packages upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Inst cvs (1.11.1p1debian-8.1 Debian-Security:3.0/stable)
Inst libcupsys2 (1.1.14-4.4 Debian-Security:3.0/stable)
Conf cvs (1.11.1p1debian-8.1 Debian-Security:3.0/stable)
Conf libcupsys2 (1.1.14-4.4 Debian-Security:3.0/stable)
Notice that you will need to reboot your system if there has been a kernel upgrade.
10.1.2.2. Checking for updates at the Desktop
Since Debian 4.0 lenny Debian provides and installs in a default installation update-notifier. This is a GNOME application that will startup when you enter your Desktop and can be used to keep track of updates available for your system and install them. It uses update-manager for this.
In a stable system updates are only available when a security patch is available or at point releases. Consequently, if the system is properly configured to receive security updates as described in
Seção 4.2, “Executar uma atualização de segurança” and you have a cron task running to update the package information you will be notified through an icon in the desktop notifcation area.
The notification is not intrusive and users are not forced to install updates. From the notification icon a desktop user (with the administrator's password) can access a simple GUI to show available updates and install them.
This application works by checking the package database and comparing the system with its contents. If the package database is updated periodically through a cron task then the contents of the database will be newer than the packages installed in the system and the application will notify you.
Apt installs such a task (/etc/cron.d/apt) which will run based on Apt's configuration (more specifically APT::Periodic). In the GNOME environment this configuration value can be adjusted by going to System > Admin > Software origins > Updates, or running /usr/bin/software-properties.
If the system is set to download the packages list daily but not download the packages themselves your
/etc/apt/apt.conf.d/10periodic should look like this:
APT::Periodic::Update-Package-Lists "1";
APT::Periodic::Download-Upgradeable-Packages "0";
Users of the KDE desktop environment will probably prefer to install adept and adept-notifier instead which offers a similar functionality but is not part of the standard installation.
10.1.2.3. Verificando automaticamente por atualizações com o cron-apt
Another method for automatic security updates is the use of cron-apt. This package provides a tool to update the system at regular intervals (using a cron job), and can also be configured to send mails to the system administrator using the local mail transport agent. It will just update the package list and download new packages by default but it can be configured to automatically install new updates.
Note que você pode querer verificar a versão da distribuição, como descrito em
Seção 7.5.3, “Per distribution release check”, se você pretende atualizar automaticamente o seu sistema (mesmo somente baixando pacotes). Caso contrário você não terá certeza que os pacotes baixados realmente são de origem confiável.
10.1.2.4. Automatically checking for security issues with debsecan
The
debsecan program evaluates the security status of by reporting both missing security updates and security vulnerabilities. Unlike
cron-apt, which only provides information related to security updates available, but this tool obtains information from the security vulnerability database maintained by the Debian Security Team which includes also information on vulnerabilities which are not yet fixed through a security update. Consequently, it is more efficient at helping administrators track security vulnerabilities (as described in
Seção 10.1.1, “Tracking security vulnerabilities”).
Upon installing the Debian package debsecan, and if the administrator consents to it, it will generate a cron task that will make it run and send the output to a specific user whenever it finds a vulnerable package. It will also download the information from the Internet. The location of the security database is also part of the questions ask on installation and are later defined /etc/default/debsecan, it can be easily adjusted for systems that do not have Internet access so that they all pull from a local mirror so that there is a single point that access the vulnerability database.
Notice, however, that the Security Team tracks many vulnerabilities including low-risk issues which might not be fixed through a security update and some vulnerabilities initially reported as affecting Debian might, later on, upon investigation, be dismissed. Debsecan will report on all the vulnerabilities, which makes it a quite more verbose than the other tools described above.
10.1.2.5. Outros métodos para atualizações de segurança
10.1.3. Evite usar versões instáveis
Ao menos que você tenha tempo para aplicar patches de segurança toda vez que uma vulnerabilidade é descoberta, você não deve usar a versão instável do Debian para sistemas em produção. A principal razão para isto é que não há atualizações de segurança para a versão unstable.
O fato é que algumas questões relacionadas à segurança podem surgir na distribuição instável e não na stable. Isto porque novas funcionalidades são constantemente adicionadas às aplicações, assim como novas aplicações são incluídas sem serem totalmente testadas.
Para se fazer atualizações de segurança na versão unstable, você pode fazer uma atualização completa para nova versão (que atualiza muito mais do que somente os pacotes afetados). Embora existam algumas exceções, patches de segurança geralmente só são portadas para a versão stable. A idéia principal é que entre as atualizações, nenhum código novo deve ser adicionado, somente consertos para questões importantes.
10.1.4. Security support for the testing branch
Se você estiver utilizando uma versão em
testing, existem algumas questões relacionadas à disponibilidade das atualizações de segurança que devem ser levadas em conta:
Quando um conserto de segurança é preparado, o Time de Segurança lança o patch para a versão stable (desde que a estável é geralmente algumas versões menor ou maior atrás). Os mantenedores de pacotes são responsáveis por preparar o patch para a versão unstable, geralmente baseado nos novos lançamentos. Algumas vezes as alterações acontecem quase ao mesmo tempo e em outras um dos lançamentos disponibiliza o conserto de segurança antes. Os pacotes para a distribuição stable são testados bem mais a fundo do que para a unstable, já que esta irá fornecer na maioria dos casos a última versão do lançamento (que pode incluir novos e desconhecidos bugs)
Atualizações de segurança estão disponíveis para a versão unstable geralmente quando os mantenedores fazem um novo pacote e para a versão stable quando o Time de Segurança publica um DSA e faz um novo upload. Observe que nada disso altera a versão em testing.
Se nenhum (novo) bug é detectado na versão unstable do pacote, ele passa para a versão em testing depois de algum tempo. Este tempo geralmente é de dez dias, embora dependa de algumas coisas como a prioridade de upload e se o pacote está ou não bloqueado para entrar em teste por causa de dependências. Note que se o pacote estiver bloqueado, a prioridade de upload não afetará o tempo que ele leva para entrar na versão em teste.
Esse comportamento pode ser alterado conforme o estado de lançamento da distribuição. Quando uma distribuição está perto de ser lançada, o Time de Segurança ou os mantenedores dos pacotes devem fornecer atualizações de segurança diretamente para a versão em teste.
Additionally, the
http://secure-testing-master.debian.net can issue Debian Testing Security Advisories (DTSAs) for packages in the
testing branch if there is an immediate need to fix a security issue in that branch and cannot wait for the normal procedure (or the normal procedure is being blocked by some other packages).
Users willing to take advantage of this support should add the following lines to their
/etc/apt/sources.list (instead of the lines described in
Seção 4.2, “Executar uma atualização de segurança”):
deb http://security.debian.org testing/updates main contrib non-free
# This line makes it possible to donwload source packages too
deb-src http://security.debian.org testing/updates main contrib non-free
10.1.5. Atualizações automáticas no sistema Debian GNU/Linux
Primeiro de tudo, atualizações automáticas não são recomendadas, já que o administrador deve revisar os DSAs (alertas de segurança do Debian) e entender o impacto causado pela atualização de segurança no sistema.
Para atualizar o seu sistema automaticamente você deve:
Configure apt so that those packages that you do not want to update stay at their current version, either with apt's pinning feature or marking them as hold with aptitude or dpkg.
To pin the packages under a given release, you must edit
/etc/apt/preferences (see
apt_preferences(5)) and add:
Package: *
Pin: release a=stable
Pin-Priority: 100
FIXME: verifcar se a configuração está OK.
A opção
-y faz com que o
apt assuma 'sim' para todos os prompts que aparecerão durante a atualização. Em alguns casos, é melhor você usar a opção
--trivial-only em vez de
--assume-yes (equivalente a
-y).
Configure o
cron para que o
debconf não faça nenhuma pergunta durante as atualizações, funcionando de forma não-interativa.
Verifique os resultados da execução do cron, que enviará um mail para o superusuário (ao menos que a variável de ambiente MAILTO seja alterada no script).
Uma alternativa mais segura seria usar a opção -d (ou --download-only), que irá fazer o download dos pacotes necessários mas não os instalará. Então se a execução do cron mostrar que o sistema precisa ser atualizado, esta atualização pode ser feita manualmente.
Entretanto, isto não é recomendado para a versão unstable sem que haja uma análise cuidadosa, uma vez que pode tornar o seu sistema inutilizável se algum pacote importante que estiver com um bug sério for instalado. A testing é um pouco mais segura com relação a isto, já que os bugs sérios podem ser detectados antes do pacote ser movido para a versão em teste (embora, você não tenha atualizações de segurança disponíveis para todos).
Se você tem uma distribuição mista, isto é, uma instalação
stable com alguns pacotes atualizados para a versão em
testing ou
unstable, você pode utilizar o recurso de
pinning assim como a opção
--target-release do
apt para atualizar
somente aqueles pacotes que devem ser atualizados.
