Help - Search - Members
Full Version: AYUDA
Kaspersky Lab Forum > Forum para usuarios hispanohablantes > Protección para usuarios domésticos
nachete75
Necesito que alguien me explique con claridad cómo se usa lo de Puerto Remoto y Local al crear reglas.Tengo el KIS 6.0 y todo me funciona bien, emule, azureus, etc...... pero me gustaría aprender a crear reglas. Por ejemplo, si quiero crear unas reglas para los puertos TCP 4000 y 4001, qué tengo qué poner:

- ¿Autorizar Entrante Y Saliente TCP? ¿O solo uno de ellos? unsure.gif
- Usar el ¿Puerto Local o Remoto? unsure.gif
No entiendo esos términos y he buscado en otros posts pero no he encontrado una explicación clara de esto.

Gracias, un saludo
RadarpSP
Primero bienvenido al foro.
Las conexiones entrantes son cuando tu equipo hace de servidor. Normalmente nunca hace un equipo doméstico de servidor. Con la excepcion de emule.
Por ejemplo si tu equipo es un servidor de páginas web necesitas abrir el puerto 80, si tu equipo es servidor de ftp necesitas el 21. Entonce sería para conexiones entrantes y el puerto local sería el 80 y 21, respectivamente. El remoto en este caso sería indiferente.

En el caso de un equipo que se conecta a una página web, se conecta al puerto remoto 80, por lo que tiene que permitir conexiones salientes al puerto 80. El puerto local suele ser uno aleatorio a partir del 1024.

Si quieres comenta el caso concreto para verlo.
Saludos
nachete75
A mi el emule, azureus me funcionan bien , pero tras leer mucho en este foro me he dado kuenta ke no keda klaro kuales son las reglas ke habria ke editar para el emule por ejemplo. Si utilizas las ke vienen por defecto hay problemas y tras mucho leer eso de poner dos reglas al final de blokear el resto, me decidí a poner Permitir todo Tcp y Udp, así me he evitado una komida de tarro tremenda.Kreo ke el KIS deberia hacer el firewall configurable más fácilmente o explikar un poko más este tema, porke es una magnifika suite.

Pero no akabo de entender por ké tantos problemas para abrir puertos

Las reglas ke vienen por defecto son las siguientes y ahí van mis preguntas.

.DNS Saliente UDP, puerto remoto 53

.Flujo entrante TCP y puerto local 4662 (en mi caso 85). esto me parece bien, un uniko puerto lokal de entrada para restringir la entrada y sin restringir en Remoto y puede así enviarse a kualkier remoto ¿no?

:Flujo saliente TCP y puerto remoto 4662 ( en mi caso 85). ¿qué sentido tiene marcar un puerto remoto específico?¿no sería mejor no marcar ninguno y así no restringir?¿ké pasa si nosotros dejamos ke salga por kualkier puerto lokal a kualkier puerto remoto?

.Las dos reglas siguientes de Posición en Cola, UDP, ¿por qué se autoriza tanto Entrante como Saliente en ambas, tanto para Puerto Local komo Remoto 4672 (1985 en el mio)?

.Para conectarse al Servidor, el Remoto 4661, vale.

. En la Fuente preguntando a servidores trae Entrante y Saliente UDP por puerto remoto 4665, ¿por qué entrante y saliente?¿ y por qué puerto remoto?

.Luego la Conexión al servidor, para routers y tal, Entrante TCP por el 4711

. Y luego lo del HTTP

Me gustaría me explikaras un poko esto, si digo muchas barbaridades y sobre todo saber: ¿con las reglas ke vienen por defecto debería funcionar todo bien?
Yo ahora tengo Permitir todo UDP y TCP y SEGURIDAD BAJA.
Sé ke podría poner SEGURIDAD ALTA y seguiría yendome bien el emule, ke ya te digo , me va bien,pero............. y ahí va otra cuestión:

Al poner SEGURIDAD ALTA, con las reglas ke vienen por defecto para el MESSENGER , éste NO ME KONECTA mientras ke en seguridad BAJA sí lo hace porke se permite todo salvo las normas kon ke tu restrinjas algo.

Y una última cosa:
si kiero abrir un puerto específico TCP y ke esa aplicación use sólo este puerto, ¿komo tendria ke crear la regla?
Es ke a mí lo de Permitir Todo al emule y al azureus por la jeta no me acaba de gustar. Una suite debería facilitar más las kosas. Tengo la sensación de ke kuando kreo una regla, no hace lo ke se pretende o ke interfiere kon otras reglas.

Muchas gracias y un saludo RadarpSP.

Espero no haber metido mucho la gamba unsure.gif
RadarpSP
Por mi experiencia con emule, la regla de permitir todo está bien. Se podría afinar algo, pero no abre ningun agujero de seguridad.
Solo permites todo, sobre todo saliente, para emule.exe. No para otras aplicaciones.

Muchos servidores cambian sus puertos por defecto para saltarse los bloqueos que ponen los proveedores de internet, así que cambian mucho.
Además, los firewall que he visto (Comodo, Outpost) su regla por defecto es permitir todo a emule.

Sobre el Messenger, y en general con todo, al principio es mejor dejar los firewall en modo entrenamiento y a partir de ahí vas creando las reglas.
Otros firewalls son más permisivos en las reglas por defecto, Kis es más restrictivo por eso a veces pregunta mucho.
Una vez que hayas configurado lo necesario para el messenger, puedes dejar la seguridad en alta.

Para abrir solo un puerto para una aplicacion, debes añadir la aplicacion en el firewall y luego editar las reglas. Es aconsejable que primero le permitas el dns a la aplicacion, ya que por seguridad es mejor deshabilitar el cliente dns de windows y entonces cada aplicacion necesita su regla dns.
Despues pones tu regla permitiendo ese puerto.
Al final crea dos reglas, bloqueando todo el tcp y otra todo udp. Marca que te registre el log para verlo, por si hace falta.
Si creas las reglas para las aplicaciones no se interfieren con las demás. El problema sería crear filtro de paquetes, que entonces afecta a todo.
Por cierto, las reglas de paquetes tienen prioridad sobre las de los programas. Es decir, que si en paquetes bloqueas el puerto 25, y lo permites en Outlook, no tendrás correo.
Saludos
nachete75
Muchas gracias RadarSP pero aún no tengo las cosas muy claras. A ver, para crear una regla para un puerto digamos el 4000, haría lo siguiente:

1. DNS Autorizar Saliente, puerto Remoto=53
2. Aqui está mi duda, Autorizar ¿Entrante y/0 Saliente?¿cual de ellos?
Y en puerto Local pondría el 4000.¿No?
3. Bloquear Resto TCP
4. Bloquear Resto UDP

Otra duda que me surge, ¿cuál es el problema de poner las dos reglas de Bloquear Resto TCP y UDP al final de las reglas del Emule que vienen por defecto en el KIS?Porque tras mucho leer, me di kuenta ke lo uniko ke no da problemas es lo de Permitir todo.

En cuanto a lo del modo de Aprendizaje, para el Messenger, ya lo probé, pero me salian tantas ventanas para Autorizar que al final no supe ké hacer y puse la seguridad en Baja.

Y la ultima kosita, me dices: "Sólo permites todo, sobre todo saliente, para emule.exe"
Realmente ¿no estamos permitiendo también Todo Entrante por cualquier puerto LOCAL nuestro?

Muchas Gracias por todo RadarpSP, y un saludo.
RadarpSP
QUOTE(nachete75 @ 26.07.2007 11:27)
Muchas gracias RadarSP pero aún no tengo las cosas muy claras. A ver, para crear una regla para un puerto digamos el 4000, haría lo siguiente:

1. DNS Autorizar Saliente, puerto Remoto=53
2. Aqui está mi duda, Autorizar ¿Entrante y/0 Saliente?¿cual de ellos?
Y en puerto Local pondría el 4000.¿No?
3. Bloquear Resto TCP
4. Bloquear Resto UDP

Otra duda que me surge, ¿cuál es el problema de poner las dos reglas de Bloquear Resto TCP y UDP al final de las reglas del Emule que vienen por defecto en el KIS?Porque tras mucho leer, me di kuenta ke lo uniko ke no da problemas es lo de Permitir todo.

En cuanto a lo del modo de Aprendizaje, para el Messenger, ya lo probé, pero me salian tantas ventanas para Autorizar que al final no supe ké hacer y puse la seguridad en Baja.

Y la ultima kosita, me dices: "Sólo permites todo, sobre todo saliente, para emule.exe"
Realmente ¿no estamos permitiendo también Todo Entrante por cualquier puerto LOCAL nuestro?

Muchas Gracias por todo RadarpSP, y un saludo.
[right][snapback]405221[/snapback][/right]

La regla del dns al puerto 53 es solo cuando una aplicion tuya salga al exterior.
Entonces tienes que permitir el puerto 53 remoto. Tu equipo saldra por uno cualquiera.
El tema del dns es porque es más seguro deshabilitar el cliente que trae microsoft. entonces para resolver los nombres, los programas necesitan conectarse directamente ellos al servidor dns. Por ello, se crea esa regla.
Por ejemplo, para el programa vnc cliente que se va a conectar a otro equipo de fuera.
Regla 1. Permitir a vncview.exe udp puerto remoto 53
Regla 2. Permitir a vncview.exe tcp al puerto remoto 3900 (puerto por defecto del servidor vnc. Puerto local cualquiera.
Regla 3. bloquear todo tcp (marcar que guarde logs)
regla 4 bloquear todo udp (marcar que guarde logs)

En el caso de que sea mi equipo el que acepte las conexiones:
En reglas de paquetes (no de aplicación)
Regla 1. Permitir puerto local 3900, remoto cualquiera, desde la ip remota (es mucho más seguro si sabemos la ip o su rango solo permitir el acceso de ese rango)

Para emule si se permite todo no tiene sentido crear reglas de bloquear todo, salvo para el caso de guardar los registros de trafico bloqueado.
Si permitimos todo, claro no tiene sentido lo de permitir todo lo entrante. Yo no me preocupaba y dejaba emule en permitir todo.

Si tengo tiempo vuelve a mirar lo del emule.

Si permites todo de entrada al emule, solo permites el tráfico de entrada destinada al emule. No para otros programas

Sobre el messenger las ventanas por la forma de se de Kis, que las reglas que crea por defecto son restrictivas. Yo no lo tengo y no puedo ver el tráfico que genera.

Saludos
nachete75
De nuevo gracias, pero RadarpSP, no acabo de entender todo esto wacko.gif .Me pregunto:, ¿cuál es entonces el problema de Permitir Todo a cualkier aplicación ke keramos? Al permitir todo ¿no dejamos agujeros de seguridad?

Con esto ya lo dejo, volveré a mirar todo esto con calma y dentro de unos días ya te contaré je,je.

Un saludo
RadarpSP
Un problema sería si a esa aplicación le encuetran un fallo y puede ser aprovechaod, por ejemplo.

Siempre es más seguro siendo restrictivo, y no permitiendo todo, pero también es más seguro no instalar el emule, o no navegar.

Saludos
This is a "lo-fi" version of our main content. To view the full version with more information, formatting and images, please click here.
Invision Power Board © 2001-2009 Invision Power Services, Inc.