none
Neúspěšný audit ID:4625 aneb 1000 neautorizovaných přihlášení DENNĚ

    Obecná diskuse

  • Zdravím všechny ochotné,
    dávám téma k diskuzi a budu rád, když se k ní přidáte. Vlastním Windows Server 2008 R2 obsluhující tyto služby: IIS, DNS, AD DS a Souborová služba (několik lokálních sdílených služeb). Na server mám směrovanou veřejnou IP adresu pro různé potřeby. Při letmé kontrole programu Prohlížeč událostí jsem pod typem událostí Neúspěšný audit narazil na nemilou skutečnost, konkrétně celkem 626 pokusů o "nabourání systému".

    Zde obecný popis události:
    Nezdařilo se přihlášení účtu.

    Předmět:
    ID zabezpečení: NULL SID
    Název účtu: -
    Doména účtu: -
    ID přihlášení: 0x0

    Typ přihlášení: 3

    Účet, pro který se nezdařilo přihlášení:
    ID zabezpečení: NULL SID
    Název účtu: administrator
    Doména účtu: postmaster-PC

    Informace o selhání:
    Důvod selhání: Neznámé uživatelské jméno nebo chybné heslo
    Stav: 0xc000006d
    Dílčí stav: 0xc000006a

    Informace o procesu:
    ID procesu volajícího: 0x0
    Název procesu volajícího: -

    Informace o síti:
    Název pracovní stanice: POSTMASTER-PC
    Adresa zdrojové sítě: 117.201.51.140
    Zdrojový port: 60580

    Podrobné informace o ověření:
    Proces přihlášení: NtLmSsp 
    Balíček ověření: NTLM
    Přenosové služby: -
    Název balíčku (pouze NTLM): -
    Délka klíče: 0

    Vzhledem k tomu, že jsem počítal se směrováním veřejné IP adresy, změnil jsem default port RDP (Typ přihlášení: 10). Nedošlo mi v tu chvíli však, že možností probourání bude více, tedy přes nyní mě strašící Typ přihlášení: 3 (síť), mezi které se řadí sdílené složky a tiskárny + IIS.

    Nemáte prosím někdo vhodné řešení, jak se preventivně chránit typů tohoto "útoku"? Nepočítám bezpečné heslo administrátora případně zakazovat dané tisíce IP pomocí firewall. Myslím si, že nejsem první ani poslední, kdo tento problém (můžu-li to takto nazvat) řeší.

    Díky za podněty k řešení a přeji hezký zbytek dne.

    středa 3. července 2013 14:06

Všechny reakce

  • NA firewallu povol z Internetu jen minimum. ROZHODNE ZAKAZ SMB/CIFS a RPC!!!

    MP

    středa 3. července 2013 21:13
    Moderátor
  • Děkuji za reakci. Porty veřejné IP mám směrované NATem, na který se nedostanu. Lze toto realizovat i pomocí Windows Firewall? Ohledně SMB potřebuji funkčnost aspoň na lokální IP, to by neměl být problém, že? Jen se ujišťuji a děkuji. . .
    středa 3. července 2013 21:43
  • Přesně k tomu firewall slouží.

    Z lokálních IP si povol, co je potřeba.

    čtvrtek 4. července 2013 6:16
  • Lze toto realizovat i pomocí Windows Firewall?

    Toto = co? NAT? Packetovy filtr?

    MP

    čtvrtek 4. července 2013 7:27
    Moderátor
  • Špatně jsem se vyjádřil. Rád bych věděl, jak ve Windows Firewall nejefektivněji blokovat vzdálená připojení. Konkrétně aspoň v případě SMB/CIFS a RPC. Server totiž využívám i jako Webový a FTP server a časem plánuji i VPN.

    Protokol RPC mám například i u služby Hyper-V či AD, je tedy nutné je zakázat u každé služby pro vzdálené připojení.

    Díky. . .

    čtvrtek 4. července 2013 8:23
  • No proste si v inboud rules toho ktereho pravidla povolis ve scope pro remote IP local subnet.

    MP

    čtvrtek 4. července 2013 9:32
    Moderátor
  • 1. "Porty veřejné IP mám směrované NATem, na který se nedostanu" Je nutne se domluvit s administratorem FW, na kterem je NAT. Z logu na FW by melo jit analyzovat, co se deje.

    2. Role jsou jasne, ale dulezite jsou funkce, ktere server vykazuje navenek a tomu odpovidajici porty.

    3. Z logu je zrejmy zdrojovy port na externim pocitaci ale ne cilovy.

    4. IIS na DC, pokud je IIS pristupny z venku, neni nejlepsi napad.

    5. Zmena portu RDP je typem ochrany typu "security by obscurity"

    6. Sdilene adresare jsou doufam pro interni uzivatele

    7. Kdo ma mit pristup na tiskarny a jak?

    8. IIS ma moznost omezit pocet soucasnych spojeni.

    M.


    čtvrtek 4. července 2013 10:10
    Moderátor
  • Ano, uznávám, že vše bylo bohužel lepeno i z mírné neznalosti na budoucí dopad. Snažím se to nyní pomalu řešit, zvlášť, když se mi konečně povedlo získat veřejnou IP adresu.

    Z venku potřebuji funkční pouze IIS, FTP, RDP a do budoucna VPN, vše ostatní mi stačí lokální cestou. Předpokládám prozatím dvě řešení tohoto problému. Buď u jednotlivých výše zmiňovaných pravidel zakázat vzdálené připojení nebo udělat jedno "globální" omezení, které povolí pouze dané porty, tedy :21 + rozsah dyn.portů; :80 + https; RDP. Tuto představu mám o problému já, moc se v zabezpeční ještě tolik neorientuju a jako základ jistě postačí. Když si někdo dá tu práci a sepíše jaké služby/porty bych měl zakázat (resp. povolit) bude jen rád.

    Ano, sdílené adresáře jsou pouze pro interní uživatele, tedy mají sloužit pouze jim. Přístup na tiskárny mají všichni interní uživatelé.

    Díky. . .

    čtvrtek 4. července 2013 15:14
  • I když jsem u všech příchozích pravidel ve Firewall pro Sdílení souborů a tiskáren... nastavil vzdálenou adresu Místní podsíť, jsem stále schopen se se vzdáleného počítače připojit do sdílených adresářů.

    Maska podsítě 255.255.255.0, proto mi to malinko nejde na rozum. Nemá někdo prosím tušení, co s tím?

    Díky. . .

    středa 10. července 2013 10:11
  • Zapni logovani a podivej naco's zapomnel

    MP

    středa 10. července 2013 10:18
    Moderátor