Cenzic 232 Patent
Paid Advertising
sla.ckers.org is
ha.ckers sla.cking
Sla.ckers.org
If you have some interesting news or want to throw up a link to discuss it, here's the place. Anything is okay, even shameless vendor launches (since that is often applicable to what we work on). 
Go to Topic: PreviousNext
Go to: Forum ListMessage ListNew TopicSearchLog In
Apache Infrastructure Team - hacked
Posted by: stuckinphp
Date: April 13, 2010 08:41PM

https://blogs.apache.org/infra/entry/apache_org_04_09_2010


I wonder who did it?

Options: ReplyQuote
Re: Apache Infrastructure Team - hacked
Posted by: Skyphire
Date: April 15, 2010 10:34PM

It's about time Apache disabled mod_status:

http://www.apache.org/server-status

Options: ReplyQuote
Re: Apache Infrastructure Team - hacked
Posted by: id
Date: April 16, 2010 11:49AM

It's about time they took security seriously period.

https://apache.org/

apache.org uses an invalid security certificate.

The certificate is only valid for *.apache.org

(Error code: ssl_error_bad_cert_domain)

uh...
># We have remedied the JIRA installation issues with our reinstall. JIRA is now installed by root and runs as a separate daemon with limited privileges.

how about running it in a secure environment that no users have access to?

># For the time being we are running JIRA in a httpd-tomcat proxy config with the following rules:
>
>
> ProxyPass /jira/secure/popups/colorpicker.jsp !
> ProxyPass /jira/secure/popups/grouppicker.jsp !
> ProxyPass /jira/secure/popups/userpicker.jsp !
> ProxyPass /jira http://127.0.0.1:18080/jira

>Sysadmins may find this useful to secure their JIRA installation until an upgrade is feasible.

I think they meant to say: Sysadmins may find this useful to give them a false sense of security with their JIRA installation.

# We will be making one-time-passwords mandatory for all super-users, on all of our Linux and FreeBSD hosts.

yay..maybe, if they understand how to implement it...and now how about locking down sudo, auditing access, etc, etc

># We have disabled caching of svn passwords, and removed all currently cached svn passwords across all hosts ast the ASF via the global config /etc/subversion/config file:

> [auth]
>store-passwords = no

good, not that I think it will help much

># Use Fail2Ban to protect web application login failures from brute force attacks

^thinking that is _protection_ is full of Fail

I guess they would have to understand security to practice it, bummer.

-id

Options: ReplyQuote


Sorry, only registered users may post in this forum.