Category: ISA/TMG

Ma egy ISA2004 szervert kellett telepítenem távolról. Nincs ebben semmi különös, csináltam már párszor. Az oprendszert a kollégák már rárakták, nekem csak állítgatnom kellett, illetve a tűzfal szoftvert felugrasztanom. Hiába távolról érem el, a szoftver okos, telepítés során az IP címemet helyből berakja a Remote Administration Group-ba, így gond nélkül végig tudom nyomni a telepítést, sőt a konfigurálást is.

Most viszont valami szellem megzavarhatta a folyamatot – egyszercsak megszűnt az RDP kapcsolat a szerverrel. Olyannyira megszűnt, hogy nem is tudtam visszakapcsolódni. Nem öröm, de itt van az ILO, majd megnézzük, mi van. Semmi. Minden remekül működik a gépen, a telepítés lefutott, a tűzfal működik. Megnéztem, az IP címem bent volt a megfelelő csoportban. Csak éppen továbbra sem értem el a gépet. A távoli hozzáférés engedélyezve volt, szabály nem tiltotta az RDP-t.
Átnéztem az ISA network beállításait, a routing táblát, a hálókártyák IP beállításait – minden rendben volt.
Nosza, nézzük a logot. Igen, ott vigyorgott benne, hogy a szerver lepattintja a 3389-re küldött kéréseimet. Indoklásként csak ennyit mondott:
0xC0040017 FWX_E_TCP_NOT_SYN_PACKET_DROPPED.

Google.

A non-SYN packet was dropped because it was sent by a source that does not have an established connection with the ISA Server computer.

Mivaan? Elolvastam néhányszor, de nem lettem okosabb.

Végül kínomban kipróbáltam, hogy felvettem a csoportba egy másik gépet, majd arról léptem be, terminál kliensből. És innen sikerült, vissza tudtam lépni az eredeti, telepítési sessionba. Ott pedig az ún. ‘Oké’ képernyő fogadott, az a képernyő, ahol az ember nyugtázza, hogy igen, megtörtént a telepítés.
Leokéztam.
Onnantól kezdve be tudtam lépni az eredeti gépemről is.

Hosszú percekig csak néztem magam elé bambán.

Egyik ügyfelünk most hétvégén tervszerű leállást hajt végre, így lehetőségünk van egy csomó régóta halasztott munkát elvégezni. Többek között jó ideje érik a tűzfaluk lecserélése.
A következőképpen terveztük: én offline összerakom az új vason a cuccot, aztán egyszerűen kidobjuk a régit, berakjuk az újat és mindenki örülni fog. Apró kihívás, hogy más a hardver (a régi 32bites procival ment, az új egy 64 bites Opteron), más az oprencer (a régi Windows2000/32, az új Windows2003R2/64) és persze más a szoftver is (ISA2004Sp1->Isa2004Sp2). De azért működjön ugyanúgy.
Mindazonáltal a feladat nem megoldhatatlan. Igaz, hogy magyar nyelvű 32 bites Windows telepítőcédét kaptam, de szerencsére telepítő médiánk nekünk voltak, megfelelő licenszkulcsai meg az ügyfélnek.
Három napig az általam eddig ismeretlen tűzfalat tanulmányoztam. Leszedtem mindent xml/txt fájlokba – és természetesen kijegyzeltem mindent spirálfüzetbe. Kisebb novella méretű anyag gyűlt össze. (Huszonvalahány subnet, VPN terminálás, szabályhegyek – nem igazán egyszerű a jószág.) A következő nap azzal telt, hogy felraktam az oprendszert és előkészítettem mindent az ISA szervernek. Végül ma jött el a nagy nap.
Ahhoz képest, hogy mennyire kényelmesen ágyaztam meg a tűzfal szoftvernek, őkényessége rövid, gyors, de határozott üzenettel közölte, hogy menjek a fenébe – erre a gépre, ha beledöglök sem fogom tudni feltelepíteni. A miértet viszont nem igazán részletezte.
Ránézésre lehetett egy csomó baja: a processzor 64 bites, az oprendszer R2/64, az ISA ellenben csak standard… A legegyszerűbb ilyenkor megnézni a hivatalos adatokat. Nos, egy szó sincs arról, hogy ne futna R2-vel, illetve 64 bites oprendszerrel. A biztonság kedvéért átnéztem a Shinder könyvet, ott se tér ki rá a hapi. Hívtam a TAM-unkat, de éppen olyan helyen volt, ahol nem vette fel a telefont. Bedobtam egy szösszenetet Shinder bácsi fórumába, majd rácsörögtem GT-re, hátha ő látott már ilyet – de nem. Mindketten nekiálltunk guglizni, végül kaptam tőle egy linket. Nem lehet azt mondani, hogy túlzottan bőbeszédű lenne az írás, de a lényeg benne van: semmilyen ISA nem fut 64 bites oprenceren. Aláírás: XY ISA MVP.
Érted, semmilyen. A frissen kijött ISA2006 sem.
Azért ez elég durva.
Felködlött előttem, milyen remek pofozkodás lesz ebből. Az ügyfél nyilván azt fogja reklamálni, miért nem szóltunk neki, hogy ne vegyen ilyen hardvert? Mi meg… mondjuk azt, hogy mi sem tudtuk? Baromira ciki. És nem csak az a durva, hogy így nem lesz a hétvégén csere – sokkal durvább, hogy mit csináljanak most a méregdrágán vett új hardverrel?
Mentsük a veszett fejsze nyelét. Fel lehet-e rakni 64 bites processzorral felvértezett gépre 32 bites Windows Server oprendszert? A franc se tudja. Talán a Gugli. Nem, ő se igazán. Még talán ez a bejegyzés nyújtotta a legvérmesebb reményeket – mintha az AMD procikra felmenne, csak az Intelekre nem…
Itt álltam, amikor visszahívott a TAM-unk. Rövid idő alatt sikerült mindent tisztáznunk.
Hogy te legközelebb ne járj ilyen hülyén, tömören leírom a lényeget:

• Jelenleg semmilyen ISA (2000/2004/2006, ill standard/enterprise) nem képes futni 64 bites operációs rendszeren.
• x64 architektúrára lehet telepíteni 32 bites Windows Server operációs rendszert – azaz AMD Opteronra igen, Intel Itaniumra nem.

Ez azért valahol megnyugtató. Nem az, hogy az ISA nem fut 64 biten, az valahol szégyen – a jó hír az, hogy az ügyfelünk csak a szervízhétvégét bukta be. Meg mi sem veszítettünk olyan nagyot az arcunkból.

Tavaly ősszel jött egy hirtelen riasztás. Egyik ügyfelünknél rendszerfrissítések felrakása után meghülyült az ISA2000 szerver. Nem is akárhogyan: a jó öreg LSASS ablakot dobálta fel és a BRC (Big Red Counter) lenullázódása után újraindult.

Első lépésben nyilván kilőttük rá a teljes víruskereső, spyware kereső és ad removal készletünket. Azt mondanom sem kell, hogy a gép naprakészen patchelt volt, a víruskeresője friss adatbázissal bírt. Eredmény semmi. Akkoriban írtam a Technet/Security listára is – nagyon szívesen belinkelném a szálat, de a lista kereső része egy kalap szar. Használható választ akkor nem kaptam, csak egy gyorsolvasó kolléga bosszantott a ‘vírusod van, haver‘ válasszal. (Harmath Zoli is próbálkozott egy darabig, de hamar kiszállt.)

Első körben arra tippeltünk, hogy van a belső hálón egy valamilyen fertőzött gép és valahogyan az teríti le a szervert. Ennek persze ellentmond az, hogy a szerver fullra foltozott, tehát nem lenne szabad érzékenynek lennie erre a hibára. De nem volt jobb ötletünk. Nosza, tegyük ellenállóvá az ISÁ-t. De hogyan? Packetfiltert nem tudunk a belső lábára tenni. Akkor? A mélypontot egy kolléga megjegyzése jelentette: tegyünk fel egy Zonealarmot, hogy megvédje az ISÁ-t.

Végül ‘vak tyúk is talál szemet‘ alapon lekapcsoltuk a víruskergetőt és megszűnt az újraindulgatás. A későbbi finomítások során kiderült, hogy a víruskereső (NOD32) tkp. jó,de az IMON modulja (HTTP scan) nem bírja elviselni az ISÁ-t. (Mindkettő webproxy akart lenni, csak más szinten.)

Jó. Hogyan tovább?

Kolléga levelezésbe kezdett a forgalmazóval és – mint utólag kiderült -némi félreértés után arra jutottak, hogy frissíteni kell ISA2004-re, azzal már remekül megy az IMON modul. A frissítés megtörtént, IMON felugrott, LSASS ablak kussban maradt, hurrá.

Három nap múlva jött a visszajelzés, hogy az ISA időnként váratlanul betonkeményre fagy. Kolléga rutinból kikapcsolta az IMON modult, a fagyások eltűntek. Wazzup?

Ekkor csináltuk meg azt, amit már rögtön az elején meg kellett volna: összehoztunk egy találkozót az ügyfél, az üzemeltető és a forgalmazó között, a tetthelyen. Itt ült ki a döbbenet a forgalmazó arcára, ő ugyanis végig abban a hitben élt, hogy az IMON modult a klienseken kapcsoltuk be, ISA firewall client mellett. Erre gondolt, amikor azt mondta, hogy nincs probléma, kompatibilis mint állat: internetböngészés közben figyeli a HTTP forgalmat a gépen és a gyanús tartalmakat kikapkodja jól. A program ISA szerveren ellenjavallt.

A következő döbbenet az volt, hogy az ISA2004 szerverenjól működik az IMON: azaz nemcsak arra képes, hogy explorerből böngészve figyelje a HTTP forgalmat,hanem az ISA webproxyját is képes volt ellenőrizni: amikor vírusos tartalmat akartunk letölteni (Eicar), akkor a kliens olyan üzenetet kapott vissza a proxytól, hogy szabály tiltja a hozzáférést, miközben a NOD32 logjában láttuk, hogy az IMON akciózott. Igaz, a csoda nem tartott sokáig. A teszt során egész pontosan fél óráig, aztán elszállt a Firewall service és nem is lehetett újraindítani, csak szerver restarttal.

Tanulság? Nincs. Csak egy újabb retkes hiba, amely nem akkor jelentkezik, amikor csinálunk valamit, hanem azután, persze sztochasztikus kivárással.

Imádom ezt a szakmát.

Ha nem számolom a csikó korabeli nekilendüléseket, életem legelőkészítettlenebb munkáját tudom magam mögött. Minimális helyismeret és ezzel összemérhető mennyiségű előkészítés után kellett egy nehéz ügyfélnél lábon upgradelni egy ISA2000 szervert 2004-re. Az hagyján, hogy ilyet eddig még tesztként sem csináltam, de a VPN-ek sem tartoznak igazán az erősségeim közé.
Azért megpróbáltam begyűjteni információkat arról, hogy mekkorára kell nyitnom a számat. Nos, azt hiszem a New York – Tel Aviv tengely(1) mellett találtam még egy globális összeesküvést: arról szól, hogyan tüntessünk el minden nyomot, mely esetleg eligazíthatná a szegény tévelygő rendszermérnököt. Első körben megnéztem Shinder 1400 oldalas könyvében. Mindösszesen fél(!) oldal foglalkozott a témával. Azt írta a pacák, hogy ez egy igen bonyolult téma, helyhiány(!!) miatt nem foglalkozik vele. Nézzem meg az ISA2004 helpjében. Ezzel beállította az IT konteszt ‘cédén szállított cédé driver’ baromsági világrekordját.
Még jó, hogy van másik ügyfelünk. Beléptem hozzájuk és a szerzői és szomszédos jogok mély és eltökélt ignorálásával egyenként vágólapra küldtem a teljes upgrade fejezetet.
A biztonság kedvéért átfutottam a netet és egy teljesen más című fejezetben a KB-ben is megtaláltam ezt a szöveget. (Meg egy chm-ben is.) De sehol sem volt semmi más anyag! Belefutottam ugyan egy hasznosnak tűnő német nyelvű leírásba, ezt azért elraktam. (És bíztam benne, hogy nem múlt el nyomtalanul a Duden korszak.)
Ennyi volt az előkészület. Terv – az nem volt, hacsak azt a folyosói kérdést nem tekintem annak, hogy ‘mit saccolsz, mennyi ideig fog ez tartani?’.

Reggel kilenckor kezdtünk. Mivel GT-től egy nagyon plasztikus hasonlatot kaptam(2) a beépített kuruzsló működésével kapcsolatban, ezért az ügyfélnél úgy döntöttem, hogy kiegészítem a beépített mentési módokat: kiírtam az összes elemet, beállítást és infót egy spirálfüzetbe. Ezzel kettős célom volt: egyrészt védőhálót szereltem a mutatvány alá, másrészt írás közben már próbáltam kialakítani a 2000 meglehetősen kusza rendszeréből a 2004 szabályait.
Itt követtem el két súlyos hibát:
– Volt négy content rule, ahol egyfajta blacklist alapú tiltást valósítottak meg. Hülye fejjel _nem_ húztam le a csúszkát megnézni, hogy milyen hosszú a lista – úgy gondoltam, ezzel úgyis simán meg fog birkózni a kuruzsló.
– Találtam az interneten egy vbscriptet – de nem bíztam benne. Ez állítólag emberi formátumba képes kiexportálni a konfigot. Lefutattam, megnéztem az első pár oldalt, aztán lehúztam a csúszkát a végéig, az is tetszett, megnyugodtam, kész. És nem tűnt fel, milyen bazi nagy lett az állomány.
Indulás előtt volt egy konfig mentés, aztán hagy szóljon. A migration file legyártása kerek három óráig tartott. Még itt is gyanút foghattam volna.
Aztán törölte a régi alkalmazást, felrakta az újat és már csak be kellett importálni az átkonvertált konfigot. Ja. Másfél óra gyötrődés után elszállt az import. Annyit mondott, hogy talált egy IP címett, amivel nem tudott mit kezdeni. Mi meg csak álltunk ott, bambán. Semmi olyan opció nem volt, hogy lépjük át aztán folytassuk.
És ekkor közölte az ügyfél is, hogy ‘ja, megtaláltátok azt a kétszázezres tiltólistát?’. Két perc néma csend után hangzott el a bűvös szó: rollback. Konfig mentés van, visszaállítás után majd töröljük a 4 content rule-t és újrakezdjük az egészet.
Itt léptünk be a Pofonok Völgyébe.
Ott kezdődött, hogy hiába raktunk fel egy szűz ISA2000 alkalmazást, Windows2003-on nem indult el. Azt mondta az a hígagyú idióta, hogy mivel nincs digitálisan aláírva a packetfilter.dll (nem ez volt a neve, de ez volt a dolga), ezért biztonsági okokból kibassza az egész ISA2000 cuccot a rétre legelni. Többször is próbáltuk lebeszélni erről a gusztustalan viselkedéséről, de rohadt makacs volt. Nyilván utána lehetett volna járni a jelenségnek, csak éppen nem volt internet. Végül a tűzfalat állítottam be, hogy direktben nyomuljon… de nem voltam boldog.
A megoldás persze triviális volt: azt írta a KB, hogy ISA2000 SP1 nélkül ne is számítsunk arra, hogy működni fog Windows2003 alatt. (Máskor békés kollégám itt már igen furcsán kezdett viselkedni. Pedig hol voltunk még a végétől…)
Oké, Sp2 felugrott. (Sehová sem megyek nélküle.:) Konfig visszatöltés elindult, leállt, kiírta, hogy kicsi a registry mérete, legalább 24 MB kell. Oké, Gizi. Bementem a System/szokásos marhaságok panelbe – és döbbenten vettem tudomásul, hogy _nincs_ registry méret beállító ablak.
Próbáld elképzelni a szituációt: az ügyfél informatikusai épp átjöttek a szobánkba, ugyanis ekkor telt le az az idő, amíg elfogadható volt számukra a szolgáltatáskiesés. Mit találtak? Két, az őrület határán eszelősen hörgő/röhögő informatikust, akik minden szaktudásukat bevetve túrták a netet (google, KB, miatyánkkivagyamennyekben…) azért, hogy megtudják, hol lehet egy szerveren beállítani a registry méretét. Ha volt is valami respektünk eddig, az most kipukkant lufiként tottyadt össze.
Nagyon sokára találtuk meg ezt: miszerint Windows2003-ban (és az XP-ben) _nincs_ lehetőség átállítani a registry méretét, ugyanis nem a paged pool-hoz rendelték, hanem a computer cache address space-hez, bármi is legyen az – és úgy döntöttek, hogy – apám totóstílusához hasonlóan – fixre veszik. Nesze, kabbe.
Igaz, találtunk olyat is, hogy Windows2000-ben hol lehetett beállítani a limitet a registryben. Ekkor már marhára ráértünk, ugyanis az ügyfél sztoikusan előszedte a szekrényből a linuxos vésztartalékot – mi szépen átírtuk az IP címeinket, ők meg beindították a B tervet. És az internetelérést.
Kipróbáltuk a registry hekket, mit ád az ég, bejött. Azaz: annak a szájbanyomott konfigvisszatöltésnek nincs igazából szüksége a nagy registry határértékre – de nem indul el, amíg nem érzi úgy, hogy elég helye lesz. Ha behazudod neki, hogy van (ugyanis Windows2003 alatt ez a beállítás egyébként hatástalan a registry tényleges határértékére), akkor elindul.
Persze így se futott le: megkaptuk a rettegett ‘configuration mismatch’ üzenetet. Első körben nem volt nehéz továbblépni, nyilván az IP címek voltak rosszak. Kértünk egy HUB-ot, beledugtuk mindkét hálókártyát és sziget módban visszaállítottuk az IP címeket. De Mismatch kisasszony nem állt tovább.
Oké, nyomjuk fel a patch-eket. (Itt jött jól az elején az IsaInfoval elmentett információ.) Lófütty és ráadásul az utolsó patch újraindítást kért. Ekkor végleg megborultunk, mert immáron be sem tudtunk lépni a gépbe.
Hosszas diplomáciai tárgyalás után kiebrudaltuk a linux gépet és visszakaptuk élesben az IP címeinket, persze az újabb kísérlet után is mismatch vigyorgott ránk. Hogy azért-e, mert az elején egyből az Sp2-t tettük fel, vagy azért, mert nem a megfelelő sorrendben raktuk fel a patch-eket, vagy azért, mert nem tetszett neki a pofánk – már soha nem fogjuk megtudni, ugyanis feladtuk a rollback-et. Ott álltunk használható migrációs fájl nélkül, a rollback lehetősége nélkül, körülbelül éjfélkor. Az ügyfél informatikusai leszaladtak az éjjelnappaliba és hevesen nekiálltak sörözni.
Választhattunk: vagy csinálunk egy szűz 2004 installt és a spirálfüzetből beverjük a szabályokat – de ekkor elveszik az L2TP kapcsolathoz szükséges tanúsítvány; vagy berúgunk az ügyféllel együtt.
Meglehetősen reménytelenül belevágtam egy harmadik elképzelésbe: a migrációs fájl tulajdonképpen egy xml fájl; talán meg lehetne próbálni kézzel kiszedni belőle azt a kétszázezer objektumot. Ne kérdezd meg, hogyan sikerült. Az se érdekeljen, hogyan tudtam megcsinálni hajnalban, hogy egy tag-et se hibáztam el. Ne kérdezd meg… mert én se tudom. De sikerült – annak ellenére, hogy ekkor az összenyitott szomszéd szobában már igen magasra hágott a hangulat… no meg a bagófüst. (Csak érdekességképpen: az előtte 51 MB méretű xml fájl 260 KB-re szottyadt össze.)
Gyorsan felraktam egy szűz ISA2004-et, beimportáltam az új fájlt – és kb 40 másodperc alatt készen is voltunk. Szokásomhoz híven elvonultam egy kicsit ajtófélfát rugdosni – de már volt egy alapunk.
Persze, hiú remény lett volna azt hinni, hogy innentől minden simán ment.
Néhány példa a torkosborz minősített eseteire:
– Firewall kliensről nem ment az internet elérés, miközben a log tele volt 1745-ös port rohamozással. Azt mondta az ISA, hogy számára ez ismeretlen protokoll. Az a négykerekű anyád: ez ugyanis pont saját kliensei, a winsock kliensek elfogadott protokollja (remote-winsock). De akkor miért nem ismeri fel? Nos, azért, mert a sokadik objektum sokadik fülén valahol be volt kattintva, hogy csak secure firewall kliens kommunikációt értelmezzen. Kolléga tekintete ekkor váltott üvegesre és a továbbiakban már nem is kapta vissza az eredeti fényét.
– Egy idő után lehalt minden kommunikáció az ISA és a DC-k között. De abszolút, még az időszinkron sem ment. Annak ellenére, hogy a kapcsolatfigyeléseknél az LDAP tökéletesnek látszott.
Megint logelemzés: most meg tele volt tiltott 1025-ös port elérésekkel. Ez olyan kliens port szagú, de azért utánanéztem – és lepadlóztam, mert kiderült, hogy ez tulajdonképpen RPC.
Hát már a 135-ös portban sem bízhat az ember?
Mivel nem találtam meg, hogy hol lehet visszaállni erre az értékre, kínomban csináltam rá egy szabályt. Kicsi is, savanyú is, de a miénk. És helyreállt az ISA-DC kapcsolat.
– Persze a legszebb az volt, hogy a linuxos csereberével teljesen megborítottuk a hálózatot. Egyébként sem volt egy robusztus cucc, ehhez képest jól belengettük a DHCP-t és a DNS-t. A group policy is igen megroggyant – hasonlóan, mint hajnalban az adminok.
És itt futottam bele – megint – egy tipikus ISA2004 szívásba.
A mostani mellett nemrég frissítettem egy másik cégnél Proxy2.0-át ISA2004-re. Mindkét helyen belefutottam abba, hogy voltak hálózati anomáliák, melyeket a korábbi szoftver azért lekezelt. Rendszeresen kapott ugyanis olyan csomagokat, melyekhez tulajdonképpen semmi köze sem volt, de elég volt betenni egy statikus route bejegyzést – vagy még ennyit sem, elég volt a LAT – és ment minden a maga módján. Csakhogy az ISA2004 ezen változtatott: mohón behabzsol minden hozzá érkező csomagot és a szabályok alapján dönti el, mit csináljon vele. De egy dolgot biztosan nem fog csinálni: nem küldi vissza arra a hálókártyára, amelyiken bejött. Ebből következőleg mindegyik ügyfélnél hatalmas veszekedésekbe bonyolódtam: én azt mondtam, hogy szar a hálózatuk, ők meg azt, hogy az upgrade előtt jó volt, ha most rossz, akkor nyilván én csesztem el.
Természetesen a tuti megoldás mindenhol az volt, hogy group policyval le kellett küldeni, hogy mi számít helyi hálózatnak – és ilyetén módon proxy kivételnek. Feltéve, hogy működött a group policy.
Itt ez utóbbi esetbe futottunk bele, megspékelve azzal, hogy az ügyfél aktív desktopot használt, ahol a háttér egy linuxos webszerverről érkező, rendszeresen aktualizált weblap (php script) volt. Kösse fel a gatyáját, aki ebben a felállásban egyből megmondja, hogy az aktív desktop tkp. milyen kliens: firewall vagy webproxy? És miért néz ki úgy a desktop, hogy először betöltődik a weblap teljes képernyősen, majd utána rögtön még három ablakba? (Persze, a régi ISÁ-val nem volt ilyen baj. Oldjuk meg…)
Határozottan komoly fegyverténynek éreztem, hogy hajnali fél ötkor el tudtunk jönni úgy, hogy egy alapszinten működő rendszert hagytunk magunk mögött.

Rám maradt, hogy egy nappal később visszamenjek és elrendezzek mindent. Aludtam öt és fél órát és ezzel valószínűleg bajnok is voltam, mert az ügyfél embereinek talán 3-3 óra jutott. Sok minden már nem volt hátra, kipihenten gyorsan rendberaktam a maradékot.
Egy dolog zavart nagyon. Az egész migrációs cirkuszt amiatt a nyomorult tanúsítvány miatt csináltuk. Ha az nem lett volna, akkor legyalultam volna mindent a francba és egy szűz installba tömtem volna bele a füzetemből a szabályokat. De biztos, hogy átjött ez a cert? És egyáltalán, hol tudom ezt megnézni?
Felhívtam minden információk kútfőjét, GT-t. Nem akarom dramatizálni a helyzetet, kiderült, hogy a tanúsítvány egy olyan tárolóban volt, melyet teljesen hidegen hagyott az, hogy háromszor-négyszer kirántották alóla az ISA szervert. (Csak azt nem értem, hogy akkor a migrációs fájl készítésekor miért kérdezte meg, hogy akarom-e a cert-et is menteni?)
Ha nem jött volna le egyből a tanulság: azért szívtunk ilyen hatalmasat, mert olyan információt akartunk ezerrel védeni, mely egyébként simán képes volt önmagát megvédeni.
Na, mindegy, ami nem győz le, az erőssé tesz.
A jó pap meg bekaphatja.
Lassan érik egy PKI tanfolyam.

(1) Nehogy komolyan vedd! Vicc. Irónia…

(2) Olyan, mint a tököm -11 fokban.