EPIC moments - Avagy miért születetthetett meg a pokoli operátor?

Az ember néha tényleg azt hinné, hogy a hülyeségnek azért valahol csak van határa, de időről időre rá kell döbbenjek, hogy az ami még tegnap tényleg jó viccnek tűnt, ma már lehet komor valóságként materializálódik a szemem előtt.

Álljon hát itt néhány kis szösszenet azokból az "URAM ISTEN" pillanatokból, amiket az elmúlt időszakban sikerült megtapasztalnom.

1) - "Van e elég hely a /dev/null alatt?"

Anno volt ez egy elszólása egy némileg távoli kollégámnak, amin sikerült jót vigadni. A dolog apropója annyi volt, hogy az egyik logfile-t átirányítottuk a /dev/null alá (mondván, hogy úgy se használjuk, csak ha debugolni kell) erre ő -féltve, hogy az FS megtelik- megkérdezte, hogy van e elég hely alatta.. Ez anno tényleg vicces volt, viszont amikor az ember ilyet lát, de most már kezdem azt hinni, hogy ilyen felszólalásokat Murphy felhívásnak érzi, hogy megcáfolja őket ; főleg amikor ilyesmi issue jön az emberrel szembe:

server@root:/ # df -m /
Filesystem    MB blocks      Free %Used    Iused %Iused Mounted on
/dev/hd4         192.00      0.00  100%     3694    85% /
server@root:/ # du -axk / |sort -rn |head -5
193860  /
109992  /dev
109956  /dev/null
27160   /etc
24272   /lpp
server@root:/ # ls -l /dev/null
-rw-------    1 root     system    112590848 Aug 23 19:55 /dev/null
server@root:/ # du -m /dev/null
107.38  /dev/null
server@root:/ # file /dev/null
/dev/null: commands text

Hogy az a jó élet.. WTF?? A /dev/null nem egy character file-nak kéne lennie? Dehogynem.. Akkor miért nem az?? A válasz: Mert valaki letörölte.. Az első jött ment process meg nyomban létre is hozta a file-t egy átirányítás révén ($command 2>/dev/null - szerintem mindenki látott már hasonlót :)), ami aztán lassan meg is telítette a / filerendszert..

* facepalm * ... Aztán akkor meg a gyógyszer:

rm /dev/null; mknod /dev/null c 2 2; chmod 666 /dev/null

Ha azt hiszitek, itt vége a sztorinak tévedtek!! Murphy úgy gondolta, hogy lesz 2. felvonás is:

server@root:/ # ls -l /dev/null*
crw-rw-rw-    1 root     system        2,  2 Aug 23 15:09 /dev/null
-rw-r--r--    1 root     system     20057274 Aug 23 13:54 /dev/null 2>&1

*sigh* Ez meg mi a lóturó...

Kis turkálás, majd az oka is megvan: http://www-01.ibm.com/support/docview.wss?uid=nas74d33539b559cc0308625792900533a8f
Igen.. A programozók ilyet is tudnak...

2) - Forkbomb sudo-val

A szituáció a következő: Megpróbálsz belépni a rendszerre, de a belépés sikertelen. HMC-ről látod, hogy a gép megy, de a gépet a virtuális terminálon át se sikerül elérni (a terminál megnyílik, de login screen-t nem kapsz). A gép lényegében vegetál, úgy hogy nincs más mint előre - force restart HMC-ről. A gép vissza is jön az életbe, persze az okot ekkor még nem tudjuk, tehát elkezdünk nézegelődni a logokban, hogy mi a fene van.. Rövid vizsgálódás után a shell közli velem, hogy "unable to fork"..
Őőő... Mi van??? És a gép tényleg ismét elkezdi azt amit előtte is: nem lehet vele semmit se kezdeni..
Újabb újraindítás, svmon-al nézzük, hogy mi zabálja a memóriát, de semmi különöset nem látok.. topas.. detto semmi.. ps lista.... állj..

server@user:/ # ps -ef
     UID      PID     PPID   C    STIME    TTY  TIME CMD
    root        1        0   0   Jul 05      -  0:06 /etc/init
    root  1441896        1   0   Jul 05      - 21:51 /usr/sbin/syncd 60
    root  1638488        1   0   Jul 05      -  0:00 /usr/ccs/bin/shlap64
    root  1769656        1   0   Jul 05      -  0:00 /usr/lib/errdemon
    root  2359508  8192170   0 17:57:36  pts/0  0:00 -ksh
    root  2424966  3145848   0   Jul 05      -  0:00 /usr/sbin/biod 6
    root  2556062  3145848   0   Jul 05      -  0:01 /usr/sbin/hostmibd
    root  2752642  3145848   0   Jul 05      -  0:02 /usr/sbin/syslogd
    root  2818192  3145848   0   Jul 05      -  1:35 sendmail: accepting connections
    root  2883696  3145848   0   Jul 05      -  0:02 /usr/sbin/snmpmibd
    root  2949226  3145848   0   Jul 05      -  0:26 /usr/sbin/aixmibd
    root  3014786 15335476   0 17:57:32  pts/0  0:00 -ksh
    root  3080398  4391120   0 17:57:29  pts/0  0:00 -ksh
    root  3145848        1   0   Jul 05      -  0:00 /usr/sbin/srcmstr
    root  3211378  3145848   0   Jul 05      -  0:00 /usr/sbin/snmpd
    root  3342544  4194544   0 17:57:33  pts/0  0:00 -ksh
    root  3407976  3145848   0   Jul 05      -  0:00 /usr/sbin/portmap
    root  3473514  3145848   0   Jul 05      -  0:00 /usr/sbin/inetd
    root  3539066  7864376   0 17:57:32  pts/0  0:00 -ksh
    root  3604658 10420352   0 17:57:33  pts/0  0:00 -ksh
    root  3735804  7536670   0 17:57:34  pts/0  0:00 -ksh
    root  3801268  7340182   0 17:57:32  pts/0  0:00 -ksh
    root  3866832  9044146   0 17:57:31  pts/0  0:00 -ksh
    root  3932166  7667938   0 17:57:34  pts/0  0:00 -ksh
    root  3997750  9764978   0 17:57:30  pts/0  0:00 -ksh
    root  4063286  4259944   0 17:57:31  pts/0  0:00 -ksh
    root  4128854 12910818   0 17:57:34  pts/0  0:00 -ksh
    root  4194544 12320872   0 17:57:33  pts/0  0:00 -ksh
    root  4259944  8978666   0 17:57:31  pts/0  0:00 -ksh
    root  4325470 13041670   0 17:57:35  pts/0  0:00 -ksh
    root  4391120 10223744   0 17:57:29  pts/0  0:00 -ksh
    root  4456662  3604658   0 17:57:34  pts/0  0:00 -ksh
...
    root 15335476 11337968   0 17:57:32  pts/0  0:00 -ksh
    root 15401026 12648676   0 17:57:36  pts/0  0:00 -ksh
    root 15532266 15204356   0 17:57:37  pts/0  0:00 -ksh
server@user:/ # ps -ef |grep -c ksh
245

őő.. ez kicsit sok nem?? Plusz mi a fenétől jöttek ezek elő??? Közben persze telik az idő, és ismét beüt a krach ; újabb restart, de most már sejtem, hogy mi a probléma , valamiért túl sok ksh forkolódik és sok kicsi sokra megy alapon mindegyik lefoglal magának egy kis memóriát, ami azért ekkora léptékben már képes megzabálni a gépet.. Úgy hogy az újraindítás után nyomban proctree-vel kezdem a játékot, s mit látok?

server@user:/ # ps -ef |grep ksh |tail -1
    root 1478878 1466588   0 18:20:10  pts/0  0:00 -ksh
server@user:/ # proctree 1478878
434214    /bin/ksh /etc/rc.itm1
   389164    -ksh -c /opt/IBM/ITM/bin/itmcmd agent start ul >/dev/null 2>&1
      462944    -ksh
         385246    -ksh
            405732    -ksh
               176296    -ksh
                  442614    -ksh
                     381148    -ksh
                        94260    -ksh

És innen meg végtelen sorokban ksh hegyek..

Na nézzük mi jön le ebből: Van egy 434214 PID-ű process-ünk ami épp egy ITM6-os indító script, ami meghívja az UL agent startupját, ami meg aztán hegyekben szórja a ksh-s forkokat.. Ahogy a hívásból látjuk egy ksh futtatja magában a /opt/IBM/ITM/bin/itmcmd file-t is (ergo az is script), ami meg init-ből indul..
Scriptet megnéztem - semmi különös - a szokásos hívások vannak csak benne.. Fejvakarás, wattafák.. Majd megpróbálok én is felmenni root szintre sudo-val, és furcsa módon tapasztalom, hogy bizony, shell-t azt nem kapok... Ctrl+C hegyekben, aztán csak kaptam shell-t..
Ez volt az a pillanat amikor már kezdtem azt hinni, hogy a root user-el van csak gond ( a user shellem gond nélkül ment), ergo belekukkantottam a root profile file-jába, és ezt a gyönyörűséget láttam:

server@root:/ # cat .profile
export ENV=.kshrc
# Define initial prompt to include hostname
export PS1=`hostname`@$USER':$PWD # '
sudo su -

ŐŐ.. Álj.. 'sudo su -' a root profiljában???? KI VOLT AZ A MARHA???? Profil átír, 'sudo su -' sor eltávolít, rendszer ujraindít, minden működik szépen.

Na de mi is történt? - valamelyik ökör belerakta a root profiljába a 'sudo su -' sort.. Miért is gond ez? Mert a 'sudo su -' a root user alatt kérdés (meg jelszó kérés) nélkül lefut, és egy újabb shell-t nyit, ami meg megint beolvassa a root .profile-ját, ami így megint lefuttatja a 'sudo su -'-t és így tovább amíg a szerver bírta...
Ergo valaki ügyesen fork bomb-á alakította a sudo-t root alatt :)

3) - Az öngyilkos java alkalmazás

Anno még írtam is az egyik szép kis kamikáze kódról, ami sikeresen szembe jött velem.. Most újra elő kell vegyem a témát, mert az amit láttam az nem hogy ennek egy emeltebb formája volt, mintsem egy komplett seppuku :)
Na szóval... Van egy szerver, egy rajta futó Websphere (Web's Fear) alkalmazással rajta, amin belül meg fut egy valaki által írt applikáció jópár éve..
Egyik nap megszólal a vészharang, ügyfél sikoltozik, hogy a hőn szeretett alkalmazása nem működik.. Jó, rendben nézzünk utána.. Kis nyomozás, közös munka az application support group-al, majd kiderül, hogy hiányzik az alkalmazás "magja". Pontosabban ott van, csak nem úgy működik, ahogy kéne (azaz sehogy).
Az elején még nem értettem miről van szó, de aztán lassacsakán megvilágosodtam.. Íme egy röpke összefoglaló arról, hogy mi történt (időrendi sorrendben)
- Jópár éve már, hogy valami fejlesztő palánta megírta az alkalmazás core modulját
- Ez a modul jópár évig gond nélkül, aztán beütött a krach - Az applikáció összeomlott, majd nem volt képes újraindulni.
- Az applikáció HOME könyvtárában lévő core file elemzése után kiderült, hogy az alkalmazás egy verem hiba miatt esett össze, majd a szokásos módon dobott egy java core-t. Mindezt egy olyan applikációs almodul játszotta el, amit közvetlenül a fő mag hívott
- Aki még nem találta ki, annak itt a csattanó - Igen, az applikáció magját 'core'-nak hívták.. Ezt volt a file neve..

Tehát mi is történt: Volt egy core nevű alkalmazásunk, ami szépen futott, míg az egyik almodulja (ugyan abból a HOME-ból futtatva) nem dobott egy coredumpot, ezzel szimplán felülvágva az eredeti 'core' file-t, innentől meg az alkalmazás központi magja nem volt elérhető, ergo persze, hogy nem is indult el ez után.

És egyesek még csodálkoznak, hogy az IT-sok néha "kicsit" idegesek.. El nem tudom képzelni miért..

AIX - booby trap

Az ember azt hinné, hogy az AIX-el nem lehet vicces dolgokat csinálni, de olykor olykor kellemesen tud csalódni abban amit el lehet ténylegesen érni vele.
Múltkor például sikerült rájönnöm, hogy IPsec-el lehet olyan szabályt létrehozni, ami annyit csinál, hogy ha egy kliens megpróbál az adott portra csatlakozni, akkor kap egy X sec-es ban-t mindenféle hálózati forgalommal együtt..
Belegondolva ez egy standard támadó ellen teljesen jó kis csapda -> Csupán annyit kell csinálnunk, hogy egy meglehetősen alacsony portra kirakunk egy sérülékeny szolgáltatást (rsh, telnet, csak hogy finoman is nézzen ki), majd rádefiniálunk egy szabályt, hogy aki megpróbál bejönni, annak mondjuk 1 napig csend legyen.. Amennyiben a támadónk valamiféle scanneléssel próbálkozik (sima nmap is elég :)) már bele is esett a csapdába.. Csodálatos, mit ne mondjak :))

Hogy ez a valóságban hogy is néz ki? Nos van 1-2 alapfeltétel:
- clic.rte alatti csomagoknak fent kell legyenek a gépen
- Be kell legyen töltve az Ipsec modul (ipsec_v4, ha IPv4et akarunk védeni)
- A szabályokat nekünk kell beállítani.

Tehát a feladat szimplán ennyi:

server # installp -avXYgd /source clic.rte.lib clic.rte.kernext  
    # Alap csomagok telepítése
server # smitty ips4_start # Indítsuk el az Ipsec IPv4es támogatását
server # lsdev -l ipsec_v4 # Nézzük meg elérhetővé vált e az ipsec_v4 device
ipsec_v4 Available  IP Version 4 Security Extension

A szabály beállítás némileg macerásabb. Csinálhatjuk 'smitty ips4_add_filter'-el, vagy genfilt-en keresztül parancssorból is.

Smitty-ből így néz ki a konfigolás:
* Rule Action                                                                   [shunHost]            
* IP Source Address                                                         [0.0.0.0]
* IP Source Mask                                                             [0.0.0.0]
  IP Destination Address                                                   [10.1.0.100]
  IP Destination Mask                                                       []
* Apply to Source Routing? (PERMIT/inbound only)    [yes]                 
* Protocol                                                                         [all]                 
* Source Port / ICMP Type Operation                             [any]                 
* Source Port Number / ICMP Type                                [0]                   
* Destination Port / ICMP Code Operation                     [eq]                  
* Destination Port Number / ICMP Type                        [23]                  
* Routing                                                                         [both]                
* Direction                                                                       [inbound]             
* Log Control                                                                  [yes]                 
* Fragmentation Control                                                 [0]                   
* Interface                                                                       [all]                 
  Expiration Time (sec)                                                   [300]                 
  Pattern Type                                                                 [none]                
  Pattern / Pattern File                                                     []
  Description                                                                   [telnet_boobytrap]

Ugyan ez parancssorból:

server # genfilt -v 4 -a H -s '0.0.0.0' -m '0.0.0.0' -d 10.1.0.100 -g y -c all -o any -p 0 -O eq -P 23 -r B -w I -l Y -t 0 -i all -e 300 -D 'telnet_boobytrap'

Némi kis magyarázat a kapcsolókról:
-v 4 -> IP version 4
-a H -> ShunHost
-s 0.0.0.0 -> Source address (0.0.0.0 == bárhonnét)
-m 0.0.0.0 -> Source Mask (0.0.0.0 == mindenhonnan)
-d 10.1.0.100 -> Destination IP (nem kötelező, de a tapasztalatok alapján érdemes megadni, mert nélküle mintha nem menne (nem tudtam rájönni miért))
-g y -> Source packet átroute-olása
-c all -> Minden protokolon (udp/tcp/icmp/ospf/ipip/esp/ah)
-o any -> Source port (0 == bármelyik)
-p 0 -> Source port (0 == bármelyik)
-O eq -> Milyen tipusú operátort használjuk (eq == equal -> megyegező port)
-P 23 -> Port száma (23 == telnet)
-r B -> Routing-ot pontosan mely láncokra érvényesítsük (route forward, local routing, avagy mind2 (both)
-w I -> Direction. Jelen esetben csak a bejövő csomagokkal foglalkozunk
-l Y -> Loggolás.. Persze, hogy akarunk loggolni :) (For the record - a logok a local4:err, local4:info és local4:notice alá mennek)
-t 0 -> Fragmenation Control, avagy melyik ID-jű tunnelbe toljuk majd bele a csomagot ( a 0 default)
-i all -> Interface.. Mindenhol halgatózni akarunk természetesen :)
-e 300 -> Expiration time másodpercben (kíméletesek leszünk, most csak 5 perces bann jár :))
-D 'telnet_boobytrap' -> Description.. Hogy kb a leírás alapján tudjuk mit is akarhatott a költő amikor ezt a szabályt létrehozta..

Ennek az eredménye egy olyan rule lesz, ami bárhonnét jövő IPv4-es kapcsolatot kitilt 5 percre, ha én a 23-as portra próbálok csatlakozni.
Szerverről lekérve pedig láthatjuk is a kis szabályunkat:

server # lsfilt -v4 -O
1|permit|0.0.0.0|0.0.0.0|0.0.0.0|0.0.0.0|no|udp|eq|4001|eq|4001|both|both|no|all packets|0|all|0|||Default Rule
2|*** Dynamic filter placement rule for IKE tunnels ***|no
3|shunHost|0.0.0.0|0.0.0.0|0.0.0.0|255.255.255.255|yes|all|any|0|eq|23|both|inbound|yes|all packets|0|all|300|||telnet_boobytrap
0|permit|0.0.0.0|0.0.0.0|0.0.0.0|0.0.0.0|yes|all|any|0|any|0|both|both|no|all packets|0|all|0|||Default Rule

Na most azért van itt még 1-2 dolgot amire ki kell térni:
- A 0ás,1es,2es szabályok állandóak, ergo a legkisebb ID amit kaphatunk az 3as lesz 1 szabályhoz, illetve afölött
- Azzal, hogy a rule-t létrehoztuk még nem jelenti, hogy életbe is léptettük azonnal -> azt külön meg kell tenni :)
- Ráadásként a loggolást is hiába állítottuk be, ha nem engedélyezzük azt is :)

Mázlinkra ez összesen 2 új parancsot jelent:

server # mkfilt -v4 -g start  # Loggolás aktiválása
server # mkfilt -v4 -u    # A felvitt rule-ok aktiválása

Innentől fogva viszont életbe léptek a változtatásaink, és mindenféle bajkeverő ilyen következményekkel kell szembenézzen

Mit jelent ez a gyakorlatban?
"telnet_boobytrap" szabály nélkül az nmap ezt dobja vissza:

pentester # nmap -sS 10.1.0.100

Starting Nmap 5.51 ( http://nmap.org ) at 2012-07-25 22:15 Central Europe Daylight Time
Nmap scan report for 10.1.0.100
Host is up (0.061s latency).
Not shown: 994 closed ports
PORT     STATE SERVICE
23/tcp   open  telnet
111/tcp  open  rpcbind
514/tcp  open  shell
1334/tcp open  writesrv
2049/tcp open  nfs
9090/tcp open  zeus-admin
MAC Address: 00:00:00:41:47:4E (Xerox)

Nmap done: 1 IP address (1 host up) scanned in 1.72 seconds

"telnet_boobytrap"-al ugyan ez:

pentester # nmap -sS 10.1.0.100

Starting Nmap 5.51 ( http://nmap.org ) at 2012-07-25 21:46 Central Europe Dayliht Time
Nmap scan report for 10.1.0.100
Host is up (0.063s latency).
Not shown: 919 closed ports, 76 filtered ports
PORT     STATE SERVICE
111/tcp  open  rpcbind
514/tcp  open  shell
1334/tcp open  writesrv
2049/tcp open  nfs
9090/tcp open  zeus-admin
MAC Address: 00:00:00:41:47:4E (Xerox)

Nmap done: 1 IP address (1 host up) scanned in 1521.31 seconds

1.72 sec VS 1521.32 sec (több mint 25 perc :)) és csak egy 5 perces tiltást állítottunk be.. Képzeld el mi lesz ha "kicsit" emeljük a tétet, mondjuk 86400-ra (24 óra) :))

Nézzük mi van akkor ha valaki csak simán be akar telnetelni:

pentester  # telnet 10.1.0.100
Trying...
telnet: connect: A remote host did not respond within the timeout period.

Mindeközben a logban:

server  # tail -f /var/log/syslog.out |grep ipsec
Jul 25 20:29:42 server local4:info ipsec_logd: #:2 R:d  I:10.1.0.100 S:10.1.0.153 D:10.1.0.100 P:tcp/ack SP:53688 DP:23 R:l I:en1 F:n T:0 L:60
Jul 25 20:29:42 server local4:info ipsec_logd: #:1 R:d  O:995:46f4:995:46d2:995:46f4:600:d1b8 S:17:0:0:1::2 D:0:1::656e:3100:f100:500 P:(1) -:54272 -:61696 R:l I: F:n T:3935892 L:18472
Jul 25 20:29:43 server local4:info ipsec_logd: #:0 R:d  I:10.1.0.100 S:10.1.0.153 D:10.1.0.100 P:tcp/ack SP:53688 DP:23 R:l I:en1 F:n T:0 L:60
Jul 25 20:29:43 server local4:info ipsec_logd: #:-2010349502 R:d  O:995:46f4:995:46d2:995:46f4:600:d1b8 S:17:0:0:1:: D:0:1::656e:3100:f100:500 P:ip -:12288 -:61696 R:l I: F:n T:3935892 L:0
Jul 25 20:29:46 server local4:info ipsec_logd: #:0 R:d  I:10.1.0.100 S:10.1.0.153 D:10.1.0.100 P:tcp/ack SP:53688 DP:23 R:l I:en1 F:n T:0 L:60
Jul 25 20:29:46 server local4:info ipsec_logd: #:-2010349502 R:d  O:995:46f4:995:46d2:995:46f4:600:d1b8 S:17:0:0:1:: D:0:1::656e:3100:f100:500 P:ip -:12288 -:61696 R:l I: F:n T:3935892 L:0
Jul 25 20:29:52 server local4:info ipsec_logd: #:0 R:d  I:10.1.0.100 S:10.1.0.153 D:10.1.0.100 P:tcp/ack SP:53688 DP:23 R:l I:en1 F:n T:0 L:60
Jul 25 20:29:52 server local4:info ipsec_logd: #:0 R:d  O:995:46f4:995:46d2:995:46f4:600:d1b8 S:17:0:0:1:: D:0:1::656e:3100:f100:500 P:ip -:27136 -:61696 R:l I: F:n T:3935892 L:0
Jul 25 20:30:04 server local4:info ipsec_logd: #:0 R:d  I:10.1.0.100 S:10.1.0.153 D:10.1.0.100 P:tcp/ack SP:53688 DP:23 R:l I:en1 F:n T:0 L:60
Jul 25 20:30:04 server local4:info ipsec_logd: #:1 R:d  O:995:46f4:995:46d2:995:46f4:600:d1b8 S:17:0:0:1:: D:0:1::656e:3100:f100:500 P:(1) -:9216 -:61696 R:l I: F:n T:3935892 L:0
Jul 25 20:30:28 server local4:info ipsec_logd: #:0 R:d  I:10.1.0.100 S:10.1.0.153 D:10.1.0.100 P:tcp/ack SP:53688 DP:23 R:l I:en1 F:n T:0 L:60
Jul 25 20:30:28 server local4:info ipsec_logd: #:0 R:d  O:995:46f4:995:46d2:995:46f4:600:d1b8 S:17:0:0:1:: D:0:1::656e:3100:f100:500 P:ip -:27136 -:61696 R:l I: F:n T:3935892 L:0
Jul 25 20:30:57 server local4:info ipsec_logd: #:0 R:d  I:10.1.0.100 S:10.1.0.153 D:10.1.0.100 P:tcp/ack SP:53697 DP:23 R:l I:en1 F:n T:0 L:60
Jul 25 20:30:57 server local4:info ipsec_logd: #:-2010349502 R:d  O:995:46f4:995:46d2:995:46f4:600:d1c1 S:17:0:0:1:: D:0:1::656e:3100:f100:500 P:ip -:12288 -:61696 R:l I: F:n T:3935892 L:0
Jul 25 20:30:58 server local4:info ipsec_logd: #:0 R:d  I:10.1.0.100 S:10.1.0.153 D:10.1.0.100 P:tcp/ack SP:53697 DP:23 R:l I:en1 F:n T:0 L:60
Jul 25 20:30:58 server local4:info ipsec_logd: #:0 R:d  O:995:46f4:995:46d2:995:46f4:600:d1c1 S:17:0:0:1:: D:0:1::656e:3100:f100:500 P:ip -:27136 -:61696 R:l I: F:n T:3935892 L:0
Jul 25 20:31:01 server local4:info ipsec_logd: #:0 R:d  I:10.1.0.100 S:10.1.0.153 D:10.1.0.100 P:tcp/ack SP:53697 DP:23 R:l I:en1 F:n T:0 L:60
Jul 25 20:31:01 server local4:info ipsec_logd: #:-2010349502 R:d  O:995:46f4:995:46d2:995:46f4:600:d1c1 S:17:0:0:1:: D:0:1::656e:3100:f100:500 P:ip -:12288 -:61696 R:l I: F:n T:3935892 L:0
Jul 25 20:31:07 server local4:info ipsec_logd: #:0 R:d  I:10.1.0.100 S:10.1.0.153 D:10.1.0.100 P:tcp/ack SP:53697 DP:23 R:l I:en1 F:n T:0 L:60
Jul 25 20:31:07 server local4:info ipsec_logd: #:0 R:d  O:995:46f4:995:46d2:995:46f4:600:d1c1 S:17:0:0:1:: D:0:1::656e:3100:f100:500 P:ip -:27136 -:61696 R:l I: F:n T:3935892 L:0
Jul 25 20:31:19 server local4:info ipsec_logd: #:0 R:d  I:10.1.0.100 S:10.1.0.153 D:10.1.0.100 P:tcp/ack SP:53697 DP:23 R:l I:en1 F:n T:0 L:60
Jul 25 20:31:19 server local4:info ipsec_logd: #:1 R:d  O:995:46f4:995:46d2:995:46f4:600:d1c1 S:17:0:0:1:: D:0:1::656e:3100:f100:500 P:(1) -:9216 -:61696 R:l I: F:n T:3935892 L:0
Jul 25 20:31:43 server local4:info ipsec_logd: #:0 R:d  I:10.1.0.100 S:10.1.0.153 D:10.1.0.100 P:tcp/ack SP:53697 DP:23 R:l I:en1 F:n T:0 L:60
Jul 25 20:31:43 server local4:info ipsec_logd: #:0 R:d  O:995:46f4:995:46d2:995:46f4:600:d1c1 S:17:0:0:1:: D:0:1::656e:3100:f100:500 P:ip -:27136 -:61696 R:l I: F:n T:3935892 L:0

Amire tessék figyelni: Amint az egyik szabály érvényesül egy bejövő címre, az ipsec elkezdi logolni az összes próbálkozását a node-nak, miután ki lett tiltva (az nmap kellemes kis 2 MB-os logot generált nekem a ~25 perc alatt :)) de innentől már nem csak a megadott portra (23), hanem mindre amire a támadó gép bepróbálkozott

Ami a nagykönyvben nincs leírva..

Vannak helyzetek, amikor az ember elkezd azon agyalni, hogy a hivatalos utakon kívűl vannak e mások is.. Utak, amiken szintén el lehet indulni, és amin keresztül el lehet jutni A-ból B pontba.. Lehetőleg még gyorsabban is, vagy kevésbé fájdalmasan 1-1 issue alkalmával..
És vannak alkalmak amikor az ember igen is az ilyen utakon akar járni, főleg ha rájön, hogy azok sokkalta kifizetődőbbek, mint a hivatalosak. Na ez az eset pontosan ilyen volt :)

A szituáció adott: Van egy JFS2 filesystem, kellemes kis 2 TB-os mérettel, alatta "egy pár" LUN-al (diszkkel), és egy csúnya üzenettel az errpt-ben, miszerint:

server # errpt |head -2
IDENTIFIER TIMESTAMP  T C RESOURCE_NAME  DESCRIPTION
E86653C3   0723123112 P H LVDD           I/O ERROR DETECTED BY LVM

Nem kell sokat találgatnotok -> Igen, az az I/O error az adott 2 TB-os FS-re jött.. Tekintve, hogy az FS DS8K-s LUN-okra építkezik így ez még viccesebbé teszi a helyzetet, mivel ez csak az alábbi scenario-k között jöhet létre:
- Disk management issue (ez esetben a driver szopat)
- Fibre adapter issue (már ha nincs normális redundancia)
- Disk locking issue (ha ne adj isten a LUN több helyre van kizónázva, és más is használja az adott LUN-t, főleg ha még írni is akar rá)
- SAN box oldali issue (a DS oldali kötet hibás ottani adapter, vagy diszk hiba miatt)

Egyik se kellemes, mit ne mondjak..
Az első amit ilyenkor tudnunk kell, hogy a hiba milyen körülmények között jön elő. Jelen esetben annyit kell még tudni, hogy csak 1 LUN-ja jött a hiba, de arra állandóan, így az első 2 hibalehetőséget nyomban ki is lehet zárni (a driver CSAK 1 diszket nem köhög meg, hanem akkor konzisztensen szívatja az összeset, a HBA meg dettó nem hajlamos kispécizni magának LUN-okat :)).

A másik 2 lehetőség felderítéséhez meg a Storage szerveren kell turkálni ami meg jelen esetben másik team hatásköre volt, ám némi kis nyomozás után kiderült, hogy a zónázással nincs gond, viszont a kiosztott LUN alatt lévő fizikai réteg bizony kehés, ergo azt ők gyorsan orvosolják..

Egy részről ez jó mert egy elég komoly hibát sikerül megoldani, más részről viszont kliens oldalon (igen, nálam) még mindig ott az a fránya kis probléma, minek eredete, hogy nem férek hozzá az adatomhoz, és esélyes, hogy a javítás után se tudnék, ergo ezt nekem is valahogy orvosolni kéne..

A kérdés persze, hogy hogyan.. A probléma ugyan is az, hogy van minimum 1 blokkom a diszken, amit garantáltan nem tudok olvasni, azt kitiltani nem tudom, migrálni szintúgy nem (pont az olvasási hiba miatt), szóval 2 szék között sikerült a pad alá kerülnöm.. Ilyen esetben a hivatalos megoldás az lenne, hogy töröljem az FS-t, hozzam létre újra (és figyeljek, hogy az a LUN véletlenül se legyen ismét része az új FS-nek), majd backup-ból restore-oljam.. Ok, de 2 TB adatról beszélünk, a restore sok idő, a downtime meg drága..

Így hát adott a kérdés - hogy a francba minimalizáljuk a downtime-ot? Ez a kis leírás kb egy scenario-t mutat be arra amit sikerült kiötlenem :)

Na szóval.. Mondtam, hogy a migrálás zsákutca.. Ezt persze nem hasra ütés alapján merem kijelenteni, hanem fájdalmas tapasztalatból, ugyan is sikerült így járjak az adott LUN-al:

server # migratepv vpath59 vpath91
0516-076 lmigratelv: Cannot remove last good copy of stale partition.
Resynchronize the partitions with syncvg and try again.
0516-812 migratepv: Warning, migratepv did not completely succeed;
all physical partitions have not been moved off the PV.

őő.. Egen.. Egy próbát megért, be is bukott.. (akinek a vpath nem lenne ismerős -> tekintve, hogy DS-ről beszélünk, így SDD driver megy az AIX alatt, ami meg hdisk-ek helyett vpath-okat használ) Megnézve a VG/LV adatokat meg ilyen randaságok jöttek szembe:

server # lsvg -l appvg |grep applv
0516-1147 : Warning - logical volume applv may be partially mirrored.
applv         jfs2       8192    9216    9    open/stale    /appdata

A VG PP size-a 256 MB, az FS pont 2 TB (8192 PP), és 9216 PP-nyi hely van felhasználva, tekintve, hogy az egyik PV-t épp át akartuk migrálni egy 9. 256 GB méretű LUN-ra (ami alapjáraton a LUN mirrorozását jelenti). Sajna a partíció open/stale helyzetben van, és ezen egy syncvg se segít

server # syncvg -l applv
0516-934 /usr/sbin/syncvg: Unable to synchronize logical volume applvg.

Ez a helyzet már magában is vicces, mivel nyomban plusz egy problémát hoz be a képbe, miszerint "Hogy a francba szedjem le a mirrort arról a LUN-ról".. unmirrorvg nem segít, az teljes VG-re van, rmlvcopy se, mert az meg teljesen kimirrorozott LV-re használható csak (itt meg csak 2 PV van "mirrorban" a 9ből), más hivatalos módszer meg nincs (vagy csak nekem nem jut eszembe)..

Ha viszont még valaki emlékszik, akkor én írtam egy módszerről anno, hogy hogy is lehet LV-t csökkenteni Na.. Ez a módszer most épp kapóra jön, csak kicsit másként kell használni, de a recept hasonló:

- Olvassuk ki az LV mappolását egy külön file-ba
- Szűrjük le, hogy mit akarunk kiszedni az LV alól
- Umountoljuk az FS-t (és tegyük closed-ba így az LV-t)
- Dobjuk ki ami nem kell
Ez kb így nézett nálam ki:

server # lquerylv -L $(getlvodm -l applv) -r > /tmp/mapfile
server # grep $(lspv |grep -w vpath91|awk '{print $2}') /tmp/mapfile >/tmp/mapfile2
server # wc -l /tmp/mapfile2
     1024 /tmp/mapfile2
server # umount /appdata
server # lreducelv -l $(getlvodm -l applv) -s 1024 /tmp/mapfile2

Ezt még persze megfejelhetjük egy fsck-val mount előtt, de itt még nem lesz probléma garantáltan.. Viszont innentől az FS visszaáll open/syncd-be :)

server # lsvg -l appvg |grep applv
applv         jfs2       8192    8192    8    open/syncd    /appdata

Ezzel egy problémát megoldottunk, viszont az eredeti még mindig megvan.. Viszont a fenti koktél némileg másként keverve itt is segíteni tud -> a módszer használható PP-k/LP-k teljes "lecserélésére" is ha összekombózzuk az lextendlv-vel :) A módszer kb így néz ki:

- 1x is pakoljunk át mindent amit tudunk a hibás LUN-ról (diszkről, ha úgy jobban tetszik) egy másik használható LUN-ra
- A pakolás közben 1, vagy több LP garantáltan nem fog átmenni, de nem is kell, elég ha a használható adat átballag a másik helyre
- Miután megvan, hogy mely LP-k nem teljesen elérhetőek, azokat kidobjuk a fenti módon
- Majd ezután ugyan annyi LP-t adunk az új diszkről, csupán az LP számozásra kell figyeljünk
Ennek a módszernek egyik nagy előnye, hogy nem kell a teljes FS-t backupból visszahozni, a másik oldalról viszont az elvesztett PP-ket üres PP-vel fogjuk feltölteni, ami meg elég durva adatvesztést/adatinkonzisztenciát jelent, amit viszont valahogy le kell kezelni. Tekintve, hogy az adat már most se nagyon elérhető, így ez még mindig a leghasználhatóbb útvonal a hiba javításához (lehet dönteni, hogy az adat nem elérhető, vagy 0-val van feltöltve -> restore mind a 2 esetben kell).

Ehhez persze tudni kell, hogy mely file-ok lesznek érintettek, ergo be kell vetni még 1-2 plusz lépést, hogy tudjuk mi és merre.. A legegyszerűbb erre az, hogy a file-okból egy checksum-ot generálunk (az legalább végigmegy a file-okon, és nem az attribútumok alapján próbál tájékozódni) a művelet előtt, majd utána, aztán összevetjük a kettőt egy diff-el, majd ami változott azt visszahozzuk backupból. Ez alapján a fenti terv az alábbi módon módosul:

- Checksum generálás minden FS-ben lévő file-ról
- LP-k migrálása egy másik LUN-ra (vpath91 a mi esetünkben) az eredeti LUN-ról (vpath59)
- FS umountolása (LV closed-ba tétele)
- Hibás PP-k/LP-k kidobása (azaz, ami marad a migráció után)
- Új "üres" PP/LP hozzáadása az LV-hez
- Újabb checksum generálás a file-okról
- A 2 checksum kimenet összevetése
- TSM restore a változott file-okról
Parancsokra lebontva ez az alábbi módon néz ki:

server # find /appdata -type f -exec sum {} \; >/tmp/checksum1
server # lslv -m applv |grep vpath59 > /tmp/applv_lslv_out
server # for i in $(awk '{print $1}' /tmp/applv_lslv_out);do migratelp applv/${i}/1 vpath91;done
....
server # lquerylv -L $(getlvodm -l applv) -r |grep $(lspv |grep -w vpath59|awk '{print $2}') > /tmp/mapfile_remove
server # umount /appdata
server # export LP_ERRORS=$(wc -l /tmp/mapfile_remove|awk '{print $1}')
server # lreducelv -l $(getlvodm -l applv) -s ${LP_ERRORS} /tmp/mapfile_remove
server # sed "s/$(lspv |grep -w vpath59 |awk '{print $2}')/$(lspv |grep -w vpath91|awk '{print $2}')/g" /tmp/mapfile_remove > /tmp/mapfile_add
server # lslv -m applv |grep -w vpath91 |awk '{print $2}' |sort -n|tail -1
1022
 # Azon LP-k száma, amit sikerült átmigrálnunk a migratelp-vel a vpath91re
server # vi /tmp/mapfile_add  
 # Itt kell átírjuk az LP számozást, nehogy ütközzön az előzővel (tehát a 2 LP-nk (Ennyi volt az $LP_ERRORS nálam) száma 1022 fölött kell legyen. 
 # Én maradtam az 1023 és az 1024-nél :)
server # lextendlv -l $(getlvodm -l applv) -s ${LP_ERRORS} /tmp/mapfile_add
server # fsck /dev/applv
The current volume is: /dev/applv
Primary superblock is valid.
*** Phase 1 - Initial inode scan
*** Phase 2 - Process remaining directories
*** Phase 3 - Process remaining files
*** Phase 4 - Check and repair inode allocation map
*** Phase 5 - Check and repair block allocation map
server # mount /appdata
server # find /appdata -type f -exec sum {} \; >/tmp/checksum2
server # diff /tmp/checksum1 /tmp/checksum2 > /tmp/checksum_difference
server # for FILE in $(awk '/^</ {print $3}' /tmp/checksum_difference);do dsmc rest $FILE;done

... PROFIT ...

# A folyamat persze feltételezi azt, hogy az FS alatt nem történik ilyenkor más változás, ergo az applikációs team-et a folyamat alatt illik távol tartani.. Viszont ez a módszer egész türhetően levitte számomra a visszaállítandó adat mennyiségét 2 TB-ról 3,2 GBra (2 db 256 MB-os PP sérülés volt az adott PV-n, azok közül az egyik meg pont egy nagyobb file-ban, ergo azt teljesen vissza kellett állítani)

Mi is történt? Kicseréltünk 2 LP-t 1 LV alól, úgy hogy azt a hivatalos módszerekkel elvileg meg se lehet oldani (legalább is nem ilyen módon). Mindebben pedig a legszebb, hogy az egészből az FS szinte alig vesz észre valamit, max némi adat nullázódik ki, de azt meg TSM-ről visszahozzuk..

Azt azért persze hozzá kell tennem, hogy ez a módszer véletlenül se támogatott hivatalosan, és ha az IBM support észreveszi, hogy nem a normál módon járunk el, akkor az ebből fakadó hibákra semmiféle felelősséget nem vállal, szóval óvatosan játszadozzon ezzel a módszerrel bárki is, és csak is saját felelősségre!

***********
Némi kis bónusz - ha az lvextend előtt kérjük le az LV állapotát, akkor ilyen kellemes helyzetben találhatjuk magunkat :))

server # lsvg -l appvg |grep applv
0516-1147 : Warning - logical volume applv may be partially mirrored.
applv         jfs2       8192    8190    8    open/stale    /appdata