Je Váš WordPress opravdu bezpečný?
6.Duben 2011
Opravdu si myslíte, že se na vašem webu nemůže nic stát a je naprosto bezpečný, protože používá tak skvělý systém jako je WordPress? Ale no tak, to jste opravdu tak naivní? Pravda je taková, že někteří uživatelé nemají ani tušení o tom, jak je jejich databáze přístupná veřejnosti, nebo že na svém webu mají umístěny již několik měsíců například desítky skrytých odkazů na Viagru a podobné zajímavé produkty.
Nevěříte? Čtěte dál a snad pochopíte, že mít svůj web není jen o tom jednou za čas kliknout na tlačítko "Publikovat".
Co možná nevíte...
Víte o tom, že jakýkoliv nainstalovaný plugin může obsahovat ve svých zdrojových kódech úplně cokoliv a nikdo to nekontroluje? Příjde vám normální bezhlavě aktivovat jakýkoliv plugin na který někde na internetu narazíte?
Pro představu, odeslání informace o všech emailových adresách všech vaších registrovaných uživatelů nebo rovnou odeslání přístupových údajů k databázi na jakýkoliv email je záležitostí na jeden řádek zdrojového kódu (některé pluginy dokonce používají PHP funkce eval a base64_encode díky kterým daný plugin dělá jednoduše řečeno něco co prostě nezjistíte).
Denně se setkávám, někdy i s desítkami nejrůznějších stránek fungujících na publikačním nástroji WordPress a odhadem bych řekl, že takových 80% z nich používá buď zastaralou verzi celého systému nebo z různých důvodu úmyslně používá neaktualizované pluginy či šablony vzhledu. Napadlo vás, že tyto aktualizace mají nějaký důvod?
Například velice oblíbený plugin WP-PostRatings v nedávné verzi 1.5 obsahoval bezpečnostní chybu (XSS), ale to jen tak pro informaci. Pluginů obsahujících "zadní vrátka" do vašeho systému existují desítky. Proto moje rada zní aktualizujte co to jde. Může se totiž snadno stát, že jednoho dne nebudete mít co aktualizovat...
Někdy vám, ale nepomůže ani aktualizace...
Opět jen pro informaci...
Plugin Placester obsahuje bezpečnostní chybu (XSS), nová verze pluginu s opravou zatím neexistuje (info viz. Secunia #43967).
Plugin WP Custom Pages obsahuje bezpečnostní chybu (načtení libovolného souboru), nová verze pluginu s opravou zatím neexistuje (info viz. Secunia #43963).
Plugin WP forum obsahuje bezpečnostní chybu (SQL injection), nová verze pluginu s opravou zatím neexistuje (info viz. Secunia #43552).
A takhle bych mohl pokračovat do zblbnutí...
Jak tedy zabezpečit svůj WordPress?
Pluginy a šablony
Vzhledem k tomu, že používáte pluginy třetí strany, nemáte nikdy jistotu, že ve vašem systému neexistuje nějaká chyba v zabezpečení. Jediná rada proto je používat pluginů co nejmíň, co nejdříve tyto pluginy aktualizovat na nejnovější verze, případně občas navštívit stránky autorů, kde se můžete dozvědět zajímavé informace. Toto vše samozřejmě platí i o šablonách vzhledů.
Přístupové údaje, hesla atd...
Dokola opisované téma, na které stejně většina lidí zvysoka kašle a pak brečí na všech známých i neznámých fórech. Používat složitá hesla, minimálně 8 znaků složené z malých a velkých písmen, čísel a jiných znaků. Samozřejmě pro každý účet (jak účet ve WP, tak i databáze, FTP a administrace hostingu) použijeme heslo jiné. S tímto souvisí použití nějakého antivirového programu, kvalitního FTP klienta a samozřejmě použití zabezpečeného FTP přenosu (SFTP nebo FTPS). Prefix databázových tabulek je hned po instalaci vhodné změnit, to že je ve výchozím stavu "wp_" ví každý kdo jednou instaloval WordPress. Pokud jej ale změníte například na "muj_wp_", při případném SQL útoku má útočník velice stíženou práci.
Uživatelské účty
V prvé řadě smažeme výchozí účet administrátora, který máme k dispozici hned po instalaci WordPressu. To provedeme snadno, vytvoříme si účet nový s jiným přihlašovacím jménem a složitým heslem (viz. předchozí odstavec) a starý účet "admin" smažeme. Všechno co doposud publikoval admin, snadno převedeme na nový účet. Toto opatření slouží k tomu, že každý ví, že tento účet "admin" je výchozí po instalaci a k plnému přístupu do systému už jen chybí uhádnout heslo, což například brute force metodou není zase takový problém z důvodu nulové ochrany samotným WordPressem (jak se proti této metodě bránit zjistíte níže). Pokud na webu povolujete registraci uživatelů, je dobré občas projít třeba namátkou některé uživatele. Docela často totiž můžete narazit na uživatele vytvořeného automaticky nějakým botem, hledající přes tento účet trhlinu v zabezpečení vaší administrace. Neaktivní uživatele neboli "mrtvé účty" smazat.
Informace
Čím míň informací případnému útočníkovi zdělíte tím líp pro vás a hůř pro něj. Proto pokud možno odstraňte všechny zbytečné a nepotřebné soubory na vašem hostingu. Nejčastěji to jsou soubory readme.txt a podobné. Neukládejte na serveru zálohy bez jejich zabezpečení. Divili by jste se kolik souborů SQL se zálohou celé databáze lze nalézt jen za pomocí vyhledávače Google!!! Blbost některých "administrátorů" a "IT specialistů" opravdu nemá hranic...
Pokud můžete upravovat nastavení serveru pomocí .htaccess souboru, je vhodné do něj umístit následující řádky:
Vypne zobrazení informací o serveru
ServerSignature Off
Zakáže procházení adresářů vašeho serveru
Options -Indexes
Zakáže přímý přístup přes prohlížeč k souborům htaccess a htpasswd, a všem s příponou ini,txt,phps,fla,psd,log,sh,bak,backup,back,set a hlavně sql.
<FilesMatch "\.(htaccess|htpasswd)$"> Order Allow,Deny Deny from all </FilesMatch> <FilesMatch "\.(ini|txt|phps|fla|psd|log|sh|bak|backup|back|set|sql)$"> Order Allow,Deny Deny from all </FilesMatch>
Další užitečným krokem je použití souboru robots.txt, ve kterém přidáním následujících řádků zakážeme vyhledávacím robotům indexovat a procházet váš WordPress (neplatí pro vaše stránky, jde jen o to aby roboti neprolézali například vaše uložené soubory nebo pluginy a šablony).
User-agent: * Disallow: /feed/ Disallow: /trackback/ Disallow: /wp-admin/ Disallow: /wp-content/ Disallow: /wp-includes/ Disallow: /xmlrpc.php Disallow: /wp-
Nakonec bych ještě doporučil odstranit informaci o vaší verzi WordPressu. To provedeme snadno přidáním tohoto kódu do souboru functions.php vaší šablony vzhledu:
remove_action('wp_head', 'wp_generator');
Ochrana samotného systému a administrace
Ke zvýšení zabezpečení můžeme pomoci i ochranou samotných systémových souborů. Htaccess soubory jsme si již ochránili, přidáním následujících kódu zabezpečíme i soubor wp-config.php s nejdůležitějším nastavením vašeho webu.
<files wp-config.php> order allow,deny deny from all </files>
Další řádky ochrání vše ve složce wp-includes:
<IfModule mod_rewrite.c>
RewriteCond %{THE_REQUEST} ^[A-Z]{3,9}\ /wp-includes/.*$ [NC]
RewriteCond %{THE_REQUEST} !^[A-Z]{3,9}\ /wp-includes/js/.+/.+\ HTTP/ [NC]
RewriteCond %{REQUEST_FILENAME} ^.+\.php$
RewriteRule .* - [F,NS,L]
</IfModule>
nebo obsah session a další drobnosti:
<IfModule mod_rewrite.c>
RewriteCond %{HTTP_COOKIE} ^.*PHPSESS?ID.*$
RewriteCond %{HTTP_COOKIE} !^.*PHPSESS?ID=([0-9a-z]+);.*$
RewriteRule .* - [F,NS,L]
RewriteCond %{ENV:REDIRECT_STATUS} 200
RewriteRule .* - [L]
</IfModule>
Nejrůznějších druhů zabezpečení pomocí .htaccess souboru jsou spousty. Od blokování nejrůznějších spamovacích botů přes zakázání odkazování na vaše obrázky či soubory. Stačí použít Google a hledat články na téma WordPress security htaccess.
Nastavení práv u souborů
Je to až k neuvěření, ale snad každý web fungující na WordPressu ke kterému jsem měl kdy přístup přes FTP, neměl správně nastavena práva u souborů nebo složek. Pokud vás někdy napadlo nastavit všem souborům a složkám max. práva doporučuji rovnou celý web smazat, ulehčíte si tím trápení. pro ty co svůj web chtějí mít pod kontrolou, doporučuji toto:
Souboru wp-config.php nastavit práva na 600, ostatním na 640.
Složkám wp-admin a wp-includes nastavit práva na 705, složce wp-content doporučuji nastavit 755. To je vše a ani to nebolelo.
Obrana proti brute-force útokům
Co to brute-force útok je, nebo v čem spočívá, vysvětlovat nebudu. Koho to zajímá, informace si už najde. Každopádně samotný WordPress proti těmto druhům útoku chráněn není (což je pro mě nepochopitelné když naprosto funkční a stupidní řešení spočívá ve využití PHP funkce sleep();, ale tak to prostě je). Ale můžeme si pomoci dostupnými pluginy, které tento problém docela obstojně řeší za nás. Mně se velice osvědčil plugin Limit Login Attempts, který vám například umožňuje nastavit maximální počet chybných pokusů o přihlášení a další "vychytávky". Někteří z vás asi i ocení, že je kompletně v Češtině.
Další užitečné pluginy
I když jsem sice na začátku psal, že by jsme měli používat pluginů co nejmíň, tyto musíme brát jako "nutné zlo"
WassUp - Statistiky návštěvnosti, logování pokusů o hack či spam, visualizace na mapě, podle mně jeden z nejlepších pluginů pro statistiky nebo kontrolu návštěvníků.
Spammer Blocker - Jednoduchý plugin pro banování IP adres. WassUp vám jednoduše oznámí pokus o hack nebo spam, a tímto pluginem jednoduše zabanujete IP adresu útočníka. Možná jsou i jiné, lepší, každopádně tento mi naprosto vyhovuje.
A samozřejmě Akismet, kdo tvrdí že nefunguje neví o čem mluví a principu fungování tohoto pluginu naprosto nerozumí. Nevím co bych bez něj dělal, naprostá spokojenost.
To je asi vše, pokud se zmíněnými radami a ukázkami budete řídit, můžete určitě klidněji usínat s vědomím, že Váš web toho ustojí zase o trochu víc. Rady to nejsou dokonalé, případné útočníky "nevyženou", ale určitě jim značně zkomplikují jejich snažení.
Všechny uvedené úpravy používejte s rozumem! Vždy před úpravou zálohujte původní soubory a důkladně otestujte funkčnost. Né každý hosting má stejné nastavení a proto některé úpravy nemusí fungovat správně.
Podobné články
Komentáře k článku “Je Váš WordPress opravdu bezpečný?”
10.Duben 2011 v 10:10
Zajímavé tipy pro provoz … díky za to. Ikdyž většinu tipů již na blogu v provozu mám, nikdy neuškodí si to shrnout do jednoho článku a vědět, že věci, které pro svůj blog dělám jsou správné
Takže dík
10.Duben 2011 v 11:07
Oprvadu velmi zajímavé tipy pro zabezpečení,už jsem jich většinu podle tvého návodu nasadil.
Pěkný článek,pěkný blog:-)
10.Duben 2011 v 12:57
Díky, každopádně ještě jen takové zajímavosti…
Při psaní článku jsem náhodně narazil na 3 weby (docela známé a s relativně velkou návštěvností) u kterých se na serveru volně povalovali zálohy celé databáze a další zajímavé soubory. Heslo pro přístup do administrace jednoho z administrátorů jsem zjistil asi během dvou minut a to jsem využil jen informací, které jsou volně dostupné přes google (weby jsem samozřejmě o této skutečnosti informoval).
Za poslední měsíc jsem zaznamenal už 27 různých pokusů o útok na tento web.
Jen díky pokusům o přihlášení přes účet „admin“ jsem byl nucen zabanovat 11 IP adres.
Z toho plyne to, že pokud o těchto útocích nebo pokusech o útoky nevíte, neznamená to, že nejsou…
18.Duben 2011 v 14:07
Dobry den,
), tak po aktualizaci WP nebo sablony nektere uvadene zmeny mohou byt vymazany, ze ano? (konkretne ty v PHP souborech) Navic predpokladam, ze zabezpeceni WP musi resit desetisice uzivatelu, tak by neco ucinneho uz mohlo existovat.
jakou mate zkusenost s bezpecnostnimi pluginy? Maji smysl? Pri hledani hned vyskoci napr. tyto: Better WP Security, Secure WordPress, BulletProof, WP Security Scan (i kdyz ten asi na „diry“ jen upozornuje)…
Totiz pokud tomu dobre rozumim (moc ne
Diky.
18.Duben 2011 v 17:59
Pluginy…to je těžký, pro zabezpečení sice jsou, jenže ve většině případů pouze informují o nějaké potenciální zranitelnosti, ale již nic neřeší. Mimoto tyto pluginy dělají úplně to samé co si může každý uživatel jednoduše udělat sám a samozřejmě neumí vše. Z toho důvodu třeba já žádný z těchto uvedených pluginů nepoužívám, raději si o problému něco přečtu a vyřeším jej podle sebe, mám tak dokonalou kontrolu nad webem.
Jsou třeba pluginy, které kontrolují zda nějaký kód neobsahuje potenciálně nebezpečné funkce
evalnebobase64_encodejenže odstranění nebo úprava je stejně na uživateli, mimoto stejně normální uživatel nikdy nezjistí co se v těchto kódech skrývá (některé šablony tak např. zobrazují pouze odkaz na svůj web).Aktualizace…všechny úpravy se snažím dělat jen pomocí htaccess souboru, který se s aktualizací nemění popřípadě pluginy. Přímo do systémových souborů WP nezasahuji, protože to ani není potřeba. WordPress sám o sobě je bezpečný, největší „díra do systému“ je vždy pouze uživatel a jeho rozum.
Nic univerzálního nikdy existovat nebude, každý server je jinak nastaven, má různé rozšíření stejně tak jako každý web. Jediná obrana proti tomuto je prostě zdravý rozum, člověk, který si postaví web (nejen na WP) si prostě tento web zabezpečit musí sám, jinak musí počítat s následky (což samozřejmě většina nedělá a pak si stěžují). Taky přece nekoupím dům bez zámků a nebudu se tvářit, že mi tam nikdo nemůže vlézt…
18.Duben 2011 v 18:12
jen pro doplnění…
Nedávno se přišlo na to, že jeden velice rozšířený script pro práci s obrázky obsahuje bezpečnostní díru (jak vrata). Lze přes něj provést jak XSS útok tak i dokonce DoS a vlastně cokoliv…
Tento script je nejen v šablonách vzhledů ale i v některých pluginech (nejen pro WP, je např. i v šablonách pro Joomlu).
Jmenuje se
TimThumb.phpa info můžete najít třeba na http://www.wpsecure.net.Proti chybám programátorů prostě žádný způsob obrany není, jde jen o to jestli správce webu tyto informace má, zajímá se o ně a popřípadě se snaží tento problém řešit nebo nad tím jen mávne rukou s nějakou trapnou výmluvou…
18.Duben 2011 v 18:31
No vidite, uz tomu rozumim. Znali snad prominou nezkusenemu, ze si myslel, ze se cast kodu zadava do samotneho wp-config.php
…uz mi ale doslo, ze vse patri do .htacces
(pred par tydny jsem treba netusil co je CSS… )
Jsem zacatecnik, ale snad me omlouva, ze se zajimam…
Jeste jednou diky za dobre tipy a zustanu tedy u uvedenych uprav, pluginama budu setrit…
PS.Urcite mate v zaloze spoustu materialu a nametu na clanky, tak jen doufam, ze SEO optimalizace (zase rucne vs pluginy) mezi ne take patri…
18.Duben 2011 v 19:10
Správně, kod ptaří do htaccess souboru a jednoduše řečeno znamená asi toto: „soubor
wp-config.phpzakázán pro všechny“. Tedy v případě že by třeba z nějakého důvodu spadlo na vašem hostingu PHP, soubor by se dal zobrazit v prohlížeči, tento zápis tomu ale zabrání (kdysi jsem měl naivní názor, že PHP snad ani spadnout nemůže, ale na jednom freehostingu mě rychle přesvědčili o opaku).SEO… určitě něco napíšu, jenže tohle téma obecně je tak na samostatný web, je toho strašně hodně co se dá/má, může/nemůže takže určitě půjde jen spíše o kódování, úpravy šablon a podobně, detaily se určitě zabývat nebudu
19.Duben 2011 v 10:19
bohuzel pri tomto nastaveni nejde se prihlasit, respektive prihlaseni probehne, ale pak uz se objevi 403 Forbidden… ale 705 vypada, ze funguje…
19.Duben 2011 v 12:22
Tohle způsobuje pravděpodobně nastavení serveru safe_mode = on, už jsem o tom byl informován jen jsem to nějak pozapomněl doplnit do článku. Na kvalitním hostingu funguje 750 bez problémů.
19.Duben 2011 v 13:57
Nene, zkontrolovano pres phpinfo, safe mode je off. Ale nevadi, 705 doufam neni tak strasny…
Delam si z toho trochu forum na tema zabezpeceni, tak kdyby to vadilo, urcite me zarazte, prestanu… Nicmene dokud me nezastavite, mel bych jeste jeden dotaz. Co si myslite o tomhle Auto IP Ban Script
Ma smysl to nasazovat proti ruznym bad bots a offline cteckam?
19.Duben 2011 v 19:42
JJ omlouvám se za zmatení, zkoušel jsem to a v
safe_modeto přímo není. Každopádně je to způsobeno nastavením (zabezpečením chete-li) serveru.Jak jsem psal správně by měly byt nastaveny uvedené hodnoty, protože uživatel vždy přistupuje pouze k souboru
index.phppřes který už WP zpracuje požadavek např. na článek. K systémovým souborům by měl mít každý z venku zakázán přístup, povolen by měl být pouze pro PHP proto ta nula na konci. Ale některé hostingy mají toto zabezpečení přístupu k souborům řešené po svém a uvedené nastavení tedy fungovat nebude, je to třeba vyzkoušet. Na freehostinzích se nejčastěji setkávám s tím, že přístup k souborům nemá ani samotné PHP, nelze tak například přes scripty měnit, vytvářet ani mazat žádné soubory na serveru (což je samozřejmě špatně a jen to vyvolává falešný pocit bezpečnosti). Já například hostuji na WEDOSu a tam toto nastavení funguje bez problémů.Na plugin jsem se díval a nějak moc z něj unešený nejsem, protože to prostě dělá něco samo co nemůžu ovlivnit. Takové pluginy nemám rád, ale to je jen můj vlastní názor. Samotné banování IP adres se mi taky nelíbí a většinou je to stejně úplně k ničemu. Z toho co pozoruji na tomto webu většina spamu nebo různých pokusů o objevení nějakých „zadních vrátek“ přichází přes nějaký vlastní server s náhodnou subdomenou, pokud tuto IP zabanuji, příště příjde zase z jiné subdomény ale ze stejného serveru (například zabanuji
125973.example.coma po chvilce se oběví459732.example.com, které už má logicky jinou IP). Užitečnější mi tedy příjde banovat rovnou celého hosta odkud tyto útoky přichází, ale to zase nepomůže proti botům kteří přichází přes nějakou proxy.Takže nějaké automatické banování mi z těchto důvodů přijde naprosto zbytečné, ono pokud stejně musím někoho zabanovat tak je to až po tom co příjde na web a něco zkusí (jen takhle můžu zjistit jeho IP a zabanovat ho). Důležitější mi proto příjde prevence.
Jinak jsem rád za každý komentář, názor nebo dotaz. Nepovažuji se za nějakého experta a rád se nechám poučit, nikdo není neomylný a pořád je co se učit nového.
19.Duben 2011 v 22:03
Mozna jsem to pochopil spatne, ale ten script „vita“ bota nebo ctecku hned v headeru linkem na 1×1 gif, na ktery kdyz prejde, tak je obratem zablokovan a dal uz se nepohne. Nebo se snad pletu a neco jse mpochopil blbe? Diky za ochotu…
19.Duben 2011 v 22:48
Tam jde pouze o to, že pokud nějaký bot vleze do míst kde je ten script nebo pokud požaduje nějaký soubor chráněný tímto scriptem automaticky se ta IP adresa zablokuje. Příklad s obrázkem slouží k zablokování botů které nerespektují soubor robots.txt.
Jenže to má trochu háček, pokud chci zakázat přístup do určité složky nebo k určitému souboru udělám to snadno zápisem do htaccess souboru (na 3 řádky) rovnou pro všechny a na furt a nepotřebuji k tomu tento script, který banuje úplně stejně ale banuje je jednotlivě každou IP zvlášť, u každého přístupu zapisuje do souboru a ještě k tomu odesílá mejl (nevím k čemu ty mejly autor má…asi na čtení až budou dlouhé zimní večery), to mi příjde trochu na hlavu.
24.Duben 2011 v 18:35
Kdyz zmenim prava u wp-config na 600 tak se web nenacte, musim nechat 644
24.Duben 2011 v 19:08
Přečti si třetí komentář nad tím tvým a zjistíš proč.
28.Duben 2011 v 22:51
Píšete o funkci: PHP funkce sleep();
Kam by se konkrétně měla umístit.
—
Kam a jaký příkaz v PHP bych měl umístit do logování, abych tam vložil nějaké časové zpoždění, např. stačilo by 0,3 sekundy, to se při přihlašování nepozná, ale robotům to značně znepříjemní čas ke crackingu.
29.Duben 2011 v 2:40
Tak existují přímo funkce napsané pro WordPress pracující s přihlášením uživatele, stačí hledat v dokumentaci a těch využít. Tady nejde ani tak o způsob použití jako spíš o tu informaci, že tohle samotné WP nijak neřeší.
Jinak konkrétněji…momentálně mně napadá napsat si asi vlastní plugin, který kontroluje POST z přihlašovacího formuláře administrace.
Tedy něco na způsob
if(isset($_POST['wp-submit'])){ sleep(1); // nebo cokoliv... }Každopádně se to dá ještě dál upravovat, kontrolovat IP nebo hosta, useragenta a podobně, ale nejlepším řešením je stejně použití nějakého silného hesla což je určitě bezpečnější a jednoduchší než jakýkoliv jiný kód.
19.Květen 2011 v 12:24
Dost zajímavé tipy pro zabezpečení,určitě rad využiji a pro zlepšeni nasadím.
Pěkný článek, velmi užitečný blog
20.Květen 2011 v 18:07
[...] chcete svůj WordPress zabezpečit dokonale, doporučuji k přečtení senzační článek o zabazpečení WordPressu přes soubor .htaccess od Lukenziho (v češtině), kde také doporučuji přečíst si diskuzi pod článkem, nebo [...]
3.Srpen 2011 v 23:15
Mohl bych poprosit podrobnější vysvětlení k zápisu zabezpečení adresáře wp-includes? Zde na webu uvádíš jednu verzi a v dokumentaci wp je ale zase jiná.. viz: http://www.separatista.net/forum/topic.php?id=413
25.Září 2011 v 18:23
Dobrý den.
Dnes jsem se pokoušel aktivovat plugin WassUp v.1.8.2.
Nelze jej aktivovat, hlásí:
Error installing WassUp tables.
Měl jsem WP-Super cache, ten je vypnutý, myslel jsem že to bude tím. Máte s tím zkušenost?
Děkuji
MirekK
7.Říjen 2011 v 14:48
Díky za pěkný článek. Musel jsem sice hodně vybírat (protože tady toho píšeš plno), ale je parádní. Práva souborů jsou již nastavené, aby se k nim nikdo z venčí nedostal a wp-config již nelze zobrazit. Nikdy by mne nenapadlo, že PHP může spadnout, ale náhoda je blbec… takže raději nastavit 403 než mít na pár minut zobrazené údaje
.
Jinak pokud už nahráváte zálohy SQL souborů doporučuji je ještě jednou zabalit a přejmenovat. Třeba na dfdgřč5g46.ddž46 a potom koncovku ddž46 zablokovat přes Filesmatch. Pochybuji, že pak někdo takový soubor najde a stáhne.
21.Říjen 2011 v 17:36
Díky za super článek!
1.Prosinec 2011 v 0:28
This can be a important publish! Thanks for that! Together with sincerely Luke aka couchgool.
2.Prosinec 2011 v 19:40
Velmi dobrý článek, něco z toho jsem citoval na svém blogu v článku o bezpečnosti. http://wordpress.bigdrobek.com/bezpecnost/
1.Leden 2012 v 15:43
Order Allow,Deny
Deny from all
Tímto kódem si zároveň zablokujete přístup k souboru robots.txt, takže doporučuji z toho příponu txt vynechat.
1.Leden 2012 v 15:46
Kód se neuložil správně. Jedná se o zákaz přímého přístupu přes prohlížeč k souborům htaccess a htpasswd, a všem s příponou ini,txt,phps,fla,psd,log,sh,bak,backup,back,set a hlavně sql.
24.Únor 2012 v 22:22
Mám dotaz k tomuto:
„Souboru wp-config.php nastavit práva na 600, ostatním na 640.“
Co znamená „ostatním na 640″? wp-pass.php, wp-atom.php … ?
27.Březen 2012 v 14:58
Díky za užitečné rady. Asi se ocitám v roli hloupého administrátora. Rychle napravím.