[<prev] [next>] [day] [month] [year] [list]
Message-ID: <1150114231.54255913.5690.sendItem@bloglines.com>
Date: Mon Jun 12 13:10:39 2006
From: schanulleke.29172787 at bloglines.com (schanulleke.29172787@...glines.com)
Subject: scanning
Believe it or not, it was a Nokia running CheckPoint NG, but not well configured.
Because the network was taking a lot of traffic during normal ops so no
problems (yet). However it was taken down by a broadcast "storm" earlier.
I was running multiple SYN-scan sessions of nmap with agressive timing
(and very low max-rtt and max-timeout and max-delay setting), so not "polite"
at all.
IF I was doing a pen test AND I wasn't telling anyone I would NOT
be using this settings, but go "low and slow". The point that I was making
tough is that pen-tests and port scans can go wrong (and if you have Murphy
as your back-seat driver, they will go wrong).
We have also seen packet
loss when scanning some webservers over a 2 Mbps line. Also because the Nokia
was taking too much CPU cycles for inspections and logging.
Schanulleke
--- GroundZero Security" <fd@....org wrote:
What kind of firewall was
it ? I can't imagine that it isn't able
> to handle your single connect()
requests, since what happens
> if a lot of the internal client computers
have external requests?
>
> The network would be constantly lagged and
as you
> describe it, the firewall would stop responding even without
>
a scan. I just wonder what vendor the firewall produced.
>
> When you use
a normal port scanner like nmap with a polite
> timing and ip by ip, i doubt
this would happen. Maybe if you
> use some scanner that is multithreaded
and scan's a lot of ip's
> a second and do a full connect() (maybe even send
a request)
> on all possible ports on as much hosts as possible, then i could
> imagine your scenario. A "normal" port scan/subnet scan
> however, shouldn't
be any problem.
>
> When you do a penetration test you do have 5 minutes
to wait
> and we where talking about a simple port scan. I think at court
> it wouldn't matter as the understanding of the scan would be the
> same
for them. So even if there is a very slim chance that this
> actually happens
on a network, it would be hard to explain
> probably. Then again all you
did theoreticaly is looking for
> open services they offer to the public,
if their server is miss
> configured, is that your fault ? On the other
side, the network
> owner would probably respond that you shouldn't snoop
> around on his servers. So this is indeed a problematic situation
> and
i have to admit you make a point here, although i still don't
> think that
this will happen very offten :-)
>
> ----- Original Message -----
> From:
<schanulleke.29172787@...glines.com>
> To: <fd@....org>
> Sent: Monday,
June 12, 2006 12:13 PM
> Subject: Re: [Full-disclosure] scanning
>
>
> > I was on local site with a direct ethernet connection, the client had
all
> > internal traffic routed via a firewall, the firewall was configured
with too
> > many and too complex rules.
> >
> > I caused too many sessions,
causing too much
> > logs causing the firewall to stop responding in time
and all servers to be
> > separated from all clients.
> >
> > Needless
to say this was a major finding in
> > my report.
> >
> > We have observed
the same behaviour with external facing firewalls.
> >
> >
> > Schanulleke
> >
> > --- GroundZero Security" <fd@....org wrote:
> > When you say
> > that by running a portscan you "dossed" a whole network
> > > then i
would say
> > either you are crazy or your portscanner is seriously broken
lol
> > > I have
> > been doing pen-tests since 1998 and never ever dossed
a whole Network
> > > by
> > accident, especially not with a simple portscan.
> > >
> > > -sk
> >
>
Powered by blists - more mailing lists