---

Hej gruppe.

Vi har en webserver stående (Debian stable) med følgende software:

PHP 5.0 med visse udvidelser.
MySQL 5.0
postgresql
IPTables
Java
samt nogle andre småting.

Serveren er blevet lagt ned et par gange de sidste par dage, og det
eneste den fortæller er kernel panic.

Vi har nu skiftet alt hardware ud, og også skiftet til stable fra
testing, men lige lidt hjælper det.

Det er som om at svartiden på hjemmesiderne den hoster bliver længere og
længere for tilsidst at ophøre. Alt dette sker inden for få minutter.

Er der nogen der kender til noget software til Linx der kan teste hvad
det er der sker på serveren.

Det er ved at være lidt irriterende da den hoster rimelig vigtige
services og programmer.

Jeg har lidt på fornemmelsen at det måske er et serverprogram der er
skrevet i java som der kan være et hul.

Dette vil vi slå fra i morgen (men vi har ikke fysisk adgang til
maskinen, så vi er afhængige af andre der kan genstarte den).

Men igen er der noget software man kan installere eller nogle logfiler
som man kan gøre brug af til fejlfinding af dette?

Firewallen blokere alt pånær port 80, 25, 21 samt lidt flere til FTP og
database programmerne. Så der er ikke nogle unødvendige porte åbne.

Håber meget i kan hjælpe os lidt på vej, da vi er på bar bund.

God weekend.
--
Med venlig hilsen
Mathias Mejborn
--
--
Med venlig hilsen
Mathias Mejborn

---

On Fri, 21 Apr 2006 23:27:43 +0200, Mathias Mejborn wrote:

>
> Er der nogen der kender til noget software til Linx der kan teste hvad
> det er der sker på serveren.
Et forslag: Hvis i har mulighed for at sætte en hub foran serveren, kan i
tilslutte en ekstra maskine i samme hub. På denne maskine kan i så køre
enten tcpdump eller ethereal, da disse vil se samtlige tcp-pakker til og
fra serveren. Hvis i så sætter tcpdump eller ethereal til at skrive
kontinuerligt til en logfil, har i en mulighed for at se, hvad der sker,
fra i starter serveren til den dør. Dette selvfølgeligt under
forudsætning af at det er udefra kommende forbindelser, der ligger
serveren ned. Hvis det derimod skyldes en applikation på serveren,
der har et memory leak, burde dette fremgå af log-filen: /var/log/syslog,
/var/log/kern.log, /var/log/daemon.log

--
Hilsen/Regards
Michael Rasmussen
http://keyserver.veridis.com:11371/pks/lookup?op=get&search=0xE3E80917

---

Michael Rasmussen skrev:
> On Fri, 21 Apr 2006 23:27:43 +0200, Mathias Mejborn wrote:
>
>> Er der nogen der kender til noget software til Linx der kan teste hvad
>> det er der sker på serveren.
> Et forslag: Hvis i har mulighed for at sætte en hub foran serveren, kan i
> tilslutte en ekstra maskine i samme hub. På denne maskine kan i så køre
> enten tcpdump eller ethereal, da disse vil se samtlige tcp-pakker til og
> fra serveren. Hvis i så sætter tcpdump eller ethereal til at skrive
> kontinuerligt til en logfil, har i en mulighed for at se, hvad der sker,
> fra i starter serveren til den dør. Dette selvfølgeligt under
> forudsætning af at det er udefra kommende forbindelser, der ligger
> serveren ned. Hvis det derimod skyldes en applikation på serveren,
> der har et memory leak, burde dette fremgå af log-filen: /var/log/syslog,
> /var/log/kern.log, /var/log/daemon.log
>

Jeg regner ikke med vi har mulighed for at sætte en hub foran men jeg
vil da helt klart gøre brug af forslaget hvis det er muligt.

Er det muligt med IPTables på en eller anden måde at blokere en IP
adresse hvis der sendes for mange requests? Eller er det ikke en optimal
måde at håndtere det på?

--
Med venlig hilsen
Mathias Mejborn

---

On Sun, 23 Apr 2006 13:49:26 +0200, Mathias Mejborn wrote:

>
> Er det muligt med IPTables på en eller anden måde at blokere en IP
> adresse hvis der sendes for mange requests? Eller er det ikke en optimal
> måde at håndtere det på?
Det kan sagtens lade sig gøre. Man kan også indsætte et time-out for et
specifik adresse efter et vist antal forsøg. Jeg har ikke lige en
syntaks, jeg kan give dig, men det findes dokumenteret i iptables manual.

--
Hilsen/Regards
Michael Rasmussen
http://keyserver.veridis.com:11371/pks/lookup?op=get&search=0xE3E80917

---

Michael Rasmussen skrev:
> On Sun, 23 Apr 2006 13:49:26 +0200, Mathias Mejborn wrote:
>
>> Er det muligt med IPTables på en eller anden måde at blokere en IP
>> adresse hvis der sendes for mange requests? Eller er det ikke en optimal
>> måde at håndtere det på?
> Det kan sagtens lade sig gøre. Man kan også indsætte et time-out for et
> specifik adresse efter et vist antal forsøg. Jeg har ikke lige en
> syntaks, jeg kan give dig, men det findes dokumenteret i iptables manual.
>

Det eneste jeg lige har kunne finde er det her:

-A PREROUTING -p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG FIN,PSH,URG

-j DROP
-A PREROUTING -p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG NONE -j DROP
-A PREROUTING -p tcp -m tcp --tcp-flags SYN,RST SYN,RST -j DROP
-A PREROUTING -p tcp -m tcp --tcp-flags FIN,SYN FIN,SYN -j DROP
-A PREROUTING -p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG FIN,PSH,URG

-j DROP
-A PREROUTING -p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG NONE -j DROP
-A PREROUTING -p tcp -m tcp --tcp-flags SYN,RST SYN,RST -j DROP
-A PREROUTING -p tcp -m tcp --tcp-flags FIN,SYN FIN,SYN -j DROP
-A PREROUTING -p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG FIN,PSH,URG

-j DROP
-A PREROUTING -p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG NONE -j DROP
-A PREROUTING -p tcp -m tcp --tcp-flags SYN,RST SYN,RST -j DROP
-A PREROUTING -p tcp -m tcp --tcp-flags FIN,SYN FIN,SYN -j DROP
-A PREROUTING -p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG FIN,PSH,URG

-j DROP
-A PREROUTING -p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG NONE -j DROP
-A PREROUTING -p tcp -m tcp --tcp-flags SYN,RST SYN,RST -j DROP
-A PREROUTING -p tcp -m tcp --tcp-flags FIN,SYN FIN,SYN -j DROP

Er det nok til at løse problemet?

--
Med venlig hilsen
Mathias Mejborn

---

Den Fri, 21 Apr 2006 23:27:43 +0200 skrev Mathias Mejborn:
> Hej gruppe.
>
> Vi har en webserver stående (Debian stable) med følgende software:
>
> PHP 5.0 med visse udvidelser.
> MySQL 5.0
> postgresql
> IPTables
> Java
> samt nogle andre småting.
>
> Serveren er blevet lagt ned et par gange de sidste par dage, og det
> eneste den fortæller er kernel panic.

Det eneste?

Kernel panic er en kontrolleret fejl, når den kan skrive det, er den
også i stand til at skrive hvad årsagen (fra kernens synspukt) er
- hvad det er den går i panik over.

Der bør helt bestemt stå mere end kernel panic. Hvis ikke det står
på konsollen, er det muligvis sendt et andet sted hen. Så må I sørge
for at den bliver sat op til at skrive det på konsollen.

Uden yderligere oplysninger, har jeg ikke andre gæt end out of
memory, med fejl-konfigureret OOM-killer.

Mvh
Kent
--
Hard work may pay off in the long run, but laziness pays off right now.