Server mehrmals pro Woche kaum erreichbar

Schaue morgen mal weiter.

Ich habe mal ne whois Abfrage für die IPs gemacht, die immer beim w00tw00t.at.ISC.SANS.DFind:) stehen:

inetnum: 85.214.16.0 - 85.214.139.255
netname: STRATO-RZG-DED2
descr: Strato Rechenzentrum, Berlin
country: DE
admin-c: CM265-RIPE
tech-c: XX1-RIPE
tech-c: WB14-RIPE
status: ASSIGNED PA
remarks: ***************************************************
remarks: * Abuse Contact: abuse@strato.de in case of Spam, *
remarks: * Hack Attacks, Illegal Activity, Violation, etc. *
remarks: ***************************************************
mnt-by: STRATO-RZG-MNT
source: RIPE # Filtered

person: Christian Mueller
address: Cronon AG
address: Pascalstrasse 10
address: D-10587 Berlin
address: Germany
phone: +49 30 398020
fax-no: +49 30 39802222
abuse-mailbox: abuse@strato.de
nic-hdl: CM265-RIPE
remarks: see also: XX1-RIPE CM5081-NSI CM1-ABC SOUL-RIPE
mnt-by: CRONON-MNT
source: RIPE # Filtered

person: Christian Xaver Mueller
address: Cronon AG
address: Pascalstrasse 10
address: D-10587 Berlin
address: Germany
phone: +49 30 398020
fax-no: +49 30 39 802-222
abuse-mailbox: abuse@strato.de
nic-hdl: XX1-RIPE
remarks: see also: CM265-RIPE SOUL-RIPE
mnt-by: CRONON-MNT
source: RIPE # Filtered

person: Wilhelm Boeddinghaus
address: Strato Rechenzentrum GmbH
address: Pascalstrasse 10
address: D-10587 Berlin
address: Germany
phone: +49 30 39802-0
fax-no: +49 30 39802-222
nic-hdl: WB14-RIPE
remarks: see also INTERNIC: >WB131<
mnt-by: CRONON-MNT
source: RIPE # Filtered

% Information related to '85.214.0.0/16AS6724'

route: 85.214.0.0/16
descr: Strato Rechenzentrum
origin: AS6724
mnt-by: STRATO-RZG-MNT
source: RIPE # Filtered

Ist es nicht seltsam, dass diese Hackerangriffe zu meinem Provider Strato führen?
 
Hallo,

in meinen Augen ist das absolut nicht seltsam.

Ich selber hatte schon mehrfache Versuche von den unterschiedlichsten Providern aus dem Server-Bereich.

Auch, wie in deinem Beispiel gennant, von Strato.

Oft handelt es sich dabei, davon bin ich zumindest überzeugt, um Scripte von denen der Serverinhaber nicht einmal etwas weiß.

Ich kann dir nur raten eine Mail mit den Logauszügen an die Abuse Mailadresse zu senden.
Meistens wird relativ schnell gehandelt und das Problem (mit diesem einen Server) hat sich erledigt.

Es ist allerdings nur eine Frage der Zeit bis der oder die nächsten Versuche im Log auftauchen.
 
Back-Up said:
inetnum: 85.214.16.0 - 85.214.139.255
Ist es nicht seltsam, dass diese Hackerangriffe zu meinem Provider Strato führen?
Click to expand...
Noe, den kanns genauso treffen wie jeden anderen ISP auch, wenn das nicht Deine eigene IP ist, dann ist das ein anderes System, ich nehme mal an eines Mietservers wie dein eigener es auch ist.
Das kann ein gekidnaptes System sein, das kann auch Vorsatz sein, nichts Genaues weiss man nicht, schau mal dass Du die Folgen fuer Dein System dokumentiert kriegst und dann sprich den Provider an, womoeglich weiss der Mieter des System gar nicht davon was da abgeht.
Davon abgesehen, Du hattest da einen Link gepostet, in dem mitunter dieser request auftaucht, aber auch ein anderer und ich denke um den ging es bei dem Hackerangriff im Sinne von sich Zugang zum Fremdsystem verschaffen.
Bei Dir wuerde ich erstmal nur davon ausgehen, dass jemand Deinen Apache halt zumuellt und ihn so lahmlegt, das ist noch nicht wirklich die Klasse, die ich als Hackerangriff bezeichnen wuerde.
Cool bleiben, Material sammeln (auch damit Du weisst woran Du bist) und dann mit diesen Informationen an den ISP gehn gut ist.

Ciao,
Mercy.
 
Hallo,

ich wollte jetzt mod_evasive installieren. Beim Compilieren erscheinen jedoch Fehlermeldungen. Was tun?

Code: 
hxxxxxx:/usr/local/src/mod_evasive # /usr/sbin/apxs2-prefork -cia mod_evasive20.c
/usr/share/apache2/build/libtool --silent --mode=compile gcc -prefer-pic -O2 -march=i586 -mtune=i686 -fmessage-length=0
-Wall -D_FORTIFY_SOURCE=2 -g -fPIC -Wall -fno-strict-aliasing -D_LARGEFILE_SOURCE -DAP_HAVE_DESIGNATED_INITIALIZER -DLIN
UX=2 -D_REENTRANT -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -D_SVID_SOURCE -D_GNU_SOURCE -DAP_DEBUG -Wmissing-prototypes -Wstric
t-prototypes -Wmissing-declarations -pthread -I/usr/include/apache2-prefork  -I/usr/include/apache2   -I/usr/include/apa
che2   -c -o mod_evasive20.lo mod_evasive20.c && touch mod_evasive20.slo
mod_evasive20.c: In function âaccess_checkerâ:
mod_evasive20.c:212: warning: implicit declaration of function âgetpidâ
mod_evasive20.c:212: warning: format â%ldâ expects type âlong intâ, but argument 4 has type âintâ
mod_evasive20.c: At top level:
mod_evasive20.c:327: warning: no previous prototype for ântt_node_createâ
mod_evasive20.c: In function âcreate_hit_listâ:
mod_evasive20.c:118: warning: control reaches end of non-void function
mod_evasive20.c: In function âdestroy_hit_listâ:
mod_evasive20.c:301: warning: control reaches end of non-void function
/usr/share/apache2/build/libtool --silent --mode=link gcc -o mod_evasive20.la  -rpath /usr/lib/apache2-prefork -module -
avoid-version    mod_evasive20.lo
/usr/share/apache2/build/instdso.sh SH_LIBTOOL='/usr/share/apache2/build/libtool' mod_evasive20.la /usr/lib/apache2-pref
ork
/usr/share/apache2/build/libtool --mode=install cp mod_evasive20.la /usr/lib/apache2-prefork/
cp .libs/mod_evasive20.so /usr/lib/apache2-prefork/mod_evasive20.so
cp .libs/mod_evasive20.lai /usr/lib/apache2-prefork/mod_evasive20.la
cp .libs/mod_evasive20.a /usr/lib/apache2-prefork/mod_evasive20.a
ranlib /usr/lib/apache2-prefork/mod_evasive20.a
chmod 644 /usr/lib/apache2-prefork/mod_evasive20.a
PATH="$PATH:/sbin" ldconfig -n /usr/lib/apache2-prefork
----------------------------------------------------------------------
Libraries have been installed in:
   /usr/lib/apache2-prefork

If you ever happen to want to link against installed libraries
in a given directory, LIBDIR, you must either use libtool, and
specify the full pathname of the library, or use the `-LLIBDIR'
flag during linking and do at least one of the following:
   - add LIBDIR to the `LD_LIBRARY_PATH' environment variable
     during execution
   - add LIBDIR to the `LD_RUN_PATH' environment variable
     during linking
   - use the `-Wl,--rpath -Wl,LIBDIR' linker flag
   - have your system administrator add LIBDIR to `/etc/ld.so.conf'

See any operating system documentation about shared libraries for
more information, such as the ld(1) and ld.so(8) manual pages.
----------------------------------------------------------------------
chmod 755 /usr/lib/apache2-prefork/mod_evasive20.so
apxs:Error: Config file /etc/apache2/httpd2-prefork.conf not found.
 
Wie kann ich "w00tw00t.at.ISC.SANS.DFind:)" verbieten irgendwas mit meinem Server zu machen? Meine Homepage lahmt schon wieder und in den Logfiles taucht wieder "w00tw00t.at.ISC.SANS.DFind:)" auf.

Code: 
85.25.48.145 - - [04/Sep/2006:14:05:08 +0200] PID: 24542 "GET /w00tw00t.at.ISC.SANS.DFind:) HTTP/1.1" 400 303 "-" "-"
85.25.48.145 - - [04/Sep/2006:14:05:08 +0200] PID: 19586 "GET /" 400 978 "-" "-"
85.25.48.145 - - [04/Sep/2006:14:30:06 +0200] PID: 20801 "GET /" 400 978 "-" "-"
85.25.48.145 - - [04/Sep/2006:14:30:06 +0200] PID: 20737 "GET /w00tw00t.at.ISC.SANS.DFind:) HTTP/1.1" 400 303 "-" "-"
Code: 
[Mon Sep 04 14:05:08 2006] [error] [client 85.25.48.145] client sent HTTP/1.1 request without hostname (see RFC2616 section 14.23): /w00tw00t.at.ISC.SANS.DFind:)
[Mon Sep 04 14:30:06 2006] [error] [client 85.25.48.145] client sent HTTP/1.1 request without hostname (see RFC2616 section 14.23): /w00tw00t.at.ISC.SANS.DFind:)
Code: 
top - 14:21:02 up 5 days, 21:51,  2 users,  load average: 2.24, 2.90, 1.90
Tasks: 449 total,   5 running, 444 sleeping,   0 stopped,   0 zombie
Cpu(s):  3.8% us, 19.9% sy,  0.0% ni, 67.4% id,  5.6% wa,  0.3% hi,  3.0% si
Mem:   2073848k total,  2024564k used,    49284k free,     3272k buffers
Swap:  1052248k total,   125148k used,   927100k free,   363572k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
19750 mysql     16   0  183m  47m 4276 S 23.2  2.3  34:22.61 mysqld
  386 root      16   0     0    0    0 R 22.2  0.0   1:34.57 kswapd0
26966 wwwrun    15   0 22576  10m 6564 D  1.7  0.5   0:01.77 httpd2-prefork
15176 wwwrun    16   0 25684  14m 6892 S  0.7  0.7   0:00.48 httpd2-prefork
 2055 root      17   0  2372 1228  768 R  0.7  0.1   0:00.21 top
30409 wwwrun    16   0 23068  11m 6768 S  0.3  0.6   0:00.80 httpd2-prefork
    1 root      16   0   688  268  224 S  0.0  0.0   0:01.85 init
    2 root      RT   0     0    0    0 S  0.0  0.0   0:00.20 migration/0
    3 root      34  19     0    0    0 S  0.0  0.0   0:00.00 ksoftirqd/0
    4 root      RT   0     0    0    0 S  0.0  0.0   0:00.10 migration/1
    5 root      34  19     0    0    0 S  0.0  0.0   0:00.00 ksoftirqd/1
    6 root      10  -5     0    0    0 S  0.0  0.0   0:00.00 events/0
    7 root      10  -5     0    0    0 S  0.0  0.0   0:00.00 events/1
    8 root      10  -5     0    0    0 S  0.0  0.0   0:00.18 khelper
    9 root      10  -5     0    0    0 S  0.0  0.0   0:00.00 kthread
   18 root      10  -5     0    0    0 S  0.0  0.0   0:00.00 kacpid
  340 root      10  -5     0    0    0 S  0.0  0.0   0:05.20 kblockd/0
  341 root      10  -5     0    0    0 S  0.0  0.0   0:00.14 kblockd/1
  384 root      15   0     0    0    0 S  0.0  0.0   0:00.03 pdflush
  385 root      15   0     0    0    0 S  0.0  0.0   0:00.29 pdflush
  387 root      11  -5     0    0    0 S  0.0  0.0   0:00.00 aio/0
  388 root      10  -5     0    0    0 S  0.0  0.0   0:00.00 aio/1
  977 root      10  -5     0    0    0 S  0.0  0.0   0:00.00 kseriod
 1030 root      15   0     0    0    0 S  0.0  0.0   0:00.00 kirqd
 1107 root      13  -5     0    0    0 S  0.0  0.0   0:00.00 ata/0
 1108 root      10  -5     0    0    0 S  0.0  0.0   0:00.00 ata/1
 1230 root      15   0     0    0    0 S  0.0  0.0   0:46.63 kjournald
 2076 root      11  -4  1848  932  628 S  0.0  0.0   0:00.62 udevd
 3279 root      20   0     0    0    0 S  0.0  0.0   0:00.00 shpchpd_event
 3894 messageb  16   0  3524 1448 1268 S  0.0  0.1   0:01.25 dbus-daemon
 4394 root      16   0  1524  492  428 S  0.0  0.0   0:00.54 dhcpcd
 4610 root      15   0  1884  900  716 S  0.0  0.0   0:10.53 syslog-ng
 4613 root      16   0  1628  604  412 S  0.0  0.0   0:07.02 klogd
 4644 root      16   0  1496  556  476 S  0.0  0.0   0:00.00 acpid
 4660 root      16   0  2792  780  692 S  0.0  0.0   0:00.00 couriertcpd
 4662 root      15   0  2692  768  608 S  0.0  0.0   0:00.00 courierlogger
 
Last edited by a moderator:
Die Requests kommen von einem vServer von Server4You.

IP: 85.25.48.145

Deswegen einfach IP mit Firewall blocken. Beispiel mit iptables:
Code: 
iptables -I INPUT -s 85.25.48.145 -j DROP

Dann solltest du deine Ruhe haben. Bei jedem Neustart ist die iptables rule wieder draussen.

Desweiteren schick doch mal ne Mail mit den Logs an abuse@server4you.de ;) Die kümmern sich da schon drum.
 
Back-Up said:
Wie kann ich "w00tw00t.at.ISC.SANS.DFind:)" verbieten irgendwas mit meinem Server zu machen?
Click to expand...

Nun ich habe selbst noch nicht damit gespielt und bin auch nicht so tief im Apachen, aber vielleicht kann mod_rewrite da was machen?
Vielleicht kann das ein Apache-Kenner hier bewerten, alternativ kann man's einfach mal ausprobieren, inhaltlich koennte das schon fast passen.
modrewrite.de | Apache mod_rewrite | Das Apache Modul mod_rewrite
modrewrite.de | mod_rewrite Anwendungen | Einsatzgebiete und Anwendungen von mod_rewrite
Apache module mod_rewrite

Alternativ fiele mir da noch ein modifiziertes denyhosts ein, wobei der Umgang mit dynamischen IP-Adressen sich beim Webserver dann doch etwas naja ... "schwieriger" darstellt.
Welcome to DenyHosts

Ciao,
Mercy.

P.S.: Sind das denn jetzt auch die Anfragen, die zu den haengenden Prozessen fuehren und wie lange ist so ein Prozess bis zu seiner Zwangsterminierung so in etwa blockiert? Wuerde mich nur der Neugierde halber mal interessieren.
 
Mercenary said:
P.S.: Sind das denn jetzt auch die Anfragen, die zu den haengenden Prozessen fuehren ...?
Click to expand...
Ich habe das Gefühl, dass dieses "w00tw00t.at.ISC.SANS.DFind" nicht viel mit den Ausfällen zu tun hat. Diese zugehörige PID findet man jedenfalls nicht in der error_log wieder.
Ich bin echt am Rande der Verzweiflung. Jetzt ist es bereits Standard, dass der Server täglich total zusammenbricht und wirklich gar nichts mehr geht und nur noch ein Reboot über den Stratokundenbereich den Server aus dem Koma erwachen lässt.

mod_rewrite schreibt doch nur Urls um?!?

IPs zu sperren ist auch recht nutzlos, da es jedes Mal andere sind.

Soll ich den Server mal komplett neu aufsetzen und diesmal nicht wieder alle Daten aufspielen, um zu schauen, obs dann wieder zu Ausfällen kommt?
 
Last edited by a moderator:
Beschaeftige dich weniger mit den sicher fatalen Folgen denn mit den Ursachen.
Soll ich den Server mal komplett neu aufsetzen und diesmal nicht wieder alle Daten aufspielen, um zu schauen, obs dann wieder zu Ausfällen kommt?
Click to expand...
Du hast den Weg, die Hinweise aus Deinem error_log, welche definitiv existierende Probleme verursachen und die Zahl der httpd-Prozesse in die Hoehe treiben, auszuwerten und die dazu gehoerenden requests zu finden scheinbar nicht weiter verfolgt (zumindest kenne ich das Ergebnis nicht).
Stattdessen ziehst Du in Betracht, Deine Daten wegzuwerfen ohne zu wissen, was die Stoerungen verursacht.

Selbst wenn es ohne Deine webpraesenzen keine Probleme gibt, was machst Du dann?
So etwas wuerde ich schon als Hinweis darauf werten, dass womoeglich etwas in Deinen Daten nicht stimmt aber was?

Wenn Du die Daten gar nicht mehr brauchst verstehe ich die Aufregung nicht, dann doch einfach platt machen und einen leeren Apache laufen lassen.
Andernfalls wirst Du aber doch auch nach einer Neuinstallation wieder nach der Ursache suchen muessen?

Du hast bisher noch kein error_log mit dazu gehoerigem access_log (samt PIDs) gepostet, sodass sich jemand anders ein Bild machen koennte, ich war davon ausgegangen es ginge um diese "/w00tw00t.at.ISC.SANS.DFind:)"-requests, welche die haengenden Prozesse verursachen jetzt stelle ich an meinem Apache fest nein, die Anfrage wird in 0,nichts beantwortet und das error_log tut das Ganze lapidar mit
[Wed Sep 06 00:44:49 2006] [error] [client 192.168.42.10] File does not exist: /mnt/disk/md0/storage/www/w00tw00t.at.ISC.SANS.DFind:)
Click to expand...
ab.

Also wenn es dahin gehen soll, dass spekuliert, geglaubt und geahnt wird, dann koennen wir in der Kirche weiter machen, Glaubensfragen und Aehnliches gehoeren dort hin.

Oder wir versuchen mithilfe des error_log und des access_log heraus zu finden was zuerst einmal die bereits bekannten weil gemeldeten Fehler verursacht zumal die bei Dir gemeldeten Fehler (die ja tatsaechlich fuer die Vielzahl Prozesse und damit Mehraufwand wohl mit verantwortlich sind).

Wenn es nicht moeglich ist, anhand von error_log und access_log der Ursache naeher zu kommen dann kann man immer noch anfangen mit der Nadel den Heuhaufen umzupfluegen.(Man muss uebrigens nicht zwangsweise nur einen 5-Zeiler aus einem Log mit codetags in den post einbinden, man kann auch ganze Dateien als Anhang beilegen).

Mercy.

P.S.: Wenn aus dem Text heraus zu lesen ist, dass ich leicht angefressen bin ob des Vorschlags halt mal einfach alles neu zu installieren, statt Ursachen zu suchen die in der jetzigen Umgebung womoeglich zu finden waeren, JA das bin ich und wenn es unangemessen war trotzdem zu antworten, dann entschuldige ich mich vorab dafuer.
P.P.S.: Ich verstehe, dass in gewissen Situationen eine ausgewogene Gelassenheit und ein kuehler Kopf einer gewissen Kopflosigkeit und hektischem Aktionismus weicht, aber der Thread zieht sich seit einigen Tagen wo dann auch mal Zeit fuer eine ruhige Betrachtung sein sollte und die Auswertung der Logs erwartete ich eigentlich mit einem gewissen Interesse. Ich bin von dem Ergebnis "Server platt machen und Daten wegwerfen" dezent .... Spock wuerde sagen "fasziniert" ich bin eher "erregt".
 
Mercenary said:
Du hast den Weg, die Hinweise aus Deinem error_log, welche definitiv existierende Probleme verursachen und die Zahl der httpd-Prozesse in die Hoehe treiben, auszuwerten und die dazu gehoerenden requests zu finden scheinbar nicht weiter verfolgt (zumindest kenne ich das Ergebnis nicht).
Click to expand...
Hallo Mercy,

das war meine Antwort, also mein Ergebnis:
Ich habe das Gefühl, dass dieses "w00tw00t.at.ISC.SANS.DFind" nicht viel mit den Ausfällen zu tun hat. Diese zugehörige PID findet man jedenfalls nicht in der error_log wieder.


Ich bin Laie und weiß einfach nicht, was zu tun ist. Deshalb kam der Vorschlag der Neuinstallation. Laien kommen halt manchmal auf Ideen, die den Experten völlig daneben vorkommen ;).
Dies ist nicht bös gemeint und soll auch absolut keine Missachtung der Vorschläge sein. Ich freue mich über die Antworten. Ich hatte meiner Meinung nach die Vorschläge berücksichtigt, aber es kann durchaussein, dass ich die Vorschläge ganz anders verstanden habe, als sie gemeint waren.
Im Moment weiß ich nicht mehr, was ich nun mit den Logdateien anfangen soll. Ich sehe halt nur immer wieder die selben Fehlermeldungen und ich konnte leider keine Verbindung zwischen access_log und error_log Meldungen herstellen.
 
Hallo,

Ursache für die ständigen Ausfälle war eine chinesische Seite, die auf eine Downloadseite bei uns verlinkt. Mir war das nur nicht aufgefallen, da es kein Trafficproblem war.
Der Server wurde trotzdem nochmal neu installiert, da der Server, nach der Meinung eines Experten, völlig falsch konfiguriert war.
Leider hat dieser Experte keine Zeit mehr gefunden den Server fertig zu konfigurieren. Jetzt stehe ich mit anderen Problemen da. Das gehört in einen anderen Thread...
 
You must log in or register to reply here.
Back
Top