Fórum Root.cz
Hlavní témata => Server => Téma založeno: Darkhunter 10. 03. 2016, 19:17:19
-
Ahoj,
já už si nevím rady, ale hackli nám dneska tři mailové účty, ze kterých odesílali spam maily.
Webmail máme přes tls a to samé se vzdáleným přístupem. Jde to jen přes port 993 a 465.
Přihlašování bylo přes plain auth, ale to by neměl být problém, když připojení jsou zabezpečená?
-
A dotaz je?
-
Jak to zabezpečit, aby se to příště nestalo a jak se to mohlo stát...
-
Zabezpečí se to takhle: v /etc/dovecot.conf musíš zapnout:
hackable = false
secure = true
-
A nějaký člověk, co není troll, by tu nebyl? :)
-
A nějaký člověk, co není troll, by tu nebyl? :)
Na blbý dotaz blbá odpověď. Očekáváš, že ti tady někdo bude vysvětlovat, co všechno znamená zabezpečit server (téma na knihu, spíš knihy) a na co konkrétně si dát pozor u dovecotu (téma na minimálně několik A4ek), když ty sis nedal práci ani s tím, abys prostudoval logy a sdělil nějaké konkrétnější informace?!
-
Na každý účet se připojili z jiné IP a připojení bylo tohoto typu:
Mar 10 17:26:15 server postfix/smtpd[21007]: Anonymous TLS connection established from unknown[143.255.144.109]: TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)
Mě by hlavně zajímalo,
jak je možné, že když to máme zabezpečené přes SSL/TLS, tak že se někdo dostal k našim heslům.
Navíc je zajímavé, že když jsem změnil z plain na login auth metodu, tak se útočník dokázal přihlásit a naši uživatelé se tam nemohli dostat.
-
Navíc je zajímavé, že když jsem změnil z plain na login auth metodu, tak se útočník dokázal přihlásit a naši uživatelé se tam nemohli dostat.
Zajímavé! :)
-
Prosím někdo normální?
Navíc jsem zjistil, že posíláním těch spamů přišlo spoustu mailů z yahoo těm userům a oni pak odesílali zpátky na yahoo.
-
Os? Verze dovecotu? Jaký webmail v jaké verzi? Logy? Konfigurace uživatelů? Umístění hesel a možnosti přístupů k nim?
To si fakt myslíš, že když napíšeš "hackli mi webmail", tak ti někdo napíše "jasně, to je tím, že tam máš špatně nastavený ssl na nginxu"?
-
A nemáš nastavený ten mail server jako open replay? Anonymous TLS connection si myslím, že by němělo vůbec nastat při pokusů na připojení do mailserveru z venčí, pokud nemáš open relay.
Případně bych prověřil, zda na serveru není software, který přistupuje k mailserveru přes localhost, někdy bývá postfix nastavený tak, že při spojení z localhostu nevyžaduje autorizaci. Pak by stačilo umístit na mailserver záškodnický script, který bude rozesílat spam a nebude vyžadovat aurorizaci.
Tak jako tak, mít hesla v PLAINTEXTU je bezpečnostní riziko.
-
Anonymous TLS connection si myslím, že by němělo vůbec nastat při pokusů na připojení do mailserveru z venčí, pokud nemáš open relay.
Ne, to jenom znamená, že se klient neprokázal certifikátem a je to úplně normální.
http://www.postfix.org/FORWARD_SECRECY_README.html#status
Tak jako tak, mít hesla v PLAINTEXTU je bezpečnostní riziko.
Tady se jedná o způsob autentizace. Plaintext je normální, pokud jde přes bezpečný kanál (v tomhle případě - snad - TLS).
-
OS je Debian 7, dovecot je verze 2.1.7
10-auth.conf:
##
## Authentication processes
##
# Disable LOGIN command and all other plaintext authentications unless
# SSL/TLS is used (LOGINDISABLED capability). Note that if the remote IP
# matches the local IP (ie. you're connecting from the same computer), the
# connection is considered secure and plaintext authentication is allowed.
disable_plaintext_auth = yes
# Authentication cache size (e.g. 10M). 0 means it's disabled. Note that
# bsdauth, PAM and vpopmail require cache_key to be set for caching to be used.
#auth_cache_size = 0
auth_cache_size = 10M
# Time to live for cached data. After TTL expires the cached record is no
# longer used, *except* if the main database lookup returns internal failure.
# We also try to handle password changes automatically: If user's previous
# authentication was successful, but this one wasn't, the cache isn't used.
# For now this works only with plaintext authentication.
#auth_cache_ttl = 1 hour
auth_cache_ttl = 1 hour
# TTL for negative hits (user not found, password mismatch).
# 0 disables caching them completely.
#auth_cache_negative_ttl = 1 hour
# Space separated list of realms for SASL authentication mechanisms that need
# them. You can leave it empty if you don't want to support multiple realms.
# Many clients simply use the first one listed here, so keep the default realm
# first.
#auth_realms =
# Default realm/domain to use if none was specified. This is used for both
# SASL realms and appending @domain to username in plaintext logins.
#auth_default_realm =
# List of allowed characters in username. If the user-given username contains
# a character not listed in here, the login automatically fails. This is just
# an extra check to make sure user can't exploit any potential quote escaping
# vulnerabilities with SQL/LDAP databases. If you want to allow all characters,
# set this value to empty.
#auth_username_chars = abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ01234567890.-_@
# Username character translations before it's looked up from databases. The
# value contains series of from -> to characters. For example "#@/@" means
# that '#' and '/' characters are translated to '@'.
#auth_username_translation =
# Username formatting before it's looked up from databases. You can use
# the standard variables here, eg. %Lu would lowercase the username, %n would
# drop away the domain if it was given, or "%n-AT-%d" would change the '@' into
# "-AT-". This translation is done after auth_username_translation changes.
#auth_username_format = %Lu
# If you want to allow master users to log in by specifying the master
# username within the normal username string (ie. not using SASL mechanism's
# support for it), you can specify the separator character here. The format
# is then <username><separator><master username>. UW-IMAP uses "*" as the
# separator, so that could be a good choice.
#auth_master_user_separator =
# Username to use for users logging in with ANONYMOUS SASL mechanism
#auth_anonymous_username = anonymous
# Maximum number of dovecot-auth worker processes. They're used to execute
# blocking passdb and userdb queries (eg. MySQL and PAM). They're
# automatically created and destroyed as needed.
#auth_worker_max_count = 30
auth_worker_max_count = 100
# Host name to use in GSSAPI principal names. The default is to use the
# name returned by gethostname(). Use "$ALL" (with quotes) to allow all keytab
# entries.
#auth_gssapi_hostname =
# Kerberos keytab to use for the GSSAPI mechanism. Will use the system
# default (usually /etc/krb5.keytab) if not specified. You may need to change
# the auth service to run as root to be able to read this file.
#auth_krb5_keytab =
# Do NTLM and GSS-SPNEGO authentication using Samba's winbind daemon and
# ntlm_auth helper. <doc/wiki/Authentication/Mechanisms/Winbind.txt>
#auth_use_winbind = no
# Path for Samba's ntlm_auth helper binary.
#auth_winbind_helper_path = /usr/bin/ntlm_auth
# Time to delay before replying to failed authentications.
#auth_failure_delay = 2 secs
auth_failure_delay = 5 secs
# Require a valid SSL client certificate or the authentication fails.
#auth_ssl_require_client_cert = no
# Take the username from client's SSL certificate, using
# X509_NAME_get_text_by_NID() which returns the subject's DN's
# CommonName.
#auth_ssl_username_from_cert = no
# Space separated list of wanted authentication mechanisms:
# plain login digest-md5 cram-md5 ntlm rpa apop anonymous gssapi otp skey
# gss-spnego
# NOTE: See also disable_plaintext_auth setting.
auth_mechanisms = plain login
##
## Password and user databases
##
#
# Password database is used to verify user's password (and nothing more).
# You can have multiple passdbs and userdbs. This is useful if you want to
# allow both system users (/etc/passwd) and virtual users to login without
# duplicating the system users into virtual database.
#
# <doc/wiki/PasswordDatabase.txt>
#
# User database specifies where mails are located and what user/group IDs
# own them. For single-UID configuration use "static" userdb.
#
# <doc/wiki/UserDatabase.txt>
#!include auth-deny.conf.ext
#!include auth-master.conf.ext
#!include auth-system.conf.ext
!include auth-sql.conf.ext
#!include auth-ldap.conf.ext
#!include auth-passwdfile.conf.ext
#!include auth-checkpassword.conf.ext
#!include auth-vpopmail.conf.ext
#!include auth-static.conf.ext
-
Tady se jedná o způsob autentizace. Plaintext je normální, pokud jde přes bezpečný kanál (v tomhle případě - snad - TLS).
Plaintext mi tedy normální úplně nepříjde. Už jenom například z toho důvodu, že nechci aby root věděl jaké mám heslo.
-
Já bych tam taky plaintext nedal, ale kdybych to chtěl zmigrovat na md5, tak bych musel předělat celou db ne?
Jinak ale ten plaintext se mi zdá ok, když se posílá přes SSL ne?
Když se podívám do db, tak heslo je hasovaný a začíná s $1$.
-
No po cestě by ti ho nikdo něměl odchytnout (pokud pomineme man in the middle attack) ale v případě špatně nakonfigurovaného serveru někdo mohl právě vydolovat hesla ne z komunikace, ale přímo ze serveru.
Jestli máš hesla uložená v databázi tak změna z plaintextu na MD5 by měla být takřka triviální. Na debianu se podívej do /etc/dovecot/conf.d/* najdi kde máš konfiguraci k databázi a tam by mělo stačit změnit:
default_pass_scheme na to, které si vybereš z http://wiki.dovecot.org/Authentication/PasswordSchemes
-
To máme md5.
Já myslel, že tady máme plain:
auth_mechanisms = plain login
-
Na každý účet se připojili z jiné IP a připojení bylo tohoto typu:
Mar 10 17:26:15 server postfix/smtpd[21007]: Anonymous TLS connection established from unknown[143.255.144.109]: TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)
Mě by hlavně zajímalo,
jak je možné, že když to máme zabezpečené přes SSL/TLS, tak že se někdo dostal k našim heslům.
Navíc je zajímavé, že když jsem změnil z plain na login auth metodu, tak se útočník dokázal přihlásit a naši uživatelé se tam nemohli dostat.
Ale tady není nic o Dovecotu, tady je Postfix/smtpd: Máš nastavené v Postfixu, že uživatelé se musí pro SMTP připojovat Loginem? (SASL), nebo ne? Pokud máš blbě restrikce, pak jsi v podstatě OnenRelay a TLS tomu nezabrání.
smtpd_recipient_restrictions = permit_mynetworks,
[b]permit_sasl_authenticated,[/b]
reject_non_fqdn_hostname,
[u] [b]reject_unauth_destination,[/b][/u]
permit
A nebo jak psáno níže, někdo ti propašoval na server nějaký script (přes Apache ...) a ten spouští.
Postfix obvykle localhostu důvěřuje a nevyžaduje ověření heslem.
-
OS je Debian 7, dovecot je verze 2.1.7
No, to je fajn, ale těch otázek tam bylo víc a základní otázka je, jak jsi vlastně došel na názor, že problém byl v dovecotu. Ten slouží ke čtení mailů, odesílají se přes úplně jiný soft (ve tvém případě postfix, ze kterého jsi vyzobl ten řádek s přihlášením).
Taky jsi neodpověděl, jestli ten postfix nemáš náhodou jako open relay. Jak se na smtp autentizuje? Není třeba z vnitřní sítě bez autentizace? Atd. atd.
Nikoho nebude bavit z tebe všechno tahat jak z chlupaté deky. Pokud chceš slušně poprosti o radu (zadarmo!), tak musíš spolupracovat a dodat všechny potřebné informace.
-
Plaintext mi tedy normální úplně nepříjde. Už jenom například z toho důvodu, že nechci aby root věděl jaké mám heslo.
Plaintext auth se úplně normálně používá. Líbit se ti to nemusí a používat to nemusíš, k tomu tě nikdo nenutí :)
-
Musí to být dovecotem. Od té doby, co jsem ve firewallu povolil 993 jen pro lokální síť, tak to přestalo dělat.
Navíc se ten člověk připojoval přes SASL.
Není to vnitřní síť. Relay zakazaná. Dá se tam dostat jen z localhostu nebo přes imap.
-
Dá se tam dostat jen z localhostu nebo přes imap.
Máš v tom chaos. Sám jsi před chvilkou řekl tohle:
Na každý účet se připojili z jiné IP a připojení bylo tohoto typu:
Mar 10 17:26:15 server postfix/smtpd[21007]: Anonymous TLS connection established from unknown[143.255.144.109]: TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)
- všimni si prosím toho "postfix/smtpd". To fakt není imap.
-
Tohle bylo ještě před tím a lognul se přes usera:
Mar 10 16:23:00 server postfix/smtpd[11754]: 0838322A05F6: client=unknown[176.111.254.59], sasl_method=PLAIN, sasl_username=
-
Nikoho nebude bavit z tebe všechno tahat jak z chlupaté deky. Pokud chceš slušně poprosti o radu (zadarmo!), tak musíš spolupracovat a dodat všechny potřebné informace.
-
Tohle bylo ještě před tím a lognul se přes usera:
Mar 10 16:23:00 server postfix/smtpd[11754]: 0838322A05F6: client=unknown[176.111.254.59], sasl_method=PLAIN, sasl_username=
Tak ti někdo nějak vybrabčil hesla uživatelů. Doporučuji zkontrolovat přístup k MySQL (ideálně jen z localhostu) a vynutit na uživatelích změnu hesel, nebo dočasně zakázat odesílání pošty z venku pro všechny (než si změní hesla).
A vynutit delší než 1234
Pamatuj, nejslabší článek v jakémkoliv zabezpečení je vždy uživatel. Když mě naposledy hákli FTP (naštěstí jen nahráli skripty, nemohli je spustit ani smazat ...), tak jsem FTP vypnul (stejně nebylo nutné). U mailu se mi to zatím (ťukťuk) nestalo.
-
Tohle bylo ještě před tím a lognul se přes usera:
Mar 10 16:23:00 server postfix/smtpd[11754]: 0838322A05F6: client=unknown[176.111.254.59], sasl_method=PLAIN, sasl_username=
A predpokladam ze Postfix nepouziva zadny filtr ktery by jednotlivym uzivatelum pocital kolik uz odeslali e-mailu, takze je to pro spamera ktery jakkoliv zjisti heslo nejakeho uzivatele neco jako raj. Bohuzel po kazdem takovem utoku spousta legitimnich e-mailu prestane odchazet protoze se IP adresa serveru dostane na smtp blacklisty kterym spousta serveru veri natolik aby e-maily z vasi IP adresy rovnou odmitaly.
Rada z praxe: uzivatelum omezit povoleny pocet odeslanych e-mailu za den (ja napriklad pouzivam upraveny policyd) a automaticky kontrolovat zda ten limit nedosahli, pokud ano tak jim automaticky zablokovat moznost odesilani mailu (ale ne prijimani) a poslat e-mail s informacemi o tom co se stalo a jak to mohou vyresit (napr. ze jim e-maily pujdou odesilat az po tom co si nastavi nove heslo).
I kdyz server zabezpecite maximalne, porad budete bojovat s tim ze hesla uzivatelum budou utocnici krast z jejich pocitacu kde je maji ulozena. Musite proto s timto pocitat a zadnemu uzivateli neduverovat natolik ze mu umoznite odesilat e-maily uplne bez omezeni!
-
Tady se jedná o způsob autentizace. Plaintext je normální, pokud jde přes bezpečný kanál (v tomhle případě - snad - TLS).
Plaintext mi tedy normální úplně nepříjde. Už jenom například z toho důvodu, že nechci aby root věděl jaké mám heslo.
Tak v tom případě to heslo nikdy na server neposílejte, protože už jenom tím si ho root může zjistit.
-
Nikoho nebude bavit z tebe všechno tahat jak z chlupaté deky. Pokud chceš slušně poprosti o radu (zadarmo!), tak musíš spolupracovat a dodat všechny potřebné informace.
Já se divím, že s tímhle mantinelem zabržděným máte tolik trpělivosti. Je očividně úplně blbej, myslí si, že když si na POP3/IMAP4 službě dá SSL/TLS, tak že má zabezpečený SMTP, neumí dát informace, přestože je o ně několikrát žádán a ještě si stěžuje, že ti co tomu rozumí mu na blbé otázky neumějí dát jiné, než blbé odpovědi.
Mám pocit, že nastává dost nepříjemná doba, protože tyhle lamy se začínají ve velkém montovat do správy Linuxových serverů a myslí si, že bez znalostí to bude vše v pořádku. Ach jo!
-
Pokud jde o plaintext hesla, tak jsem k tomu nedávno něco málo sepsal...
http://www.abclinuxu.cz/clanky/plaintextova-hesla-uzivatele-a-scram
-
Jak to zabezpečit, aby se to příště nestalo
Zabezpečí se to takhle: v /etc/dovecot.conf musíš zapnout:
hackable = false
secure = true
pobavilo ;[] vzhledem k vyvoji diskuse je ovsem reseni mnohem jednodussi a prospesnejsi okoli
sudo shutdown -h now "be secured"
pozor: funkcni reseni!
-
Pokud jde o plaintext hesla, tak jsem k tomu nedávno něco málo sepsal...
http://www.abclinuxu.cz/clanky/plaintextova-hesla-uzivatele-a-scram
Pěknej článek, díky! Trochu mi tam ale chybí jedna věc: v praxi se člověk bohužel nerozhoduje na základě toho, co by bylo nejelegantnější/nejbezpečnější, ale hledá nejmenšího společného jmenovatele všech schemat podporovaných všemi klienty. Stačí mít požadavek na podporu jednoho typu klienta, který neumí nic než (s ničím nekompatibilní schema) a všechny pěkné teoretické úvahy letí ven oknem...
-
Alternatnivni reseni (z praxe), vzit klacek a natrit kazdyho usera. Protoze ty jejich jednopismenkovy hesla se fakt nedaj uhodnout ...
-
Alternatnivni reseni (z praxe), vzit klacek a natrit kazdyho usera. Protoze ty jejich jednopismenkovy hesla se fakt nedaj uhodnout ...
Doporučuji spíš vzít klacek na admina který uživatelům zpřístupnil možnost nastavovat si jednopísmenková hesla.
-
Prosímtě, vypni ten server. Pokud možno ihned. Provozování mailserverů fakt není vhodný koníček pro lidi, co nechápou rozdíl mezi IMAP a SMTP. >:(
-
Prosímtě, vypni ten server. Pokud možno ihned. Provozování mailserverů fakt není vhodný koníček pro lidi, co nechápou rozdíl mezi IMAP a SMTP. >:(
Od toho máme přece blacklisty, ne?