[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
fwd: JYA, Cryptome Help Request
- To: debate@fitug.de
- Subject: fwd: JYA, Cryptome Help Request
- From: Andy Mueller-Maguhn <andy@ccc.de>
- Date: Wed, 26 Jul 2000 17:10:03 +0200
- Comment: This message comes from the debate mailing list.
- Sender: owner-debate@fitug.de
kam grad passend zum thread...
>Date: Wed, 26 Jul 2000 10:22:19 -0400
>To: cypherpunks@cyberpass.net
>From: John Young <jya@pipeline.com>
>
>We have finally been able to get the error log of jya and cryptome.
>Assistance in interpreting logs would be appreciated.
>
>Background: late Friday, July 21, service for both sites began to be
>very slow and there have been repeated outages since then.
>
>Our ISP, Digital Nation, has checked on our system several times during the
>outages and had stated each time that there is nothing wrong except an
>overload of hits, that our server is underpowered for the load. There is
>no evidence of DoS or other attack. One administrator stated that due to
>the volume of hits he could not access the machine, had to turn it off,
>and then quickly get inside for review before the hits built up sufficiently
>to prevent access.
>
>On Monday, July 23, upon Digital Nation's advice that more CPU power was
>needed to handle the load, and that there was no other cause of the problem,
>we rented a more powerful server (about 8-fold increase) which should come
>online at the end of this week.
>
>Declan's article ran on Friday July 21 day and the hits from it did not
>seem to affect the sites. Saturday, an AP story appeared but it did not
>include links to the site, however, Drudge Report picked up the AP story
>and provided a munged link to jya.com:
>
> http://jya.com/crypto.htmhttp://jya.com/crypto.htm
>
>Thousands of hits on this non-existent file began to appear in the
>error log, and there have now been tens of thousands of them (maybe in
>the hundreds of thousands, no count has been made, and each is
>multiplied by Digital Nation's error page with its graphics).
>
>Late Saturday night a Washington Post article appeared which provided
>a link to http://jya.com/crypto.htm. That article later appeared on
>a number of popular sites. Later articles in Reuters, Financial Times,
>also provided links, and the access log shows folks coming in
>from those sites without problems. Still, the Drudge errors were
>predominant by far.
>
>The size of the access log for the two sites jumped from ~11MB before
>the problem began (May 3 to July 21) to over 113MB in four days, a
>ten-fold increase.
>
>The error log has jumped from 13MB to only 15MB since July 21. (By far the
>largest cause of previous errors is the pernicious "favicon.ico.")
>
>Soon after the Drudge attack began, this entry in the error log started to
>appear and repeated every few minutes, sometimes every minute (entries
>numbered by us for reference):
>
>(1) (32)Broken pipe: accept: (client socket)
>
>This entry had appeared only infrequently previously.
>
>Several hours later entry (2) appeared dozens of times at the
>same clock time:
>
>(2) [warn] child process 736 still did not exit, sending a SIGTERM
>
>Followed by several iterations of entry (3) at the same clock time:
>
>(3) [error] child process 628 still did not exit, sending a SIGKILL
>
>And then:
>
>(4) Site site1 has invalid certificate: 4999 Certificate files do not exist.
>(5) Site site2 has invalid certificate: 4999 Certificate files do not exist.
>
>(6) [crit] (98)Address already in use: make_sock: could not bind to port 80
>
>(7) [notice] caught SIGTERM, shutting down
>
>(8) Site site1 has invalid certificate: 4999 Certificate files do not exist.
>(9) Site site2 has invalid certificate: 4999 Certificate files do not exist.
>
>(10) [notice] Apache/1.3.6 (Unix) mod_perl/1.21 mod_ssl/2.2.8 OpenSSL/0.9.2b
> configured -- resuming normal operations
>
>The pattern of these series of entries continues, with shutdowns and restarts
>repeating since Saturday, July 22.
>
>During the outage period we have been sent frequent automatic messages like
>the following:
>
>(11) Over the past fifteen minutes, the CPU has been heavily loaded.
>
> This will result in noticible performace loss. Consider moving some
>of the
> services to other Cobalt servers, or reduce the complexity of the CGI
> scripts running on the Cobalt server itself.
>
> 1 minute load average: 27.79
> 5 minute load average: 68.67
> 15 minute load average: 84.27
>
>(12) Memory on the Cobalt server is heavily used.
> The Cobalt server needs more memory than it currently has.
>
> Consider adding more DRAM to the server.
>
> Total memory is: 162376 KB
> Used memory is: 161012 KB
> Free memory is: 1364 KB
> Percent used is: 99
>
>(13) Your server (cob487) is not responding on the port (80) we are
>monitoring -
> please let us know if this is going to be a permanent condition.
>
> If you have a support contract with us, and this is within normal
>business
> hours, feel free to send an e-mail to unixadmin@dn.net or ntadmin@dn.net
> regarding the problem you are having.
>
> If you are doing work on your server, you can reply to this message
>and it will
> be noted by our SOC staff. If this is an unexpected problem for you,
>you may
> wish to contact anyone else at your company who might be working on the
> server to find out if they are aware of the situation.
>
> This ticket will remain open until the server is back online, is
>accepting
> connections, or you are notified by our SOC staff that the port we are
> monitoring has been changed to avoid alarms on our end.
>
> Please let us know if you need anything.
>
> Thanks,
>
> --Server Operations Center
>
>
>We would appreciate advice on whether these log entries and messages are
>consistent with simple overloading or could indicate an attack, even a
>presumbably accidental attack by Drudge (who has still not answered my
>Saturday e-mail to correct the URL).
>
>Thanks very much.
>