Rejtélyes hiba a syslogban

Sziasztok,

a Debian 7-es serveremen a portsentry-t kapcsoltam be (ekkor vettem észre) és elvileg, ekkor jött ez a hiba a syslog-mba, ami azt eredményezi, hogy szinte folyamatosan tölti ezekkel az adatokkal, amit nem tudok hova tenni és nem tudok leállítani. Kérdésem mi ez és mi okozza?

Feb 16 18:51:27 fqhn kernel: [3027140.641869] IN=eth0 OUT= MAC=XX:XX:XX:3c:24:c7:00:08:e3:ff:fd:90:08:00 SRC=XX.XXX.114.82 DST=XX.XXX.223.36 LEN=40 TOS=0x00 PREC=0x00 TTL=119 ID=9123 DF PROTO=TCP SPT=54650 DPT=7791 WINDOW=251 RES=0x00 ACK URGP=0 Feb 16 18:51:28 fqhn kernel: [3027140.679113] IN=eth0 OUT= MAC=XX:XX:XX:3c:24:c7:00:08:e3:ff:fd:90:08:00 SRC=XX.XXX.114.82 DST=XX.XXX.223.36 LEN=40 TOS=0x00 PREC=0x00 TTL=119 ID=9145 DF PROTO=TCP SPT=54650 DPT=7791 WINDOW=256 RES=0x00 ACK URGP=0 Feb 16 18:51:28 fqhn kernel: [3027140.730359] IN=eth0 OUT= MAC=XX:XX:XX:3c:24:c7:00:08:e3:ff:fd:90:08:00 SRC=XX.XXX.114.82 DST=XX.XXX.223.36 LEN=124 TOS=0x00 PREC=0x00 TTL=119 ID=9124 DF PROTO=TCP SPT=54650 DPT=7791 WINDOW=251 RES=0x00 ACK PSH URGP=0 Feb 16 18:51:28 fqhn kernel: [3027140.730393] IN=eth0 OUT= MAC=XX:XX:XX:3c:24:c7:00:08:e3:ff:fd:90:08:00 SRC=XX.XXX.114.82 DST=XX.XXX.223.36 LEN=92 TOS=0x00 PREC=0x00 TTL=119 ID=9125 DF PROTO=TCP SPT=54650 DPT=7791 WINDOW=251 RES=0x00 ACK PSH URGP=0 Feb 16 18:51:28 fqhn kernel: [3027140.761824] IN=eth0 OUT= MAC=XX:XX:XX:3c:24:c7:00:08:e3:ff:fd:90:08:00 SRC=XX.XXX.114.82 DST=XX.XXX.223.36 LEN=40 TOS=0x00 PREC=0x00 TTL=119 ID=9184 DF PROTO=TCP SPT=54650 DPT=7791 WINDOW=255 RES=0x00 ACK URGP=0 Feb 16 18:51:28 fqhn kernel: [3027140.797834] IN=eth0 OUT= MAC=XX:XX:XX:3c:24:c7:00:08:e3:ff:fd:90:08:00 SRC=XX.XXX.114.82 DST=XX.XXX.223.36 LEN=40 TOS=0x00 PREC=0x00 TTL=119 ID=9205 DF PROTO=TCP SPT=54650 DPT=7791 WINDOW=252 RES=0x00 ACK URGP=0 ...

Segítségeteket előre is köszönöm!

Üdv.

KALMI

5126 megtekintés

Az IP-címeket lecsekkoltad?

0 szavazat

A hozzászóláshoz be kell jelentkezni

Példa:

Feb 16 19:11:32 fqhn kernel: [3028345.295807] IN=eth0 OUT= MAC=XX:XX:XX:XX:24:c7:00:XX:e3:ff:fd:90:08:00 SRC="T-homes enyém" DST="SERVEREM" LEN=40 TOS=0x00 PREC=0x00 TTL=119 ID=2919 DF PROTO=TCP SPT=54650 DPT=7791 WINDOW=256 RES=0x00 ACK URGP=0

Az SRC IP címek változnak, hol az enyém hol más IP Címe....

0 szavazat

A hozzászóláshoz be kell jelentkezni

Kíváncsi vagyok, tud-e rá valaki, valami értelmeset mondani!
(részemről ártalmatlan dolognak tűnik: lásd még TCP ACK flag, de a hiányos ismereteim miatt nem merem kijelenteni, hogy valóban az)

A 7791-es porton egyébként van valami ismerős szolgáltatásod? (rootként: netstat -ltp | grep 7791)

Apropo: amikor "idegen" cím van a forrás helyén, az nem lehet, hogy egy korábbi kapcsolódásod nyoma? (feltételezve, hogy nincs fix IP-d)

0 szavazat

A hozzászóláshoz be kell jelentkezni

Én sem gondolom, hogy nagy hibába futottam, csak telenyomja a syslog-omat, mert nagyon gyorsan tölti fel.
A kérdéses szám az SSH-m....

Nem tudom, hogy van-e összefüggés, de a serveremen fent van a PSAD (Port Scan Attack Detector:) és a Portsentry is, mivel szeretném a Portsentry-t beállítani, de a PSAD-t leállítva a hiba meg van :(

0 szavazat

A hozzászóláshoz be kell jelentkezni

Ha megnézed, hogy működik a tcp protokoll... azt hiszem, nem ok nélkül írja tele a diszket. ;)
(már ha helyes a feltételezésem és ezek olyan csomagok, amiket nem kellene logolni)
Portsentry-t nem ismerem, fogalmam sincs, mivel lehetne rávenni, hogy csak a lényeges dolgokat logolja.
Csak egy gyanú részemről, hogy kb. debug szinten logoltatsz vele.

0 szavazat

A hozzászóláshoz be kell jelentkezni

Értem és, hogyan lehetne ezt kikapcsolni?

0 szavazat

A hozzászóláshoz be kell jelentkezni

iptables csinál ilyen logokat, ha a forgalmat a LOG láncra irányítod. Állítsd be,hogy ne menjen LOG láncra semmi.

0 szavazat

A hozzászóláshoz be kell jelentkezni

-
(hülyeséget írtam, most megnéztem, a portsentry alapkonfiggal biztosan nem tesz semmit az iptables-be)

0 szavazat

A hozzászóláshoz be kell jelentkezni

iptables -L -n | grep LOG

Aztan tuntesd el.

--
L

0 szavazat

A hozzászóláshoz be kell jelentkezni

Nem teljesen értem, hogy mit kell csinálni.

Ha megnézem az iptables-t, akkor a következőknél van LOG
---
-A INPUT -j LOG
-A FORWARD -j LOG
-A internet_input -p tcp -m tcp --dport ssh -m limit --limit 3/minute --limit-burst 5 -j LOG --log-level warning --log-prefix "SSH Attack: "
---

A GREP-nél pedig:
---
iptables -L -n | grep LOG LOG all -- 0.0.0.0/0 LOG all -- 0.0.0.0/0 LOG tcp -- 0.0.0.0/0 LOG all -- 65.41.233.81 LOG all -- 61.160.213.172 LOG all -- 61.174.51.199 LOG all -- 91.236.116.157 LOG all -- 188.165.239.73 LOG all -- 61.160.215.14 LOG all -- 180.149.93.10 LOG all -- 222.186.62.72 LOG all -- 95.224.16.156 LOG all -- 222.186.62.3 LOG all -- 85.233.79.6 LOG all -- 60.169.74.204 LOG all -- 218.2.22.120 LOG all -- 222.186.62.68 LOG all -- 83.0.132.241 LOG all -- 222.186.62.71 LOG all -- 217.162.142.193 LOG all -- 5.178.85.228 LOG all -- 81.213.63.205 LOG all -- 222.186.62.55 LOG all -- 64.232.158.13 LOG all -- 222.186.62.5 LOG all -- 222.186.62.35 LOG all -- 61.160.215.217 LOG all -- 218.26.89.179 LOG all -- 222.186.62.66 LOG all -- 222.186.62.11 LOG all -- 61.160.213.176 LOG all -- 61.174.51.213 LOG all -- 200.97.90.70 LOG all -- 88.250.159.157
--- 0.0.0.0/0 LOG flags 0 level 4
0.0.0.0/0 LOG flags 0 level 4
0.0.0.0/0 tcp dpt:22 limit: avg 3/min burst 5 LOG flags 0 level 4 prefix `SSH Attack: '
0.0.0.0/0 limit: avg 3/min burst 5 LOG flags 0 level 7 prefix `Portsentry: dropping: '
0.0.0.0/0 limit: avg 3/min burst 5 LOG flags 0 level 7 prefix `Portsentry: dropping: '
0.0.0.0/0 limit: avg 3/min burst 5 LOG flags 0 level 7 prefix `Portsentry: dropping: '
0.0.0.0/0 limit: avg 3/min burst 5 LOG flags 0 level 7 prefix `Portsentry: dropping: '
0.0.0.0/0 limit: avg 3/min burst 5 LOG flags 0 level 7 prefix `Portsentry: dropping: '
0.0.0.0/0 limit: avg 3/min burst 5 LOG flags 0 level 7 prefix `Portsentry: dropping: '
0.0.0.0/0 limit: avg 3/min burst 5 LOG flags 0 level 7 prefix `Portsentry: dropping: '
0.0.0.0/0 limit: avg 3/min burst 5 LOG flags 0 level 7 prefix `Portsentry: dropping: '
0.0.0.0/0 limit: avg 3/min burst 5 LOG flags 0 level 7 prefix `Portsentry: dropping: '
0.0.0.0/0 limit: avg 3/min burst 5 LOG flags 0 level 7 prefix `Portsentry: dropping: '
0.0.0.0/0 limit: avg 3/min burst 5 LOG flags 0 level 7 prefix `Portsentry: dropping: '
0.0.0.0/0 limit: avg 3/min burst 5 LOG flags 0 level 7 prefix `Portsentry: dropping: '
0.0.0.0/0 limit: avg 3/min burst 5 LOG flags 0 level 7 prefix `Portsentry: dropping: '
0.0.0.0/0 limit: avg 3/min burst 5 LOG flags 0 level 7 prefix `Portsentry: dropping: '
0.0.0.0/0 limit: avg 3/min burst 5 LOG flags 0 level 7 prefix `Portsentry: dropping: '
0.0.0.0/0 limit: avg 3/min burst 5 LOG flags 0 level 7 prefix `Portsentry: dropping: '
0.0.0.0/0 limit: avg 3/min burst 5 LOG flags 0 level 7 prefix `Portsentry: dropping: '
0.0.0.0/0 limit: avg 3/min burst 5 LOG flags 0 level 7 prefix `Portsentry: dropping: '
0.0.0.0/0 limit: avg 3/min burst 5 LOG flags 0 level 7 prefix `Portsentry: dropping: '
0.0.0.0/0 limit: avg 3/min burst 5 LOG flags 0 level 7 prefix `Portsentry: dropping: '
0.0.0.0/0 limit: avg 3/min burst 5 LOG flags 0 level 7 prefix `Portsentry: dropping: '
0.0.0.0/0 limit: avg 3/min burst 5 LOG flags 0 level 7 prefix `Portsentry: dropping: '
0.0.0.0/0 limit: avg 3/min burst 5 LOG flags 0 level 7 prefix `Portsentry: dropping: '
0.0.0.0/0 limit: avg 3/min burst 5 LOG flags 0 level 7 prefix `Portsentry: dropping: '
0.0.0.0/0 limit: avg 3/min burst 5 LOG flags 0 level 7 prefix `Portsentry: dropping: '
0.0.0.0/0 limit: avg 3/min burst 5 LOG flags 0 level 7 prefix `Portsentry: dropping: '
0.0.0.0/0 limit: avg 3/min burst 5 LOG flags 0 level 7 prefix `Portsentry: dropping: '
0.0.0.0/0 limit: avg 3/min burst 5 LOG flags 0 level 7 prefix `Portsentry: dropping: '
0.0.0.0/0 limit: avg 3/min burst 5 LOG flags 0 level 7 prefix `Portsentry: dropping: '
0.0.0.0/0 limit: avg 3/min burst 5 LOG flags 0 level 7 prefix `Portsentry: dropping: '
0.0.0.0/0 limit: avg 3/min burst 5 LOG flags 0 level 7 prefix `Portsentry: dropping: '

0 szavazat

A hozzászóláshoz be kell jelentkezni

Ez a 3 sor mondja azt,hogy naplózzon minden kérést.
-A INPUT -j LOG <--- INPUT láncon
-A FORWARD -j LOG <--- FORWARD láncon

-A internet_input -p tcp -m tcp --dport ssh -m limit --limit 3/minute --limit-burst 5 -j LOG --log-level warning --log-prefix "SSH Attack: "

Az utolsó sorhoz egy idézet a könnyebb érthetőség kevéért:
limit

Ezt a modult önállóan kell betölteni a "-m limit" vagy a "--match limit" kapcsolókkal. Az illeszkedések számának korlátozására használjuk, például naplózás elnyomására. Csak egy adott idõt fog megfeleltetni adott gyakorisággal (alapesetben 3 megfelelés óránként, 5 csomagra). Két új opciót tesz elérhetõvé:

--limit

és utána egy szám; meghatározza a másodpercenkénti maximális illeszkedések számát. A szám meghatározható kifejezésekkel, a "/second", "/minute", "/hour" és "/day" használatával, vagy részeikkel (például a "5/second" ugyanazt jelenti, mint a "5/s").

--limit-burst

és utána egy szám, meghatározza a maximális csomagszámot mielõtt a felsõ limit korlátozna.

Forrás: http://www.szabilinux.hu/iptables/chapter7.html

A legjobb védekezés, ha első lépésben a 22-es portot átteszed magasabb tartományba. Pl.: 42322 és a támadások jó része nem érint, mert a scanneléseket alapvetően robototok végzik és csak kevés csinál teljes port scannelést.

0 szavazat

A hozzászóláshoz be kell jelentkezni

Köszönöm a leírásodat!

Az SSH portom nem 22-sen van. Amit nem értek, hogy mi okozta a hibát?

A rendszert újra indítottam és a hiba, mintha megszűnt volna. Helyette most ilyen hibákat gyárt a serverem:

---
Feb 17 00:08:23 fqhn named[974]: error (unexpected RCODE SERVFAIL) resolving '42.54.34.217.in-addr.arpa/PTR/IN': 193.0.9.6#53
Feb 17 00:08:23 fqhn named[974]: error (network unreachable) resolving '42.54.34.217.in-addr.arpa/PTR/IN': 2001:67c:e0::6#53

Feb 17 00:09:31 fqhn named[974]: error (network unreachable) resolving 'vns1.hinet.net/A/IN': 2001:b000:168::1:100:1#53
Feb 17 00:09:31 fqhn named[974]: error (network unreachable) resolving 'vns1.hinet.net/AAAA/IN': 2001:b000:168::1:100:1#53
Feb 17 00:09:31 fqhn named[974]: error (network unreachable) resolving 'vns2.hinet.net/A/IN': 2001:b000:168::2:100:1#53
Feb 17 00:09:31 fqhn named[974]: error (unexpected RCODE REFUSED) resolving '128.48.122.86.in-addr.arpa/PTR/IN': 213.157.178.1#53
Feb 17 00:10:37 fqhn named[974]: error (network unreachable) resolving '1.169.232.211.in-addr.arpa/PTR/IN': 2001:67c:1010:27::53#53
Feb 17 00:10:37 fqhn named[974]: error (network unreachable) resolving '1.169.232.211.in-addr.arpa/PTR/IN': 2001:500:13::c7d4:35#53
Feb 17 00:10:40 fqhn named[974]: error (network unreachable) resolving 'ns2.vega.com.ua/AAAA/IN': 2001:470:2e:46::3#53
Feb 17 00:10:42 fqhn named[974]: error (network unreachable) resolving '208.199.228.165.in-addr.arpa/PTR/IN': 2001:dc0:2001:a:4608::59#53
--

0 szavazat

A hozzászóláshoz be kell jelentkezni

A következőre jöttem rá, hogy kapok a PSAD-tól egy figyelmeztetést:

---
You may just need to add a default logging rule to the INPUT chain on
fqhn. For more information, see the file "FW_HELP" in
the psad sources directory or visit:

http://www.cipherdyne.org/psad/docs/fwconfig.html
---
Itt azt írja, hogy adjam ki ezeket a parancsokat:
# iptables -A INPUT -j LOG
# iptables -A FORWARD -j LOG

Ha kiadom, akkor megindul a hibaüzenet folyam...

Érdekes az IPTABLES-ben benne, van így:
-A INPUT -j LOG
-A FORWARD -j LOG

Ennek ellenére küldi az e-mail, ha pedig lefuttaom, akkor pedig a syslogot terheli.
Ezt amúgy nem értem, ha az IPTABLES tartalmazza, akkor miért nem fut?

Megosztom az IPTABLES-t is:
---
*nat :PREROUTING ACCEPT #:INPUT ACCEPT :OUTPUT ACCEPT :POSTROUTING ACCEPT

-A POSTROUTING -o eth0 -j MASQUERADE

COMMIT
*filter
:INPUT DROP
:FORWARD DROP
:OUTPUT ACCEPT
:internet_input -
:intranet_input -
:internet_forward -
:intranet_forward -
:portsentry -
:fail2ban-SSH -
:fail2ban-apache-multiport -
:fail2ban-apache-noscript -
:fail2ban-courierauth -
:fail2ban-couriersmtp -
:fail2ban-dovecot-pop3imap -
:fail2ban-postfix -
:fail2ban-sasl -
:fail2ban-sendmail -
:IMSCP_INPUT -
:IMSCP_OUTPUT -

###
### INPUT
###
-A INPUT -i lo -j ACCEPT
-A INPUT -m state --state INVALID -j DROP
-A INPUT -j portsentry
-A INPUT -i eth0 -j internet_input
-A INPUT -p tcp -m tcp --dport 11191 -j fail2ban-SSH

-A INPUT -p tcp -m multiport --dports 25,465,143,220,993,110,995 -j fail2ban-sasl
-A INPUT -p tcp -m multiport --dports 25,465 -j fail2ban-postfix

-A INPUT -p tcp -m multiport --dports 110,143,25,995,993,465 -j fail2ban-sendmail
-A INPUT -p tcp -m multiport --dports 80,443 -j fail2ban-apache-noscript
-A INPUT -p tcp -m multiport --dports 25,465 -j fail2ban-couriersmtp
-A INPUT -p tcp -m multiport --dports 25,465,143,220,993,110,995 -j fail2ban-sasl
-A INPUT -p tcp -m multiport --dports 110,995,143,993 -j fail2ban-dovecot-pop3imap
-A INPUT -p tcp -m multiport --dports 80,443 -j fail2ban-apache-multiport
-A INPUT -p tcp -m multiport --dports 25,465,143,220,993,110,995 -j fail2ban-courierauth
-A INPUT -j IMSCP_INPUT
-A INPUT -j LOG

###
### FORWARD
###
-A FORWARD -m state --state INVALID -j DROP
-A FORWARD -j portsentry
-A FORWARD -j LOG

###
### Internet INPUT
###
-A internet_input -p icmp -m limit --limit 10/minute --limit-burst 5 -j ACCEPT
-A internet_input -p icmp -j DROP
-A internet_input -p tcp -m tcp --dport ssh -m limit --limit 3/minute --limit-burst 5 -j LOG --log-level warning --log-prefix "SSH Attack: "

###
### ALL INPUT
###
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT

###
### Internet FORWARD
###
-A internet_forward -j ACCEPT
-A fail2ban-SSH -j RETURN

-A OUTPUT -j IMSCP_OUTPUT

COMMIT

0 szavazat

A hozzászóláshoz be kell jelentkezni

"Itt azt írja, hogy adjam ki ezeket a parancsokat", "Ha kiadom, akkor megindul a hibaüzenet folyam..."
Egyértelmű, hiszen a psad a logból dolgozik, csak akkor van értelme a psad futtatásának, ha valóban logolod azt a forgalmat, amit a psad által (is) figyelendőnek gondolsz. Ha nem akarsz figyelmeztetést erről, tiltsd le az ellenőrzését (ENABLE_FW_LOGGING_CHECK).

"You may just need..."
"Itt azt írja, hogy adjam ki ezeket a parancsokat"
Pontosítsunk: nem teljesen ezt jelenti. Továbbá warning üzenetről van szó, működni fog a psad, ha valóban megkapja a szükséges logokat. Lehet konfigurálni a portsentryt is, a psadot is, illetve a tűzfalszabályban is meg lehet mondani, mi is a logolásra érdemes forgalom.

"Ennek ellenére küldi az e-mail"
Mármint bekapcsolt ENABLE_FW_LOGGING_CHECK mellett a fwcheck_psad kimenetét. És nem a portscan alertet.

"Ezt amúgy nem értem, ha az IPTABLES tartalmazza, akkor miért nem fut?"
Lefuttattad kézzel (iptables-restore)? Mert pusztán a file-ba való beleírástól nem fog érvényre jutni.

Használsz fail2ban, portsentry és psad eszközöket is. Miután meghatároztad, hogy melyik eszközt milyen célra szeretnéd használni, be kell állítanod őket a megfelelő működésre, figyelve arra is, hogy egymást se akadályozzák.
Azt nehezményezed, hogy a psad a működéséhez szükséges logolás lehetséges megvalósítását leíró példa változtatás nélküli másolásával teleszemeteli a logot. Mivel a megfogalmazásból is egyértemű, hogy nem biztos, hogy azt "kell" tenned ("you may just need to add"), vagy nem csak ezt, így érdemes lenne a tűzfalszabályokat a logolandó forgalomnak megfelelő alakra hoznod. Ha pedig nem vagy kíváncsi a panaszolt TCP/7791-re, akkor azt ne engedd rá a logolást végző szabályra. Ha a logra egy másik eszköz miatt mégis szükséged van, akkor pedig a konfigból kellene kezelni (Portsentrynél módtól függően pl. TCP_PORTS, ADVANCED_EXCLUDE_TCP, ADVANCED_PORTS_TCP, valamint IGNORE_FILE; psadnál pl. FW_SEARCH_ALL, IGNORE_PORTS).

Egyéb: a tűzfalszabályok között sorrendi probléma van. a RELATED+ESTABISHED szabály előnyösebb lenne a LOG előtt, a jelenlegi sorrend ezeknek a felesleges logolását eredményezi. A fail2ban esetében is elég furcsa SMTP-re sendmail, courier és postfix egyidejű alkalmazása, legalábbis a nevekből erre lehetne következtetni.

0 szavazat

A hozzászóláshoz be kell jelentkezni

Sajnos megint kezdem látni, hogy kicsit értem a dolgokat, de nem vagyok 100%-os a tudásomban, nagyon köszönöm a válaszodat!

Először is, hogyan tudok arról meggyőződni (kezdeném az alapokról), hogy logol a PSAD, melyik a beállítása, illetve mi lesz a log file?

Egyértelmű, hiszen a psad a logból dolgozik, csak akkor van értelme a psad futtatásának, ha valóban logolod azt a forgalmat, amit a psad által (is) figyelendőnek gondolsz. Ha nem akarsz figyelmeztetést erről, tiltsd le az ellenőrzését (ENABLE_FW_LOGGING_CHECK).
Akkor hagyjam figyelmen kívül az e-mail üzenetet, illetve ha letiltom, akkor hiba esetén, hogyan szerzek róla tudomást?

"Ennek ellenére küldi az e-mail"
Mármint bekapcsolt ENABLE_FW_LOGGING_CHECK mellett a fwcheck_psad kimenetét. És nem a portscan alertet.

Ezt most nem értem

"Ezt amúgy nem értem, ha az IPTABLES tartalmazza, akkor miért nem fut?"

Itt szerkesztetem az IPTABLES és kiadom a "iptables-apply " parancsot, hogy érvényesítse. Így elvileg ennek, akkor érvényesíteni kellene azonnal a tűzfalon újraindítás nélkül, azaz nem csak szerkesztem a file-t.

Fail2ban - Ezt a hibás próbálkozások védelmére szeretném használni.

A porstsentry és a PSAD nem tudom, együtt érdemes-e használni vagy sem. Ha nem akkor törlöm valamelyiket, kérdés melyik a jobb vagy érdemes használni?

Ha pedig nem vagy kíváncsi a panaszolt TCP/7791-re, akkor azt ne engedd rá a logolást végző szabályra. Ha a logra egy másik eszköz miatt mégis szükséged van, akkor pedig a konfigból kellene kezelni (Portsentrynél módtól függően pl. TCP_PORTS, ADVANCED_EXCLUDE_TCP, ADVANCED_PORTS_TCP, valamint IGNORE_FILE; psadnál pl. FW_SEARCH_ALL, IGNORE_PORTS).

Ezt szintén nem teljesen értem, ebben kérek egy kis segítséget.

A -A INPUT -j LOG, -A FORWARD -j LOG bejegyzéseknek igazából hol kellene lenniük, mi az optimális helye?

A fail2ban tette ezeket a bejegyzéseket, mivel idővel automatikusan bejegyzéseket tesz a tűzfalamba (gyakran ismétlődéseket is). Így azt végkép nem tudom és értem, hogy minek hol kellene lennie, illetve jók-e a bejegyzések vagy sem....

0 szavazat

A hozzászóláshoz be kell jelentkezni

"Először is, hogyan tudok arról meggyőződni (kezdeném az alapokról), hogy logol a PSAD, melyik a beállítása, illetve mi lesz a log file?"
A psad elsősorban nem logol, hanem egy kész logfile-t dolgoz fel, és ennek alapján küld mailt, vagy blokkol további forgalmat.

"Akkor hagyjam figyelmen kívül az e-mail üzenetet, illetve ha letiltom, akkor hiba esetén, hogyan szerzek róla tudomást?"
Arra utaltam, hogy ha specifikus log szabályt gyártasz, és nem a példában említett mindent logolást választod, adhat rá warningot, de ettől még működni fog. Ha a példában említett sorokat szúrod be, azt megfelelően detektálja.

"Ezt most nem értem"
Amit bemásoltál "You may just need to add a default logging rule" kezdetű levelet, az arra vonatkozik, hogy nem találja a tűzfalszabályok között a logolást végző sort. Ezt említettem az előzőkben, hogy elképzelhető, hogy teszel be az igényeidnek megfelelő logolást, de a psad nem képes azt megfelelően detektálni, ezért warnngot mond. Ezt az ellenőrzést tudod szabályozni az említett ENABLE_FW_LOGGING_CHECK változóban. De ez a levél nem a portscanről való értesítés.

"Itt szerkesztetem az IPTABLES és kiadom a "iptables-apply " parancsot, hogy érvényesítse. Így elvileg ennek, akkor érvényesíteni kellene azonnal a tűzfalon újraindítás nélkül"
Ez így rendben van. Viszont ha mégsem kerül be, akkor csak arra tudnék gondolni, hogy nem válaszoltál igennel a kérdésére.

A porstsentry és a PSAD nem tudom, együtt érdemes-e használni vagy sem. Ha nem akkor törlöm valamelyiket, kérdés melyik a jobb vagy érdemes használni?

"Ha pedig nem vagy kíváncsi a panaszolt TCP/7791-re, akkor azt ne engedd rá a logolást végző szabályra."
Példa:

iptables -A INPUT -p tcp --dport 7791

iptables -A INPUT -j LOG

"Ezt szintén nem teljesen értem, ebben kérek egy kis segítséget."
Az a javaslatom, hogy nézd át a programok man oldalait, valamint a konfigjaikat (jól kommentezettek). Nézd meg, hogy a portsentry milyen módokban képes futni, milyen módon lehet megadni a figyelt illetve a kivétel portokat, illetve nézd át ugyanilyen módon a psad dokumentációját is. Utána ha van konkrét kérdésed, nézzük meg.

"A -A INPUT -j LOG, -A FORWARD -j LOG bejegyzéseknek igazából hol kellene lenniük, mi az optimális helye?"
Ott legyenek, ahol logolni szeretnél. De a cél általában az - a psadnál is -, hogy az eldobott csomagokat logolja, a psad szempontjából más csomag logolása gyakorlatilag felesleges. Ha előbb logolsz, utána pedig még van ACCEPT szabály, akkor értelemszerűen a LOG sor utáni átengedettek is logolódnak. A konkrét esetben az INPUT lánc default policy képviseli a csomageldobást, közvetlen az előtt, azaz utolsó szabályként lenne érdemes a LOG-ot megadni.

"A fail2ban tette ezeket a bejegyzéseket, mivel idővel automatikusan bejegyzéseket tesz a tűzfalamba (gyakran ismétlődéseket is)"
A fail2ban alapesetben saját lánc(ok)ba teszi a blokkolt IP-ket. Ezeket látod új láncként fail2ban-* neveken. De a fail2ban default konfigja alig tartalmaz engedélyezett jailt, azokat a rendszernek megfelelően illik engedélyezni. Ez így jelen állapotában is működhet, de furcsa és felesleges. Ha nem használasz courier SMTP-t, akkor ne legyen engedélyezve (enabled) az a jail.

0 szavazat

A hozzászóláshoz be kell jelentkezni

Lehet, hogy nepszerutlen leszek, de: kell neked egyaltalan ez a tool, ha azt sem igazan tudod, hogyan mukodik?

A Sentry Tools csaladba tartozo portsentry - ha jol emlekszem, vagy 10 eve nem lattam - figyeli bizonyos portok forgalmat es egyreszt logolja a lehetseges tamadasokat, masreszt kepes kitiltani a beerkezo kereseket. Az en problemam a logolassal van: ha eleg izmos savon ulsz, akkor elkepzelheto, hogy egy jol iranyzott DoS tamadas nem csak a halozatodat terheli le, hanem a logrendszert es/vagy a diszkjeidet is. Szemely szerint en szepen kikapcsolnam es a tuzfalbeallitasokra forditanek nagyobb figyelmet.

--
L

0 szavazat

A hozzászóláshoz be kell jelentkezni

Így van, jól megírt tűzfalszabályrendszer a megfelelő mennyiségű és minőségű logolással, továbbá ehhez illeszkedően beüzemelt védelmi eszközökkel. Figyelve arra, hogy ne fulladjon bele sem a gép, sem az ember a csomagokba, logokba, levelekbe. Ismerkedés és finomhangolás szükséges.

0 szavazat

A hozzászóláshoz be kell jelentkezni

Friss hozzászólások

A nagy probléma a prompt… 2025-08-09T13:09:51+0200
Asszonyba két hónapig… 2025-08-09T13:06:40+0200
Szerintem van akinek… 2025-08-09T12:56:50+0200
Fiatalok vagytok! 😄 2025-08-09T12:57:57+0200
Ez a régi!
https://hup.hu… 2025-08-09T12:56:31+0200
Majd petya dob egy szelfit… 2025-08-09T12:54:23+0200
Végre sikerült új tortát… 2025-08-09T12:46:02+0200
Ezek mind teljesen… 2025-08-09T12:38:45+0200
Pont ezt a két mondatot… 2025-08-09T12:30:38+0200
Nos, igazad van, Tényleg… 2025-08-09T12:28:59+0200

Rejtélyes hiba a syslogban

Hozzászólások