Re: Kernel Log Messages in Security Output
Terry Sposato wrote: Hi, Just got the following in my security run output and wondering what exactly it means: +++ /tmp/security.zNWgsW2T Fri Dec 28 03:01:05 2007 +(da0:umass-sim1:1:0:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 +(da0:umass-sim1:1:0:0): CAM Status: SCSI Status Error +(da0:umass-sim1:1:0:0): SCSI Status: Check Condition +(da0:umass-sim1:1:0:0): NOT READY asc:3a,0 +(da0:umass-sim1:1:0:0): Medium not present +(da0:umass-sim1:1:0:0): Unretryable error Opened disk da0 - 6 +(da0:umass-sim1:1:0:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 +(da0:umass-sim1:1:0:0): CAM Status: SCSI Status Error +(da0:umass-sim1:1:0:0): SCSI Status: Check Condition +(da0:umass-sim1:1:0:0): NOT READY asc:3a,0 +(da0:umass-sim1:1:0:0): Medium not present +(da0:umass-sim1:1:0:0): Unretryable error Opened disk da0 - 6 If anyone can shed some light on it or point me to some documentation that would be great. As far as I can tell the machine is running fine. There is hardware raid setup with mirroring on this box. There are no errors on the physical machine itself. Regards, Terry Does this error also occur at bootup? Medium not present seems to indicate something like I'm trying a CDROM drive but it's empty, or, since this is apparently umass(4) talking, there's this unformatted thumb drive stuck in my USB slot, or something like that. What, if anything, *is* plugged into the USB ports? What does `camcontrol devlist -v say? Could maybe also be some unsupported device that *looks* like a umass(4)device, too, but I'm not guru enough to guess much about that. It's just that the error looks a lot like what I described above. Maybe FBSD senses something interesting with the HW Raid? HTH, if grasping at straws is your hobby, Kevin Kinsey -- If your mother knew what you're doing, she'd probably hang her head and cry. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: kernel log messages
On Sep 14, 2007, at 10:05 AM, Ian Lord wrote: +++ /tmp/security.iwonKikI Thu Sep 13 03:02:27 2007 +pid 85092 (httpd), uid 80: exited on signal 11 pid 85097 (httpd), uid +80: exited on signal 11 pid 85099 (httpd), uid 80: exited on signal 11 +pid 85091 (httpd), uid 80: exited on signal 11 pid 85090 (httpd), uid +80: exited on signal 11 pid 85094 (httpd), uid 80: exited on signal 11 [ ... ] Is this something I should care about ? First time I see this, and since the os mention it to me, I guess it's something important :-) Well, it could indicate something going wrong with your hardware-- failing memory or an overheating CPU would tend to make long-running daemon processes die. However, it can also indicate that there was a bug in Apache or one of the modules which is being exposed by the incoming requests. In some cases, that may mean that someone malicious is trying to exploit a security problem. You might want to run portaudit and check to make sure you're current -- -Chuck ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: kernel log messages
+pid 85092 (httpd), uid 80: exited on signal 11 pid 85097 (httpd), uid +80: exited on signal 11 pid 85099 (httpd), uid 80: exited on signal 11 Is this something I should care about ? First time I see this, and since the os mention it to me, I guess it's something important :-) In almost every case I've seen posted to this list regarding sig 11 problems, the response has nearly always been replace memory. Even in a case of my own a few years back, said recommendation fixed my problem. (I think mine was during a buildworld). Aside from that, I've also heard of heat (as already stated this thread), and flaky power supply. Steve ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: kernel log messages
On Friday 14 September 2007 22:47:47 Steve Bertrand wrote: +pid 85092 (httpd), uid 80: exited on signal 11 pid 85097 (httpd), uid +80: exited on signal 11 pid 85099 (httpd), uid 80: exited on signal 11 Is this something I should care about ? First time I see this, and since the os mention it to me, I guess it's something important :-) In almost every case I've seen posted to this list regarding sig 11 problems, the response has nearly always been replace memory. Even in a case of my own a few years back, said recommendation fixed my problem. (I think mine was during a buildworld). Aside from that, I've also heard of heat (as already stated this thread), and flaky power supply. While this may be true, 90% of the cases of SIGSEV is programming error, combine that with a publically accessible daemon, it means unauthorized access thread. This is why it's listed in daily and why running the suggested portaudit is a good idea (both apache and php released security releases this week FYI). -- Mel ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Kernel log messages
Can you try the following patch to /etc/periodic/security ?
%%%
diff -u security.functions.orig -r1.2 security.functions
--- security.functions.orig 16 Nov 2002 14:58:39 -
+++ security.functions14 Dec 2002 20:00:41 -
@@ -44,6 +44,9 @@
if [ $1 = new_only ]; then
shift
filter=grep '^'
+if [ $2 = dmesg ]; then
+ filter=${filter} | grep -v 'ipfw:'
+fi
else
filter=cat
fi
%%%
Thanks, i'll try.
Where did you find it ?
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-questions in the body of the message
Re: Kernel log messages
On 2002-12-15 11:14, Erwan Breton [EMAIL PROTECTED] wrote:
Can you try the following patch to /etc/periodic/security ?
%%%
diff -u security.functions.orig -r1.2 security.functions
--- security.functions.orig 16 Nov 2002 14:58:39 -
+++ security.functions 14 Dec 2002 20:00:41 -
@@ -44,6 +44,9 @@
if [ $1 = new_only ]; then
shift
filter=grep '^'
+if [ $2 = dmesg ]; then
+ filter=${filter} | grep -v 'ipfw:'
+fi
else
filter=cat
fi
%%%
Thanks, i'll try.
Where did you find it ?
Nowhere. I wrote it. The usual there it no warranty, and I'm not
going to accept any responsibility for it stuff applies of course :P
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-questions in the body of the message
Re: Kernel log messages
On 2002-12-14 13:28, Jens Rehsack [EMAIL PROTECTED] wrote: Erwan Breton wrote: Hi, Since i have activate the firewall on my Box, I have many kernel log messages in my security check output every night. the problem is, i don't see anymore interessant messages like bad login. athena kernel log messages: ipfw: 600 Deny TCP 80.14.195.215:3795 10.255.255.250:4661 out via tun0 ipfw: 800 Deny TCP 80.14.195.215:3801 192.168.10.210:4661 out via tun0 ipfw: 800 Deny TCP 80.14.195.215:3810 192.168.1.77:4661 out via tun0 ipfw: 1600 Deny ICMP:3.3 192.168.1.2 80.14.195.215 in via tun0 ipfw: 4000 Deny TCP 80.105.241.117:62104 80.14.195.215:139 in via tun0 ipfw: 700 Deny TCP 80.14.195.215:4198 172.16.1.50:4661 out via tun0 Etc .. etc .. etc ... It seems you use rules which locks the blocked packets. If you sent your firewall config, I can say you which rules do that. Moved to [EMAIL PROTECTED], cause it's not a security related question but a config related one. Actually the rule numbers are listed above too. Rules 600, 700, 800, 1600 and 4000 are the ones that log denied packets. Deleting the 'log' keyword from those rules will make sure that logs are kept a bit more clean. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
Re: Kernel log messages
On Saturday 14 December 2002 14:23, Giorgos Keramidas wrote: On 2002-12-14 13:28, Jens Rehsack [EMAIL PROTECTED] wrote: Erwan Breton wrote: Hi, Since i have activate the firewall on my Box, I have many kernel log messages in my security check output every night. the problem is, i don't see anymore interessant messages like bad login. athena kernel log messages: ipfw: 600 Deny TCP 80.14.195.215:3795 10.255.255.250:4661 out via tun0 ipfw: 800 Deny TCP 80.14.195.215:3801 192.168.10.210:4661 out via tun0 ipfw: 800 Deny TCP 80.14.195.215:3810 192.168.1.77:4661 out via tun0 ipfw: 1600 Deny ICMP:3.3 192.168.1.2 80.14.195.215 in via tun0 ipfw: 4000 Deny TCP 80.105.241.117:62104 80.14.195.215:139 in via tun0 ipfw: 700 Deny TCP 80.14.195.215:4198 172.16.1.50:4661 out via tun0 Etc .. etc .. etc ... It seems you use rules which locks the blocked packets. If you sent your firewall config, I can say you which rules do that. Moved to [EMAIL PROTECTED], cause it's not a security related question but a config related one. Actually the rule numbers are listed above too. Rules 600, 700, 800, 1600 and 4000 are the ones that log denied packets. Deleting the 'log' keyword from those rules will make sure that logs are kept a bit more clean. humm, it's an idea but no way to log ipfw messages AND have only kernel messages in security check output ? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
Re: Kernel log messages
On 2002-12-14 16:04, Erwan Breton [EMAIL PROTECTED] wrote:
On Saturday 14 December 2002 14:23, Giorgos Keramidas wrote:
On 2002-12-14 13:28, Jens Rehsack [EMAIL PROTECTED] wrote:
Erwan Breton wrote:
Since i have activate the firewall on my Box, I have many kernel
log messages in my security check output every night. the problem
is, i don't see anymore interessant messages like bad login.
athena kernel log messages:
ipfw: 600 Deny TCP 80.14.195.215:3795 10.255.255.250:4661 out via tun0
ipfw: 800 Deny TCP 80.14.195.215:3801 192.168.10.210:4661 out via tun0
ipfw: 800 Deny TCP 80.14.195.215:3810 192.168.1.77:4661 out via tun0
ipfw: 1600 Deny ICMP:3.3 192.168.1.2 80.14.195.215 in via tun0
ipfw: 4000 Deny TCP 80.105.241.117:62104 80.14.195.215:139 in via tun0
ipfw: 700 Deny TCP 80.14.195.215:4198 172.16.1.50:4661 out via tun0
Etc .. etc .. etc ...
It seems you use rules which locks the blocked packets. If you sent
your firewall config, I can say you which rules do that.
Actually the rule numbers are listed above too. Rules 600, 700, 800,
1600 and 4000 are the ones that log denied packets. Deleting the
'log' keyword from those rules will make sure that logs are kept a bit
more clean.
humm, it's an idea but no way to log ipfw messages AND have only kernel
messages in security check output ?
Can you try the following patch to /etc/periodic/security ?
%%%
diff -u security.functions.orig -r1.2 security.functions
--- security.functions.orig 16 Nov 2002 14:58:39 -
+++ security.functions 14 Dec 2002 20:00:41 -
@@ -44,6 +44,9 @@
if [ $1 = new_only ]; then
shift
filter=grep '^'
+if [ $2 = dmesg ]; then
+ filter=${filter} | grep -v 'ipfw:'
+fi
else
filter=cat
fi
%%%
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-questions in the body of the message
