<?xml version="1.0" encoding="UTF-8"?><!-- generator="wordpress/MustLive Edition" -->
<rss version="2.0" 
	xmlns:content="http://purl.org/rss/1.0/modules/content/">
<channel>
	<title>Коментарі для запису: Хакерські війни</title>
	<link>http://websecurity.com.ua/2375/</link>
	<description></description>
	<pubDate>Sat, 18 Apr 2026 16:36:55 +0000</pubDate>
	<generator>http://wordpress.org/?v=MustLive Edition</generator>

	<item>
		<title>від: MustLive</title>
		<link>http://websecurity.com.ua/2375/#comment-267552</link>
		<pubDate>Sun, 01 Mar 2009 21:53:01 +0000</pubDate>
		<guid>http://websecurity.com.ua/2375/#comment-267552</guid>
					<description>&lt;blockquote&gt;Тобто на цьому в першу чергу варто зосередитися, так?&lt;/blockquote&gt;
На цьому в першу чергу. Але не тільки на цьому, окрім самого сайту, також варто звертати увагу на серверне ПЗ (і дірки в ньому) - веб сервер, інтерпретатори, СУБД та інши сервіси даного сервера. Через дірки в серверному ПЗ також проводять атаки.

Тому при проведені аудиту безпеки я досліджую і питання серверного ПЗ - досліджую уразливості класу Web Server/Application Fingerprinting.

&lt;blockquote&gt;Але ж тут є спосіб більш низького рівня: атака на ПЗ вебсервера&lt;/blockquote&gt;
Саме так - це також складова безпеки веб сайта. Причому вона залежить від адміна сервера (а не конкретного сайта), і тому подібні уразливості власнику сайта важче виправити (бо він повинен звертатися до хостера і той може не дуже швидко виправити дірки).

&lt;blockquote&gt;Хіба що приховувати типи та версії свого ПЗ, щоб ускладнити задачу.&lt;/blockquote&gt;
Так - приховувати версії. Назви конкретних серверних додатків приховувати не обов'язково, тим паче існують методи визначення який конкретно додаток є на сервері (незалежно від заявленої інформації). Щоб не було Fingerprinting уразливостей на сервері. Нехай люди думають, що встановлена остання й відповідно найбільш безпечна версія.</description>
		<content:encoded><![CDATA[<blockquote><p>Тобто на цьому в першу чергу варто зосередитися, так?</p></blockquote>
<p>На цьому в першу чергу. Але не тільки на цьому, окрім самого сайту, також варто звертати увагу на серверне ПЗ (і дірки в ньому) - веб сервер, інтерпретатори, СУБД та інши сервіси даного сервера. Через дірки в серверному ПЗ також проводять атаки.</p>
<p>Тому при проведені аудиту безпеки я досліджую і питання серверного ПЗ - досліджую уразливості класу Web Server/Application Fingerprinting.</p>
<blockquote><p>Але ж тут є спосіб більш низького рівня: атака на ПЗ вебсервера</p></blockquote>
<p>Саме так - це також складова безпеки веб сайта. Причому вона залежить від адміна сервера (а не конкретного сайта), і тому подібні уразливості власнику сайта важче виправити (бо він повинен звертатися до хостера і той може не дуже швидко виправити дірки).</p>
<blockquote><p>Хіба що приховувати типи та версії свого ПЗ, щоб ускладнити задачу.</p></blockquote>
<p>Так - приховувати версії. Назви конкретних серверних додатків приховувати не обов&#8217;язково, тим паче існують методи визначення який конкретно додаток є на сервері (незалежно від заявленої інформації). Щоб не було Fingerprinting уразливостей на сервері. Нехай люди думають, що встановлена остання й відповідно найбільш безпечна версія.
</p>
]]></content:encoded>
				</item>
	<item>
		<title>від: trovich</title>
		<link>http://websecurity.com.ua/2375/#comment-179638</link>
		<pubDate>Tue, 26 Aug 2008 06:11:19 +0000</pubDate>
		<guid>http://websecurity.com.ua/2375/#comment-179638</guid>
					<description>Гаразд, з термінологією визначилися.
Давай поглянемо на такі рівні "взлому": якщо сайт написано на динамічній мові (PHP/Perl/etc) з використанням СУБД, то є шанс отримати а) адміністративний доступ; б) доступ до даних; в) зіпсувати дані; г) розмістити шкідливий код. Тобто на цьому в першу чергу варто зосередитися, так? Я саме про цю складову питаю. Звісно, вживати слово "неможливо" - це невірно, вірнішим було б "занадто великий проміжок часу" для вирішення задач а-в. 
Але ж тут є спосіб більш низького рівня: атака на ПЗ вебсервера, будь то інтерпретатор PHP чи Apache чи nginx чи ще щось. Тут, я розумію, гарантій жодних. Адже вразливості знаходять постійно, і вчасне оновлення ще не гарантує захищеності. Хіба що приховувати типи та версії свого ПЗ, щоб ускладнити задачу. Ще що тут можна зробити?</description>
		<content:encoded><![CDATA[<p>Гаразд, з термінологією визначилися.<br />
Давай поглянемо на такі рівні &#8220;взлому&#8221;: якщо сайт написано на динамічній мові (PHP/Perl/etc) з використанням СУБД, то є шанс отримати а) адміністративний доступ; б) доступ до даних; в) зіпсувати дані; г) розмістити шкідливий код. Тобто на цьому в першу чергу варто зосередитися, так? Я саме про цю складову питаю. Звісно, вживати слово &#8220;неможливо&#8221; - це невірно, вірнішим було б &#8220;занадто великий проміжок часу&#8221; для вирішення задач а-в.<br />
Але ж тут є спосіб більш низького рівня: атака на ПЗ вебсервера, будь то інтерпретатор PHP чи Apache чи nginx чи ще щось. Тут, я розумію, гарантій жодних. Адже вразливості знаходять постійно, і вчасне оновлення ще не гарантує захищеності. Хіба що приховувати типи та версії свого ПЗ, щоб ускладнити задачу. Ще що тут можна зробити?
</p>
]]></content:encoded>
				</item>
	<item>
		<title>від: MustLive</title>
		<link>http://websecurity.com.ua/2375/#comment-179523</link>
		<pubDate>Mon, 25 Aug 2008 22:43:48 +0000</pubDate>
		<guid>http://websecurity.com.ua/2375/#comment-179523</guid>
					<description>Сергію, тут потрібно уточнювати. З однієї сторони всі сайти можна похакати (використовуючи будь-які засоби), а з іншої - чи вважати це за хак в залежності від використаних засобів.

Наприклад, одне діло використання веб уразливостей, а інша річ - через соціальну інженерію або віруси викрасти логін і пароль до адмінки чи фтп. Є різні хакерські засоби, деякі відносяться до веб безпеки, інші відносяться до "безпеки розуму" та безпеки ПК. До того ж, для зменшення ризиків сайт можна розмістити тільки в локальній мережі (без доступу з вебу), а той на локальному ПК не підключеному до Мережі, щоб максимально його захистити.

Але навіть в даних випадках залишається ще можливість атаки через віруси і фізичний доступ до комп'ютера. Тоді для максимального захисту потрібно буде сервер з сайтом помістити в сейф :-). Й при цьому бажано забути код до нього, щоб через соціальну інженерію (або "фізичний вплив") ніхто до сайту не дістався.

Тим не менше, головне питання, на яке я звертав увагу в пості, що є взломом сайту. Одне діло взлом (через "о", щоб відрізняти від слів поламати і зламати) - хак сайту, інша річ - зламати сайт, тобто будь-яким чином унеможливити до нього доступ (чи фізично знищити кабелі або сервер, чи забити канал через DDoS). В першому випадку це буде інтелектуальний метод (хакерський), в іншому - брутальний (ламерський). І тому до хакерських війн я відношу лише перший метод і ті види хакерської діяльності, що його використовують.

А DDoS атаки не є хакерськими атаками (тому що в самій атаці майже немає інтелектуальної складової, хакерський елемент знаходиться лише на початковій стадії (створення бот-мережі) і саму атаку роблять боти), скільки б їх так не називали журналісти, до хакерських вони відносяться лише опосередковано. Тому до хакерських війн дані атаки не відносяться. Зазначу, що даний пост є передмовою до мого нового проекту, який я незабаром розпочну, так що слідкуй за новинами ;-).</description>
		<content:encoded><![CDATA[<p>Сергію, тут потрібно уточнювати. З однієї сторони всі сайти можна похакати (використовуючи будь-які засоби), а з іншої - чи вважати це за хак в залежності від використаних засобів.</p>
<p>Наприклад, одне діло використання веб уразливостей, а інша річ - через соціальну інженерію або віруси викрасти логін і пароль до адмінки чи фтп. Є різні хакерські засоби, деякі відносяться до веб безпеки, інші відносяться до &#8220;безпеки розуму&#8221; та безпеки ПК. До того ж, для зменшення ризиків сайт можна розмістити тільки в локальній мережі (без доступу з вебу), а той на локальному ПК не підключеному до Мережі, щоб максимально його захистити.</p>
<p>Але навіть в даних випадках залишається ще можливість атаки через віруси і фізичний доступ до комп&#8217;ютера. Тоді для максимального захисту потрібно буде сервер з сайтом помістити в сейф <img src='http://websecurity.com.ua/wp-includes/images/smilies/icon_smile.gif' alt=':-)' class='wp-smiley' /> . Й при цьому бажано забути код до нього, щоб через соціальну інженерію (або &#8220;фізичний вплив&#8221;) ніхто до сайту не дістався.</p>
<p>Тим не менше, головне питання, на яке я звертав увагу в пості, що є взломом сайту. Одне діло взлом (через &#8220;о&#8221;, щоб відрізняти від слів поламати і зламати) - хак сайту, інша річ - зламати сайт, тобто будь-яким чином унеможливити до нього доступ (чи фізично знищити кабелі або сервер, чи забити канал через DDoS). В першому випадку це буде інтелектуальний метод (хакерський), в іншому - брутальний (ламерський). І тому до хакерських війн я відношу лише перший метод і ті види хакерської діяльності, що його використовують.</p>
<p>А DDoS атаки не є хакерськими атаками (тому що в самій атаці майже немає інтелектуальної складової, хакерський елемент знаходиться лише на початковій стадії (створення бот-мережі) і саму атаку роблять боти), скільки б їх так не називали журналісти, до хакерських вони відносяться лише опосередковано. Тому до хакерських війн дані атаки не відносяться. Зазначу, що даний пост є передмовою до мого нового проекту, який я незабаром розпочну, так що слідкуй за новинами <img src='http://websecurity.com.ua/wp-includes/images/smilies/icon_wink.gif' alt=';-)' class='wp-smiley' /> .
</p>
]]></content:encoded>
				</item>
	<item>
		<title>від: trovich</title>
		<link>http://websecurity.com.ua/2375/#comment-179035</link>
		<pubDate>Sun, 24 Aug 2008 17:15:45 +0000</pubDate>
		<guid>http://websecurity.com.ua/2375/#comment-179035</guid>
					<description>От скажи мені, чи відповідає дійсності твердження, що "не існує сайтів, котрі не можна зламати"? Я так собі розумію, що в цю категорію засунули й дос. Але якщо мати на увазі саме описане тобою?</description>
		<content:encoded><![CDATA[<p>От скажи мені, чи відповідає дійсності твердження, що &#8220;не існує сайтів, котрі не можна зламати&#8221;? Я так собі розумію, що в цю категорію засунули й дос. Але якщо мати на увазі саме описане тобою?
</p>
]]></content:encoded>
				</item>
</channel>
</rss>
