jest bezpieczne NetNamedPipeBinding?

Question

Chciałbym wiedzieć, czy netNamedPipeBinding jest uważane za bezpieczne:

Z jednej strony NetNamedPipeBinding realizuje zabezpieczenia tylko na warstwie transportowej i używa NTLM (source), który nie jest już zalecane przez Microsoft (source)

Włączone z drugiej strony, potok nazwany nie jest dostępny z komputera zdalnego i nie ma możliwości podsłuchania konkretnej instancji otwartej rury używanej do przesyłania danych lub zapisywania do niej danych, chyba że można uzyskać uchwyt do konkretnej instancji .

Jest to powód, dla którego nie wiem, co myśleć o bezpieczeństwie tego rozwiązania.

Answer 1

Naprawdę nie zadawałeś właściwego pytania: nie jest możliwe podanie prawidłowej odpowiedzi boolowskiej we wszystkich okolicznościach. Zawsze należy oceniać bezpieczeństwo rozwiązania jako całości, identyfikując zagrożenia i modelując powiązane zagrożenia bezpieczeństwa.

Powiedział, że prawdą jest, że WCF NetNamedPipeBinding ma cechy bezpieczeństwa, które sprawia, że ​​nieco różni się od powiązań na podstawie protokołów sieciowych:

• W porównaniu do dowolnego protokołu sieciowego, NetNamedPipeBinding jest z natury znacznie bardziej zabezpieczony przed zagrożenia dla komunikacji przez połączenie transportowe. Zamiast bajtów transmitowanych przez sieć, w przypadku nazwanych potoków wiadomości są wymieniane za pośrednictwem mechanizmu obejmującego przekazywanie bajtów danych (za pośrednictwem interfejsów API systemu operacyjnego) do iz pamięci zarządzanej przez jądro systemu operacyjnego na jednej maszynie. Strumień wiadomości nie może być podsłuchiwany, z wyjątkiem atakującego, który ma już uprzywilejowany kod działający w trybie jądra (a jeśli taki atakujący jest już w majtkach systemu operacyjnego, prawdopodobnie już teraz może zrobić wszystko, co mu się podoba w procesie aplikacji). W konsekwencji WCF "Bezpieczeństwo transportu" is more or less irrelevant to the security of the message stream and should arguably often be disabled in configuration to avoid unnecessary runtime overhead.
• Mechanizm używany przez powiązanie nazwanego potoku do publikowania punktów końcowych usługi potencjalnym klientom jest również z natury bardziej bezpieczny niż protokoły sieciowe: opiera się na wymienionym obiekcie Shared Memory, a zatem jest niemożliwy do uzyskania dostępu z dowolnego komputera zdalnego.
• Nazwany potok używany do wymiany komunikatów ma nazwę GUID, która zmienia się przy każdym ponownym uruchomieniu serwera i jest dodatkowo chroniona przez listę ACL, która uniemożliwia otwarcie jej przez użytkownika zdalnego, nawet jeśli udało jej się w jakiś sposób wykryć bieżący identyfikator GUID nazwa potoku.

Z drugiej strony, jest oparta na obiekcie systemu operacyjnego dostęp za pośrednictwem interfejsu API, a nie na standardach publicznych dla komunikacji sieciowej, istnieją pewne specyficzne luk w zabezpieczeniach, które nie pojawiają się na powiązaniach sieciowych:

• Ataki "przysiadu" na serwer, w których procesowi innym niż zamierzony host usługi WCF uda się odsłuchać nazwaną potok. Określone powiązanie potoku w .NET 3.5 i wcześniejszych wersjach nie było zabezpieczone przed tą usterką z powodu błędu w liście ACL utworzonej przez powiązanie w celu zabezpieczenia potoku. .NET 4 w większości naprawił ten błąd.
• Nazwane potoki w systemie Windows mają wbudowany mechanizm obsługi nazwanych serwerów potoku podszywających się pod ich klientów. WCF NetNamedPipeBinding zawiera błąd, który w niektórych scenariuszach umożliwia serwerowi potoku (tj. Usług WCF) używanie poświadczeń systemu Windows klienta w celu takiego podszywania się, nawet jeśli powiązanie WCF po stronie klienta jest skonfigurowane tak, aby uniemożliwić podszywanie się.

Podsumowując, należy ocenić ogólne bezpieczeństwo aplikacji/systemu w świetle zagrożeń, które są dla Ciebie ważne, biorąc pod uwagę szczególne cechy różnych wiązań, które możesz wziąć pod uwagę. NetNamedPipeBinding często będzie najlepszym wyborem dla scenariuszy tej samej maszyny.