Web, mail, IRC, IM, hálózatok

A kérdés a témában megfogalmazva: van-e használható real-time antivírus Linuxra?

Eddig eggyel van tapasztalatom, az ESET antivírusával, ez korábban nagyon fasza volt, de megszűnt a desktopos Endpoint Antivírus, ami meg helyette lett, az növesztett egy rosszul konfigurálható, még rosszabbul működő, és Linuxon le egyáltalán nem tiltható tűzfalat. Őszintén, eddig több problémát okozott, mint amennyit megoldott.

Ami érdekelne

• Mennyire fogja meg a gépet egy nagyobb (10-100G állomány) és egy közepes (100M-5G) állomány mozgatása esetén?
• Használod-e virtualizációval, konténerizációval, ha igen, milyennel, és mik a tapasztalatok?
• Server vagy Desktop termék? Van GUI-ja?
• Van belőle otthon használható verzió vagy csak céges? Mindkét megoldás érdekel!
• Ha van céges, tud központi policy-t vagy valamilyen könnyen export/importálható szabályrendszert (pl CSV-be ki tudom exportálni mire ne ugorjon rá)?

FONTOS! Légyszi, kizárólag a fenti kérdésekre keresek választ, elsősorban saját tapasztalatot, kifejezetten valamilyen Linuxon is működő antivírus termékkel.

Ha nem használsz antivírust, ha úgy gondolod hogy nem kell, ha az a véleményed, hogy rossz nyomon járok ezzel a kérdéssel, akkor köszi szépen, hogy idáig elolvastad, de ne válaszolj.
20 éve dolgozom Linuxszal, én tudom hogy kell bánni vele, soha, semmilyen biztonsági incidensem nem volt sem Linuxszal sem Windowsal, de most van 1-2 olyan ok, ami miatt mindenképpen kellene használni valamilyen antivírust (előírás), nem opcionális, nem átugorható, és mocskosul rohadtul senkit nem érdekel az, hogy mennyire vagyok képzett. Ez egy checkbox, ki kell pipálnom, de ha már szopni kell vele, valami olyan megoldásra vágyok, ami mellett dolgozni is lehet. És mindenképpen real-time védelemmel kell rendelkezzen.

Sziasztok!

Egy ideje foglalkoztat a dolog, hogy megszabjam milyen domain nevekről lehessen küldeni kifelé levelet. Jelenlegi konfig szerint bármilyen címet elfogad küldőként az Exim, akár gmail.com-ot is, ami nem ideális.

ACL-ben próbálkoztam megszabni, hogy csak olyan sender_address_domaint engedjen át, ami egy adott fájlban/listában szerepel, és ez végül sikerült is, viszont mindkét irányban ellenőrzi a címet és a befelé jövőket elutasítja. Alább láthatjátok, ameddig jutottam. Hogyan tudnám megoldani, hogy ez a condition csak az innen kifelé menő levelekre legyen vizsgálva?

Ezt konkrétan az acl_check_rcpt alá írtam közvetlen, ezen kívül itt még van jó pár feltétel.

# only allow local domains to send
               accept condition = ${if match_local_part{$sender_address_domain}{lsearch;/etc/exim/domains} {yes}{no}}
                      message = "Sender domain allowed for sending"
               deny   message = "Sender domain NOT allowed for sending"

Már az új felületen jelentkeztem be a régi Digis ügyfélkapu adataimmal. Ez fogadott:

Tájékoztatjuk, hogy a DIGI Online szolgáltatás 2024. december 31. napjától kivezetésre került, majd 2025. január 31-én a meglévő DIGI Online regisztrációkat töröljük. Amennyiben rendelkezik DIGI Online hozzáféréssel, a szolgáltatás kivezetésével kapcsolatban Önnek nincs teendője. A DIGI Online belépéshez szükséges jelszó törlése nem érinti a DIGI Ügyélkapu regisztrációs adatait. Amennyiben hasonló szolgáltatást keres a One kínálatában, kérjük hívja a 1270-et vagy keresse fel bármelyik üzletünket.

Nincs se TV se telefon szolgáltatásom, csak egy 1000-es netem. 

Ezek után várom mikor lesz (Vodaf)One a vezetékes netem is.  Akkor majd mehetek vissza a Telekomhoz. Kár érte, elégedett voltam a szolgáltatásukkal. Illetve még elégedett vagyok, de ki tudja meddig...

2024-ben sincs karácsony bloat nélkül.

Ezt a topikot azért hoztam létre, hogy csiligány, erőforráspazarló, kikapcsolhatatlan karácsonyi díszekkel rendelkező közismert weboldalak szégyenfalaként szolgáljon.

Sziasztok!

IMAP levelezőszerver LE tanúsítvánnyal nov. 27 óta a fenti hibát adja, ha az IOS Mail appjával szeretnének csatlakozni a szerverhez. A telefon használója szerint ekkor frissítette a rendszerét 18.1.1-re
Nem vagyok egyedül. Mindenki más telefonja, asztali gépe, laptopja, mail kliense működik a cégben, de az IOS Mail nem (ez az egy IOS van).
Elég speckó konstelláció, elimerem.

szilárd

Másnak sem megy https://kau.gov.hu/ ?

Érdekes, mert az https://ugyfelkapu.gov.hu/ az megy. 

Sziasztok!

Proxy mögött lévő gépen Firefox 132.0.2 tökéletesen működik.
133.0-ra történő upgrade után nem tud webhelyekhez kapcsolódni. Secure Connection Failed hibát dob mindenre.
Mintha valami policy szigorodott volna az új verzióban.
Megpróbáltam about:config-ban a triviális dolgokat (security.tls.version.min=1 meg ami még relevánsnak tűnt). Nem segített.
Downgrade 132.0.2-re: újra minden megy.

Néztem a changelog-ot. Ez a pont tűnik relevánsnak, ugyanakkor nehezen hiszem, hogy ettől lett hirtelen minden broken:

Firefox now has a new anti-tracking feature, Bounce Tracking Protection, which is now available in Enhanced Tracking Protection's "Strict" mode. This feature detects bounce trackers based on their redirect behavior and periodically purges their cookies and site data to block tracking.

Találkozott más is ezzel a jelenséggel?
Mi a megoldás?

Sziasztok,

ha esetleg van valakinek kéznél Telekom (T-mobil) prepaid SIM kártyája (esetleg postpaid - felteszem, adott kérdésben nem kezelik őket külön) - ki tudná próbálni, hogy
lehet-e vele levelet küldeni tcp/25 porton kifelé SMTP auth-al?

Tulajdonképpen az is elég volna, ha csak rá tudna telnet-elni egy tetszőleges (de biztosan működő) levelező server 25-ös portjára.

Előre is köszönöm!

Ps: vasárnap még tudott küldeni az eszköz email-t (a saját smtp serveremen keresztül) azóta viszont nem megy. Tudom, állítsam át 465/587-re. Meglesz...

Van egy saját domainem, az emailt is erről intézem. Az Odroidon futó OpenSMTP-6.8 a T-Online smarthost segítségével küldi ki a leveleket, ez a módszer vált eddig be a legjobban.

Vasárnap (12.01) óta a kimenő leveleim nem mennek el. Az OpenSMTP logban ezt látom:

Dec 03 06:24:48 486 smtpd[3150]: 0d72e7006560a36d smtp connected address=192.168.1.1 host=sagemcom
Dec 03 06:24:48 486 smtpd[3150]: 0d72e7006560a36d smtp tls ciphers=TLSv1.3:TLS_AES_256_GCM_SHA384:256
Dec 03 06:24:48 486 smtpd[3150]: 0d72e7006560a36d smtp authentication user=transitive result=ok
Dec 03 06:24:49 486 smtpd[3150]: 0d72e7006560a36d smtp message msgid=14246fd3 size=635 nrcpt=1 proto=ESMTP
Dec 03 06:24:49 486 smtpd[3150]: 0d72e7006560a36d smtp envelope evpid=14246fd31c10153b from=<transitive@akarmi.hu> to=<transitive@celcim.hu>
Dec 03 06:24:49 486 smtpd[3150]: 0d72e7006560a36d smtp disconnected reason=quit
Dec 03 06:24:49 486 smtpd[3150]: 0d72e70387f746a7 mta connecting address=smtp+tls://84.2.46.3:25 host=mail.t-online.hu
Dec 03 06:24:49 486 smtpd[3150]: 0d72e70387f746a7 mta connected
Dec 03 06:24:49 486 smtpd[3150]: 0d72e70387f746a7 mta tls ciphers=TLSv1.3:TLS_AES_256_GCM_SHA384:256
Dec 03 06:24:49 486 smtpd[3150]: 0d72e70387f746a7 mta error reason=SSL certificate check failed
Dec 03 06:24:49 486 smtpd[3150]: smtp-out: Disabling route [] <-> 84.2.46.3 (mail.t-online.hu) for 15s
Dec 03 06:24:51 486 smtpd[3150]: 0d72e704ae061244 mta connecting address=smtp+tls://84.2.44.3:25 host=mail.t-online.hu
Dec 03 06:24:51 486 smtpd[3150]: 0d72e704ae061244 mta connected
Dec 03 06:24:51 486 smtpd[3150]: 0d72e704ae061244 mta tls ciphers=TLSv1.3:TLS_AES_256_GCM_SHA384:256
Dec 03 06:24:51 486 smtpd[3150]: 0d72e704ae061244 mta error reason=SSL certificate check failed
Dec 03 06:24:51 486 smtpd[3150]: smtp-out: Disabling route [] <-> 84.2.44.3 (mail.t-online.hu) for 15s
Dec 03 06:24:53 486 smtpd[3150]: smtp-out: No valid route for [connector:[]->[relay:mail.t-online.hu,port=25,smtp+tls,auth=cred:t-online,mx],0x0]
Dec 03 06:25:00 486 smtpd[3150]: 0000000000000000 mta delivery evpid=14246fd31c10153b from=<transitive@akarmi.hu> to=<transitive@celcim.hu> rcpt=<-> source="-" relay="mail.t-online.hu" delay=12s result="TempFail" stat="Network error on destination MXs"
Dec 03 06:25:04 486 smtpd[3150]: smtp-out: Enabling route [] <-> 84.2.46.3 (mail.t-online.hu)
Dec 03 06:25:05 486 smtpd[3150]: 0d72e7051274e597 smtp connected address=154.203.197.56 host=<unknown>
Dec 03 06:25:05 486 smtpd[3150]: 0d72e7051274e597 smtp failed-command command="AUTH LOGIN" result="503 5.5.1 Invalid command: Command not supported"
Dec 03 06:25:05 486 smtpd[3150]: 0d72e7051274e597 smtp disconnected reason=disconnect
Dec 03 06:25:06 486 smtpd[3150]: smtp-out: Enabling route [] <-> 84.2.44.3 (mail.t-online.hu)

A certificate még évekig jó, nem járt le. Nekem kicsit gyanús, hogy "kerek dátummal" (12.01) leállították a t-online smarthostot, vagy valamit módosítottak rajta. Egyelőre nem tudom kideríteni, mi történt.

Ha valakinek van infója, azt megköszönném, illetve ötleteket is szívesen fogadok, mi mehetett félre. A küldés SMTP+TLS-sel stb megy, nem titkosítatlan 25-ös porton keresztül...

-------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Kisilabizáltam, hogy snq- a következő parancs kimenetéből idézett (ez nekem új volt):

openssl s_client -host mail.t-online.hu -port 465

és itt valóban benne van a certificate panasz. Ha jól értelmezem, a "chain of trust" sérült meg, mivel nem volt a gépemen root certificate (?), amivel a T-Online certjét verifikálni lehetett volna. 11.30-ig volt, valószínűleg 12.01-én lecseréltek a certet egy Sectigosra.

Debianon az /usr/share/ca-cerificates alatt van egy rakat cert, ide kellett betenni a mail.t-online.hu-hoz tartozó root certet, majd hívni egy update-ca-certificates -et.

Fedorán nem találtam előre telepített certeket, itt az /etc/pki-ca-trust/source/anchors könyvtárba kellett bemásolni a hiányzó certet, majd kiadni az update-ca-trust parancsot.

Ezek után a feljebb leírt openssl s_client ... parancs már nem panaszkodik, és az OpenSMTPd-m is szépen tud küldeni levelet ismét mindenhiova.

Köszönöm a segítséget!

Sziasztok

Adott a következő smb.config részlet:

### full audit ########

    vfs objects = full_audit
    full_audit:prefix = %u|%I|%m|%S
    full_audit:failure = connect
    full_audit:success = audit_file mkdirat write pwrite renameat ftruncate  unlinkat openat read pread snap_delete
    full_audit:facility = local5
    full_audit:priority = NOTICE
    path = /data/Fileserver

##########################

Ha az openat benne van, akkor 1db mappa megnyitásakor, (dokumentacio) melyben 1db almappa van (helyisegrajzok, de oda bele sem lépek, csak látom), ennnyi sor generálódik (hozzászólásba illesztem).

Miért olvassa fel ennyiszer?

Cél: Mappák és fájlok olvasásáról logom legyen. A kliensek sajnos folyamatosan sasolják a mappákat és ezek tonnányi sort generálnak.
Elég volna mappába lépéskor egy. Fájl felolvasáskor 1.
Nem tudom számít-e, de öröklő ACL-ek vannak a szülő mappákon, fájlokon.