fast scan - Page 2

Do you have a question? Post it now! No Registration Necessary.  Now with pictures!

Threaded View

Re: fast scan

Quoted text here. Click to load it

I have play with POE but not in depth, because I tired from its big  
documentation and its many modules.
I think I will try once more but I will monitor carefully the system to  
check if what it claims is true.
I mean the threads module in documentation is perfect but in real life  
.... forget it, at least for real intensive tasks.

Re: fast scan

# dizzying fast with port scanner, cpu is almost 0%
# this is forking the forks !

use strict;
use warnings;
use feature qw/say/;
use Net::Ping;

my $threads  = 80;
my $duration = 1;
my @ip_team  = ();
my $db_dir   = Unique_node_name('/tmp/.fastscan');

mkdir $db_dir or die "Could not create directory \"$db_dir\" because  
\"$^E\"\n" unless -d $db_dir;
$|= 1;

my @ports = (21, 22, 80, 135, 443);
my ($o1a,$o1b,  $o2a,$o2b,  $o3a,$o3b,  $o4a,$o4b) =  
Check_and_define_octet( '192.168.0.[1-254]' );

foreach my $o1 ($o1a .. $o1b) {
foreach my $o2 ($o2a .. $o2b) {
foreach my $o3 ($o3a .. $o3b) {
foreach my $o4 ($o4a .. $o4b) {

push @ip_team, "$o1.$o2.$o3.$o4";

if ( $threads == @ip_team ) { Scan(@ip_team); @ip_team = () }


system("/bin/rm -rf $db_dir");

sub Scan
my @Pids;

    foreach my $ip (@_)
    my $pid    = fork(); die "Could not fork because $!\n" unless defined $pid;
        if  (0 == $pid)
        $ping= Net::Ping->new('icmp');
            if ( $ping->ping($ip, $duration) )
            mkdir "$db_dir/$ip";
            my @SubPids;
                foreach my $port (@ports)
                my $pid = fork(); die "Could not fork because $!\n" unless defined $pid;
                    if  (0 == $pid)
                    $subping = Net::Ping->new('tcp', 2);
                    mkdir "$db_dir/$ip/$port" if $subping->ping($ip);
                    exit 0
                    push @SubPids, $pid
            foreach my $pid (@SubPids) { waitpid($pid, 0) }
            say "$ip is up";
            chdir "$db_dir/$ip";
            foreach ( glob '*' ) { say "\t port $_ is open" }            

        exit 0
        push @Pids, $pid

foreach my $pid (@Pids) { waitpid($pid, 0) }

sub Unique_node_name
my ($dir,$file )= $_[0] =~/^(.*?)([^\/]*)$/;
if ( $dir=~/^\s*$/ ) { $dir = '.' } else { $dir    =~s/\/*$// }
$file = 'node' if $file=~/^\s*$/;
return "$dir/$file" if ! -e "$dir/$file";
my $i=1; while ( -e "$dir/$i.$file" )

#   Accepts a host definition like  192.168.[0-3].[1-254]
#   and returns for every octet its first and stop number
#   For example for the [10-12].1.86.[1-100]
#   it will return
#   10,12,  1,1,  86,86,  1,100
sub Check_and_define_octet
my @O;
( my $hosts = $_[0] )=~s/\s+//g;
( $O[0]->[0] , $O[1]->[0], $O[2]->[0], $O[3]->[0]  ) = $hosts  
=~/^([^.]+)\.([^.]+)\.([^.]+)\.([^.]+)$/ or die "The host definition  
argument is not like  192.168.[0-3].[1-254]\n";
my $i=0;
    foreach my $start (1,0,0,1)
        if ( $O[$i]->[0] =~/^\d+$/ )
        @[0,1] = (( $O[$i]->[0] >= $start ) && ( $O[$i]->[0] < 255 ))  
? @[0,0] : die "Octet \"$O[$i]->[0]\" should be an integer from  
$start to 254\n"
        elsif    ( $O[$i]->[0] =~/\[(\d+)-(\d+)\]/ )
        $O[$i]->[0]    = (( $1 >= $start ) && ( $1 < 255 )) ? $1 : $start;
        $O[$i]->[1]    = (( $2 >= $start ) && ( $2 < 255 )) ? $2 : 254;        
        @[0,1]    = $O[$i]->[0] > $O[$i]->[1] ? @[1,0] :  
        die "Sorry but octet \"$O[$i]->[0]\" should be something like 12 or  
[10 - 254]\n"

#use Data::Dumper; print Dumper \@O; exit;
@, @, @, @

Re: fast scan

Quoted text here. Click to load it

[more of this]

Something which also deserves to be mentioned here: The sole reason
for this insane fork-orgy is that George has to work around the
library he chose to use for 'network communication' which offers only
a synchronous 'send request and wait for reply' interface. Which is
actually not atypical for 'technical solutions' starting with 'Welches
Gurkenglass, das hier dumm herumsteht, koennte sich wohl dafuer
eignen, diesen Nagel in die Wand zu schlagen?': It starts with some
clueless, devil-may-care individual selecting the wrong tool for the
job at hand because he reaches for the closest one and then proceeds
as set of 'ingenious' workarounds for the deficiencies of that.

Re: fast scan

Στις 5/8/2013 10:45, ο/η Rainer Weikusat έγραψε:
Quoted text here. Click to load it

Playing around for fan I’ve done the same think using the modules


The code was much smaller but to my surprise cpu usage jumped from  
almost 0 to 60% and script all together consume about 1.5Gb ram, wow !

I think this is because the threads module create real threads probably  
duplicating each memory. Fork somehow creates something more light …

Re: fast scan

Quoted text here. Click to load it


Quoted text here. Click to load it

The perl (bytecode) interpreter doesn't support
multithreading. Because of this, Perl threading support works such
that each thread gets its own copy of the interpreter created by
making a memory-to-memory copy of an already existing one. This
implies that creating threads is slow and multi-threaded Perl programs
need a lot of memory because despite running in a shared address space
they can't really share any of it.

In contrast to this, fork nowadays usually works by copying the page
table of the forking process and changing the memory access
permissions to read-only: Initially, both parent and child process
will share all memory. As soon as either of both tries to write to
something, a page fault occurs and the kernel handles that by
allocating a new page of memory, copying the page where the fault
occurred and then giving one to the child and the other to the parent
with access permissions changed back to read-write. This means copying
happens only when needed and only what really has to be copied is.

But for 'network scanning' this is an aside. The sensible way to do
that is to make it work asynchronously, ie, instead of waiting for a
reply after each request, keep sending whatever requests remain to be
sent (again, rate-limited) and process replies as they arrive.

Re: fast scan

Στις 5/8/2013 17:24, ο/η Rainer Weikusat έγραψε:
Quoted text here. Click to load it

Very sensible explanation.

For curiosity I fire up some similar scans using nmap.
It is very fast while it respects cpu and network utilization.
I have to look at its code to grab a general idea of how it works.

Site Timeline