Q - With all of the other tools out there, why are you wasting time
building another one?

A - While working on projects we ran across a number of networks that
were difficult to accurately and timely collect information from.  We
were using many different tools, but none of them could scale, nor were
accurate enough for our needs. One need in particular was better UDP
scanning.

Basically, when you're doing UDP scanning, you're counting on the target
machine to either send back an ICMP T3C3 (port unreachable) or an ICMP
T3C13 (administratively prohibited) response to let you know it's either
"closed" or "filtered".  This works most of the time if the box is
sitting right next to you on a LAN and isn't firewalled, but when
scanning a large network of firewalled machines this method is
completely useless.

For example, if you send a UDP probe and get nothing back, most tools
call it "open" (now open|filtered in nmap 3.7+), though it often really
means that there was nothing there. To get around that issue while
testing firewalled networks for UDP we had to resort to grabbing
individual programs such as net-snmp, dig, etc. This manual testing sort
of works, but becomes really tiresome very quickly. Managing the output
of 10+ manual tools is a chore as well. So in June 2004, we set out to
build a new scanner that focused on UDP and called it ... udpscan :).

Udpscan had about 20 payloads to actually talk the protocol that you
were scanning for.  Obviously there is not a generic/universal packet to
send to get a response from a UDP service.  In some cases you even have
to come from the right source port and send the right payload in order
to get a response.  To know if a UDP service is really up SPEAK the
language of the service the same way a real client would. You can't rely
on ICMP messages to do UDP scanning. It turns out people out there
actually do use firewalls :P

We did some other things with udpscan to tackle the reporting issues and
were influenced by some of Dan Kaminsky's ideas that he used with
scanrand.

For those unfamiliar, scanrand is a SYN scanner (in addition to other
things) that allows for really fast SYN scanning. What was novel about
Dan's approach is he split up the sending and the receiving functions of
the scanner. One of the things that really slows down traditional port
scanners is that they keep track of state, meaning they will send out
packets and account for them on a port by port basis. What this leads to
is port scans that can take well over 30 minutes per IP per protocol to
scan when a filter is in place. With scanrand you simply sent a
bazillion packets with the 1st instance of the program and listened for
response data with the second instance of the program. Eg. a
"stateless" port scanner.

Some of the other things Dan did right was allowing you to more clearly
see the data coming back from the receiver. Things such as the hop
count, the timing of the received packet vs the when you sent the
packet, what type of response, where the response came from, etc. 
Obviously this additional information is really useful when analyzing
the results you got back.  The best part was that you could easily place
this data into an SQL table for more complex analysis.  Once we saw this
we would never again be satisfied with text, xml, or spreadsheet output. 
Anyhow see http://www.doxpara.com for more on scanrand, which is part of
the Paketto Keiretsu project.

After we had our base and went out looking for handshakes, we found
another UDP scanner at: http://www.geocities.com/fryxar/.  This was a
good find as it confirmed that other folks were running into the same
problems with UDP that we were.

After a week or so of playing with udpscan, we realized our framework
was pretty flexible and powerful. In order to do more than just UDP, we
took all knowledge of TCP/IP out of the core and made it a generic "take
target data from here, send it to the doers, and report it back to the
receivers".  So then we had separate pieces to handle scanning TCP, UDP,
ICMP, and IP, etc.

Scalability was another area we wanted to improve. From a typical
Pentium box we can generate between 10,000 and 30,000 packets per
second.  This allows for port scanning 1 port on a /16 (class B) network
in 3-7 seconds, assuming you've done proper logistics and controls
first. We also made an IPC channel for the senders and receivers to
communicate on.  This allows us to use multiple machines as either
senders or receivers in conjunction with one another and share the
collective information to analyze from the relational database back-end. 
What is special about this is that as the receivers receive a SYN/ACK
they can send the information from the SYN/ACK to the senders over the
IPC channel to allow the sender to complete the 3-way handshake. This
allows for things like massively parallel banner grabbing, which is 
included with the 1st public release of unicornscan.  This is also the
basis for lots of custom payloads in the near future.

Now that we were doing more than just UDP scanning, udpscan needed a new
name.

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

Q - So what's with the name?

A - I know, unicornscan is a really silly sounding name. It was
originally a joke. But now you have the power to "find the lost
unicorn" somewhere on the net. :)

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

Q - So what happens if I'm running other tests while running our scan? 
I'm getting all sorts of strange responses.

A - Yeah.  We would expect that :). It's a really bad idea to have
multiple scans at the same time from the same hardware.  Believe it or
not, even multiple nmaps at the same time is a bad idea.  You want to be
in a scientifically clean environment as much as possible.  You need
proper controls in place so that when you introduce a stimulus, and get
a response, you can actually track down why you got that response.  With
other things going on at the same time, you loose out on a lot of your
ability to figure out why things are happening.

Another thing to consider is that as you add more processes that try to
listen to packets off of the wire, you start dropping packets.  This
will make ALL of your scans invalid as you won't know which packets you
were dropping.  We recommend not even using tcpdump or iptraf at the
same time on the same machine as a unicornscan while performing real
tests.  That's OK for learning what the scanner is doing, but it's not
ideal when you want to ensure as little packet loss as possible.

If you want to troubleshoot what response data you're getting back, use
the -w option to write the response data to a pcap file.  You can look
through this pcap file later with tcpdump or ethereal.

You can also play with verbosity levels (-vvvvvv, etc).

To avoid confusing your kernel, be sure to use the fantaip command as
explained in the walk through.

If you're still seeing more than you want to see, you can employ the -P
option to weed out anything.

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

Q - I'm trying to perform testing from an internal network that has an
in-line proxy server that intercepts all TCP port 80 destined traffic. 
Because of this, port 80 is ALWAYS being returned as open.  What can
this tool do for me?

A - Three answers to this ... 

1) - If every open port on a device has a TTL of 59 except the port 25
which has a TTL of 255, then you should quickly see that a device is in
the middle mucking things up for your port 25 scan.  This will also be
way more obvious when we introduce the banner grabbing module if a large
percentage of responses come back with either no banner, or the exact
same banner.  Since we're expecting you to use this tool with a database
back-end, you'll be able to say things like "If they all match this
banner and this ttl and this port then ignore those packets" to weed out
the junk.

2) - On top of that we're doing a fingerprinting module to examine
packets coming back.  By analyzing the response packets we'll be able to
say things like "If you see this fingerprint, ignore the packet".  This
research was started to make it possible to scan a tarpit'd network. Ex.
those silly boxes that say they're open on all ports.  This may end up
also helping with your port 25 problem.

3) - Scanning from behind a device like that is non-ideal for testing. 
Having boxes manipulate your packets does not help you with an accurate
scan :).  I'm not sure if that will ever change. 

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

Q - I thought this was supposed to be really fast?  It seems just the
same speed as [super scan|a Java based port scanner]... what gives?

A - There are a few things to look at here.

1) The -r option will specify how fast to send the packets.  If you
don't specify any, the default is a conservative 200 packets per second. 
If you want to stress your hardware, try -r10000.  Also, read the walk
through again.

2) There is a set time to wait after sending all of the packets to see
if there are any late response packets coming back to us.  The default
is 7 seconds.  You can change this in the configuration file.

To see how long it took just to send the packets, use -v at the end of
your command.

3) Also bear in mind that we're all about scale and accuracy, not speed. 
To understand the difference, think of how Solaris scales.  When it's
just you and the box, it seems just a little bit on the slow side.  When
it's you, and a lot of other processes on the box consuming a ton of
resources, it still seems just a little bit on the slow side.  This
consistency in low load and high load represents how well it can scale. 
Unicornscan was built with scale in mind.  Lots of bees can gather lots
of pollen. Think of individual scanner speed as a bonus.


To that end, scanning a /32 isn't the best way to show off Unicornscan's
real power.  To really see that you'll want to rip through at least a
/24.  If you're feeling wild, you might try your hand at a TCP port 80
scan across a public /16 network.

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

Q - I'm scanning an internal network, and it's going really slow.  I
looked at the wire and saw a lot of ARP traffic, which appears to be
slowing it down.  This sucks!

A - Have you tried the -mA mode?

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

Q - I am trying to get the banner grabbing mode working.  I specified
-msf on the command line and it appears to be doing something with the
3-way handshakes, but I'm not seeing any of the banner information.  Why
not?

A - You likely need to set up fantaip to listen on an IP address that
your kernel doesn't respond for.  It is likely that your kernel is
sending RST packets to close the 3-way handshake before the banner could
be grabbed.

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

Q - I really need [Feature XYZ]!  When will unicornscan have [Feature
XYZ]?

A - We're currently building the tool to meet the needs we've
identified.  We'd be more than happy to implement additional features. 
Please drop us an email at "unicornscan at dyadsecurity.com" and we'll
add it to the TODO list.  If you make a good case for the feature we 
may even move it to the top of the priority list! :).

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

Q - I Downloaded a precompiled package of the 0.4.2 version of
Unicornscan.  How do I get the database features and PHP/Web front end
working?

A - Unfortunately, the 0.4.2 release requires you to know your database
needs at compile time and hard coding them into the
unicornscan-0.4.2/src/output_modules/database/logininfo.h file.  You
will also need to uncomment the OPT_MODS=db_module from the
unicornscan-0.4.2/src/Makefile.inc file.

After recompiling with those changes, you can use the "-e database"
option with Unicornscan.  Once that is working properly, proceed with
installing Alicorn.

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=