[Cialug] URGENT! How to list all files new/modified last 24 hours

Fri Oct 26 13:23:21 CDT 2012

Agreed. Securing PHP is possible. Ubuntu.com is largely PHP based (using
Drupal). We are a huge target so it takes diligence.

That said, it is very easy to write insecure PHP code because it is kind of
like the assembly language of the web. There are lots of getting started
tutorials that teach bad practices. For example, <?php $name =
$_GET["name"]; echo "Hello {$name}"; ?> has an XSS vulnerability in it.

I will say that my company now has a policy against writing new apps in PHP
though, simply because new frameworks provide a lot of protection that help
avoid simple errors. We use Django (and Python) but Rails, Play (Java) and
such also do this. Zend is a PHP framework which provides many of these
benefits. I'd strongly suggest leaning on a framework like those and follow
their best practices. You get great stuff like CSRF protection, hashed
passwords and frequent security updates from a huge team of contributors to
help watch you back.

If you have access to the server via SSH only while it is off line you can
set up SSH tunneling to connect to the mail server using a pop or imap
client. If you have fs access to the mail spool (i.e. root access) you can
check to see if your mail is in /var/spool/mail and if so, just copy the
files. They are probably in mbox format, which can be read natively by
thunderbird, or as a folder full of emails, one file per email. In this 2nd
case you can rename the files to have a .eml extension and many email
programs will let you read them.

On Fri, Oct 26, 2012 at 12:25 PM, Kenneth Younger <kyounger at gmail.com>wrote:

> PHP itself isn't inherently dangerous. Let's not spread some FUD, now.
>
> There are plenty of very large sites that run PHP without security
> incidents of this kind, because they understand how to secure it. Facebook
> and WordPress.com come to mind. In fact, the WordPress.com vs. the
> self-installed-on-shared-hosting security incidents of the last year is a
> perfect example of that.
>
> A good measure you can take against attacks like this: Just make sure your
> systems are as quickly recoverable as possible. It won't save you from
> getting hacked, but when you do, you can at least be back up and running in
> no time (and hopefully have the hole plugged).
>
> Separation of duties would be another good one -- did anyone else wonder
> how email was affected here? One would hope that a compromised web server
> wouldn't affect that... Perhaps look at hosting your email someplace
> different (I gave up years ago and went with Google, I understand why a lot
> of folks don't).
>
> My two cents.
>
> -Kenny
>
> On Fri, Oct 26, 2012 at 12:12 PM, Afan Pasalic <afan at afan.net> wrote:
>
> > That would be great. But, this is "shared hosting" kind of server and I
> > don't have access to these things.Though, even I have dedicated server, I
> > don't think my "knowledge" will allow me to do it :-)
> >
> >
> >
> >
> > On 10/26/2012 12:05 PM, Josh More wrote:
> >
> >> To be clear... I am also advocating scrapping it and rebuilding.  I
> >> just think that after it's rebuilt, you should use Suhosin and
> >> Mod_Security and then use AppArmor to chroot it.  (There are other
> >> ways to chroot... I just like AppArmor the best.)
> >>
> >> AppArmor can also do cool stuff with your back end databases.
> >>
> >> You can also look at CloudFlare and Incapsula if you want additional
> >> cloudy protection.
> >>
> >> -Josh
> >>
> >> On Fri, Oct 26, 2012 at 12:02 PM, Nicolai
> >> <nicolai-cialug at chocolatine.**org <nicolai-cialug at chocolatine.org>>
> >> wrote:
> >>
> >>> On Fri, Oct 26, 2012 at 11:10:43AM -0500, Afan Pasalic wrote:
> >>>
> >>>  they changed every index.php file
> >>>>
> >>> Ah, good ol' PHP.  If you don't scrap it, then follow Josh's advice to
> >>> the letter.  But it would be better to scrap it IMO.  Then take the
> time
> >>> to set up a chroot webserver (nginx and Apache are both chroot by
> >>> default on OpenBSD).
> >>>
> >>> If you're going to take the time to do something, it may as well be to
> >>> build something that lasts.
> >>>
> >>>  Looks like they got in through my old website I coded myself. They
> found
> >>>> the hole.
> >>>>
> >>> I admire your honesty.  Lots of people in the same situation try to
> >>> "hide" the details to protect their supposed image, rather than be open
> >>> about it and learn from the experience.  Their efforts are transparent
> >>> and have the opposite effect.
> >>>
> >>>  I talked to tech support and the guy said they got in through FTP but
> I
> >>>> doubt it.
> >>>>
> >>> Unless this is chroot non-root UID anonymous read-only FTP, it should
> be
> >>> turned off.  Use SFTP or scp instead, already provided by OpenSSH.
> >>>
> >>> Nicolai
> >>> ______________________________**_________________
> >>> Cialug mailing list
> >>> Cialug at cialug.org
> >>> http://cialug.org/mailman/**listinfo/cialug<
> http://cialug.org/mailman/listinfo/cialug>
> >>>
> >> ______________________________**_________________
> >> Cialug mailing list
> >> Cialug at cialug.org
> >> http://cialug.org/mailman/**listinfo/cialug<
> http://cialug.org/mailman/listinfo/cialug>
> >>
> >
> > ______________________________**_________________
> > Cialug mailing list
> > Cialug at cialug.org
> > http://cialug.org/mailman/**listinfo/cialug
> >
> > --
> > Kenneth Younger III
> > Founder, Sheer Focus Inc.
> > e: <http://cialug.org/mailman/listinfo/cialug>kenny at sheerfocus.com
> > p: (515) 367-0001
> > t: @kenny <http://twitter.com/kenny>
> >
> >
> _______________________________________________
> Cialug mailing list
> Cialug at cialug.org
> http://cialug.org/mailman/listinfo/cialug
>

-- 
Matthew Nuzum
newz2000 on freenode, skype, linkedin and twitter

♫ You're never fully dressed without a smile! ♫