Re: Debian crashes: sw, hw or malicious hacker/virus problems?
HELO,
Please check the mailing list archives. If i don't remember wrong i've
heard about a package that breaks after a certain time, a bug that is
resolved now. I don't remember which package it was but you could at
least try to find something about it.
I know this reply is very vague but maybe it gives you somewhere to
start...
Regards,
Björn Elwhagen
On Mon, Oct 23, 2000 at 08:57:59AM +0200, Jean Orloff wrote:
> Hello, dear debian fellows!
>
> Please forgive my paranoid anonymity, in view of the last section of
> this message.
>
> 1) My problem:
>
> I have happily used debian since 1995 (0.93R6 if I recall?). But since I
> installed 2.1 on my new PC at work, about a year ago, that machine
> undergoes about a crash per month in average. Nothing to scare a
> windblows user, of course, but unbearable for someone who knows this
> should not be so. Especially as these crashes are unrecoverable: screen
> frozen, mouse/keyboard frozen (no vt switching nor clean reboot
> possible) and even no access from outside through the network. Thus no
> alternative to the brutal power switchoff, with subsequent fsck'ing of
> the whole disk.
>
> When does this happen? Always with a heavy load (2-3 users on a 128Mb
> pentium
> 400, each with several windows, netscape, emacs etc + some compilation
> or latex2html going on); always with at least one remote ssh login. I
> also sometimes had the impression of the mouse freezing temporarily
> before the total crash, but you know how short time causality can be
> violated in the human brain.
>
> 2) Software problems?
>
> In the beginning, I attributed this to the network interface card
> (3C905C=Tornado) that was not officially supported by Donald Becker's
> 3C59x
> driver. Indeed, a twin sister machine (same install, same hardware
> except for an officially supported 3C905B) had no problem whatsoever. So
> I fetched the official driver from 3com site, tried a precompiled
> mandrake kernel with this 3com driver, but the problem remained. I then
> tried various kernel+3C59x pre- or home-compiled versions (2.13, 2.15,
> 2.17)
> but with each I endured at least one crash. I checked the NIC
> autoconfigured network parameters with ether-diag, found out half duplex
> generated less error messages but nothing more serious. I installed
> gnu-accounting package (acct), to see the last commands that were
> executed before the crash, but found nothing special.
>
> 3) Hardware problems?
>
> Bored with switching kernels, I followed the hardware problem track.
> Despite a successful memory test at boot, maybe one of the 2 memory bars
> was bad? I ran during the summer on half memory, but it ended up by a
> crash again. I switched the memory bar: problem again a month later.
> Maybe the NIC slot was bad? I switched with the soundcard last week. No
> crash yet, but I have reasons to believe it won't help.
>
> 4) Hacker/virus problems?
>
> During the very first hour of the very first install, I got port-scan
> attacked (see log below). Bad point for debian, I thought: what is the
> probability of a PC being attacked in the first hour of its connection
> to the net? Looks more probable that the attack was triggered by the
> install process! Anyway, the ports for telnet (22) and ftp (??) were
> filtered by the local router (except for local machines), I was not
> running any daemon, so I was not too scared. After watching the logs for
> about a week, I opened the machine to full internet exclusively through
> ssh connections which are not filtered by the local router.
>
> Until last week, I had no reason to think of hacker origin to my
> crashes. But last week, I got 2 crashes. And I noticed something very
> curious in the accounting logs. Among the last processes that finished
> less than 5 minutes before the crash, there was a bunch of NAMELESS root
> processes, that started at 0 unix time (Jan 1 1970) and lasted 0 second
> (!?). E.g:
>
> # lastcomm
>
> S20acct S root ?? 0.01 secs Thu Oct 19 19:40
> accton S root ?? 0.00 secs Thu Oct 19 19:40
> ---> reboot
> root ?? 0.00 secs Thu Jan 1 01:00
> root ?? 0.00 secs Thu Jan 1 01:00
> root ?? 0.00 secs Thu Jan 1 01:00
> root ?? 0.00 secs Thu Jan 1 01:00
> root ?? 0.00 secs Thu Jan 1 01:00
> root ?? 0.00 secs Thu Jan 1 01:00
> root ?? 0.00 secs Thu Jan 1 01:00
> root ?? 0.00 secs Thu Jan 1 01:00
> root ?? 0.00 secs Thu Jan 1 01:00
> root ?? 0.00 secs Thu Jan 1 01:00
> root ?? 0.00 secs Thu Jan 1 01:00
> root ?? 0.00 secs Thu Jan 1 01:00
> root ?? 0.00 secs Thu Jan 1 01:00
> root ?? 0.00 secs Thu Jan 1 01:00
> root ?? 0.00 secs Thu Jan 1 01:00
> perl user1 ?? 0.18 secs Thu Oct 19 18:57
> sh user1 ?? 0.01 secs Thu Oct 19 18:57
>
> Suspicious, no? Such nameless processes occured in both crashes last
> week. I kept the acct logs of the previous one too: there they were,
> less than 5 minutes before the crash. Unfortunately, I could not check
> the ones before.
>
> But even more curious: my previous machine (call it PC2), with the
> same install, but a totally different (older) hardware. Users from my
> machine (call it PC1) often ssh-log to PC2 and vice-versa. Furthermore,
> during the portscan-attacked install, the new PC1 was bearing the name
> and address the previously existing PC2. Anyway, for the first time last
> week, PC2 endured 2 crashes too. On one of these crashes, there were
> nameless-timeless root processes just before the
> crash also. But no sign of remote login the full day: looks more like a
> virus than a hacker? Unless the nameless root processes were in fact
> erasing the footprints of the remote-login in the various logs, and
> their name got erased by the process that crashed the machine and thus
> left no track.
>
> All this is a bit loose: not that many statistics to be sure. But I am
> not too keen on accumulating statistics! So I would like to be able to
> get as much info out of each crash as I can. Acct is better than
> nothing, but in fact, I have no way to know which processes were
> actually active *during* the crash. Nor how much memory was used and
> things like that.
>
> 5) Questions:
>
> 0) Is anybody experiencing the same kind of flakiness? If it is really
> the install that triggered it for me, it should have triggered
> it for others!
> 1) How can one generate nameless processes in acct logs? Can this be
> normal?
> 2) What tools could I use to help pinpointing the problem? E.g: a
> process accounting that would log the beginning (instead of
> ending) processes...
> 3) Can a network driver really freeze the full kernel?
> 4) How can the kernel be frozen? Is there a kernel bug that propagated
> through 2.2.13-17?
>
> Many thanks for any help!
>
> PS: you can privately reply to this mail.
>
> Annex 1: Portscan attack (november 99)
>
> 9:07:13 tcplogd: port 1114 connection attempt from
> unknown@some.foreign.host [123.4.576.89]
> 9:07:13 tcplogd: port 1116 (idem)
> 9:07:15 tcplogd: port 1171 "
> 9:07:18 tcplogd: port 1174 "
> 9:07:20 tcplogd: port 1183 "
> 9:07:24 tcplogd: port 1186
> 9:07:26 tcplogd: port 1192
> 9:08:34 tcplogd: port 1195
> 9:09:10 tcplogd: port 1203
> 9:09:42 tcplogd: port 1206
> 9:10:05 tcplogd: port 1212
> 9:10:27 tcplogd: port 1215
> 9:11:03 tcplogd: port 1282
> 9:13:15 tcplogd: port 1371
> 9:14:07 tcplogd: port 1430
> 9:14:37 tcplogd: port 1433
> 9:14:48 tcplogd: port 1503
> 9:15:00 tcplogd: port 1506
> 9:18:23 tcplogd: port 1599
> 9:19:05 tcplogd: port 1634
> 9:19:13 tcplogd: port 1667
> 9:19:15 tcplogd: port 1794
> 9:19:17 tcplogd: port 1888
> 9:19:18 tcplogd: port 2042
> 9:19:20 tcplogd: port 2089
> 9:19:22 tcplogd: port 2093
> 9:21:20 tcplogd: port 2098
> 9:21:33 tcplogd: port 2103
> 9:21:35 tcplogd: port 2106
> 9:21:37 tcplogd: port 2146
> 9:21:38 tcplogd: port 2149
> 9:21:40 tcplogd: port 2153
> 9:21:42 tcplogd: port 2157
> 9:22:05 tcplogd: port 2160
> 9:24:01 tcplogd: port 2166
> 9:24:09 tcplogd: port 2169
> 9:26:10 tcplogd: port 2174
> 9:27:57 tcplogd: port 2213
> 9:27:57 tcplogd: port 2216
> 9:28:27 tcplogd: port 2221
> 9:31:17 tcplogd: port 2224
> 9:31:29 tcplogd: port 2232
> 9:31:48 tcplogd: port 2235
> 9:32:03 tcplogd: port 2243
> 9:32:16 tcplogd: port 2252
> 9:32:29 tcplogd: port 2255
> 9:32:42 tcplogd: port 2258
> 9:32:59 tcplogd: port 2266
> 9:33:23 tcplogd: port 2308
> 9:34:39 tcplogd: port 2377
> 9:34:41 tcplogd: port 2383
> 9:34:42 tcplogd: port 2386
> 9:34:45 tcplogd: port 2456
> 9:34:48 tcplogd: port 2465
> 9:35:29 tcplogd: port 2480
> 9:35:34 tcplogd: port 2545
> 9:35:38 tcplogd: port 2662
> 9:35:42 tcplogd: port 2666
> 9:35:46 tcplogd: port 2670
> 9:35:51 tcplogd: port 2857
> 9:35:58 tcplogd: port 2904
> 9:36:11 tcplogd: port 3084
> 9:36:13 tcplogd: port 3138
> 9:36:22 tcplogd: port 3141
> 9:36:36 tcplogd: port 3146
> 9:36:40 tcplogd: port 3203
> 9:36:51 tcplogd: port 3271
> 9:37:03 tcplogd: port 3329
> 9:37:15 tcplogd: port 3388
> 9:37:23 tcplogd: port 3444
> 9:37:26 tcplogd: port 3631
> 9:37:29 tcplogd: port 3689
> 9:37:32 tcplogd: port 3695
> 9:37:34 tcplogd: port 3755
> 9:37:38 tcplogd: port 3879
> 9:37:41 tcplogd: port 4003
> 9:37:43 tcplogd: port 4126
> 9:37:45 tcplogd: port 4129
> 9:37:54 tcplogd: port 4136
> 9:37:57 tcplogd: port 4142
> 9:38:03 tcplogd: port 4147
> 9:38:10 tcplogd: port 4152
> 9:38:19 tcplogd: port 4156
> 9:38:26 tcplogd: port 4159
> 9:38:28 tcplogd: port 4163
> 9:38:30 tcplogd: port 4169
> 9:38:41 tcplogd: port 4174
> 9:38:45 tcplogd: port 4180
> 9:38:54 tcplogd: port 4183
> 9:38:58 tcplogd: port 4188
> 9:39:03 tcplogd: port 4191
>
>
> --
> Unsubscribe? mail -s unsubscribe debian-user-request@lists.debian.org < /dev/null
>
Reply to: