Insecure Port Vs Secure Port

Insecure Port Vs Secure Port | Credits:

e-Learn Cyber Security

Insecure Ports vs Secure Ports

Insecure Port	Protocol	Description	Secure Port	Protocol	Description
21	FTP	Sends username and password in plaintext.	22	SFTP	Encrypts user credentials and data packets.
23	Telnet	Sends all info in plaintext; vulnerable to interception.	22	SSH	Encrypts terminal traffic; protects from sniffing.
25	SMTP	Sends emails without encryption; vulnerable to sniffing.	587	SMTP (TLS)	Encrypts emails between client and server.
37	TIME	Legacy protocol, mostly replaced.	123	NTP	Better error handling and accuracy.
53	DNS	Widely used but unencrypted.	853	DoT	Encrypts DNS with TLS, protects in transit.
80	HTTP	Unencrypted web traffic; vulnerable to sniffing.	443	HTTPS	Uses TLS to protect browser-server communication.
143	IMAP	Retrieves email without encryption.	993	IMAP (SSL/TLS)	Encrypts email retrieval traffic.
445	SMB	Unencrypted file sharing on Windows networks.	2049	NFS	Can be encrypted, but often blocked by firewalls.
389	LDAP	Unencrypted directory queries; vulnerable to attacks.	636	LDAPS	Adds SSL/TLS to secure directory access.

🇺🇦 Незахищені порти порівняно із захищеними

Незахищений порт	Протокол	Опис	Захищений порт	Протокол	Опис
21	FTP	Передає ім’я користувача і пароль у відкритому вигляді.	22	SFTP	Шифрує облікові дані користувача і передані дані.
23	Telnet	Уся інформація передається у відкритому вигляді; вразлива до перехоплення.	22	SSH	Шифрує термінальний трафік; захищає від перехоплення.
25	SMTP	Відправляє електронну пошту без шифрування; вразлива до перехоплення.	587	SMTP (TLS)	Шифрує пошту між клієнтом і сервером.
37	TIME	Застарілий протокол, майже не використовується.	123	NTP	Краще обробляє помилки, підвищує точність.
53	DNS	Широко використовується, але не шифрується.	853	DoT	Шифрує DNS через TLS, захищає під час передавання.
80	HTTP	Нешифрований вебтрафік; вразливий до перехоплення.	443	HTTPS	Використовує TLS для захисту з’єднання браузера з сервером.
143	IMAP	Отримання пошти без шифрування.	993	IMAP (SSL/TLS)	Шифрує трафік отримання електронної пошти.
445	SMB	Нешифроване спільне використання файлів у Windows-мережах.	2049	NFS	Може шифруватися, але зазвичай блокується фаєрволами.
389	LDAP	Нешифровані запити до каталогу; вразливі до атак.	636	LDAPS	Додає SSL/TLS для захисту доступу до каталогу.

🪟 На стартову сторінку

SIEM. Denny Roger

Denny Roger
https://www.linkedin.com/in/dennyroger/
LinkedIn Top Voice | SOC Builder | Cybersecurity Startup Builder | 23 anos de consultoria estratégica em cibersegurança | Master Coach | Triatleta
Сан-Паулу, Бразилия



SIEM (Security Information and Event Management):

Думаєш, що SIEM — це просто миготливі алерти? Тоді присядь, я покажу, як все працює насправді.
Справжній SIEM — це цикл. Живий механізм. І якщо хоч одна шестерня в цій машині вийде з ладу — все, прогавиш атаку і дізнаєшся про неї з новин. Тож розберімо цю систему по пунктах:

1. Збір журналів (Log Collection)

Усе починається тут. Немає логів — немає безпеки. SIEM бачить тільки те, що збирає. Жодних логів з фаєрволів, AD, кінцевих точок чи Microsoft 365? Це як намагатися скласти пазл без головних частин.

2. Обробка журналів (Log Processing)

Зібрав логи? Тепер їх треба привести до ладу. Фільтрація, нормалізація, уніфікація — усе має бути готове до аналізу. Інакше отримаєш цифрове звалище, в якому не розбереться ніхто.

3. Зберігання (Storage)

Де ти це все зберігаєш? І скільки часу? Тут в гру вступають Retention (строк зберігання або політика зберігання), Compliance (відповідність вимогам або дотримання нормативів) і політики зберігання. Бачив компанії, які отримували штрафи, бо видаляли логи через 15 днів. Без стратегії зберігання — болючі проблеми гарантовані.

4. Запити (Querying)

Дані є — а запитати вмієш? Тут вирішується, аналітик ти чи просто пасажир. Уміння ставити правильні запитання до логів — це те, що відрізняє ефективний SOC від загублених у логах людей.

5. Кореляція (Correlation)

А ось і магія. SIEM зв’язує події: підозрілий логін + нетиповий аплоад + нічний трафік = інцидент. Правильна кореляція — це коли бачиш загрозу до того, як вона стане проблемою.

6. Дашборди (Dashboards)

Все добре, але CISO хоче бачити цифри. Дашборд має розповідати історію, а не просто бути красивою картинкою. Якщо з нього не можна приймати рішень — це просто декорація для презентації.

7. Застереження (Alerts)

SIEM починає кричати. Але чому саме? Якісне застереження має контекст, пріоритет і план дій. Погане застереження — просто шум, який виснажує команду SOC.

8. Управління інцидентами (Incident Management)

Дійшли до інциденту? Тепер важливо діяти: створити тікет, слідувати плейбуку, правильно повідомити й швидко вирішити. Цикл завершується — і починається знову, з урахуванням набутого досвіду.

Підсумок?

SIEM — це не просто інструмент. Це спосіб мислення. Це мозок добре організованого SOC.
А якщо ти не поєднав усі компоненти — у тебе просто дорогий інтерфейс з маленькою користю.

Хочеш робити все правильно? Інтегруй усе. Розумій цикл. І пам’ятай: дані без мети — це просто витрати.


Оригінал:
https://www.linkedin.com/posts/dennyroger_t%C3%A1-achando-que-siem-%C3%A9-s%C3%B3-alerta-piscando-activity-7330840895459667970-OHWR
( Read more... )

🪟 На стартову сторінку

Термін — Alert

Питання:
— Alerts — це події?

Ні, alerts (тривоги, сигнали, оповіщення) — це не події (events), а реакція SIEM на події.

Ось чітке розмежування:

Термін	Українською	Що це таке	Приклад
Event	Подія	Будь-який факт, зафіксований системою: логін, відкриття порту, запуск процесу тощо.	Успішний логін користувача до AD
Log	Журнал (запис)	Текстовий запис події з технічними деталями (час, IP, користувач тощо).	2025-05-22 18:03:12 user:admin login success from 192.168.1.10
Alert	Тривога / сигнал	Автоматично або вручну створене повідомлення, яке вказує на потенційно шкідливу або аномальну активність, на основі подій.	"Підозрілий логін о 3:00 ночі з іншої країни"

🔁 Взаємозв’язок:

1. Події (events) →
2. Журнали (logs) →
3. Обробка (normalization) →
   
4. Кореляція (correlation rules) →
5. Створення alert-ів (за певними умовами)
   

🔎 Приклад:

• Подія: "10 невдалих логінів поспіль".
  
• Подія: "Потім один успішний логін з іншого регіону".
  
• Alert: "Можливе brute-force проникнення → реагувати!"
  

🔧 Підсумок:

• Подія — це факт.
  
• Alert — це висновок SIEM, що цей факт (або комбінація фактів) може свідчити про інцидент.
  

Тому Alert — Застереження (Найкращий баланс між "сповіщенням" і "тривогою")

🪟 На стартову сторінку