What you have mentioned is generally how we protect all of our critical
path sites (shibboleth and restricted IP access to the backend), however
we have gone a step further with some of our more high-profile sites. We
also require all POST attempts to be made from an on-campus or VPN IP
address as ufl.edu is currently being botnetted(and has been for some
time), and it attempts to POST to our database. This doesn't effect the
end-user unless you have forms, which we have aggregated out to another
domain that we monitor vigilantly.
Additionally, after an attack make sure your database is cleaned. We
have advised a few sites where there have been a few attacks that were
repeatedly successful because the db wasn't pruned of malicious entries.
This is our dead-bolt, alarm system, and vicious guard-dog protection
system. We as admins can only do so much: the largest hole in any
security system is not the system, but the users.
We will see some(hopefully many) of you at the conference this afternoon,
On 04/22/2013 08:52 AM, Kelley,Richard A,JR wrote:
> We are in the process of getting a WordPress site set to use Shibboleth (meaning we are going through the Shibboleth paperwork). The site was regularly brute forced (no comment on people's password choices) until we made three changes:
> 1. Only techs were set as admins (initially, faculty were also admins--it was a control issue, ie they felt they needed 100% control).
> 2. All passwords were reset to 20 character pass phrases.
> 3. Dashboard access was locked down to just UF and VPN.
> Step two would not have been as important if Shibboleth was in place, but being this was an issue that we knew people would bulk at and drag their feet...
> The long and the short of it is attacks have stopped being successful. As a tech who regularly does support work while on vacation, I have not had a problem with the third step. It was the first step we implemented after the attacks and it definitely appeared to have an impact.
> Do I think there is a need for both Shibboleth and restricting the dashboard to UF and VPN? Put it this way, the front door to my house has a lock and a dead-bolt. I also have an alarm system. In a world where people break into others homes, you go with the level of security you can afford and that does not make life a pain. The dashboard restriction is an almost non-cost, and it does not really add much in the way of pain. We will keep it in place when Shibboleth is set.
> In a place beyond time and space,
> in a land far better than this,
> look for me there...
> RICHARD A KELLEY JR
> M.E. Rinker, Sr. School of Building Construction
> University of Florida
> Voice: 352-273-1186
> Email: [log in to unmask]
> This transmission is intended only for the person
> or entity to which it is addressed. If you are
> not the intended recipient of this message you
> are hereby notified that any use, review,
> retransmission, dissemination, reproduction or
> any action taken in reliance upon this message is
> prohibited. Any views expressed in this message
> may not necessarily reflect the views of the
> University of Florida.
> GATOR RAIDERS
> --The Bugs Stop Here--
> From: UF Web Managers [[log in to unmask]] on behalf of Chapman,Priscilla M [[log in to unmask]]
> Sent: Friday, April 19, 2013 4:38 PM
> To: [log in to unmask]
> Subject: WordPress authentication best practices
> From what I've read about automated attacks targeting WordPress, it looks like UF sites using Shibboleth for authentication wouldn't be vulnerable to these kinds of attempts. (It does confirm that having a default 'admin' user with 'admin' as the password is always a bad idea, though)
> Does anyone think there's a need to go beyond Shibboleth as a best practice? For example, limiting access to the dashboard to campus/VPN users?
> Just throwing it out there...discuss...
> Priscilla Chapman
> IT Expert / Web Developer
> College of Liberal Arts and Sciences IT
> University of Florida