Re: [Lug-bg] наследяване на сървъри
В 07:23 +0300 на 20.06.2013 (чт), Yordan Radunchev написа: Хора, попадали ли сте в ситуация да ви връчат сървър, за който няма нито ред документирано? Какво работи, защо работи, кой го ползва? При това сървъра си е production, има над 400 дена ъптайм, ползва се сериозно... Какво правите в такава ситуация, какви са стъпките за инвентаризиране? Идентифицарне на потребителите в passwd, на сървисиз...? От къде почвате и как бихте подходили? r., yra ___ Принципът е да разбереш какво точно се случва на машината (какво прави, какви услуги и хора има на нея), да ограничиш достъпа на който не трябва да го има и да почнеш малко по малко да update-ваш каквото има нужда (щото всичко с 400 дни uptime поне kernel трябва да му се смени). Може да тръгнеш от отворените портове или процесите в ps auxw, може първо от passwd файла, от инсталираните пакети (въпреки че това е малко тежко) и т.н., вероятно някъде има списъци за ред за security audit на сървъри, може да са ти полезна отправна точка. -- Regards, Vasil Kolev signature.asc Description: This is a digitally signed message part ___ Lug-bg mailing list Lug-bg@linux-bulgaria.org http://linux-bulgaria.org/mailman/listinfo/lug-bg
Re: [Lug-bg] наследяване на сървъри
On Thu, Jun 20, 2013 at 10:30:43AM +0300, Vasil Kolev wrote: В 07:23 +0300 на 20.06.2013 (чт), Yordan Radunchev написа: Хора, попадали ли сте в ситуация да ви връчат сървър, за който няма нито ред документирано? Какво работи, защо работи, кой го ползва? При това сървъра си е production, има над 400 дена ъптайм, ползва се сериозно... Какво правите в такава ситуация, какви са стъпките за инвентаризиране? Идентифицарне на потребителите в passwd, на сървисиз...? От къде почвате и как бихте подходили? r., yra ___ Принципът е да разбереш какво точно се случва на машината (какво прави, какви услуги и хора има на нея), да ограничиш достъпа на който не трябва да го има и да почнеш малко по малко да update-ваш каквото има нужда (щото всичко с 400 дни uptime поне kernel трябва да му се смени). Може да тръгнеш от отворените портове или процесите в ps auxw, може първо от passwd файла, от инсталираните пакети (въпреки че това е малко тежко) и т.н., ...от startup скриптовете (макар че това напоследък е малко сложно - допреди пет години си имахме SysV-style init scripts и BSD-style init scripts, после се нароиха всякакви upstart-и (а тук каква игра на думи има...) и какво ли не). Като при гледане на startup-скриптовете не забравяш две, не, три, уф, не, четири неща: - не само имената на скриптовете; понякога може да си заслужава да вземеш да ги отвориш, за да видиш дали някой кръгъл иди... така де, администратор с много опит и оправдано самочувствие не е решил да променя нещо директно в тях, а не в конфигурационните им файлове - не само отделни скриптове, ами и еквивалентът на rc.local, в който някой мързелив иди... така де, администратор, който отговаря за твърде много неща и няма никакво време да се занимава с глупости като разучаване на формата на startup script-ове, може да си е написал какво ли не - не всеки скрипт отговаря на една програма - има startup-скриптове, които пускат неща като runit или svscan, които пък си гледат съвсем други директории и файлове за информация за това какво да пуснат - не само startup-скриптовете, ами и, както каза Васил, ps auxw, за да видиш дали някой още по-кръгъл иди... така де, администратор, който знае, че сървърът му е стабилен и нищо не може да му се случи, не е пуснал процес на ръка, защото няма абсолютно никакъв смисъл да се пишат startup скриптове за нещо, което се пуска толкова елементарно вероятно някъде има списъци за ред за security audit на сървъри, може да са ти полезна отправна точка. Всъщност това би било интересно. Поздрави, Петър -- Peter Pentchev r...@ringlet.net r...@freebsd.org p.penc...@storpool.com PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13 If this sentence didn't exist, somebody would have invented it. signature.asc Description: Digital signature ___ Lug-bg mailing list Lug-bg@linux-bulgaria.org http://linux-bulgaria.org/mailman/listinfo/lug-bg
Re: [Lug-bg] наследяване на сървъри
On Thu, Jun 20, 2013 at 10:58:17AM +0300, Peter Pentchev wrote: On Thu, Jun 20, 2013 at 10:30:43AM +0300, Vasil Kolev wrote: В 07:23 +0300 на 20.06.2013 (чт), Yordan Radunchev написа: Хора, попадали ли сте в ситуация да ви връчат сървър, за който няма нито ред документирано? Какво работи, защо работи, кой го ползва? При това сървъра си е production, има над 400 дена ъптайм, ползва се сериозно... Какво правите в такава ситуация, какви са стъпките за инвентаризиране? Идентифицарне на потребителите в passwd, на сървисиз...? От къде почвате и как бихте подходили? r., yra ___ Принципът е да разбереш какво точно се случва на машината (какво прави, какви услуги и хора има на нея), да ограничиш достъпа на който не трябва да го има и да почнеш малко по малко да update-ваш каквото има нужда (щото всичко с 400 дни uptime поне kernel трябва да му се смени). Може да тръгнеш от отворените портове или процесите в ps auxw, може първо от passwd файла, от инсталираните пакети (въпреки че това е малко тежко) и т.н., ...от startup скриптовете (макар че това напоследък е малко сложно - допреди пет години си имахме SysV-style init scripts и BSD-style init scripts, после се нароиха всякакви upstart-и (а тук каква игра на думи има...) и какво ли не). Като при гледане на startup-скриптовете не забравяш две, не, три, уф, не, четири неща: - не само имената на скриптовете; понякога може да си заслужава да вземеш да ги отвориш, за да видиш дали някой кръгъл иди... така де, администратор с много опит и оправдано самочувствие не е решил да променя нещо директно в тях, а не в конфигурационните им файлове Тази точка може да бъде силно улеснена, ако администраторът не е бил твърде откачен и ти е оставил система, в която повечето, ако не всички, startup-скриптове са инсталирани през някаква пакетна система, която пази контролни суми на файловете и можеш с една команда да ги провериш. Поздрави, Петър -- Peter Pentchev r...@ringlet.net r...@freebsd.org p.penc...@storpool.com PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13 This sentence contradicts itself - or rather - well, no, actually it doesn't! signature.asc Description: Digital signature ___ Lug-bg mailing list Lug-bg@linux-bulgaria.org http://linux-bulgaria.org/mailman/listinfo/lug-bg
Re: [Lug-bg] наследяване на сървъри
On Thu, Jun 20, 2013 at 11:11:20AM +0300, Peter Pentchev wrote: On Thu, Jun 20, 2013 at 10:58:17AM +0300, Peter Pentchev wrote: On Thu, Jun 20, 2013 at 10:30:43AM +0300, Vasil Kolev wrote: В 07:23 +0300 на 20.06.2013 (чт), Yordan Radunchev написа: Хора, попадали ли сте в ситуация да ви връчат сървър, за който няма нито ред документирано? Какво работи, защо работи, кой го ползва? При това сървъра си е production, има над 400 дена ъптайм, ползва се сериозно... Какво правите в такава ситуация, какви са стъпките за инвентаризиране? Идентифицарне на потребителите в passwd, на сървисиз...? От къде почвате и как бихте подходили? r., yra ___ Принципът е да разбереш какво точно се случва на машината (какво прави, какви услуги и хора има на нея), да ограничиш достъпа на който не трябва да го има и да почнеш малко по малко да update-ваш каквото има нужда (щото всичко с 400 дни uptime поне kernel трябва да му се смени). Може да тръгнеш от отворените портове или процесите в ps auxw, може първо от passwd файла, от инсталираните пакети (въпреки че това е малко тежко) и т.н., ...от startup скриптовете (макар че това напоследък е малко сложно - допреди пет години си имахме SysV-style init scripts и BSD-style init scripts, после се нароиха всякакви upstart-и (а тук каква игра на думи има...) и какво ли не). Като при гледане на startup-скриптовете не забравяш две, не, три, уф, не, четири неща: - не само имената на скриптовете; понякога може да си заслужава да вземеш да ги отвориш, за да видиш дали някой кръгъл иди... така де, администратор с много опит и оправдано самочувствие не е решил да променя нещо директно в тях, а не в конфигурационните им файлове Тази точка може да бъде силно улеснена, ако администраторът не е бил твърде откачен и ти е оставил система, в която повечето, ако не всички, startup-скриптове са инсталирани през някаква пакетна система, която пази контролни суми на файловете и можеш с една команда да ги провериш. Поздрави, Петър Благодаря, много ценни съвети. Захващам се. Системата е SLES, има си zypper, ще ми каже поне нещата инсталирани през него. Ще му пусна и cfg2html - ще спести малко време. Но идеята да се отварят стартъп скриптовете е златна - наистина има вероятност да е мазано вътре и един бог знае какво всъщност пускат. Сървърите са 5, на един от тях намирам puppet... но ме е страх да се надявам още, че е използван за всичките, върде лесно би било. По тях са работили доста хора във времето, повечето от които в момента вече не работят тук. Последно на един индиец са били поверени, но той е бил в същото положение в което съм и аз. Отделно с него не говорим един английски, та ще е трудна комуникацията... R., yra signature.asc Description: Digital signature ___ Lug-bg mailing list Lug-bg@linux-bulgaria.org http://linux-bulgaria.org/mailman/listinfo/lug-bg
Re: [Lug-bg] наследяване на сървъри
On 20.6.2013 г. 07:23 ч., Yordan Radunchev wrote: Хора, попадали ли сте в ситуация да ви връчат сървър, за който няма нито ред документирано? Какво работи, защо работи, кой го ползва? При това сървъра си е production, има над 400 дена ъптайм, ползва се сериозно... Какво правите в такава ситуация, какви са стъпките за инвентаризиране? Идентифицарне на потребителите в passwd, на сървисиз...? От къде почвате и как бихте подходили? r., yra ___ Lug-bg mailing list Lug-bg@linux-bulgaria.org http://linux-bulgaria.org/mailman/listinfo/lug-bg Тръгни да ъпдейтваш/ъпгрейдваш/секюрити пачиш непозната система и ще дойде някой да ти връчи black spot или ще се събудиш с отрязана конска глава в леглото :) Какво си мисля, че би трябвало да направя аз в подобна ситуация: 1. V2P migration/Ghost4Linux/dd/rsync/ поне cp -r на /etc /usr/ 2. netstat/nmap/ps | grep -v нещата които си мисля, че знам + man/google за всички останали 3. AIDE/TripWare/audit/fschange - не е това идеята на тез тулчета, но ще е добре да се знае кои файлове как/защо/от_кой_сървиз се променят 4. незнам с какви тулчета за packet discovering разполагаш, но дори и едно ls -Rcalt / е по-добре от нищо преди да се почне голямато мазане 5. file level бекъп на каквото може и както може 6. svn/git - каквото ти повелява религията (cfg2html е много симпатично тулче ) 7. sandbox машина и (по възможност) почват да се вдигат услугите една-по-една... особенно ако ще съм администратор не само на сървъра ами и на услугите (и ще трябва да изпълнявам заявки от рода: Качвам файл в CMS-a, ама искам да могат да виждат само хора на които 4-ят символ от името е затворена гласна и потенциалният приход от тях е 4к юана месечно ) ___ Lug-bg mailing list Lug-bg@linux-bulgaria.org http://linux-bulgaria.org/mailman/listinfo/lug-bg
Re: [Lug-bg] наследяване на сървъри
Изклучи ги от мрежата и слушай за викане :-). R. Mason s...@mason.ch 2013/6/20 Eol e...@nat.bg On 20.6.2013 г. 07:23 ч., Yordan Radunchev wrote: Хора, попадали ли сте в ситуация да ви връчат сървър, за който няма нито ред документирано? Какво работи, защо работи, кой го ползва? При това сървъра си е production, има над 400 дена ъптайм, ползва се сериозно... Какво правите в такава ситуация, какви са стъпките за инвентаризиране? Идентифицарне на потребителите в passwd, на сървисиз...? От къде почвате и как бихте подходили? r., yra ___ Lug-bg mailing listLug-bg@linux-bulgaria.orghttp://linux-bulgaria.org/mailman/listinfo/lug-bg Тръгни да ъпдейтваш/ъпгрейдваш/секюрити пачиш непозната система и ще дойде някой да ти връчи black spot или ще се събудиш с отрязана конска глава в леглото :) Какво си мисля, че би трябвало да направя аз в подобна ситуация: 1. V2P migration/Ghost4Linux/dd/rsync/ поне cp -r на /etc /usr/ 2. netstat/nmap/ps | grep -v нещата които си мисля, че знам + man/google за всички останали 3. AIDE/TripWare/audit/fschange - не е това идеята на тез тулчета, но ще е добре да се знае кои файлове как/защо/от_кой_сървиз се променят 4. незнам с какви тулчета за packet discovering разполагаш, но дори и едно ls -Rcalt / е по-добре от нищо преди да се почне голямато мазане 5. file level бекъп на каквото може и както може 6. svn/git - каквото ти повелява религията (cfg2html е много симпатично тулче ) 7. sandbox машина и (по възможност) почват да се вдигат услугите една-по-една... особенно ако ще съм администратор не само на сървъра ами и на услугите (и ще трябва да изпълнявам заявки от рода: Качвам файл в CMS-a, ама искам да могат да виждат само хора на които 4-ят символ от името е затворена гласна и потенциалният приход от тях е 4к юана месечно ) ___ Lug-bg mailing list Lug-bg@linux-bulgaria.org http://linux-bulgaria.org/mailman/listinfo/lug-bg ___ Lug-bg mailing list Lug-bg@linux-bulgaria.org http://linux-bulgaria.org/mailman/listinfo/lug-bg
Re: [Lug-bg] наследяване на сървъри
On Thu, Jun 20, 2013 at 01:43:35PM +0300, Spam wrote: Изклучи ги от мрежата и слушай за викане :-). R. Mason ;) Това би дало ефект за преброяване на юзърите. signature.asc Description: Digital signature ___ Lug-bg mailing list Lug-bg@linux-bulgaria.org http://linux-bulgaria.org/mailman/listinfo/lug-bg
Re: [Lug-bg] наследяване на сървъри
Вместо да гледаш всеки /etc/init.d script провери кои са инсталирани от rpm package rpm -qf /etc/init.d/ другите ще трябва да ги чекнеш на ръка :) след това за всички тези пакети пусни един verify: rpm -V rpm_package това цялото освен ако SuSE не е безумно старо :) Нещото от което найстина трябва да те е страх в SuSE е някой да не е пипал дирекно conf files а да не е ползвал yast/yast2 :))) има много хора които сега биха ме hate-нали :) но те си знаят :) преди да правиш каквото и да било :)) защото се чуха разни патчвай и тн :) това хубаво ама ако намажеш нещата си загубен :) направи си копие на машината което можеш да restor-неш 100% и да я имаш работеща за по малко от час :) тогава ръгай :) tools колкото искаш аз лично бих направил един ReaR за да съм сигурен :) или ако имаш mirror го счупи докато ръгаш и ако скапеш sync на обратно! Успех! 2013/6/20 Yordan Radunchev yor...@radunchev.com On Thu, Jun 20, 2013 at 11:11:20AM +0300, Peter Pentchev wrote: On Thu, Jun 20, 2013 at 10:58:17AM +0300, Peter Pentchev wrote: On Thu, Jun 20, 2013 at 10:30:43AM +0300, Vasil Kolev wrote: В 07:23 +0300 на 20.06.2013 (чт), Yordan Radunchev написа: Хора, попадали ли сте в ситуация да ви връчат сървър, за който няма нито ред документирано? Какво работи, защо работи, кой го ползва? При това сървъра си е production, има над 400 дена ъптайм, ползва се сериозно... Какво правите в такава ситуация, какви са стъпките за инвентаризиране? Идентифицарне на потребителите в passwd, на сървисиз...? От къде почвате и как бихте подходили? r., yra ___ Принципът е да разбереш какво точно се случва на машината (какво прави, какви услуги и хора има на нея), да ограничиш достъпа на който не трябва да го има и да почнеш малко по малко да update-ваш каквото има нужда (щото всичко с 400 дни uptime поне kernel трябва да му се смени). Може да тръгнеш от отворените портове или процесите в ps auxw, може първо от passwd файла, от инсталираните пакети (въпреки че това е малко тежко) и т.н., ...от startup скриптовете (макар че това напоследък е малко сложно - допреди пет години си имахме SysV-style init scripts и BSD-style init scripts, после се нароиха всякакви upstart-и (а тук каква игра на думи има...) и какво ли не). Като при гледане на startup-скриптовете не забравяш две, не, три, уф, не, четири неща: - не само имената на скриптовете; понякога може да си заслужава да вземеш да ги отвориш, за да видиш дали някой кръгъл иди... така де, администратор с много опит и оправдано самочувствие не е решил да променя нещо директно в тях, а не в конфигурационните им файлове Тази точка може да бъде силно улеснена, ако администраторът не е бил твърде откачен и ти е оставил система, в която повечето, ако не всички, startup-скриптове са инсталирани през някаква пакетна система, която пази контролни суми на файловете и можеш с една команда да ги провериш. Поздрави, Петър Благодаря, много ценни съвети. Захващам се. Системата е SLES, има си zypper, ще ми каже поне нещата инсталирани през него. Ще му пусна и cfg2html - ще спести малко време. Но идеята да се отварят стартъп скриптовете е златна - наистина има вероятност да е мазано вътре и един бог знае какво всъщност пускат. Сървърите са 5, на един от тях намирам puppet... но ме е страх да се надявам още, че е използван за всичките, върде лесно би било. По тях са работили доста хора във времето, повечето от които в момента вече не работят тук. Последно на един индиец са били поверени, но той е бил в същото положение в което съм и аз. Отделно с него не говорим един английски, та ще е трудна комуникацията... R., yra ___ Lug-bg mailing list Lug-bg@linux-bulgaria.org http://linux-bulgaria.org/mailman/listinfo/lug-bg ___ Lug-bg mailing list Lug-bg@linux-bulgaria.org http://linux-bulgaria.org/mailman/listinfo/lug-bg
Re: [Lug-bg] наследяване на сървъри
On Thu, Jun 20, 2013 at 02:57:42PM +0300, Orlin Vasilev wrote: Вместо да гледаш всеки /etc/init.d script провери кои са инсталирани от rpm package rpm -qf /etc/init.d/ другите ще трябва да ги чекнеш на ръка :) Нещото от което найстина трябва да те е страх в SuSE е някой да не е пипал дирекно conf files а да не е ползвал yast/yast2 :))) има много хора които сега биха ме hate-нали :) но те си знаят :) преди да правиш каквото и да било :)) защото се чуха разни патчвай и тн :) това хубаво ама ако намажеш нещата си загубен :) направи си копие на машината което можеш да restor-неш 100% и да я имаш работеща за по малко от час :) тогава ръгай :) tools колкото искаш аз лично бих направил един ReaR за да съм сигурен :) или ако имаш mirror го счупи докато ръгаш и ако скапеш sync на обратно! Успех! а, дума да не става да се бута каквото и да било преди да се разбере със сигурност какво, как, кой, къде, защо... signature.asc Description: Digital signature ___ Lug-bg mailing list Lug-bg@linux-bulgaria.org http://linux-bulgaria.org/mailman/listinfo/lug-bg
Re: [Lug-bg] наследяване на сървъри
On Thu, Jun 20, 2013 at 09:22:28PM +0300, Yasen Pramatarov wrote: Другите ти дадоха много ценни идеи вече. Моята е далеч по-проста – аз бих подходил първо с контакт с човека или хората, дето са отговорни за тая машина и нещата, които се въртят на нея. Та най-лесно и ценно е преди да пишеш и бришеш по машината, да опиташ да издириш инфото от тези. Почти никога не дава конкретни, бързи и лесни отговори, но според мен е най-важният начин да доближаване до такава машина. ;) Точно такъв ми я повери - каквото знаеше, вече го знам :) но то е нищо. Картинката вече се изясни. Ползва се като dead drop за размяна на файлове м/у клиенти отвън и хората отвътре, които работят за тях. Но е толкова нагласено решение, че е трудно да се каже защо работи :) Примерно crontab на root има следния запис: */5 * * * * /opt/script.sh */15 * * * * /opt/script1.sh От всички, които са я поддържали, никой не си е направил дори собствен акаунт, всички си работят с root... Като за учебник... signature.asc Description: Digital signature ___ Lug-bg mailing list Lug-bg@linux-bulgaria.org http://linux-bulgaria.org/mailman/listinfo/lug-bg
Re: [Lug-bg] наследяване на сървъри
Пожелавам ти успех колега :) За 400 дена няма ли да крашне това нещо. Я го изключи и му махни кабела от мрежата и го прегледай обстойно. Бизнеса може да понесе няколко часа dowtime. +++ Поздрави! Васил Петров Може би не отговарям, защото: http://6lyokavitza.org/mail +++ На 20 юни 2013, 22:25, Yordan Radunchev yor...@radunchev.com написа: On Thu, Jun 20, 2013 at 09:22:28PM +0300, Yasen Pramatarov wrote: Другите ти дадоха много ценни идеи вече. Моята е далеч по-проста – аз бих подходил първо с контакт с човека или хората, дето са отговорни за тая машина и нещата, които се въртят на нея. Та най-лесно и ценно е преди да пишеш и бришеш по машината, да опиташ да издириш инфото от тези. Почти никога не дава конкретни, бързи и лесни отговори, но според мен е най-важният начин да доближаване до такава машина. ;) Точно такъв ми я повери - каквото знаеше, вече го знам :) но то е нищо. Картинката вече се изясни. Ползва се като dead drop за размяна на файлове м/у клиенти отвън и хората отвътре, които работят за тях. Но е толкова нагласено решение, че е трудно да се каже защо работи :) Примерно crontab на root има следния запис: */5 * * * * /opt/script.sh */15 * * * * /opt/script1.sh От всички, които са я поддържали, никой не си е направил дори собствен акаунт, всички си работят с root... Като за учебник... ___ Lug-bg mailing list Lug-bg@linux-bulgaria.org http://linux-bulgaria.org/mailman/listinfo/lug-bg ___ Lug-bg mailing list Lug-bg@linux-bulgaria.org http://linux-bulgaria.org/mailman/listinfo/lug-bg
