Vorgehensweise bei gecracktem Server (hoher Traffik usw.)

Rund um die Sicherheit des Systems und die Applikationen
[nix]pepe
Userprojekt
Userprojekt
Posts: 244
Joined: 2003-04-08 19:36
 

Re: Vorgehensweise bei gecracktem Server (hoher Traffik usw.)

Post by [nix]pepe »

du gekommst bei den von hand eingetragenen cronjobs immer ne mail, warum auch immer... ich bekomme z.B. jedesmal, wenn mein server reload script zuschlägt ne mail, kann auf dauer echt nervig sein...
captaincrunch
Userprojekt
Userprojekt
Posts: 7066
Joined: 2002-10-09 14:30
Location: Dorsten
Contact:
 

Re: Vorgehensweise bei gecracktem Server (hoher Traffik usw.)

Post by captaincrunch »

du gekommst bei den von hand eingetragenen cronjobs immer ne mail, warum auch immer... ich bekomme z.B. jedesmal, wenn mein server reload script zuschlägt ne mail, kann auf dauer echt nervig sein...
Warum ist ganz einfach : der cron-Daemon verschickt die Ausgabe der Jobs, die du ihm vor die Füße schmeißt.

Wenn du das nicht möchtest, kannst du die Ausgabe einfach mit angehängtem 2>&1 >/dev/null im Datennirvana verschwinden lassen, und bekommst keine "nervigen" Mails mehr.

Btw. : Wenn das Thema interessant für dich ist, mach doch bitte ein eigenes Posting dazu auf, hier ist es relativ OffTopic ... ;)
DebianHowTo
echo "[q]sa[ln0=aln256%Pln256/snlbx]sb729901041524823122snlbxq"|dc
sacha
Posts: 65
Joined: 2002-11-11 19:01
Location: Aachen, NRW, Germany
Contact:
 

Re: Vorgehensweise bei gecracktem Server (hoher Traffik usw.)

Post by sacha »

Hi [NIX]Pepe,

mail bekommen ist ja gut und schoen, aber die Werte, die da drinstehen machen mir Sorgen. Schliesslich macht das per Cronjob aufgerufene Script ja nichts anderes, als den Befehl auszufuehren, den ich auch so eingeben kann:
ls -d /proc/* | grep [0-9] | wc -l; ps ax | wc -l

Nur stimmen die Werte beim Script halt nicht ueberein waehrend sie das beim manuellen Aufruf aber doch tun.

Ciao,

Sacha
msgbeep
Posts: 62
Joined: 2002-10-08 11:27
 

Re: Vorgehensweise bei gecracktem Server (hoher Traffik usw.)

Post by msgbeep »

:) bei mir gehts auch auf nem Suse Distr. problemlos !!!
msgbeep
chris76
Posts: 1878
Joined: 2003-06-27 14:37
Location: Germering
 

Bei mir auch Probleme

Post by chris76 »

Tach also bei mir mit suse 8.1 ist es auch so das das script jedes mal meldet, das die Prozesse nicht stimmen? Aber beim Manuellen aufruf danach passt alles?

Danke Ciao Christian
kwik
Posts: 41
Joined: 2002-06-28 20:08
Location: München
Contact:
 

Re: Vorgehensweise bei gecracktem Server (hoher Traffik usw.)

Post by kwik »

Könnte hier jemand passend posten, wie ich die Ã?beltäter-IP herausfinden und sperren kann, so dass er nicht mehr auf den Server zugreifen kann?
wintix
Posts: 22
Joined: 2003-07-22 15:47
 

Re: Vorgehensweise bei gecracktem Server (hoher Traffik usw.)

Post by wintix »

bei mir selbiges problem. hat aber nichts mit dem cronjob zu tun.

wenn ich das shell-script per hand ausführe bekomme ich unterschiedliche werte. wenn ich jetz aber nur den befehl ausführe stimmen die werte überein.

Suse 8.1 kernel 2.4
hasso11
Posts: 6
Joined: 2004-03-22 13:57
 

Re: Vorgehensweise bei gecracktem Server (hoher Traffik usw.)

Post by hasso11 »

hab gui / gnome redhat 9.0shrike

hab die zeile im xterm eingegeben.... alles scheint wunderbar zu sein

74
74

viele grüße :=)
bonanza
Posts: 39
Joined: 2003-07-12 14:26
 

Re: Vorgehensweise bei gecracktem Server (hoher Traffik usw.)

Post by bonanza »

Muss mal den Thread vorholen, da ich auch das Problem habe das wenn ich das Skript starte ich 2 unterschiedliche Werte habe und wenn ich es per Hand starte stimmts mit einem Wert. Weis jemand weiter?
acheron
Posts: 23
Joined: 2004-10-08 17:57
 

Re: Vorgehensweise bei gecracktem Server (hoher Traffik usw.)

Post by acheron »

Wenn ich den Befehl öfter manuell eingeben kommen folgende Zahlen:
74/76, 74/75, 74/76, 76/77, 75/76, 75/77, 74/76, 74/75, 82/84, 81/82, 74/75


Was heißt das nun?
aule
Posts: 24
Joined: 2004-08-21 16:18
 

Re: Vorgehensweise bei gecracktem Server (hoher Traffik usw.)

Post by aule »

Ich habe einen Debian Sarge-Server und es kommt immer 1 oder 2 Unterschied raus.

Ich habe absolut keine Hacking-Versuche -Programme ... finden können

Aule
aule
Posts: 24
Joined: 2004-08-21 16:18
 

Re: Vorgehensweise bei gecracktem Server (hoher Traffik usw.)

Post by aule »

Ein Fehler ist mir zumindest einmal aufgefallen:
Bei dem Verzeichnis-Listing von /proc ist keine überschrift vorhanden, bei os ax aber schon:
PID TTY STAT TIME COMMAND

Wenn immer 1 Unterschied rauskommt, ist das zu erklären. Aber trotzdem bleibt diese Methode ungenau, denn das Verhalten mit geringem Unterschied tritt auch bei einem Rechner mit Debian Sarge auf, der noch nie am Netz war.


Aule
entro
Posts: 6
Joined: 2005-09-03 13:24
Location: Kiel
Contact:
 

Re: Vorgehensweise bei gecracktem Server (hoher Traffik usw.)

Post by entro »

Hallo Aule,
bei mir ist es ähnlich, ich habe immer 1-2 Prozesse weniger in /proc

Als erstes ist das wohl durch die Ã?berschrift von ps zu erklären, als zweites ist mir aufgefallen, dass die pid von "ps ax" gar nicht in /proc gelistet wird, was ja auch klar ist, denn der Prozess ist ja auch abgeschlossen, bzw. wird ja erst, je nach reihenfolges des Kommandos, nach dem auslesen von /proc ausgeführt.
braindead
Posts: 250
Joined: 2002-10-22 09:49
Location: vorm Rechner
 

Re: Vorgehensweise bei gecracktem Server (hoher Traffik usw.)

Post by braindead »

Ich hatte auch das Prob das beim ersten versuch mehr im PS waren als im proc (genau einer mehr). Naja, nach einem kurzen versuch wußte ich auch warum ;)

ls -d /proc/* | grep [0-9] | wc -l; ps ax | wc -l
103
104

ps ax
PID TTY STAT TIME COMMAND
1 ? S 0:34 init [2]


Jetzt ist die Headerzeile weg und jetzt stimmts auch:

ps ax | grep -v "^ PID"
1 ? S 0:34 init [2]

ls -d /proc/* | grep [0-9] | wc -l; ps ax | grep -v "^ PID" | wc -l
103
103
umbroboy
Posts: 258
Joined: 2005-05-11 11:49
 

Re: Vorgehensweise bei gecracktem Server (hoher Traffik usw.)

Post by umbroboy »

Hi Braindead,

habe es gerade mal mit deinem befehl probiert:

Code: Select all

ls -d /proc/* | grep [0-9] | wc -l; ps ax | grep -v "^ PID" | wc -l
Leider hab ich imer noch ein wenig grosse Unterschiede.
Letzte Woche ging aufeinmal mein mailserver nicht mehr. Es lag dann aber wohl an den rechten.

In den Logfiles konnt eich soweit auch nichts finden.

Jetzt mach ich mir allerdings schon sorgen, weil ich derzeit diese daten rausbekomme:

98
81

Habe gerade mal chkrootkit darüber laufen lassen und da hab ich entweder: nothing detected, not found, not infected, nothing deleted.


Wird wohl doch eine unruhige nacht :(
lord_pinhead
Posts: 774
Joined: 2004-04-26 15:57
 

Re: Vorgehensweise bei gecracktem Server (hoher Traffik usw.)

Post by lord_pinhead »

Schreib aktuelle PIDs in Textfiles und auch aus Proc, dann lass sie mit Diff mal abgleichen, damit solltest du schnell sehen was nicht passt.
umbroboy
Posts: 258
Joined: 2005-05-11 11:49
 

Re: Vorgehensweise bei gecracktem Server (hoher Traffik usw.)

Post by umbroboy »

Hallo,

also ich hab mir mal beide dateien angeschaut, verglichen noch nicht über Diff. Aber das mach ich nocht.

Was mir als erstes auffiel ist, dass diverese Prozeesse doppelt oder dreifach laufen. Dachte immer dass dies normal sei, z.b. wenn nur einmal der APache daemon läuft, dauert es länger, wenn andere anfragen aus dem netz kommen.

Habe mal beide Ausgaben gespeichert:

80.237.145.233/Ausgabe1.txt

80.237.145.233/Ausgabe2.txt

Wäre super wenn du dir mal das anschauen kannst.
lord_pinhead
Posts: 774
Joined: 2004-04-26 15:57
 

Re: Vorgehensweise bei gecracktem Server (hoher Traffik usw.)

Post by lord_pinhead »

Das liegt an deiner Serverconfiguration, steht ebenfalls im Forum ;)
umbroboy
Posts: 258
Joined: 2005-05-11 11:49
 

Re: Vorgehensweise bei gecracktem Server (hoher Traffik usw.)

Post by umbroboy »

Also ich hab gerade mal gesucht und bin dann fündig geworden zumindest für apache.

Da wäre dann dieser Eintrag verantwortlich:

Code: Select all

<IfModule prefork.c>
StartServers         5
MinSpareServers      5
MaxSpareServers     10
MaxClients          20
MaxRequestsPerChild  0
</IfModule>
oder?

Hab aber noch nicht feststellen können ob das für das ganze system gilt oder nur für apache2. tippe mal jetzt eher nur für apache2, oder?
Post Reply