Brian Layman gave a presentation on WordPress security best practices. He discussed common attacks like SQL injection, cross-site scripting, and denial of service attacks. He recommended keeping WordPress, plugins, and themes updated, using strong unique passwords, and enabling SSL. Other tips included regular backups, using limited user accounts, and carefully vetting any third-party code added to a site. The presentation provided resources for hardening specific platforms like WordPress, Drupal, and Joomla.
2. Who I am. What I do. What I see.
What software do your blogs run on?
Who here has had a blog hacked, defaced, stolen or
taken down?
Is your site safe? (No one would ever want to hack
my blog about _____.)
The title is a lie…
5. Content or uploads destroyed
Hidden hyperlinks added to your site
Redirect to another site
Content edited
Hijacked website
Defacement
Bank fraud
6. CSRF/XSRF – Cross Site Request Forgery
XSS – Cross Site Scripting
SQL Injection
DDOS – (Distributed) Denial of Service
DNS Hijacking – Spoofing or Poisoning
Malvertising – Malicious Advertising
Stolen Password
Bad Code
8. What is it? You tell me…
Who is right?
My thought:
Any steps that may eliminate a large subset of
attacks on your blog should be taken.
9. The basics
Passwords
Communication (Plain Text vs. SSL)
Updates
Watch what you add to your sites
(plugins/themes/add-ons)
Backups
Google Webmaster Tools
10. Use strong passwords
Make them unique in high value situations
11. Pay attention to how you are sending your
passwords
Wireless Networks = Risk
FTP – Use SFTP instead
Email – Use SSL Ports 587,995,993 vs 25,110,143
Skype – Syncs history upon connect, never send
secure passwords – EVER
CPanel/WHM/Admin pages – if it is http not https, your
password can be scraped
12. Keep your blog, plugins, themes, & operating system
current – yes, even Linux
Security and attacks improve over time
2005 – Admin operations required a referrer
2006 – Admin operations required a NONCE
2007 – Plugin pages forced to check security
2008 – Randomized keys and salts & upgrades
2009 – Security escalations issues – full review
2010 – Automated plugin and theme upgrades
2011 – Sniffing, upload, clickjacking, file cleanup
13. Every plugin or theme is a security risk
“Free Theme” sites are a very high risk
Less popular & highly specialized plugins have had
less eyes on them and are riskier
Older plugins used older security standards - we
simply knew less and had fewer tools
You are responsible for your site. Learn how to
identify problems or make a friend who can.
14. Both files and database
Keep the files offline
If you have files online keep them out of public_html
As important as having the backups…
Know how to restore them!
Before you restore – delete the files and directories
to remove the hack files
15. How do you know you are hacked?
Google will email you when they consider you a risk
http://www.google.com/webmasters/
http://www.google.com/webmasters/checklist/
https://www.google.com/webmasters/tools/reconsideration
You can configure multiple owners
16. EVERYTHING that is displayed on the screen must
be filtered.
WordPress provides: esc_html esc_url esc_*
http://codex.wordpress.org/Data_Validation
EVERYTHING that you send to the database must
be filtered.
WordPress provides: $wpdb->prepare
TRUST NOTHING
Try to use your text instead of user input
17. Permissions - The 755 myth
chmod -R 755 *
Generic: Directories Should be 755 Files 644
Reality: The least privileges provides the most access
VPS vs Shared Hosting vs Managed Hosting
Flexibility, Access, Less risk = More $
Harden your own server or let someone do it
suPHP – Isolates your installation
18. Create a “Editor” user for posting
Create a new “Administrator”, delete the old one,
then only use it for maintenance
Never use wp_ as your table prefix
Look at wp-config-sample.php now and then and
update your wp-config.php
Force Secure password logins
http://codex.wordpress.org/Administration_Over_SSL
19. Move wp-config.php
Remove version Info
Rename the admin user
Move your wp-content directory – Possibly worth
doing but will break many plugins and themes
Use .htaccess to white list IP addresses or add an
extra password layer