1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
|
#use wml::debian::template title="Realizar una auditoría"
#use wml::debian::recent_list
#use wml::debian::translation-check translation="1.16" maintainer="juanma"
# $Id$
<p>Esta página le proporciona un vistazo somero de los pasos que son necesarios
para afrontar la auditoría de un paquete.</p>
<p>El primer paso es elegir un paquete que realmente necesite examinarse.
Debería elegir uno cuya seguridad sea crítica.</p>
<p>Diríjase a <a href="$(HOME)/security/audit/packages">la lista de
paquetes cuya auditoría es prioritaria</a> para encontrar
sugerencias que le ayudarán a tomar su decisión.</p>
<p>Una cosa que debería tener clara es que <em>no</em> pretendemos que el
paquete se audite una sola vez. Es bueno que muchas personas elijan
examinar el mismo paquete, porque se demostrará que mucha gente piensa
que ese paquete es sensible a cuestiones de seguridad.</p>
<p>Permitiendo una selección de paquetes esencialmente aleatoria, simplificamos
la coordinación y eliminamos el problema de <q>¿cómo puedes fiarte de que la
persona X ha hecho un buen trabajo?</q> (No lo necesitamos porque asumimos que
tarde o temprano alguien decidirá examinar el mismo programa).</p>
<h2>Comenzar la auditoría</h2>
<p>Tras tomar la decisión de los paquetes, tiene que comenzar la verdadera
auditoría.</p>
<p>Si no está seguro del tipo de problemas que tiene que buscar, comience
leyendo un libro sobre desarrollo de software seguro.</p>
<p><a href="http://www.dwheeler.com/secure-programs">Secure Programming for
Linux and Unix HOWTO</a> (n.t. en inglés) tiene información de calidad que
puede resultarle muy útil.
<a href="http://www.securecoding.org/">Secure Coding: Principles &
Practices</a>, de Mark G. Graff y Kenneth R. van Wyk (n.t. en inglés)
también es un excelente libro.</p>
<p>Aunque las herramientas son imperfectas, puede ser extremadamente útiles para
encontrar posibles vulnerabilidades. Diríjase a <a href="tools">la página de
herramientas de auditoría</a> para encontrar más información acerca de algunas
de las herramientas de auditoría disponibles y de cómo se usan.</p>
<p>Además de mirar el propio código, es buena idea leer la propia documentación
del paquete, e intentar instalarlo y usarlo.</p>
<p>Esto le debería permitir urdir maneras de subvertir el comportamiento típico
del programa.</p>
<h2>Informar de problemas</h2>
<p>Si descubre un problema en el paquete que está examinando, debería
informar de ello. Cuando informe de un fallo de seguridad, intente
proporcionar también un parche, para que los desarrolladores puedan
repararlo cuanto antes. No es necesario facilitar una muestra de
ataque (lo que se suele llamar un <em>exploit</em> o una <em>prueba de
concepto</em>), ya que el parche debería hablar por sí msimo. Suele
preferirse la inversión de tiempo en proporcionar un parche adecuado
que en facilitar un ataque con éxito que saque provecho del error.</p>
<p>Aquí tiene una lista con los pasos recomendados para cuando
encuentre un error de seguridad en Debian:</p>
<ol>
<li>Intente producir un parche para el error u obtener información
suficiente para que otros puedan determinar la existencia del fallo.
De forma ideal, cada fallo debería contener una solución para el
problema que se ha descubierto, y que se haya probado y verificado
que ciertamente corrige el problema.
<p>Si no tiene una solución para el problema, lo mejor será que dé los máximos
detalles sobre el ámbito del problema, la severidad de la incidencia y la
información adicional que haya recopilado sobre ella durante su
análisis.</p></li>
<li>En primer lugar, compruebe si el error de seguridad está presente
en la versión estable de Debian o si puede estar presente en otras
distribuciones o en la versión original.</li>
<li>Según los resultados de la comprobación anterior, informe del
incidente:
<ul>
<li>Al desarrollador original, a través del correo electrónico de
contacto para seguridad. Proporcione el análisis y el parche.</li>
<li>Al equipo de seguridad de Debian, si el error está presente
la versión publicada de Debian. El equipo de seguridad de Debian le
suele asignar un <a
href="$(HOME)/security/cve-compatibility">nombre CVE</a> a la
vulnerabilidad. El equipo de seguridad se coordinará con otras
distribuciones de Linux si fuese necesario y se pondrá en contacto
con el responsable del paquete en su nombre. Una cosa que podría
hacer usted es mandar también una copia del correo al responsable
del paquete. De todas formas, hágalo sólo cuando se trate de
vulnerabilidades de bajo riesgo (tiene más información abajo).</li>
<li>Si el error no está presente en la versión publicada de Debian
y la aplicación puede estar presente en otras distribuciones o
sistemas operativos, escriba a <a
href="https://www.lst.de/cgi-bin/mailman/listinfo/vendor-sec">vendor-sec</a>
(una lista de correo privada que la mayoría de distribuciones de
software libre utilizan para debatir sobre errores de seguridad). No
tiene que hacer esto si ya ha enviado el fallo al equipo de seguridad
de Debian, puesto que este equipo también seguirá los pasos de esta
lista.</li>
<li>Si el error <strong>no</strong> está presente en ninguna de las
versiones publicadas por Debian y está absolutamente seguro de que la
aplicación <strong>no</strong> forma parte de ninguna otra distribución
ni sistema operativo, informe de ello a través del sistema de
seguimiento de fallos.</li>
</ul></li>
<li>Una vez que la vulnerabilidad sea pública (por ejemplo, cuando el
equipo de seguridad de Debian o cualquier otro vendedor haya emitido
un aviso) se rellenará un informe de fallo con toda la información
relevante en el sistema de seguimiento de fallos de Debian para seguir
la pista de las incidencias de seguridad en las versiones no publicadas
de Debian (esto es, <em>sid</em> o <em>en pruebas</em>). Esto lo
suele hacer el propio equipo de seguridad. De todas formas, si viera
que no se ha producido este paso o si no va a avisar de esto al equipo
de seguridad, puede informar usted mismo. Asegúrese de que la etiqueta
del fallo es la adecuada (use la etiqueta <em>seguridad</em>) y de que
ha definido la prioridad apropiada (normalmente, <em>grave</em> o
superior). Asegúrese también de que el título del error incluye el <a
href="$(HOME)/security/cve-compatibility">nombre CVE</a> adecuado, si
es que se le ha asignado. De esta forma se le puede seguir la pista a
los errores de seguridad que se han corregido tanto en las versiones
publicadas como en las no publicadas de Debian.</li>
<li>Si lo desea, una vez que sea pública la incidencia, puede reenviar
esta información a listas de correo públicas de divulgación, como
<a href="http://lists.netsys.com/full-disclosure-charter.html">full-disclosure</a>
o
<a href="http://www.securityfocus.com/archive/1">Bugtraq</a>.</li>
</ol>
<p>Tenga en cuenta que estos pasos pueden variar según el riesgo
asociado con la vulnerabilidad que se encuentre. Tiene que valorar
el riesgo según:</p>
<ul>
<li>Se trate de una vulnerabilidad remota o local.</li>
<li>Las consecuencias del provecho que se pueda sacar de la
vulnerabilidad.</li>
<li>La popularidad y difusión del software que se vea afectado por la
vulnerabilidad.</li>
</ul>
<p>Se deben dar distintos pasos, por ejemplo, para informar de un
ataque local de enlaces simbólicos que sólo puedan aplicar los
usuarios autenticados y que sólo provea de una forma de dañar el
sistema que para informar de un desbordamiento remoto de buffer que
proporcione privilegios administrativos y esté presente en un
software popular y de gran difusión.</p>
<p>En la mayor parte de los casos, los errores de seguridad no se
deberían revelar hasta que se hayan corregido. Por tanto, <i>no</i>
informe de ellos por el <a href="http://bugs.debian.org/">sistema
estándar de seguimiento de fallos</a>. En su lugar, informe del
problema directamente al <a href="$(HOME)/security/">equipo de
seguridad</a>, que gestionará la publicación de un paquete actualizado
y, una vez corregido, informará de ello en el BTS.</p>
|