NYCPHP Meetup

[Eddie Drapkin]

On Fri, Sep 11, 2009 at 4:11 PM, Ajai Khattri <ajai at bitblit.net> wrote:
> On Fri, 11 Sep 2009, Randal Rust wrote:
>
>> That's what I was thinking actually. There has to be something
>> *somewhere* that would give me an indication of where the issue lies.
>
> Finding the source of a break-in like this can be notoriously difficult.
> Much better to wipe the drive and reinstall using the latest OS and
> software that can run your app (because you have no idea if any system
> binaries have been replaced with trojans).
>
> If the breakin is through an OS vulnerability then keeping it up to date
> will help. Obviously, if it happens again with a up-to-date OS, then its
> possible its a vulnerability in PHP and/or your application code (in which
> case looking at POST requests in logs might help).
>
> I once had an old server that had an IRC process running disguised as a
> regular Apache process. I only figured it out by observing open port
> numbers using netstat and finding the process with lsof. In the end I
> narrowed the problem down to an old component in a Joomla install that
> had a known vulnerability - updating that component fixed the problem.
>
> But servers are constantly fending off brute-force ssh attacks (denyhosts
> is your friend for that kind of crap). These days I switch off all
> unnecessary services and make sure needed services are not exposed to the
> outside (MySQL listening on localhost, Postfix too is its just used for
> sending out, etc). On many systems this might been running a firewall
> with a very locked down configuration (protocol tracking is also my
> friend).
>
>
> --
> Aj.
>
> _______________________________________________
> New York PHP User Group Community Talk Mailing List
> http://lists.nyphp.org/mailman/listinfo/talk
>
> http://www.nyphp.org/show_participation.php
>


Speaking of firewall lock down, I'm a big fan of the iptables
configurations that deny access to ALL ports that aren't explicitly
allowed, which for a vanilla web server would be 443/80 and 22 for ssh
(and if you're crazy deny access to 22 save for an IP-based whitelist,
I use a dyndns entry and re-resolve it every 15 minutes, so I can get
in wherever, but I'm the only person to ever have ssh access to the
server).  I'd make sure password authentication is off for ssh as well
and only use keyfile auth, as it's inherently more secure and less
prone to attack.  If you set your firewall up this way, you're pretty
much guaranteed that an exploit is in your webapp, as webservers and
openssh are very rarely open to exploits.