Security Log Management by Dr. Stephen Drazhev

Икономически университет – Варна Център „Магистърско обучение”

РЕФЕРАТ на тема „LOG MANAGEMENT”

По Безопастност и защита на Microsoft мрежи и приложения

Изготвили:

Проверил:

Фатих Демирел, ФН 9301

Проф. Д-р. Стефан Дражев

5 курс, спец. „Информатика – СС”

Варна 2011

СЪДЪРЖАНИЕ

Какво е Log?......................................................................................................................3 Кои са източниците на Log?...........................................................................................3 Грешки в log management................................................................................................4 Време за печат..................................................................................................................4 Архитектура на Active directory логове.........................................................................4 За колко време трябва да запазим логовете?................................................................5 Интеграция на лог файлове ...........................................................................................5 Управление на log-файлове по отношение на стандарти............................................5 Управление на log-файлове UNIX/Linux системи........................................................6 Дисковото пространство:................................................................................................7 Ефективността за въздействието на Вземане на log-файлове.....................................7 В Kритични сървъри вземане на log-файлове..............................................................8 Управление в апарати на мрежи и защита..................................................................13 Вземане на log-файлове в бази данни .........................................................................13 Log-файлове в приложения..........................................................................................13 С SSIM (Symantec Security Information Manager) отдалечено вземане на log-файлове .........................................................................................................................................14 С SQL Server Change Data Capture да се вземи log-файлове които се променени. .15 Постижения....................................................................................................................20 Използвани Литаратури................................................................................................23

Какво е Log? Повечето приложения или компютри с различни формати записват процеси, които се правят, за да се информират потребителите,като тези данни, които са записани се наричат Log.

Кои са източниците на Log ? Защитна стена Усещане на атака\спиране системи Network апарати Сървър, PC и Laptop Приложения (SharePoint, IIS, Exchange) Бази данни (MsSQL, MySQL ) Антивирусни програми VPN Usb, CD Proxy приложения

Логовете преди се използваха, за да се решават системни проблеми, но днес логовете се вземат за стандарти и защита. Като FISMA, HIBAA, SOX, COBIT, ISO 27001 международните стандарти са направили задължително управлението на логове. Целта на Log management проектите е клиенти, сървъри и firewall устройства, които произвеждат лог файлове, да събира данни и да ги конвертират с по-разбираемо значение . Аз ще направя база данни, с които може да се извеждат данни за обяснение на логовете. Когато срещнем грешки в системата ни и търсим решение ще можем да въведем event id и source и да намерим решение. 3

Има много програми, които ни дават професионална помощ като infraskope, event log explorer, log parser, които дават възможност да изследваме логовете на системата ни. Аз ще анализирам продукта Infraskope ,който е създаден от фирмата на Karmasis. Infraskope от много време дава решение на средни и големи фирми. С лесна инсталация, интеграция и ефективност дава на фирмите голямо удобство. Kогато не ви е ясно можете да разгледате логовете на еvent id от този сайт http://www.eventid.net/

Грешки в log management -Само системни администратори могат да разглеждат и анализират(създава риск) -Изобщо без да се разглеждат се изтриват -Краткосрочно записване на логове или отделяне на малко пространство за логове -Не се анализират или само когато има проблем се разглеждат -Игнориране на логове в приложенията

Време за печат Информацията на hash (резюме) от Получаваните лог файлове трябва да бъде с точно време подписано и архивирано. Защото системните администратори или други могат да променят лог файловете и ние трябва да докажем ,че не са променени. Time сървърите могат да бъдат пак променени. Можете да използвате услугите на фирмите, които предлагат да подписват с време данните ви.

Архитектура на Active directory логове Когато се отвори компютър, се говори ,че може да се направят други процеси и да се получи билета на *Kerberos (TGT). В този процес се записват случай в DC Security лог с номер 672 (Authentication Ticket Granted)(Win2003). След това за GPO(group policy) и други процеси се създават две event с номера 673 (Service Ticket Granted). След тези процеси веднага се променя датата на logon. Този случай се записва като 646 (Computer Account Changed). Потребителите когато отварят компютрите си говорят с Domain Controller. За това е възможно да изследваме потребителите кога се логват и на кои сървъри се постигат. 4

*Керберос е удостоверяващ източника протокол използващ синхронизращ такт. Широко се използва от системите за удостоверяване на източник на данни. Използва симетрични ключове и изисква трета удостоверяваща страна. Разширения на Керберос използват и публични ключове през определени фази от удостоврението. Подслушваща трета страна може да компроментира връзката: изпращайки отново прихванат временен ключ, може да се разбере и окончателния ключ. Използват се два абстрактни модула: Удостоверяващ сървър (Authentication server - AS) и Гарантиращ билетен сървър (Ticket-granting server - TGS). Удостоверяващия сървър знае всички ключове и отговаря при въвеждане на парола с билет за достъп, съдържащ ключа на удостоверявания. Билета за достъп се изполва допълнително с нов сесийен ключ за достъп до билетния сървър. Подобно протича и удостоверяването за други подобни услуги на билетния център.

За колко време трябва да запазим логовете? То се променя в съответствие със законите и стандартите,но общоприетото време е 90 дена за онлайн логовете и година за запазване на архивите .

Интеграция на лог файлове Интеграцията на log-файловете е един от най- важните въпроси, за да се докаже ,че log-файловете не са променени. В UNIX можем да променим режима да работи само при добавяне на файлове. Тогава може само да се добави, но не може да се промени т.е. съдържанието ще остане непроменено. Архивираните файлове преди да вземат резервно копие, ако се сложи електронен печат за време, ще може да се докажат че са непроменени.

Управление на log-файлове по отношение на стандарти Безопасността за данните насочени към стандартите, законите,наредбите и докладите са дали голям акцент върху действията, предприети в това отношение са задължителни. Всеки стандарт иска различни неща, но в основата си той е единствен и за това с една лог файлова система може да се работят съвместими стандарти.

Управление на log-файлове UNIX/Linux системи В UNIX системата обикновено се вземат логове Syslog. Приложения,с които работи системата може да изпращат логове чрез Syslog върху системата или върху отдалечена система. Но с този класически метод в системата, може да се работи с команди или с промени върху файлове,които не може да се контролират. Почти всички търговски системи UNIX имат уникалната инфраструктура за audit и тази инфраструктура, като се използва, командите работещи в система може да се вземат като log-файлове .Например, PCI DSS когато искат някои данни за логове може да използваме BSM инфрастрактура.

*Solaris за BSM може да се помогне когато направим конфигурация както е по долу: /etc/security/audit_control На този файл за да добавим долното ред

flags:lo,-fr,+fc,+fd и /etc/security/audit_user На този файл ,за да добавим долния ред. root:ex,fr,fw,+aa:no оторизиран потребител: ex fr,fw,+fm:no В системите на Windows вземането на log-файлове може да е малко по- лесно,но логовете не са толкова ясни.

Дисковото пространство: Един от най-големите проблеми за анализиране на log-файлове е колко пространство ще отделим за логове в системата ни и колко логове произвежда.По принцип се правят грешки и се мисли, че не е толкова важно да се запазят дълго време log-файловете , затова не се отделя достатъчно пространство.

За една година средно дисково пространство се изчислява; 365 ден x 24 час x 3600 секунди x 100 x 200 byte = 580~ gigabyte / yıl . Разбира се, тази стойност е некомпресирани сурови данни. Е, тази стойност се намалява с компресия. Ако използвате базата данни дневници трябва да умножите това число по 2-3.

Ефективността за въздействието на Вземане на logфайлове Това се променя за всяка система ,която анализира log-файлове.Ако се вземе да се анализира от системата целите log-файлове и се изпраща изцяло може да има проблем за перформанса в системата и мрежата ви.За това обикновенно се използват системи ,които работят с логиката на агент и тогава се изпраща на централата за log-файлове,но не едновременно за това не тежи на системата ви. Когато анализираме логове в бази от данни също трябва да се внимава и само да се анализират важни процеси. Иначе базата от данни няма да може да върши основната му цел. Когато искате да измервате вземането на log-файлове за ефективност на въздействието избирайте всички select заявки от база данните и анализирайте загубите от това въздействие. Този процес ще доведе средно до 30% от производителността. Когато се направи грешно вземане на log-файлове в системата на мрежата за безопастност ще може да отворите DDOS. Ако запишите на диск log-файловете ,които получавате при тежък трафик, системата ви може да бъде неактивна.

В Kритични сървъри вземане на log-файлове Процеса на критични сървъри и вземане на log-файлове е 1.

Определяне на критични сървъри :

Първата стъпка е да се определят критичните сървъри. Този процес е за 5-10 сървърни фирми и може да не е много валиден. Но броят на сървърите във фирмите когато са 500-1000 или дори повече тогава става сериозно да се определи. Защото когато се увеличават източниците за вземане на log-файлове става много по -трудно да се анализират и това създава сериозна тежест. Тогава става много важен броя на Event Per Second (случаи за секунда). Когато Event Per Second се прехвърли може да имате загуба на log-файлове. Затова трябва да направите списък с критични файлове. Критериите на определяне на критичните файлове; -За важността на стартираните приложения. Например, сървъри, които запазват информация за заплатите и човешките ресурси. -Което запазва тези критични услуги. Например, като IIS, FTP и др сървъри които дават услуги за местоположение. -Може да няма критични файлове, услуга или приложение върху сървъра ,но за сервизите, които работят върху него може да е опасно да работят с различни акаунти. И това влиза в нашите критични сървъри. 2. Определянето на видовете log-файлове трябва да бъде предприето следното: На този етап в операционната система на сървъра се определя кои logфайлове трябва да се вземат . Ако даваме пример на Windows server ще бъдат както е по долу;

  

System Log Application Log Security Log

Всеки компютър идва серийно оборудван освен тези политики за анализиране ,има и различни механизми за управление на log-файлове. Например в Active Directory върху DC (Domain Controller) има Directory Service или върху DNS сървър може да има регистри, които записват dns логове. Тука

трябва да се определи точно какви log-файлове ще анализират, и трябва да избягваме да не се натовари излишно системата ни. В фигура 1 типове системи и приложения event е; I. Information : Дава информация ,че някакви приложения или сервизи се инсталират успешно. II. Warning : Дава информация ,че напред можем да срешнем проблеми. И за този случай да вземем мерки. III. Error : Дава информация ,че някои сервизи или приложения докато работи е срещнал някакви проблем.

Фигура-1 Типове на Security event са; I. Success : Записва когато се случват успешни случаи. II. Failure : Процеси, които са направени са неуспешни. В противен случай данните от регистъра искаме да направим запис . Фигура -2 в мониторинга на политиките и характеристики са, както следва: За да може да се вземат security логове трябва да се създаде чрез операционни системи политики за анализа. В противен случай не можем да

стигнем до данните на регистъра. В фигира 2 политиките за анализ и свойства са;  Account Logon : Даннните за потребителите ,които са logon на Domain.  Account Management : Данните на откриване,изтриване и променяне на групи или потребители.  Directory Service Access: Данните, за които потребителите са отворили обекти на AD (Active Directory).  Logon Events : В локална или мрежа, данни на потребители които са logon/logoff.  Object Access : Изследване на потребителите, които правят промени във файлове и папки.  Policy Change : Анализира промени в политики.  Privlege Use : Записва промяна в системи. Например промени в системни часовници.  Process Tracking : Анализиране данните на работещи програми.  System Events: Данните които за restart и shutdown .

Фигура 2

За да можете да конфигурирате тези политики трябва да сте член от група на администратори. За всички политики стига да изчертавате като Sucess/Failure. Значи позволява да се анализират успешни или неуспешни процеси.

Събиране на log-файлове в период от време:

Трябва да се определи, че преди да се събират log-файлове, трябва да се събират определени периоди от време. В сървъри когато минава препоръчаната стойност в операционната система ще има проблем с непрекъснатостта на бизнеса. За това преди да е в критични размери трябва да се вземат мерки. Ако разгледаме структурата на регистъра на събитията на Windows, размера на регистрите не трябва да надвишава 300 MB. С Win 2008 не е проблем да е стойност 16.4 GB. Другите стойности са накратко, както следва; • • •

Win2003 16 mb Win2003 DC 132 mb Win 2000 и XP 512 kb

Размера на log-файлове можа да стигне критични размери,като във фигура 3 можете да разгледате “When maximum log size is reached” .

Фигура-3 •

Overwrite events as needed: Когато достигне критичната стойност размера на log-файловете, ще бъдат изтрити старите log-файлове. Когато не вземем на време ще загубим log-файлове.

•

Overwrite events older than: Размера на log-файлове когато достигна критичната стойност, новите log-файлове ще се запишат върху постарите от 7 дни.

•

Do not overwrite events: Това означава, че няма да се запишат върху старите log-файлове и няма да бъдат изтрити никакви случаи. log-файлове може да бъдат изтрити ръчно. Но когато стигне критичната стойност може да се открие в операционната система проблеми.

Препоръка; В критични сървъри опция на “When maximum log size is reached” да е “Overwrite events as needed”.

4. Определяне на критични регистри:Когато започне процеса на събиране на log-файлове от определени сървъри, да се определят правила за аларма и трябв да се определят критични лог регистри в сървъра. Например;

• • • • • • •

За проследяване на Logon/logoff Event Id 528, Неуспешно влизане в система Event Id 529, Изтриване на лог файлове Event Id 517, За проследяване на променяне на акаунт Event Id 642, За да се определи кои потребители влизат в системата чрез мрежа Event Id 540, В уеб сървър променяне в index.html, Спиране сервиза на Dhcp сървър т.н.

5. Създаване на реално време Аларма и механизмите за мониторинг: Вземане на log-файлове в критични сървъри пети етап е аларма и механизма за мониторинг наблюдение. Събиране на логове в определени сървъри и за нас критични log-файлове трябва да бъдат информирани на съответните лица чрез маил, съобщение или popup и да се вземат мерки, без да губим време.

6. Създаване на екрани за доклади: Освен анализиране на реално време другият процес е log-файлове за съществуващи политики и удобни на критериите са седмично, месечно или годишно да се създадат доклади и да се изпращат на съответните лица с формата на pdf, xlsx или docx.

Управление в апарати на мрежи и защита В тези категории са Router, switch, wireless, VPN системи, firewall и IPS и в тези системи обикновенно няма да има възможност да се инсталират допълнителни програми за това се използва syslog, за да изпраща log-файлове.

Вземане на log-файлове в бази данни В база данни вземане на log-файлове се предпочита с два начина едното използване на инфрастрактура на audit ,а другата е система на анализиране пасивно трафика на бази данни в сървъра и да се запази в смислен начин. Избиране на начина трябва да се направи според изискванията на бази данни. Ако имате притеснение за въздействието можете да избирате пасивно вземане на log-файлове.

Log-файлове в приложения При вземане на log-файлове най-неприятен компонент обикновено са разработените приложения. Тези приложения са написани в съотвествие с изискването за това дали липсват свойства за вземане на log-файлове или е 13

много слаб. За такива приложения може да се направи вземане на log-файлове за бази данни и така може да се намери решение за проблема, но ако на програмисти обясните изискваниява ви за вземане на log-файлове може да имате по хубави решения. Например приложения ,които никакви не вземани log-файлове и управляван с отдалечен telnet, може да вземат логове чрез *Snort. Долу правилата на Snort за всички telnet връзки и характери, които минават през връзки ще се запишат както е удобно за разбиране. log tcp any any <> $SERVER_IP 23 (session: printable;) И други приложения (ftp, sql vs) можете да анализирате същия начин пасивно.

С SSIM (Symantec Security Information Manager) отдалечено вземане на log-файлове В SSIM интерфейса на log management раздел на "System" инсталирайте колектора и ще намерите конфигурации. "Microsoft Windows Event Collector" е колектор в windows операционни системи от сървър и позволява клиенти да вземат event логове. Конфигурация за сървъра ,който ще вземе log-файлове ще влизате както долу и за да вземате отдалечени логове.Тук е важното акаунта да има позволение да чете event logs..

С SQL Server Change Data Capture да се вземи logфайлове които се променени

Във фирми един от най-големите проблеми е историческата информация ,която трябва да поддържат да се промени или изтрие. До версията на SQL 2008 трябваше да се запише под таблиците trigger или трябваше да промени пакетни програми. Тези тригери разбират променени регистри и позволяват да се запише какъвто формат искате. С SQL Server 2008 идва едно свойство от името на CDC (Change Data Capture) и е много бързо и ефективно, че работи директно върху логове. Като например напишите UPDATE и работите както е долу UPDATE CUSTOMERS SET ACTIVE=1 В таблицата на CUSTOMERS да речем има създадени 20 области ,обаче ние само областа направихме update. Значи SQL Server transaction в логове прави процес само за една област. Ето Change Data Capture (след това ще се нарича CDC) само чете тази информация и се записва за данните в log-файлове. Вие когато се конфигурирате CDC за определено време можете да вземате логове или да изтриете след от определена дата. Тука когато пишете един script датите ви можете да вземате на някакви warehouse и после да изчистите от системата ви.

Сега да видим CDC как работи 1. първо да създадем таблица. CREATE TABLE dbo.Customers(ID int Primary Key NOT NULL,Name varchar(100) NOT NULL,Address ) varchar(500) NOT NULL) 2.Ще направим enable CDC в база данни. EXEC sp_cdc_enable_db 3.В таблицата ни да направим enable yapalım CDC.

EXEC sp_cdc_enable_table @source_schema = N'dbo',@source_name = N'Customers',@role_name = NULL,@filegroup_name = N'',@supports_net_changes =1 Когато направим enable CDC под tables се създават таблици както е на долу.

• •

cdc.captured_columns – запази критични области. Тази таблица може да се промени ръчно. cdc.change_tables – Ще има данни за проследяване на промени за таблиците. 16

• •

cdc.ddl_history – Данните за схема cdc.lsn_time_mapping В основната таблица всички процеси за транзакция се записва в тази таблица и има данни за процеса на реда.

И автоматично се създадават два job. Тези, cdc.TestDb_capture job:В log-файлове чете данните и се записват данните, които са променени cdc.TestDb_cleanup job: Изтрива тези, които са записани след определено време. 4.Сега да се добави един регистър. INSERT INTO CUSTOMERS (1,'MER','TRKYE')INSERT INTO CUSTOMERS (2,'AHMET','STANBUL') 5.Да направим UPDATE . UPDATE CUSTOMERS SET ADDRESS='ANKARA' WHERE ID=1 6.Да направим DELETE DELETE FROM CUSTOMERS WHERE ID=1 Сега направихме процеса 2 insert,1 update и 1 delete. Тука в системата трябва да запишем логове за тези регистри. В системата може да видим регистри директно или с параметъра на дата (table valued function). В тези таблици регистри се записват с log sequence number (lsn). Когато искаме да постигмен регистри за log-файлове за цялата таблица select * from cdc.dbo_customers_CT. Формата на таблицата cdc.<schema>_<tablename>_CT . table valued функции се използват както е на долу. DECLARE @from_lsn binary(10), @to_lsn binary(10);

--Намираме минимален номер на lsn. ET @from_lsn = sys.fn_cdc_get_min_lsn('dbo_customers'); --намираме максималният номер на lsn . SET @to_lsn = sys.fn_cdc_get_max_lsn(); -- С процеса на зависимост с CDC се използват функциите на CDC . SELECT * FROM cdc.fn_cdc_get_all_changes_dbo_customers(@from_lsn, @to_lsn, 'all'); Тука разглеждаме резултата както е на долу.

Както виждаме области ,които са повече от 4 и са промени в системата ни не се записват. Тука __$start_lsn log: Е съдържа данните на sequence number. Тук се постига датата за регистъра. __$operation:Използва се за 2 Insert, 4 Update и 1 Delete. __$operation:1 Insert,Delete 0 Update

За да видим датата на регистъра използваме функция на sys.fn_cdc_map_lsn_to_time.

select sys.fn_cdc_map_lsn_to_time(__$start_lsn) as Време за регистър, *from cdc.dbo_customers_CT За да се изтриват тук създадените log-файлове ще запишем команда на sp_cdc_cleanup_change_table. -- долу командата изчистват log-файлове за три дни. declare @lsn binary(10); set @lsn = sys.fn_cdc_map_time_to_lsn('largest less than or equal',getdate()-3); exec sys.sp_cdc_cleanup_change_table @capture_instance = 'dbo_Customers', @low_water_mark=@lsn --за да направим disable CDC sp_cdc_disable_db, sp_cdc_disable_table EXECUTE sp_cdc_disable_table@source_schema = N'dbo',@source_name = N'Customers',@capture_instance = N'dbo_Customers' Резултат: 1.CDC наистина е нужен и полезен. 2.В системата може да се изведат log-файлове както insert, update и delete. 3.Ако е в update няма промени не запазва излишно място. Например: UPDATE CUSTOMERS SET NAME=NAME като работите не записва никакви log-файлове, защото няма промени.

Постижения -кои компютри имат най-голяма мрежова активност(симптоми на (вируси, троянски коне) -кой какви документи изпраща чрез Msn, icq, skype... -Анализиране на перформанс -Откриване на успешни и неуспешни достъпи -Незабавно събиране на доказателства за разкриване на нарушенията и осигуряване -проследява се кой използва без лиценз програми и операционни системи - Хармония на FISMA, HIBAA, SOX, COBIT, ISO 27001 международните стандарти и закони -корпоративни закони и стандарти -кой има достъп с Vpn връзка и по кое време -откриване на оторизиран и не оторизиран достъп -Проследяване на В файл сървър ,достъп до критични файлове и дейности ( изтриване, създаване, променяне на собствеността) -С Вземането на логове от приложения на ESX и т.н., се определя кой създава сървъра, изтрива го или го изключва -Определяне като trojan приложения които работят от страна на клиентите -Проследяване на кои потребитети, по кое време и в кои компютри са online -Изчезва риска от изтриване на логове -Намираме с кой принтер е разпечатано и от кого -Кой иска достъп и с кой порт и компютър -В архитектурата на печат сървъра- какво се разпечатва и в кое устройство -Проследяване на потребителите по всяко време и с кои компютри работят -Незабавно разкриване на нарушенията и осигуряване на събирането на доказателства -Изследване на достъпа до критични файлове 20

-Рискът от загуба и изтриване на досиета изчезва -Проследяване на Системните администратори (в големите фирми трябва да се открива друг отдел за изследване на логове освен системните администратори. Защото логовете могат да се променят). -кой какво купира с usb дискове -Проследяването на промените Хардуер, IP, име на хост -Проследяването на програми като Msn, icq, skype -Могат да бъдат записани VoIP разговори -Определяне на приложения, с които работи клиента като sniffer (cain, wireshark) -Кои са направили port scan -Кои потребители използват P2P (Emule, Kazaa v.s) приложения ( P2P (Pear to Pear) е технология, позволяваща потребители от цял свят да обменят информация помежду си - директно от един към друг компютър. В случая, както е показано на картинката. Връзката м/у компютрите се осъществява чрез специален сървър, който играе ролята на свързваща точка. Самата информация не минава през сървъра, а директно м/у потребителите. Какво ни позволява p2p технологията? В днешно време, голяма част от информацията в интернет пространството се пренася чрез p2p. Файлове, Музика, Видео и Телевизии се пренасят м/у потребителите. Сайтове като youtube, vbox7 и metacafe използват тази технология, за пренос на аудио-видео клипове м/у потребителите.) -Като вземем log-файлове в Mail сървър, ще открием кой, кога и на кого е изпратил маил -С вземане на IIS логове, ще проследяваме достъпи до фирмени уеб страници -С вземане на Call Center логове , ще можем да извадим рапорти кой, кога и от къде се е обаждал. (Банки, GSM оператори)

-С вземане на Tmg, Websense т.н. логове, ще може да се изпращат доклади на управители за достъпа на уеб страниците (facebook, cnn…) -Анализиране на логове за програми за отдалечен достъп и да разгледаме кой и на кой компютър е достъпен (Radmin, CA Remote т.н.) -С вземане на Firewall логове, можем да анализираме какви атаки се получават в кои ip адреси - При анализиране на Antivirüs логове , ще можем да разгледаме данните за вирусите. -С вземане на сървър security логове се открие кои сървъри , кои и кога се свързани (RDP) -С вземане на Mail security логове се откриват изпращачи на spam -Router, switch т.н. мрежови апарати с начина на syslog, snmp вземането на логове откриваме неоторизирани достъпи -Domain control и локалните потребителски акаунти се изследват, за да проследяват промените на груповите свойства (добавяне на потребители на domain admin група) -Приложения,в които има идентифициране с потребителско име и парола за Електронна търговия, Интернет клон и др се определя с атака на паролите (в 5 мин пробваме парола повече от 100 пъти) -Логове на Web дейности

Използвани Литаратури 1-http://www.sans.org/reading_room/whitepapers/logging/ 2-http://chuvakin.blogspot.com/ 3-http://www.xmcopartners.com/ 4-http://technet.microsoft.com/en-us/ms376608 5-http://cagatayisikci.wordpress.com