Seguridad .htaccess

Seguridad

The safest way to access web pages in a certain directory is to create .htpasswd and .htaccess files. La manera más segura para acceder a páginas web en un directorio determinado es crear. Htpasswd y. Htaccess. The second file must reside inside directory you want to protect. El segundo archivo debe residir dentro del directorio que desea proteger. If you check HTML headers you'll see that no password is in it during login process. Si usted marca encabezados HTML verás que no hay ninguna contraseña en él durante el proceso de inicio de sesión.

Inicio de sesión seguro

Create empty files pas.txt and .htpasswd (you can choose location of .htpasswd file) in folder c:\wamp\bin\apache\apache2.2.6\bin, then open DOS window in the same folder. Crear archivos vacíos y pas.txt. Htpasswd (se puede elegir la ubicación de. Htpasswd archivo) en la carpeta C: \ wamp \ bin \ apache \ apache2.2.6 \ bin, a continuación, abra la ventana de DOS en la misma carpeta. Type Tipo

Código:

htpasswd pas.txt morgan

y escriba la contraseña de usuario que está creando.



Ahora tome mirar pas.txt archivo y usted verá este

Código:

morgan : $apr1$Yb......$2f/BA9bm/asswG1mWliH71 Morgan: $ apr1 $ Yb ......$ 2f/BA9bm/asswG1mWliH71

Word in blue is username and word in red is encrypted password you typed. Palabra en azul es nombre de usuario y palabra en rojo se cifra la contraseña que ha escrito. That row must be added to the .htpasswd file. Esa fila debe ser añadido a la. Htpasswd archivo. I don't recommend to work directly with .htpasswd file. Yo no recomiendo a trabajar directamente con. Htpasswd archivo. Repeat command several times for several user and they will be added to file pas.txt. Comando Repetir varias veces para el usuario y que varios se añadirá al archivo pas.txt.

Now create folder c:\wamp\www\secure\ and in it two files. Ahora crea la carpeta C: \ wamp \ www \ seguro \ y en ella dos archivos.

File: .htaccess De archivo:. Htaccess

Código:

AuthUserFile C: / wamp/bin/apache/apache2.2.6/bin/.htpasswd

AuthName "Protected area. Log in!" AuthName "área protegida. Entrar!"

AuthType Basic AuthType Basic

require valid-user Require valid-user 

Archivo: index.php

Código:

echo "Welcome to secure directory." ; ?>

Now point your browser to http://localhost/secure and you'll be asked to enter username and password you typed in DOS window. Ahora, dirija su navegador a http://localhost/secure y se le pedirá que introduzca nombre de usuario y contraseña que escribió en la ventana de DOS. After entering them you'll see the message from index.php file. Después de entrar en ellos verá el mensaje de archivo index.php.

Fuente[!url]

Security Open SSH

OpenSSH is developed with the same rigorous security process that the OpenBSD group is famous for. If you wish to report a security issue in OpenSSH, please contact the private developers list <openssh@openssh.com>.

For more information, see the OpenBSD Security page.

• OpenSSH prior to version 5.2 is vulnerable to the protocol weakness described in CPNI-957037 "Plaintext Recovery Attack Against SSH". However, based on the limited information available it appears that this described attack is infeasible in most circumstances. For more information please refer to the cbc.adv advisory and the OpenSSH 5.2 release notes.

• Portable OpenSSH 5.1 and newer are not vulnerable to the X11UseLocalhost=no hijacking attack on HP/UX (and possibly other systems) described in the OpenSSH 5.1 release notes.

• OpenSSH 5.0 and newer are not vulnerable to the X11 hijacking attack described in CVE-2008-1483 and the OpenSSH 5.0 release notes.

• OpenSSH 4.9 and newer do not execute ~/.ssh/rc for sessions whose command has been overridden with a sshd_config(5) ForceCommand directive. This was a documented, but unsafe behaviour (described in OpenSSH 4.9 release notes).

• OpenSSH 4.7 and newer do not fall back to creating trusted X11 authentication cookies when untrusted cookie generation fails (e.g. due to deliberate resource exhaustion), as described in the OpenSSH 4.7 release notes.

• OpenSSH 4.5 and newer fix a weakness in the privilege separation monitor that could be used to spoof successful authentication (described in the OpenSSH 4.5 release notes). Note that exploitation of this vulnerability would require an attacker to have already subverted the network-facing sshd(8) process, and no vulnerabilities permitting this are known.

• OpenSSH 4.4 and newer is not vulnerable to the unsafe signal handler vulnerability described in the OpenSSH 4.4 release notes.

• OpenSSH 4.4 and newer is not vulnerable to the SSH protocol 1 denial of service attack described in the OpenSSH 4.4 release notes.

• OpenSSH 4.3 and newer are not vulnerable to shell metacharacter expansion in scp(1) local-local and remote-remote copies (CVE-2006-0225), as described in the OpenSSH 4.3 release notes.

• OpenSSH 4.2 and newer does not allow delegation of GSSAPI credentials after authentication using a non-GSSAPI method as described in the OpenSSH 4.2 release notes.

• OpenSSH 4.2 and newer do not incorrectly activate GatewayPorts for dynamic forwardings (bug introduced in OpenSSH 4.0) as described in the OpenSSH 4.2 release notes.

• Portable OpenSSH 3.7.1p2 and newer are not vulnerable to "September 23, 2003: Portable OpenSSH Multiple PAM vulnerabilities", OpenSSH Security Advisory. (This issue does not affect OpenBSD versions)

• OpenSSH 3.7.1 and newer are not vulnerable to "September 16, 2003: OpenSSH Buffer Management bug", OpenSSH Security Advisory and CERT Advisory CA-2003-24.

• OpenSSH 3.4 and newer are not vulnerable to "June 26, 2002: OpenSSH Remote Challenge Vulnerability", OpenSSH Security Advisory.

• OpenSSH 3.2.1 and newer are not vulnerable to "April 21, 2002: Buffer overflow in AFS/Kerberos token passing code", OpenSSH Security Advisory: Versions prior to OpenSSH 3.2.1 allow privileged access if AFS/Kerberos token passing is compiled in and enabled (either in the system or in sshd_config).

• OpenSSH 3.1 and newer are not vulnerable to "March 7, 2002: Off-by-one error in the channel code", OpenSSH Security Advisory.

• OpenSSH 3.0.2 and newer do not allow users to pass environment variables to login(1) if UseLogin is enabled. The UseLogin option is disabled by default in all OpenSSH releases.

• OpenSSH 2.9.9 and newer are not vulnerable to "Sep 26, 2001: Weakness in OpenSSH's source IP based access control for SSH protocol v2 public key authentication.", OpenSSH Security Advisory.

• OpenSSH 2.9.9 and newer do not allow users to delete files named "cookies" if X11 forwarding is enabled. X11 forwarding is disabled by default.

• OpenSSH 2.3.1, a development snapshot which was never released, was vulnerable to "Feb 8, 2001: Authentication By-Pass Vulnerability in OpenSSH-2.3.1", OpenBSD Security Advisory. In protocol 2, authentication could be bypassed if public key authentication was permitted. This problem does exist only in OpenSSH 2.3.1, a three week internal development release. OpenSSH 2.3.0 and versions newer than 2.3.1 are not vulnerable to this problem.

• OpenSSH 2.3.0 and newer do not allow malicious servers to access the client's X11 display or ssh-agent. This problem has been fixed in OpenSSH 2.3.0.

• OpenSSH 2.3.0 and newer are not vulnerable to the "Feb 8, 2001: SSH-1 Daemon CRC32 Compensation Attack Detector Vulnerability", RAZOR Bindview Advisory CAN-2001-0144. A buffer overflow in the CRC32 compensation attack detector can lead to remote root access. This problem has been fixed in OpenSSH 2.3.0. However, versions prior to 2.3.0 are vulnerable.

• OpenSSH 2.2.0 and newer are not vulnerable to the "Feb 7, 2001: SSH-1 Session Key Recovery Vulnerability", CORE-SDI Advisory CORE-20010116. OpenSSH imposes limits on the connection rate, making the attack unfeasible. Additionally, the Bleichenbacher oracle has been closed completely since January 29, 2001.

• OpenSSH 2.1.1 and newer do not allow a remote attacker to execute arbitrary commands with the privileges of sshd if UseLogin is enabled by the administrator. UseLogin is disabled by default. This problem has been fixed in OpenSSH 2.1.1.

• OpenSSH was never vulnerable to the "Feb 5, 2001: SSH-1 Brute Force Password Vulnerability", Crimelabs Security Note CLABS200101.

• OpenSSH was not vulnerable to the RC4 cipher password cracking, replay, or modification attacks. At the time that OpenSSH was started, it was already known that SSH 1 used the RC4 stream cipher completely incorrectly, and thus RC4 support was removed.

• OpenSSH was not vulnerable to client forwarding attacks in unencrypted connections, since unencrypted connection support was removed at OpenSSH project start.

• OpenSSH was not vulnerable to IDEA-encryption algorithm attacks on the last packet, since the IDEA algorithm is not supported. The patent status of IDEA makes it unsuitable for inclusion in OpenSSH.

• OpenSSH does not treat localhost as exempt from host key checking, thus making it not vulnerable to the host key authentication bypass attack.

• OpenSSH was not vulnerable to uncontrollable X11 forwarding attacks because X11-forwarding is disabled by default and the user can de-permit it.

• OpenSSH has the SSH 1 protocol deficiency that might make an insertion attack difficult but possible. The CORE-SDI deattack mechanism is used to eliminate the common case. Ways of solving this problem are being investigated, since the SSH 1 protocol is not dead yet.

Fuente: http://www.openssh.com/security.html

Modificando .htaccess y evitando el error 404

###########################################################################

.Report Bugs BugDox Ethical

###########################################################################

.By ShadinessDark.Zero Bits

###########################################################################

Modificando .htaccess y evitando el error 404

Bueno primero que todo este manual va con el fin de que aprendan a editar los .htaccess de sus Web
Bueno he leído varios tutoriales y de cada uno fui agarrando alguito y pues me puse hacer este tutorial...

¿Que es .htaccess?

Bueno el archivo .htaccess es un fichero de TEXTO que apache usa para tener, una serie de directivas que obligan
A un servidor de pagina Web a actuar de una manerta tenermidad.

¿Que haremos en este tutorial?

No gran cosa aprenderemos a controlar el acceso de las carpetas de nuestras webs por ejemplo.
Www.WebDeEjemplo.com/images veríamos las imágenes de la Web o también podemos ocultar carpetas
Importantes a visitantes con mala intención.


¿De donde sacas el txt que darás como ejemplo?

Bueno el texto es casi que completamente mio simplemente que le agrego un codigo que es con la cual
Dara Acces desnegado a los que intenten mirar la carpeta donde guardas el .htaccess link

¿Acceso de carpetas?

Bueno con este code que les pondré aquí les dará un mensaje de error al visitante que entre a la carpeta donde has guardado el
.htaccess Ejemplo: Vamos al FTP metemos nuestra Web abrimos nuestra carpeta vamos a abrir nuestro Bloc de notas y ponemos el siguiente código:

#deny all access
deny from all

Ahora guardamos el archivo con la extracción .htaccess y lo subimos por FTP o Cpanel o por su upload recuerda que el txt tienen que subirlo
A la carpeta que no quiere que algún visitante la vea ya puede ser /images /tmp y otros...

¿Bloquear acceso a carpeta mediante IP?

Digamos que tenemos un visitante con mala intencion en nuestra web y lo hemos piyado quizás por los log de errores.
Y piyamos su ip y no queremos que vea alguna carpeta o alguna otra cosa.

Simplemente le agregamos al txt

#deny all access
deny from all
allow from 210.0.0.2

Y lo guardamos igual como el de arriba y lo subimos por ftp a la carpeta que quieren bloquear la ip donde sale allow from 210.0.0.2
Solo editen 210.0.0.2 y ponen la ip de el usuario que no quieren que vea la carpeta

¿Como bloqueamos el acceso a un archivo especifico?

simplemente le agregamos:


Order allow,deny
Deny from all

Solo editaran donde dice aquí el archivo.html hay pondrán el nombre de el archivo por ejemplo foro.php foro.html etc. ya Uds. sabrán...

Muchos diran bueno pero esto lo podemos hacer a mano con el FTP o por el Cpanel si pueden hacerlo simplemente cambiándole los permisos a los archivos
A 333 y asi los tienen seguro pero es más recomendado hacerlo manualmente

Bueno no es algo del otro mundo pero luego les traeré otros tutoriales en la revista que saldrá pronto saludos


Group's Ethical BugDoox

Team: V1rtu@l VIRu$ Bl@ck Team

PD. Si existe algun error corrijanme de los errores se aprende saludos

FUENTE<

________________________________________________

Evitando el error 404 By Zero Bits

Minitutorial de como evitar el error 404

Bueno este error es muy comun en las Paginas Webs, muchos Defacers por asi decirlo
se aprovechan y hacen de las suyas...

Ejemplo de error 404:
IMAGEN

Entren por FTP o el Panel del Host, y abran para modificar este fichero ".htaccess"

y agreguenle (no borren nada)

RewriteEngine On
ErrorDocument 404: Http://paginaquequieras.com/archivo.html


Aqui ("http://paginaquequieras.com/archivo.html") ponen la pagina que quieran o la suya misma....

Siempre que salga el error 404 ira al archivo que redireccionen.

Tambien sirven para otros errores:
ejemplo:

RewriteEngine On
ErrorDocument NUMERO_DEL_ERROR: Http://paginaquequieras.com/archivo.html

Saludos...

Autor: Zero Bits
Team: Pandoras Box Team
Contacto: Zero_Bits@GobiernoFederal.com

FUENTE<
Www.Ethical-security.co.cc

Evitando XSS y introduccion de codigos HTML By: ShadinessDark

Bueno con este simple codigo pueden evitar xss en su web y hay
Muchas personas que entran a las paginas webs y empiezan a ejecutar
Comandos en los buscadores o en su libro de visita ejemplo buscando
El xss



Bueno si les salta una ventanita repitiendoles el text digan estoy jodido.
Pero aqui les traigo un codigo hecho en php exelente para evitar xss
Y que las personas utilicen HTML en su web

function limpiar_tags($tags){ 
$tags = strip_tags($tags); 
$tags = stripslashes($tags); 
$tags = htmlentities($tags); 
return $tags; 
} 


limpiar_tags($variable);

Si no saben como usarlo solo avisenme y yo les explico con mucha calma

By: ShadinessDark
Att: Virtu@l Virus Bl@ck Team

Fuente: Www.ethical-security.co.cc

Como limpiar tu web de troyanos (backdoor)

No se sabe a ciencia cierta porqué algunas personas que se hacen llamar “hackers” contaminan páginas web con troyanos que infectan a las computadoras que visitan las páginas web.

Lo que si se sabe es que estas personas se dedican a robar información de miles y posiblemente millones de víctimas que pueden ser desde simples usuarios hasta empleados, funcionarios públicos de alto nivel, policías, militares, congresistas, banqueros, etc

Ultimamente hemos visto que algunos hackers han infectado algunas páginas web muy conocidas, pero técnicamente hablando no es una gran hazaña de hackers. (según los conocedores)

Los hackers logran introducir archivos Shell o backdoor que luego son accesados por estos mismos y toman el control del servidor, se dice que esto no es un gran logro técnicamente hablando por que no requiere muchos conocimientos técnicos y más bien es pura suerte.

Lógicamente el acceso que tienen los hackers a la web víctima es lenta y nunca conocen o pueden encontrar la contraseña del hosting (Ej. Cpanel/plesk) por qué esta está a otro nivel de seguridad, sin embargo si el administrador de la página usa una sola contraseña para todos sus login… está perdido ….. el hacker haciendo una búsqueda por la base de datos podrá conocer las contraseñas y modificar lo que desee.

¿Qué hacer?

* Las contraseñas en el servidor deben estar guardadas en MD5, esto le impide al hacker descubrirlas.
* No Usar las mismas contraseñas en el cpanel/plesk, correos y demás servicios.
* Cerrar inmediatamente las carpetas desprotegidas, quitarle los permisos 777, que es por donde logran meter los archivos troyanos.


¿Cómo desinfectar el servidor?

Para eliminar estos archivos depende del nivel del webmaster o el personal de sistemas. Hay dos recomendaciones.

- Opción 1, y tediosa es buscar con el programa FTP cada archivo sospechoso y eliminarlo, normalmente encontrarás más de uno en diferentes carpetas y con diferentes nombres. Casi siempre son archivos .php pero hemos visto que también pueden cambiar la extensión a .jpg o cualquier otro.

Además al darse cuenta que por seguridad se busca estos archivos los hackers han optado por encriptar los mismos para hacerlos supuestamente invisibles, pero igualmente se detectan.

- Opción 2 y más efectiva, conectarse mediante SSH y buscar/eliminar todos los archivos que contengan las cadenas "c99shell" ... por ejemplo... estas cadenas pueden variar según el programita que hayan metido en el hosting...

Es convenientes agregar un script que cada minuto busque archivos sospechosos y los elimine, o activar un antivirus para servidores de linux que haga esa tarea, de esta manera cada archivo que se suba al servidor será analizado y borrado en el acto.(recomendable)

Una vez limpio el sistema, es conveniente cambiar las contraseñas y cerrar las carpetas que quedaron abiertas con los permisos 777.

Si eres un webmaster y eres el único que sube archivo a tu web, ya sea blog o página comercial/personal, cambia los permisos y sube tus archivos por FTP, con eso ya está seguro tu hosting sobre este tema de seguridad.

Ahora recuerda que debes grabar cada IP que accesa a tu servicios, con estos registros dependiendo del daño se podrá hacer una denuncia policial.

Existen otros ataques a los servidores un poco más sofisticados que iremos tocando en otro artículo, por mientras hay que cuidarse de este tipo de infección.

Fuente:
http://blogs.deperu.com/blogueando/como-limpiar-tu-web-de-troyanos-backdoor

¿Cómo evitar ataques DDoS en el DNS?

Quienes estén utilizando últimamente los servicios de DNS Report habrán notado que el diagnóstico regresa ahora un error que en resumen dice que el servidor puede ser susceptible de sufrir/participar en un ataque DDoS (Distributed Denail of Service o denegación de servicio distribuido).

Un DDoS (Distributed Denial of Service) es una ampliación del ataque DoS, se efectúa con la instalación de varios agentes remotos en muchas computadoras que pueden estar localizadas en diferentes puntos del mundo. El atacante consigue coordinar esos agentes para así, de forma masiva, amplificar el volumen del saturación de información (flood), pudiendo darse casos de un ataque de cientos o millares de computadoras dirigido a una máquina o red objetivo. Esta técnica se ha revelado como una de las más eficaces y sencillas a la hora de colapsar servidores, la tecnología distribuida ha ido haciendo más sofisticada hasta el punto de otorgar poder de causar daños serios a personas con escaso conocimiento técnico.

La falla reportada por DNS Report dice así:

[u]«ERROR: One or more of your nameservers reports that it is an open DNS server. This usually means that anyone in the world can query it for domains it is not authoritative for (it is possible that the DNS server advertises that it does recursive lookups when it does not, but that shouldn't happen). This can cause an excessive load on your DNS server. Alos, it is strongly discouraged to have a DNS server be both authoritative for your domain and be recursive (even if it is not open), due to the potential for cache poisoning (with no recursion, there is no cache, and it is impossible to poison it). Alos, the bad guys could use your DNS server as part of an attack, by forging their IP address»
[/u]
Significa que el servidor DNS puede permitir a cualquiera realizar consultas recursivas. Si se trata de un DNS que se desea pueda ser consultado por cualquiera, como puede ser el caso del DNS de un ISP, esto es normal y esperado. Si se trata de un servidor que solo debe consultar la red local, o bien que se utiliza para propagar dominios hospedados localmente, si es conveniente tomar medidas al respecto.

Solución al problema: en el fichero /etc/named.conf se añade en la sección de opciones (options) una línea que defina la red, las redes o bien los ACL que tendrán permitido realizar todo tipo de consultas.

[code]options {
directory "/var/named";
dump-file "/var/named/data/cache_dump.db";
statistics-file "/var/named/data/named_stats.txt";
forwarders { 192.168.0.1; };
forward first;
allow-recursion { 127.0.0.1; 192.168.0.0/24; };
};[/code]

Lo anterior hace que solo 192.168.0.0/24 pueda realizar todo tipo de consultas en el DNS, ya sea para un nombre de dominio hospedado localmente y otros dominios resueltos en otros servidores (ejemplo: www.yahoo.com, www.google.com, www.linuxparatodos.net, etc). El resto del mundo solo podrá realizar consultas sobre los dominios hospedados localmente y que estén configurado para permitirlo.
[code]
options {
directory "/var/named";
dump-file "/var/named/data/cache_dump.db";
statistics-file "/var/named/data/named_stats.txt";
forwarders { 192.168.0.1; };
forward first;
allow-recursion { 127.0.0.1; 192.168.0.0/24; };
};

zone "." IN {
type hint;
file "named.ca";
};

zone "miredlocal" {
type master;
file "miredlocal.zone";
allow-update { none; };
allow-query { 192.168.0.0/24; };
allow-transfer { 192.168.0.2; };
};

zone "midominio.com" {
type master;
file "midominio.com.zone";
allow-update { none; };
allow-transfer { 200.76.185.252; 200.76.185.251; };
};[/code]

Una configuración como la anterior hace lo siguiente:

*

Red Local: cualquier tipo de consulta hacia dominios externos y locales (es decir, www.yahoo.com, www.google.com, linuxparatodos.net, además de midominio.com).
*

Resto del mundo: solo puede hacer consultas para la zona de midominio.com

De este modo se impide que haya consultas recursivas y con esto impedir la posibilidad de sufrir/participar de un ataque DDoS.

Fuente:[url=http://www.linuxparatodos.net/portal/article.php?story=20060316153700459]http://www.linuxparatodos.net/portal/article.php?story=20060316153700459[/url]

Introducción a la seguridad de Servidores Web

Introducción a la seguridad de Servidores Web

0. Introducción

Saludos, Este tutorial de comienzo de la zine ah sido escrita por Zero Bits & ShadinessDark sobre Seguridad Web. En este comienzo le daremos buenos tips y consejos para su seguridad, “paper acto para empresas por así decirlo”.

¿Por qué para empresas?

Como veras, la mayoría de las personas que reciben ataques y su informaciones son muy delicada son las empresas, yo eh tenido amigos que me cuentan que muchos WEBMASTERS, programan y le ponen su seguridad una sola vez y la sacan al mundo, sin actualizarlo diario, guardas respaldos y mejorar su seguridad cada dia. QUE ES ALGO MUY MALO.

1. La Información

Lo primero que tienes que tener en cuentas es que todos los servidores, así sea de quien sea, no son 100% seguros, ¿Cómo es eso?, SI, todo servidor por lo menos tiene una Vulnerabilidad.

Pero, para evitar que por culpa de esa vulnerabilidad venga un atacante, borre todo y no tengamos tendremos que:

- Tener respaldos:

Los respaldos son muy importantes por si nos borran información, ya que con tener la copia de seguridad (Backup) de tu web, pondrás montarla y estar tranquilo.

Por lo menos, cada dos días guarden copias de seguridad.

- Testeo de Servers

Analicen sus servidores en busca de ficheros desconocidos, vulnerabilidad, analicen sus puertos, etc.

- Al tanto de nuevas vulnerabilidades

Por lo general los atacantes, atacan webs con vulnerabilidades nuevas que han salidos, por ejemplo: XSS (Cross Site Scripting), Inyección SQL (Muy vistas), RFI (Remote File Inclusión), LFI (Local File Inclusión) entre otras. Por eso tienes que estar al tanto de esas vulnerabilidades y taparla.

- Buena Programación

Las vulnerabilidades se deben a la mala programación del webmaster, por eso siempre revisar tus programas a ver si tiene algún BUG.

- Actualicen
Siempre mantengan actualizado sus servidores, ya que se puede descubrir vulnerabilidades en una versión anterior y han salidos nuevas sin ese problema.

2. Los Empleados

Muchos de los ataques a empresas, no solo por vulnerabilidades webs, sino también en las computadores de sus empleados.

¿Cómo es eso? Los empleados de cualquier empresa teniendo computadoras con conexión a Internet, navegan todos en la red, y la mayoría hace esto:

- Chatea, ya sea en su MSN o cualquier otro medio.
- Revisan su mail
- Descargan Música
- Abren sus Facebooks, Twitter, HI5, etc..
- Revisan sus cuentas bancarias
- Ven Noticias

¿Por que es peligroso esto?, pueden que estén bajando PowerPoints, imágenes, archivos o spam de su correo, bajan música en la red, el problema es esto, bajan lo que creen ver, pero sin saber que es en realidad, Bueno un amigo de el no le va a mandar un malware a tu empleado, pero ya que la gente manda emails son COPIA OCULTA, sin saber que dejaron sus emails, aquí es donde llegan los spammers y mandan spam ya sea con malwares o publicidad.

Peligroso también es bajar música ya que hay softwares maliciosos, que se pueden hacerse para por una canción, tu empleado lo ejecuta y tienes un SOFTWARE ESPIA en su computadora, con la capacidad de controlarla y también llegar a controlar TODAS las Computadoras.

Una forma de evitar esto es tener buenos antivirus, que estén activados y antes de abrir un archivo, avise que es malicioso.

Autor: Zero Bits
Zine: White Shadow
Mail: Zero_Bits@GobiernoFederal.com
Site: BuGDoX.ORG - E-R00T.ORG - Ilegalintrusion.NET

Fuente:
http://ethical-security.co.cc/Forum/index.php?board=41.0