Mailinglist Archive: opensuse (3337 mails)

< Previous Next >
Re: [opensuse] Massive PHP DDOS ??
  • From: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@xxxxxxx>
  • Date: Fri, 21 Apr 2006 01:17:49 +0200
  • Message-id: <4448169D.7030401@xxxxxxx>
Marcel Mourguiart schrieb:
> On 4/20/06, jdd <jdd@xxxxxxxxx> wrote:
>>Marcel Mourguiart wrote:
>>>Hi, i have a web server with suse 10 ( php, apache, postnuke, etc ).
>>>My connection has been stop because MY server is making DDOS attacks
>>>Then i read this:
>>>Is there a patch, link or what ever you can give me to resolf the poblem ??
>>>Sorry if this not the appropriate list, i'm just desperate.
>>the best way should be to update your php version with YOU,
>>or if this is not sufficient directly from the php site.
>>I'm sure this bug is already fixed.
> I have every thing updated with YOU.
> Carl: I'll subscribe to "suse-segurity" and i'm aware this is not a
> suse specific bug or a linux one, is probably a php bug, which make
> the problem just harder to resolve.
> Any way if some body know the specific problem with PHP or have a
> clue, i'll be happy to heart.

Did you write some PHP code yourself? Do you use "safe mode"?
There are many things that can go wrong. The way I would recover from
such a situation if I had not explicitly secured the machine before:

1. Are there any passwords on this server which are also used elsewhere?
Change these passwords (only!) at the other locations.
2. Same for SSH keys.
3. Same for VPN keys.
4. Did you log into any machine from the compromised server? That machine
is likely also compromised.
5. Log into the server via SSH (but make sure to disable agent forwarding).
6. Is the server physically accessible? If yes, goto 7. Else goto 11.
7. Suspend-to-disk.
8. Boot from a live DVD.
9. Make an image of the whole hard drive and copy it to another machine
for later inspection.
10. Resume into the compromised installation.
11. Do you want to learn more, but risk to lose some forensic data?
If yes, goto 12. Else goto 18.
12. kill -STOP everything except the master sshd, your session sshd and
you session bash.
13. Change the sshd configuration to only accept pubkey authentication
and only accept connections from an IP address only you can use.
14. Restart sshd.
15. Check whether there are any non-stopped processes besides the ones
mentioned in step 11. If there are any, kill -STOP them.
16. Change the root password.
17. Backup all filesystems to another computer (do NOT login to the other
computer from the compromised machine, login to the compromised
machine FROM the other computer instead).
18. echo 1 > /proc/sys/kernel/sysrq
19. echo s > /proc/sysrq-trigger
20. echo u > /proc/sysrq-trigger
21. echo b > /proc/sysrq-trigger
22. Boot from readonly installation media.
23. Back up all data to another machine
24. Format and reinstall.
25. Run all updates.
26. Install and use tripwire.
27. Configure AppArmor or SELinux and learn to use it.
28. Restore your configuration from a known clean state.
29. Stop here unless you want to perform forensic analysis.
30. Make two copies of all data you gathered, at least one to readonly
media to prevent accidential deletion.
31. Begin forensic analysis on a writable copy of your data. First step
suggested is a diff between last known clean state and current state.


< Previous Next >