| 1 |
El 24/12/12 03:16, Alex Efros escribió: |
| 2 |
> Hi! |
| 3 |
> |
| 4 |
> Please take a look at |
| 5 |
> http://serverfault.com/questions/460429/clone2-30-sec-delay-in-apache |
| 6 |
> |
| 7 |
> I didn't think it may be related to hardened but I've just found this in |
| 8 |
> kernel logs: |
| 9 |
> |
| 10 |
> 2012-12-23_20:45:19.15938 kern.alert: grsec: From 75.101.174.3: Segmentation fault occurred at 000014e2 in /usr/sbin/apache2[apache2:5346] uid/euid:81/81 gid/egid:81/81, parent /usr/sbin/apache2[apache2:1391] uid/euid:0/0 gid/egid:0/0 |
| 11 |
> 2012-12-23_20:45:19.17936 kern.alert: grsec: From 75.101.174.3: Segmentation fault occurred at 000014b6 in /usr/sbin/apache2[apache2:5302] uid/euid:81/81 gid/egid:81/81, parent /usr/sbin/apache2[apache2:1391] uid/euid:0/0 gid/egid:0/0 |
| 12 |
> 2012-12-23_22:28:17.53334 kern.alert: grsec: From 91.207.5.222: Segmentation fault occurred at 00003e5a in /usr/sbin/apache2[apache2:15962] uid/euid:81/81 gid/egid:81/81, parent /usr/sbin/apache2[apache2:5461] uid/euid:0/0 gid/egid:0/0 |
| 13 |
> 2012-12-23_22:28:17.69334 kern.alert: grsec: From 91.207.5.222: Segmentation fault occurred at 00003c0e in /usr/sbin/apache2[apache2:15374] uid/euid:81/81 gid/egid:81/81, parent /usr/sbin/apache2[apache2:5461] uid/euid:0/0 gid/egid:0/0 |
| 14 |
> 2012-12-23_22:28:17.92335 kern.alert: grsec: From 91.207.5.222: Segmentation fault occurred at 00004214 in /usr/sbin/apache2[apache2:16916] uid/euid:81/81 gid/egid:81/81, parent /usr/sbin/apache2[apache2:5461] uid/euid:0/0 gid/egid:0/0 |
| 15 |
> 2012-12-23_22:28:18.75335 kern.alert: grsec: From 91.207.5.222: Segmentation fault occurred at 00003fa4 in /usr/sbin/apache2[apache2:16292] uid/euid:81/81 gid/egid:81/81, parent /usr/sbin/apache2[apache2:5461] uid/euid:0/0 gid/egid:0/0 |
| 16 |
> |
| 17 |
> I can't check this right now - I have to wait until this bug happens again - |
| 18 |
> but looks like this bug happens after about 10-20 such records in logs. |
| 19 |
> So, maybe grsec break something in kernel while handling these segfaults |
| 20 |
> which in turn result in delay in clone(2)? Or maybe I have to run memtest. :( |
| 21 |
> |
| 22 |
┌────────────────────────────────────────────────────────────────────────────── |
| 23 |
Deter exploit bruteforcing |
| 24 |
───────────────────────────────────────────────────────────────────────────────┐ |
| 25 |
│ CONFIG_GRKERNSEC_BRUTE: │ |
| 26 |
│ │ |
| 27 |
│ If you say Y here, attempts to bruteforce exploits against forking │ |
| 28 |
│ daemons such as apache or sshd, as well as against suid/sgid binaries │ |
| 29 |
│ will be deterred. When a child of a forking daemon is killed by PaX │ |
| 30 |
│ or crashes due to an illegal instruction or other suspicious signal, │ |
| 31 |
│ the parent process will be delayed 30 seconds upon every subsequent │ |
| 32 |
│ fork until the administrator is able to assess the situation and │ |
| 33 |
│ restart the daemon. │ |
| 34 |
│ In the suid/sgid case, the attempt is logged, the user has all their │ |
| 35 |
│ processes terminated, and they are prevented from executing any further │ |
| 36 |
│ processes for 15 minutes. │ |
| 37 |
│ It is recommended that you also enable signal logging in the auditing │ |
| 38 |
│ section so that logs are generated when a process triggers a suspicious │ |
| 39 |
│ signal. │ |
| 40 |
│ If the sysctl option is enabled, a sysctl option with name │ |
| 41 |
│ "deter_bruteforce" is created. │ |
| 42 |
|
| 43 |
Likely your culprit. |
Archives