Little Snitch: ¿La restricción de dirección/puerto para una aplicación deshabilita futuras solicitudes de conexión?

He descargado la versión de prueba de Little Snitch .

Después de la instalación, cuando se me solicitan solicitudes de conexión, tengo la opción de permitir o denegar la conexión a través de "Cualquier conexión" o "Solo" una conexión específica.

ingrese la descripción de la imagen aquí

Si selecciono " Solo para siempre ", asumo que la regla evitará que la aplicación se conecte a otra dirección/puerto.

Pero si la aplicación quiere conectarse a otra dirección/puerto, ¿se me pedirá que establezca una nueva regla para esa dirección/puerto específico, o la primera regla bloqueará todas las futuras solicitudes de Little Snitch?

Con respecto a la pregunta anterior, ¿el comportamiento difiere entre Permitir y Denegar ? P.ej:

  1. Si permito SOLAMENTE una determinada dirección Y puerto , ¿deshabilitará las solicitudes para todas las variantes futuras de dirección y/o puerto ?
  2. Si rechazo SOLO una determinada dirección Y puerto , ¿deshabilitará las solicitudes para todas las variantes futuras de dirección y/o puerto ?

Supongo que (2) anterior simplemente negará esa combinación específica, pero ¿qué pasa con la restricción de la asignación como en (1)?

Es lógica booleana. Sus opciones son permitir o denegar [por supuesto]. Sus operadores son entonces 'quién' y 'qué'. Puede establecer 'quién', 'qué' o 'quién Y qué' o 'quién O qué'. Ref [para la explicación completa de la exageración] en.wikipedia.org/wiki/Boolean_algebra
@Tetsujin Todavía no entiendo si permitir solo XYZ:80 para siempre evitará que LS pregunte si la aplicación puede llegar a ZYX:443. Leí su respuesta varias veces y traté de resolverlo, mientras reinstalaba para borrar los cachés de arranque de LS... No es realmente la lógica booleana, es si LS me pedirá que actualice mis reglas cuando la aplicación haga una solicitud.
Dado que es lógica booleana, si solo permito una combinación específica, parece sugerirme que no se realizarán más indicaciones, si es que LS desprecia esa configuración. Pero lo que realmente quiero hacer es manejar cada solicitud de regla única que hace.
Suponiendo que sus preferencias de LS estén configuradas en 'si no hay una regla ya establecida, pregunte', que es la predeterminada, entonces [solo puedo hacer esto en pseudocódigo]... if(my.app && xyz.com && 443) deny; si no pregunta; denegaría solo si se cumplen las tres condiciones; de lo contrario, preguntaría. Sigo siendo de la opinión de que deberías empezar de arriba hacia abajo, no de abajo hacia arriba. Estás creando un conjunto de reglas que te confundirá por completo en el futuro, de lo contrario.

Respuestas (1)

Si hace clic en Denegar en la imagen que publicó, no se mostrarán más notificaciones [y se denegará la conexión] para los jugadores que intentan conectarse a (static.gc.apple.com Y puerto 443), no para (static.gc .apple.com O puerto 443).

Se marcarán todos los demás intentos de conexión; por ejemplo, se marcará una conexión a static.gc.apple.com en el puerto 442, o se marcará una conexión a notstatic.gc.apple.com en la publicación 443.

La próxima vez que se inicie el juego, su denegación anterior se marcará nuevamente para su atención, ya que solo la denegó hasta Salir.

Nota:
si hace clic en static.gc.apple.com en la línea anterior, puede ampliar el dominio que desea bloquear, aunque debe decirse que bloquear los dispositivos y servicios de Apple [gamed es un servicio de Apple] para que no se conecten a Apple realmente no va a ser un buen movimiento a largo plazo.
En términos generales, Little Snitch se puede usar para bloquear cualquiera o todas las conexiones para cualquier aplicación o servicio, ¡ya sea como una herramienta de precisión o como un mazo!
Debe usarse con cuidado.

¡Gracias! Además, debo preguntar, ¿qué pasa si solo PERMITO ? ¿ Bloqueará eso las solicitudes futuras para esa aplicación y/o dirección? Mi objetivo aquí es tener un control granular, por lo que no quiero una restricción de permitir solo para evitar avisos futuros. static.gc.apple.com AND port 443
En mi opinión, depende de su objetivo final, especialmente en términos de conectividad de Apple. Suponiendo que considere que Apple como entidad es un dominio confiable (si no lo es, entonces todos estamos en problemas;) entonces probablemente tenga más sentido permitir primero que cualquier aplicación reine libremente sobre el dominio 17.xxx, que es íntegramente Apple. Little Snitch también es bastante bueno para saber 'quién es quién' en los grandes dominios, por lo que simplemente puede permitir 'cualquiera' en apple.com, iCloud.com, etc. y resolverá las redes reales a partir de eso. Apple también posee una parte del dominio 2.xxx. [continuación...]
[...continuación] Una vez hecho esto, al igual que con cualquier firewall, perfeccione a partir de eso, en lugar de intentar trabajar hacia arriba desde cada pequeño subdominio/servicio.
Lo siento, debería haber sido más claro: la captura de pantalla es solo algo que tomé de la web y mi pregunta no se relaciona específicamente con los servicios de Apple :) Mi pregunta es más sobre la naturaleza de la lógica de la regla y las indicaciones.
De acuerdo, entonces mi 'arriba hacia abajo' anterior aún se aplica: decida qué desea permitir en lugar de negar primero. Las aplicaciones individuales que desea evitar que "llamen a casa" luego establezca conjuntos de reglas específicas para ellas. LS es tan granular como podría desear.... por ejemplo, permita que 'todos' se conecten a xyz.com y luego niegue que foobar.app se conecte SÓLO a xyz.com en el puerto 21. Una de las ventajas de LS en comparación con una empresa cortafuegos es que puede averiguar la prioridad de la regla para usted
Little Snitch: ¿La restricción de dirección/puerto para una aplicación deshabilita futuras solicitudes de conexión?
RespuestasAquíPolítica de privacidad1y, 0v