https://archive.mroczna-zaloga.org/ Paweł Goleń, blog - Zrzędzenie starego zgreda pl Serendipity - http://www.s9y.org/ Sat, 15 Mar 2025 22:15:28 GMT https://archive.mroczna-zaloga.org/templates/bulletproof/img/s9y_banner_small.png https://archive.mroczna-zaloga.org/ 100 21 https://archive.mroczna-zaloga.org/archives/1159-drop-vs-reject.html#c11240 https://archive.mroczna-zaloga.org/archives/1159-drop-vs-reject.html#comments https://archive.mroczna-zaloga.org/wfwcomment.php?cid=1159 nospam@example.com (Paweł Goleń) Tak :) Jeszcze przy FTP też szło odpytanie do identd. Jeśli był DROP na 113, to połączenie z usługą na początku miało taki "fajny" lag, do czasu, aż serwer zorientował się, że z identd to sobie raczej nie pogada. Sun, 09 Dec 2012 12:30:53 +0100 https://archive.mroczna-zaloga.org/archives/1159-guid.html#c11240 https://archive.mroczna-zaloga.org/archives/1159-drop-vs-reject.html#c11239 https://archive.mroczna-zaloga.org/archives/1159-drop-vs-reject.html#comments https://archive.mroczna-zaloga.org/wfwcomment.php?cid=1159 nospam@example.com (Piotr Kas) port 113 to usługa identd, serwery IRC zawsze sprawdzają przez niego z jakiego konta się ktoś łączy ;) ostatnio jego użycie zauważyłem również przez serwery SMTP, do detekcji z jakiego konta jest spam wysyłany Sun, 09 Dec 2012 12:12:03 +0100 https://archive.mroczna-zaloga.org/archives/1159-guid.html#c11239 https://archive.mroczna-zaloga.org/archives/1159-drop-vs-reject.html#c11223 https://archive.mroczna-zaloga.org/archives/1159-drop-vs-reject.html#comments https://archive.mroczna-zaloga.org/wfwcomment.php?cid=1159 nospam@example.com (Paweł Goleń) Tak, jeśli aplikacja musi gadać z zewnętrznymi, to proxy jest tutaj rozwiązaniem, pod warunkiem, że musi ona gadać w sposób, który da się puścić przez proxy. Ewentualnie - jeśli aplikacja pozwala na puszczenie ruchu przez proxy, bo są takie przypadki, że aplikacja ignoruje wszelkie sposoby jego ustawienia. Jeśli chodzi o Twój drugi pomysł - patrzenie w logi, to oczywiście jest to bardzo chwalebna koncepcja, ale trochę ciężka do praktycznego wykonania w przypadku duuuużej korporacji gdzie jest separation of duties i kompletnie kto inny zajmuje się aplikacją, zezwalaniem na stworzenie reguły na FW i faktycznym tworzeniem tej reguły :) Sat, 08 Dec 2012 09:54:17 +0100 https://archive.mroczna-zaloga.org/archives/1159-guid.html#c11223 https://archive.mroczna-zaloga.org/archives/1159-drop-vs-reject.html#c11221 https://archive.mroczna-zaloga.org/archives/1159-drop-vs-reject.html#comments https://archive.mroczna-zaloga.org/wfwcomment.php?cid=1159 nospam@example.com (XANi) Jeżeli app potrzebuje gadać z "zewnętrznymi" stronami lepszym rozwiązaniem jest postawienie proxy między aplikacją a internetem. Z Pozwala to na puszczanie konkretnych URLi a nie tylko "per IPek" (prócz SSLa, chociaż teoretycznie też się da ale wymaga dużo więcej grzebania), jest jedno centralne miejsce do debugu i ew. dziury w aplikacji mają ograniczony dostęp do zewnątrz Innym sposobem jest wstawienie przed każdym DROP regułki LOG z jakimś sensownym limitem i kontrolowanie co zwraca, docelowo na serwerze "wewnętrznym" nie powinno być w logu dużo. Ofc. na czymkolwiek wystawionym na zewnątrz będzie tona crapu ;] Sat, 08 Dec 2012 04:04:00 +0100 https://archive.mroczna-zaloga.org/archives/1159-guid.html#c11221 https://archive.mroczna-zaloga.org/archives/1159-drop-vs-reject.html#c11159 https://archive.mroczna-zaloga.org/archives/1159-drop-vs-reject.html#comments https://archive.mroczna-zaloga.org/wfwcomment.php?cid=1159 nospam@example.com (Paweł Goleń) Tak, ale to issuing CA ma w górę ścieżkę, która kończy się w zaufanym w przeglądarkach root, czyli efektywnie mogą wystawić sobie certyfikat dla dowolnego serwisu. A wspomniałem o tym tylko dlatego, że, o ile mnie pamięć nie myli, nie tak dawno jeszcze certyfikat był od "zewnętrznego dostawcy". Sam certyfikat dla Gmail jest dość nowy, certyfikat CA Google jest natomiast z 2009 roku. Sat, 08 Dec 2012 00:16:42 +0100 https://archive.mroczna-zaloga.org/archives/1159-guid.html#c11159 https://archive.mroczna-zaloga.org/archives/1159-drop-vs-reject.html#c11157 https://archive.mroczna-zaloga.org/archives/1159-drop-vs-reject.html#comments https://archive.mroczna-zaloga.org/wfwcomment.php?cid=1159 nospam@example.com (msu) Jeżeli chodzi natomiast o PKI i wystawianie certyfikatów przez Google, to Google posiada jedynie Issuing CA, które jest podpisane przez OU = Equifax Secure Certificate Authority, O = Equifax, C = US. Podobnie ma Microsoft, co jest opisane tutaj: http://blogs.technet.com/b/configmgrteam/archive/2009/08/13/recommended-white-paper-for-native-mode-customers-deploying-and-managing-pki-inside-microsoft-microsoft-it-showcase.aspx. Swoją drogą warto przeczytać, ciekawa lekcja dla tych, którzy chociaż raz wdrażali (lub niedługo będą wdrażać PKI). Pokazuje ewolucję koncepcji wykorzystania PKI na przestrzeni kilkunastu lat. Warto uczyć się na błędach i doświadczeniach innych. Fri, 07 Dec 2012 19:21:10 +0100 https://archive.mroczna-zaloga.org/archives/1159-guid.html#c11157 https://archive.mroczna-zaloga.org/archives/1159-drop-vs-reject.html#c11154 https://archive.mroczna-zaloga.org/archives/1159-drop-vs-reject.html#comments https://archive.mroczna-zaloga.org/wfwcomment.php?cid=1159 nospam@example.com (msu) Podobny objaw mieliśmy, jak w DMZcie próbowaliśmy skonfigurować jedną aplikację. Serwer miał otwarty tylko jeden port 443/tcp do serwera na backendzie (zgodnie z dokumentacją producenta, nie było innych wymogów odnośnie ruchu sieciowego) i nie miał ustawionych i otwartych portów do DNS. Jak przenosiło się go do innego VLANy (te dobrodziejstwa wirtualizacji) wszystko działało ok. W myśl zasady "ruch sieciowy prawdę Ci powie" zrobiliśmy snapshot, zainstalowaliśmy Wiresharka i porównaliśmy ruch. Nie było nic szczególnego oprócz odwołań do WPAD w celu lokalizacji Proxy i prób odwołania do adresów IP serwera z CRL. Co ciekawe nie pomagało nawet wpisanie w hosts adresów podstawionego serwera, który zawierał pobrane wcześniej CRLe w odpowiednich ścieżkach. Po przepuszczeniu DNS serwer odwołał się do DNS w celu lokalizacji CRL, przy próbie nawiązania połączenia http w celu pobrania CRL firewall zwrócił REJECT i konfiguracja powiodła się. Wcześniej nie można było poprawnie skonfigurować usługi, ponieważ z powodu timeout'u na DNS instalator stwierdzał, że konfigurowanie usługi trwało za długo, więc najprawdopodobniej coś poszło nie tak i wywalał błąd i nie był w stanie poprawnie dokończyć konfiguracji. Fri, 07 Dec 2012 19:14:20 +0100 https://archive.mroczna-zaloga.org/archives/1159-guid.html#c11154