I'm seeing hundreds of these appearing in my log - I have the GRSecurity patch on my server, so it's blocking these, but I'm still VERY concerned. Here's what's appearing most recently:

Oct 3 18:38:26 server2 kernel: grsec: attempted resource overstep by requesting 4096 for RLIMIT_CORE against limit 0 by (ht$
Oct 3 18:38:27 server2 kernel: grsec: attempted resource overstep by requesting 4096 for RLIMIT_CORE against limit 0 by (ht$
Oct 3 18:38:27 server2 kernel: grsec: attempted resource overstep by requesting 4096 for RLIMIT_CORE against limit 0 by (ht$
Oct 3 18:38:28 server2 kernel: grsec: attempted resource overstep by requesting 4096 for RLIMIT_CORE against limit 0 by (ht$
Oct 3 18:38:28 server2 kernel: grsec: attempted resource overstep by requesting 4096 for RLIMIT_CORE against limit 0 by (ht$
Oct 3 18:38:28 server2 kernel: grsec: attempted resource overstep by requesting 4096 for RLIMIT_CORE against limit 0 by (ht$
Oct 3 18:38:28 server2 kernel: grsec: more alerts, logging disabled for 30 seconds
Oct 3 18:38:58 server2 kernel: grsec: attempted resource overstep by requesting 4096 for RLIMIT_CORE against limit 0 by (ht$
Oct 3 18:38:58 server2 kernel: grsec: attempted resource overstep by requesting 4096 for RLIMIT_CORE against limit 0 by (ht$
Oct 3 18:38:58 server2 kernel: grsec: attempted resource overstep by requesting 4096 for RLIMIT_CORE against limit 0 by (ht$
Oct 3 18:38:58 server2 kernel: grsec: attempted resource overstep by requesting 4096 for RLIMIT_CORE against limit 0 by (ht$
Oct 3 18:38:59 server2 kernel: grsec: attempted resource overstep by requesting 4096 for RLIMIT_CORE against limit 0 by (ht$
Oct 3 18:38:59 server2 kernel: grsec: attempted resource overstep by requesting 4096 for RLIMIT_CORE against limit 0 by (ht$
Oct 3 18:38:59 server2 kernel: grsec: more alerts, logging disabled for 30 seconds
Oct 3 18:39:29 server2 kernel: grsec: attempted resource overstep by requesting 4096 for RLIMIT_CORE against limit 0 by (ht$
Oct 3 18:39:29 server2 kernel: grsec: attempted resource overstep by requesting 4096 for RLIMIT_CORE against limit 0 by (ht$
Oct 3 18:39:29 server2 kernel: grsec: attempted resource overstep by requesting 4096 for RLIMIT_CORE against limit 0 by (ht$
Oct 3 18:39:29 server2 kernel: grsec: attempted resource overstep by requesting 4096 for RLIMIT_CORE against limit 0 by (ht$
Oct 3 18:39:29 server2 kernel: grsec: attempted resource overstep by requesting 4096 for RLIMIT_CORE against limit 0 by (ht$
Oct 3 18:39:29 server2 kernel: grsec: attempted resource overstep by requesting 4096 for RLIMIT_CORE against limit 0 by (ht$
Oct 3 18:39:29 server2 kernel: grsec: more alerts, logging disabled for 30 seconds
Oct 3 18:40:00 server2 kernel: grsec: attempted resource overstep by requesting 4096 for RLIMIT_CORE against limit 0 by (ht$
Oct 3 18:40:00 server2 kernel: grsec: attempted resource overstep by requesting 4096 for RLIMIT_CORE against limit 0 by (ht$
Oct 3 18:40:00 server2 kernel: grsec: attempted resource overstep by requesting 4096 for RLIMIT_CORE against limit 0 by (ht$
Oct 3 18:40:00 server2 kernel: grsec: attempted resource overstep by requesting 4096 for RLIMIT_CORE against limit 0 by (ht$
Oct 3 18:40:00 server2 kernel: grsec: attempted resource overstep by requesting 4096 for RLIMIT_CORE against limit 0 by (ht$
Oct 3 18:40:00 server2 kernel: grsec: attempted resource overstep by requesting 4096 for RLIMIT_CORE against limit 0 by (ht$
Oct 3 18:40:00 server2 kernel: grsec: attempted resource overstep by requesting 4096 for RLIMIT_CORE against limit 0 by (httpd:28405) UID(0) EUID(0), parent (httpd:1007) UID(0) EUID(0)....<<<<----- Full line, for an example
Oct 3 18:40:00 server2 kernel: grsec: more alerts, logging disabled for 30 seconds
Oct 3 18:40:30 server2 kernel: grsec: attempted resource overstep by requesting 4096 for RLIMIT_CORE against limit 0 by (ht$
Oct 3 18:40:30 server2 kernel: grsec: attempted resource overstep by requesting 4096 for RLIMIT_CORE against limit 0 by (ht$
Oct 3 18:40:30 server2 kernel: grsec: attempted resource overstep by requesting 4096 for RLIMIT_CORE against limit 0 by (ht$
Oct 3 18:40:30 server2 kernel: grsec: attempted resource overstep by requesting 4096 for RLIMIT_CORE against limit 0 by (ht$
Oct 3 18:40:30 server2 kernel: grsec: attempted resource overstep by requesting 4096 for RLIMIT_CORE against limit 0 by (ht$
Oct 3 18:40:30 server2 kernel: grsec: attempted resource overstep by requesting 4096 for RLIMIT_CORE against limit 0 by (ht$
Oct 3 18:40:30 server2 kernel: grsec: more alerts, logging disabled for 30 seconds

And here's what was happening earlier:

Oct 3 02:16:46 server2 kernel: grsec: From 209.237.238.158: attempted resource overstep by requesting 302235648 for RLIMIT_AS against limit 101009408 by (httpd:15274) UID(99) EUID(99), parent (httpd:12708) UID(99) EUID(99).... <<<<<---- Full line, for example
Oct 3 02:16:46 server2 kernel: grsec: From 209.237.238.158: attempted resource overstep by requesting 302235648 for RLIMIT_$
Oct 3 02:16:49 server2 kernel: grsec: From 207.158.138.29: attempted resource overstep by requesting 301961216 for RLIMIT_A$
Oct 3 02:16:49 server2 kernel: grsec: From 207.158.138.29: attempted resource overstep by requesting 301961216 for RLIMIT_A$
Oct 3 02:18:51 server2 kernel: grsec: From 216.142.43.54: attempted resource overstep by requesting 302309376 for RLIMIT_AS$
Oct 3 02:18:51 server2 kernel: grsec: From 216.142.43.54: attempted resource overstep by requesting 302309376 for RLIMIT_AS$
Oct 3 02:21:45 server2 kernel: grsec: From 65.95.81.114: attempted resource overstep by requesting 302141440 for RLIMIT_AS $
Oct 3 02:21:45 server2 kernel: grsec: From 65.95.81.114: attempted resource overstep by requesting 302141440 for RLIMIT_AS $
Oct 3 02:21:51 server2 kernel: grsec: From 195.224.200.135: attempted resource overstep by requesting 302149632 for RLIMIT_$
Oct 3 02:21:51 server2 kernel: grsec: From 195.224.200.135: attempted resource overstep by requesting 302149632 for RLIMIT_$
Oct 3 02:22:25 server2 kernel: grsec: From 209.157.220.197: attempted resource overstep by requesting 302268416 for RLIMIT_$
Oct 3 02:22:25 server2 kernel: grsec: From 209.157.220.197: attempted resource overstep by requesting 302268416 for RLIMIT_$
Oct 3 02:23:46 server2 kernel: grsec: From 12.247.57.160: attempted resource overstep by requesting 302309376 for RLIMIT_AS$
Oct 3 02:23:46 server2 kernel: grsec: From 12.247.57.160: attempted resource overstep by requesting 302309376 for RLIMIT_AS$
Oct 3 02:25:55 server2 kernel: grsec: From 66.55.232.203: attempted resource overstep by requesting 301961216 for RLIMIT_AS$
Oct 3 02:25:55 server2 kernel: grsec: From 66.55.232.203: attempted resource overstep by requesting 301961216 for RLIMIT_AS$

Any thoughts? The earliest attacks look like they're from random IPs, and the newest don't even have IPs attached. Even with GRSEC, I'm still concerned that something could happen.

- Matt

Have you updated openssl in the last couple days?


tcpdump and capture the traffic to see what is actually being sent

I just updated openssh, but openssl was not upgraded by CPanel - I still have the old version, and if CPanel doesn't release a patch in the next day, I'll get the DC to upgrade openssl. I saw nothing strange in tcpdump, and the attacks haven't happened since late last night.

- Matt

Run these if you wanna upgrade OpenSSL ..


cd && mkdir ./updates
cd ./updates
rpm -e openssl-devel

wget http://www.openssl.org/source/openssl-0.9.7b.tar.gz
tar -xzvf ./openssl-0.9.7b.tar.gz
cd ./openssl-0.9.7b
whereis openssl
rm -f /usr/bin/openssl
rm -rf /usr/include/openssl
./config --prefix=/usr --openssldir=/usr/include/openssl
make
make test
make install
cd ../
rm -rf ./openssl-0.9.7b

..and run the following to check the version afterwards ...

openssl version

Should I upgrade to 0.9.7c instead of b? I was going to upgrade to the latest version (which I will do soon), and I know how to do it, but I'm just trying to figure out if I should go with the latest version or b.

- Matt

Up to you really.. I normally stay a build behind for a week or two until it appears stable enough... unless it's a security release.

Originally posted by PepsiTwist22
Up to you really.. I normally stay a build behind for a week or two until it appears stable enough... unless it's a security release.

That's the point. 0.9.7c is a security release:

http://www.openssl.org/news/secadv_20030930.txt

Kevin

Well, there might be some openssl-exploit out there ... at least someone (from brazil) ist testing my server :(

***.***.***.*** - - [05/Oct/2003:10:52:43 +0200] "GET /mod_ssl:error:HTTP-request HTTP/1.0" 400 453 "-" "-"

That's quite disgusting!
I've updated openssl last week, but my (self compiled) apache shows still the old version in its server info!
(Apache/1.3.28 (Unix) PHP/4.3.3 mod_ssl/2.8.15 OpenSSL/0.9.7b)
Will I have to recompile apache as well?

Michael

Originally posted by m-b
That's quite disgusting!

Actually, you should always assume that someone somewhere on the Internet is scanning you and probing you. Not only is it a good idea to be paranoid, it's usually true. The time to get worried about server security isn't when you get probed; it's long before.

I've updated openssl last week, but my (self compiled) apache shows still the old version in its server info!
(Apache/1.3.28 (Unix) PHP/4.3.3 mod_ssl/2.8.15 OpenSSL/0.9.7b)
Will I have to recompile apache as well?


No, not if Apache is dynamically linked against OpenSSL. Use 'ldd httpd' to take a look at that; you should see lines pointing to /usr/local/lib/libssl.so or something similar. Apache builds its version string at compile time, so if you want it to reflect the correct version string, do a quick rebuild. It will prevent false alarms in the future when you or a customer go to check the version and see the older number.

Kevin

thanks a lot!
That was a new command (lld) to me ;)
And a rebuild can't be wrong ...
(although tht 'ldd'-command shows that it is dynamic linked: it's just the server-string that is from build-time)

And paranoia is quite a funny thing: it's quite ok in a restricted way but it can also be sick! :)

Regards,
Michael