From: robert@dyadsecurity.com
Date: Mon Jan 09 2006 - 13:30:55 EST
offset(offset@core.svcroot.net)@Mon, Jan 09, 2006 at 07:47:53AM +0200:
> Do you find that bandwidth is the limiting factor to negate
> differences between scanners? Assuming source is typical broadband
> (dsl, cable) around 1Mbps upload speed.
If by source, you're refering to the network you are testing from, you
have to be very careful with most DSL/Cable connections. They tend to
queue your outbound packets and will start dropping packets if you go
too fast. Too fast varries from system to system. Here in SoCal, I can
typically safely scan at around 200-300 packets per second from a crappy
cable modem. From a network with "clean" bandwidth, we've scanned at
well over 100,000 packets per second. Last week while in sweden I was
shocked to see that my friends network could only accurately send a max
of around 35 packets per second, even though they had a ton of
"available" bandwidth for uploading files.
As far as nmap vs unicorn.... nmap currently does a far superior job of
the preliminary "logistics and controls" testing. Ie, it does probe the
remote side for timing information prior to scanning. I would say for
the novice nmap will get you the results you want. Unicornscan currently
expects the tester to do this manually. However, once you have a better
understanding of what your source and destination networks can handle,
unicornscan will deliver very consistant and accurate results. In head
to head speed tests, unicornscan has an unfair advantage over nmap, in
that they use completely different methods for the scanning. If you
have any more questions about that, feel free to ask.
> Looking to find most efficient methods of the following, assume
> stealth is not the goal, but accuracy is 1. host up detection
> (detecting ports (ie, 80, 443)), mark for followup later (queue for
> full scan)
>From remote this might be what you want. On local, it may be easier to
just arp scan. When we enumerate live systems, we like to spend time
with dns also. Try zone transfer. If that doesn't work, try using a
dictionary file for finding host names. You can also try to brute force
host names, and IP reverse lookup for host names. You can find goofy
systems like "ids.somecompany.com" that wouldn't otherwise be easily
viewable (assuming it's passively listening only).
Before you even start scanning for common TCP ports, you should find out
what types of protocols the remote network accepts and responds with.
Simply kicking of a port scanner will tend to leave you with
inconsistant results.
It's also worth mentioning that todays networks are growing in
complexity. You're going to have networking devices that may respond on
behalf of the systems behind them. You may have ports on a single IP
that redirect to completely different systems. You may have an
application layer gateway that only redirects certain types of
application specific querries to the true destination host. If you're
thinking of hosts as a 1:1 relationship with an IP, you may want to
rethink how you account for hosts.
Unicornscan treats every response packet as potentially being a
different host. Ie, all of the stack characteristcs can be examined for
every response received. That way you can see when different ports on
the same ip have different characteristics, or see when the
characteristics of a remote system change during a handshake, or post
handshake one the correct application specific querry was sent.
The ISECOM OPST class drills into this stuff a fair amount if you want
to see this applied in a hands on environment.
> 2. full port SYN scan on detected hosts (TCP only)
It may be more efficient to perform a full tcp connection, grab banners,
send payload triggers etc, all in one step. IE .. make it so every time
it receives a SYN/ACK a remote system on TCP port 80, have it send
complete the handshake, and then send a
"HEAD / HTTP/1.1\r\nHost: $IP\r\nUser-Agent: froghead\r\n"
to enumerate web services. You should
also scan UDP using a similar trigger/response methodology... ie send a
snmp v1 and v2c public/private probe to the remote system. See
http://seclists.org/lists/pen-test/2004/Aug/0040.html for why that may
work better in a firewalled environment.
Once you enumerate live hosts, active services, versions of services,
etc... if you have that information stored, you could querry CVE to find
the publicly disclosed problems associated with those platforms and
services. You could even write scripts that pull that information down
for you based on the information you got back during step 2.
Btw, you shouldn't have to do a port 25,80,110, etc type of common port
sweep first. After performing logistics and controls exercises to
determine safe pps levels and what protocols are allowed, you could jump
to the full port connections+trigger/response testing. It is not
complete to do it the other way. You will miss systems/services.
> 3. vulnerability analysis based on host/port information
Neither project (to my knowledge) is currently shipping with
vulnerability tests. Unicornscan does support the concept of payload
triggers. You could put together basic trigger response patterns, have
the information stored to a database, and then later sort through the
database to find the information you want. This may be and ideal way to
get a specific payload from say canvas or metasploit and use unicornscan
as the delivery agent for the payload in order to scale to every system
in your testing network.
Robert
-- Robert E. Lee CIO, Dyad Security, Inc. W - http://www.dyadsecurity.com E - robert@dyadsecurity.com M - (949) 394-2033 ------------------------------------------------------------------------------ Audit your website security with Acunetix Web Vulnerability Scanner: Hackers are concentrating their efforts on attacking applications on your website. Up to 75% of cyber attacks are launched on shopping carts, forms, login pages, dynamic content etc. Firewalls, SSL and locked-down servers are futile against web application hacking. Check your website for vulnerabilities to SQL injection, Cross site scripting and other web attacks before hackers do! Download Trial at: http://www.securityfocus.com/sponsor/pen-test_050831 -------------------------------------------------------------------------------
This archive was generated by hypermail 2.1.7 : Sat Apr 12 2008 - 10:55:20 EDT