lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [day] [month] [year] [list]
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ