Little Snitch: Чи обмежує адресу / порт для програми відключення запитів на майбутнє з'єднання?

Я завантажив пробну версію Little Snitch .

Після встановлення, коли мені запропоновано запити на з'єднання, у мене є можливість дозволити або заборонити з'єднання через "Будь-яке з'єднання" або "Тільки" певне з'єднання.

Якщо я виберу " Тільки назавжди ", я припускаю, що правило не дозволить додатку підключатися до іншої адреси / порту.

Але якщо програма хоче підключитися до іншої адреси / порту - мені буде запропоновано встановити нове правило для цієї конкретної адреси / порту - чи перше правило фактично блокує всі майбутні запити Little Snitch?

Що стосується вищезазначеного питання, чи відрізняється поведінка між Дозволити та Заборонити ? Наприклад:

Якщо я дозволю ТОЛЬКО певну адресу І порт - чи відключить він підказки для всіх майбутніх варіантів адреси та / або порту ?
Якщо я ЗАБОРУЮТЬ ТІЛЬКИ певну адресу І порт - чи відключить він підказки для всіх майбутніх варіантів адреси та / або порту ?

Я припускаю, що (2) вище просто заперечуватиме цю конкретну комбінацію - а як щодо обмеження надбавки, як у (1)?

macos network firewall

— Зимові прапори
джерело

Це булева логіка. Ваш вибір дозволяють або забороняють [звичайно]. Тоді ваші оператори - "хто" і "що". Ви можете встановити "хто", "що" або "хто ТА що" або "хто АБО що". Посилання [для повного пояснення про зайві потреби] en.wikipedia.org/wiki/Boolean_algebra

— Tetsujin

@Tetsujin Я все ще не дуже розумію, якщо дозвіл лише XYZ:80 назавжди запобіжить спонуканню LS, якщо програма може дійти ZYX:443. Я кілька разів читав вашу відповідь і намагався розібратися, перевстановлюючись, щоб очистити кешовані файли завантаження LS ... Це насправді не булева логіка, а чи LS запропонує мені оновити свої правила, коли додаток робить запит.

— Winterflags

Оскільки це логічна логіка, якщо я дозволю лише певну комбінацію - мені здається, що мені підказують, що більше не буде зроблено підказок, якщо дійсно LS зневажає цей параметр. Але те, що я дійсно хочу зробити, - це обробляти кожний унікальний запит правила, який він робить.

— Winterflags

Якщо припустимо, що у ваших префіксах LS встановлено значення "якщо жодне правило вже не встановлено, запитайте", який є за замовчуванням, тоді [я можу це зробити лише в псевдо-коді] ... якщо (my.app && xyz.com && 443) заперечувати; ще запитати; заперечував би лише в тому випадку, якщо всі три умови будуть дотримані, інакше він попросить. Я все ще вважаю, що вам слід починати зверху вниз, а не знизу вгору. Ви створюєте набір правил, який вас в майбутньому повністю заплутає.

— Tetsujin

Якщо натиснути Заборонити на опублікованому вами зображенні, більше не з’являтиметься подальше сповіщення [і в зв’язку буде відмовлено] для ігор, які намагаються підключитися до (static.gc.apple.com AND порт 443), а не для (static.gc .apple.com АБО порт 443).

Будь-які та всі інші спроби підключення будуть позначені прапорцями - наприклад, підключення до static.gc.apple.com на порту 442 буде позначено прапором, або підключення до notstatic.gc.apple.com на пошті 443 буде позначено.

Наступного разу, коли гра буде запущена, ваш попередній заперечення знову буде позначений вашою увагою, оскільки ви лише відмовляли їй, поки не Вийдете.

Примітка.
Якщо натиснути static.gc.apple.com у рядку вище, ви можете розширити домен, який ви хочете заблокувати, хоча слід сказати, що блокування пристроїв і служб Apple [ігровий сервіс Apple] від підключення до Apple насправді не буде хорошим кроком, довгостроковий.
Загалом, Little Snitch можна використовувати для блокування будь-якого або всіх підключень для будь-якого додатка чи послуги - як точний інструмент, так і кувалда!
Її слід використовувати обережно.

— Тецуджин
джерело

Дякую! Крім того , я повинен запитати, що якщо я дозволяв тільки static.gc.apple.com AND port 443 - буде що блок майбутнього запит запитує для цього додатка і / або адреса? Моя мета тут мати чіткий контроль, так що я не хочу , щоб дозволити тільки обмеження , щоб запобігти майбутнім запити.

— Winterflags

imo, це залежить від вашої кінцевої мети, особливо з точки зору підключення Apple. Якщо припустити, що ви вважаєте, що Apple як сутність є довірливим доменом (якщо це не так, то ми всі в біді;), то, ймовірно, має сенс спочатку дозволити будь-якому додатку безкоштовно керувати над доменом 17.xxx, який є повністю Apple. Маленький Snitch також дуже добре знає, хто є хто в доменах b ig, так що ви можете просто дозволити "будь-який" до apple.com, iCloud.com тощо, і він розібрає фактичні мережі з цього. Apple також володіє частиною домену 2.xxx. [продовження ...]

— Tetsujin

[... продовження] Як тільки це буде зроблено, то, як і будь-який брандмауер, відключіться від цього, а не намагайтеся працювати вгору від кожного крихітного піддомену / послуги

— Tetsujin

Вибачте, я мав би бути більш зрозумілим - скріншот - це щось, що я схопив з Інтернету, і моє запитання не стосується конкретно служб Apple :) Моє запитання більше про природу логіки правил та підказок.

— Winterflags

Гаразд, моє вище "зверху вниз" все ще застосовується - вирішіть, що ви хочете дозволити, а не заперечувати спочатку. Окремі додатки, які ви хочете запобігти "телефоненню додому", тоді встановіть для них конкретні набори правил. LS настільки деталізований, як ви коли-небудь могли захотіти .... наприклад, дозвольте "всім" підключитися до xyz.com, а потім заборонити foobar.app від підключення ТОЛЬКО xyz.com на порт 21. Одне з переваг LS порівняно з корпоративним брандмауер, це може визначити пріоритет для вас правила

— Tetsujin