냐컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴� +-+-+-+-+-+-+-+-+ 栢栢栢栢昉께께굇굇굅같�|O|u|t|b|r|e|a|k|臍같굇굇굉께께栢栢栢� +-+-+-+-+-+-+-+-+ Issue #4 - Page 5 of 12 냐컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴� ########################################### ##...network reconnaissance. -dropcode...## ########################################### "know thy enemy..." -sun tzu, the art of war. ----------------------------------------------------------------------- :: introduction :: network reconnaissance involves gathering information dealing with your targets network. though, often a gruling task, the information gleaned with the simple techniques i will explain throughout this article will allow an attacker to build a complete dossier against a target network. using simple recon techniques an attacker can systematically reduce a network from a mess of connected machines to a specific range of domains, network blocks and ip addresses. ----------------------------------------------------------------------- :: public database digging :: there are generally three areas of important info that can be gleaned from public databases related to the targets network, they are registrar, domain and network. registrar queries provide the attacker with specific whois / registrar servers directly associated with the targets network. this is important because these associated servers are where the next queries will be directed. in the following example, i will be performing a registrar query on psuedo networks inc. from a bash shell. of course, the crsnic.net server could be queried in other ways, the bash shell was only a preference. --- $ whois "psuedo."@whois.crsnic.net psuedostuff.com psuedosomethin.com psuedo.net psuedopsuedo.org --- placing the . wildcard at the end of my search string forced the server to return all occurances of psuedo in the crsnic.net database. we can now dig deeper to determine which domain is the one we want. i would guess that psuedo.net is our best chance. --- $ whois "psuedo.net"@whois.crsnic.net Domain Name: PSUEDO.NET Registrar: NETWORK SOLUTIONS, INC. Whois Server: whois.networksolutions.com Referral URL: www.networksolutions.com Name Server: DNS1.PSUEDO.NET Name Server: DNS2.PSUEDO.NET --- blamo. from that query we see that whois.networksolutions.com is the server we should direct our next queries at. the domain query will provide us with information relating to the registrant, the domain name, admin, when the record was last updated and the primary and secondary dns servers (also aquired from the first query) --- $ whois psuedo.net@whois.networksolutions.com [whios.networksolutions.com] Registrant: Psuedo Networks, Inc. (PSUEDO-DOM) 123 nowhere ave. Buttfsck, AZ 12345 Domain Name: PSUEDO.NET Administrative Contact, Technical Contact, Zone Contact: Rick, Slick [Network do0d] (SR924) slickrick@PSUEDO.NET 710-555-1234 (fax) 710-555-1235 Record last updated on 30-Mar-02. Record created on 30-Mar-02. Database last updated on 10-Mar-02. Domain servers in listed order: DNS1.PSUEDO.NET 10.10.10.1 DNS2.PSUEDO.NET 10.10.10.2 --- the word record refers to the information stored in the whois database. if the record was created years ago and hasn't been updated, its quite possible that the information in the record is out of date. but if the update is recent we've aquired a wealth of information on our mark. lastly, the network query. american registry of internet numbers [arin] maintains actual network blocks and ownership information in a gorga- massive database. we will use whois to query the arin database: --- $ whois "Psuedo Networks."@whois.arin.net [whois.arin.net] Psuedo Networks (NETBLK) 10.10.10.0 - 10.50.129.255 --- a tighter search can be made using a netblock as our search string. --- $ whois 10.10.10.0@whois.arin.net [whois.arin.net] Some Big Backbone (NETBLK NA-05BLK) 10.10.0.0 - 10.10.255.255 Psuedo Networks (NETBLK NA-10-10-10-) 10.10.10.0 - 10.50.129.255 --- basically, arin.net's database has given us a network block owned by psuedo networks, inc. thereby providing the attacker with a basic map of systems to target. ----------------------------------------------------------------------- :: ping sweeping :: ping sweeping is a very simple, but quite versatile technique used to determine which ip's in a given network block are actually live machines. the basic concept is to ping a range of ip's, compiling a list of the ones that respond. for instance, psuedo networks own a class c netblock ranging from 10.10.10.0 to 10.50.129.255. at first glance this seems likely to be a long gruling process, and often it is, especially if you're mapping a larger class a type netblock. however, there is a simple technique to quicken the process. there are a few programs out that, instead of pinging each system subsequently, send out all the pings at once and idle waiting for the replies. this speeds up the process significantly. generally, pinging a host sends an icmp echo packet (icmp type 0x08) and waits for an icmp echo_reply packet (icmp type 0x00). this method is sometimes erroneous due to the fact that acd's are often configured to filter icmp packets. it is possible to use a similar method to see if a system is alive called the tcp ping. this methed sends a tcp ack to the system and waits for an rst, showing that the system is infact alive. gping/fping/hping are very handy *nix programs capable of ping sweeping a network block. ----------------------------------------------------------------------- :: traceroute/tracert :: using traceroute it is possible to find firewalls, packet filtering devices and other access control devices [acd] on the target network. --- $ traceroute psuedo.net traceroute to psuedo.net (10.10.10.1), 30 hops max, 40 byte packets 1 box1 (207.124.10.1) 5.133 ms 5.101 ms 5.111 ms 2 rtr1.bigbackbone.net (10.10.22.10) 40.103 ms 40.210 ms 41.122 ms 3 rtr2.bigbackbone.net (10.10.22.11) 43.123 ms 43.163 ms 43.211 ms 4 acd.bigbackbone.net (10.10.11.11) 45.533 ms 45.364 ms 47.164 ms 5 box.psuedo.net (10.10.10.1) 47.733 ms 47.103 ms 47.603 ms --- generally, it is safe to assume that the last hop before an important machine on the targets network is some form of acd on their isp's network. this acd can be anything from a physical hardware firewall to a simple packet filtering device or router. in the above example, hop four is likely an acd. traceroute generally uses udp packets by default allowing the user to switch to icmp if they feel if necesary at the command line. (the reverse is true for tracert users) often acd's will filter icmp or udp packets and give you output such as: --- $ traceroute psuedo.net traceroute to psuedo.net (10.10.10.1), 30 hops max, 40 byte packets 1 box1 (207.124.10.1) 5.133 ms 5.101 ms 5.111 ms 2 rtr1.bigbackbone.net (10.10.22.10) 40.103 ms 40.210 ms 41.122 ms 3 rtr2.bigbackbone.net (10.10.22.11) 43.123 ms 43.163 ms 43.211 ms 4 acd.bigbackbone.net (10.10.11.11) 45.533 ms 45.364 ms 47.164 ms 5 * * * 6 * * * --- it is possible that switching the type of packets traceroute/tracert sends might bypass this form of acd filtering. also, it is possible to use the -p switch to specify a starting udp port in conjunction with the -S switch to stop port incrementation. generally, traceroute will start at the port specified with -p and increment +1. with -S switch you can specify a port and keep all packets sending there. for instance udp port 53 handles dns queries. since most acd's allow inbound dns queries, its very likely that if you point your traceroute to 53, it will bypass the acd's filtering and allow you to see beyond the acd. ----------------------------------------------------------------------- :: port scanning :: once you have a list of operational systems on your targets network you can begin looking for vulnerable services on each individual system. this can be accomplished by connecting to every tcp/udp port on the victims machine to determine which ports are set in listening state. if a port is listening, there's a good chance that there is a service daemon running on that machine handling connections to that port. and if there's a daemon running, there's a chance that it's vulnerable. for instance, http daemons, or webservers generally run on port 80. if port 80 is listening, its quite likely that the target machine is running a webserver. -tcp full connection scan: ------------------------- the most common type of port scan is the tcp full connection scan. this type of scan completes a threeway handshake, syn, syn/ack, ack. this method is easily detectable but, with this method it is possible to grab the daemons banner which often includes the name and version of the running service. -tcp syn scan: ------------- the tcp syn scan is a little more stealthy because a full connection is never made. the downside is that with a syn scan banners cannot be retrieved. however, an attacker can make an educated guess as to what service is running on the port because all services have a default. (httpd:80, ftpd:21, telnetd:23, smtpd:25, etc) -tcp ack scan: ------------- this method can help in determining what types of packets are filtered by an acd. the tcp ack bit is set before the packet is sent to see if the acd filters packets without this bit set. -tcp fin scan: ------------- fin packets are sent to the target system on every port subsequently. all closed ports should reply with rst's according to the standards of the tcp protocol. -tcp xmas scan: -------------- an advanced version of the fin scan, the xmas method sends fin, urg and push packets also forcing rst's from all closed ports. -tcp null scan: -------------- a tcp null scan sends packets to the target machine with no bits set. this forces all closed ports to respond with an rst. -udp scan: --------- the basic principal of a udp scan is that when no icmp port unreachable msg is recieved, the port must be listening. ----------------------------------------------------------------------- :: outro :: well, thats about it for network recon. any questions or comments can be emailed to me at uberego@hotmail.com ... respect to: gr3p, rambo, adeamis, smurf, fork, smiley, antimatt3r, gambiit, ocean, ech0. droptone: dood, it looks so much better on me :P, abused: xoxoxxx, heather: can't we all jus' get along? kleptic: don't give up on outbreak, dood people need you. :) honeypot: i lub j0o. ... anyone I'm forgetting, meh. :) EOF. -----------------------------------------------------------------------