Sunday, March 31, 2013

httperf performance script

Here's a script that relies on httperf and runs in a loop for generation of HTTP traffic. It relies on Httperf

It provides time measurement for completion of the request and overall is an excellent tool for  http webserver benchmarking

---------------------------------------------------    SOM       ----------------------------------------

proteus:downloads kfelix$ cat httperf_requester.sh


#!/bin/bash
#
#

#rev 1.0

#  HTTP requester for traffic generation via httperf
#  full http.request == GET|PUT|POST|HEAD|TRACE etc......

#  Be careful not to flood any downwind DoS monitors, and be kind to your client sever(s)!
#
#
if [ ! $1 ]; then
            echo " Usage : httperf_requester.sh <delay in seconds between requests>  < The total #s of requests to send > <server ip_addrss in x.x.x.x>   <url>   <http.request METHOD 'GET|HEAD|PUT|POST|TRACE' > "
            echo ""
            echo "Example  httperf_requester.sh 5 10  192.0.2.1 http://www.5example.com GET"

            echo ""

            echo "  or   "

            echo "Example  httperf_requester.sh 5 10  192.0.2.1 http://www.5example.com HEAD"
            echo ""

            exit 1
fi

#
i="0"

#
MAX=1000

COUNTER=$2

H=httperf

if  (( $2 >= $MAX )) ; then

        echo "   "
        echo "Please make a request range of <1000 or less"
        echo "   "
else


while [ $i -lt $COUNTER ] ;

  do  $H --server $3 --num-conn 1 --uri $4 --timeout 60 --max-connections 1 --method $5 | grep "Total:"

  sleep $1

  echo "The request connection times are given above"
  echo ""

  i=$[$i + 1]

#   let "COUNTER += 1"

done
fi

---------------------------------------------------    EOM       ----------------------------------------

Ken Felix
Freelance Network/Security Engineer
kfelix  a-t hyperfeed d-o-t com

webcrawler & robots.txt how they work and do we use them for

In this post we will look at the purpose of webcrawlers ( aka  web search bots, spider, ant, robots ) and the purpose of a robots.txt

These ( bots )  are distributed bots,  that crawls web sites and searchs urls as listed on a website. The main purpose of the bot, is to  help index the sites and urls. Bot are used by every search engines, and for indexing URLs that it visits,  in hope of categorizing  content for search engines.

You can check this website for up-to-date known webcrawlers;

http://www.robotstxt.org/db.html

Now web crawlers are suppose to honor the robots.txt file  if present. This is a on a trusted honor relationship. Take for example http://www.hp.com main site;

 curl www.hp.com/robots.txt
#$Header: robots.txt,v 1.19 2009/10/19 16:47:17 autreja Exp $ $Locker:  $

# robots.txt file for www.hp.com
# send e-mail to hp<dot>comOperations<at>hp<dot>com for updates or problems

User-agent:    *
Disallow:    /cgi-bin/
Disallow:    /info/
Disallow:    /support/
Disallow:    /JumpData/
Disallow:    /cposupport/
Disallow:       /whpadmin/
Disallow:       /offweb/
Disallow:       /hho/res/us/en/
Sitemap:     http://www.hp.com/google-sitemap-index.xml

 

They provide instruction to web crawlers that provide information on what's allowed or denied.

The "User-agent: *"  , allows all crawlers. If you wanted to be specific, you could included instruction for that known crawler via his User-Agent: id.


The Above "Disallow:" are providing instruction or what we do not want the bot to crawls. These are like signs that says;  don't enter, no parking, or no trespass. They have no enforcement.  The opposite of a "Disallow:" is a "Allow:". You can used these along with the disallow to provide instruction on specific content.

e.g

Disallow:  /home/
Allow: /home/kentheethicalhacker/


The "Sitemap:" is just that a sitemap that helps the crawler find content that might otherwise not been found or seen. You can read about sitemap here ; http://www.sitemaps.org/

Here's one of my free mail hosting provider robots.txt;
(output shorten )

petra:~ root# curl www.mail.com/robots.txt | more
 
Sitemap: http://www.mail.com/sitemapindex.xml

User-agent: *
Disallow: /*?ls=*
Disallow: /*?localePreference=*
Disallow: /*;jsessionid=*
Disallow: /*;kid=*
Disallow: */company/
Disallow: /Site/

User-agent: grub-client
Disallow: /

User-agent: grub
Disallow: /

User-agent: looksmart
Disallow: /

User-agent: WebZip
Disallow: /


So don't use a robots.txt file for controlling access. If you have content that needs to be secured or hidden, use the proper  http.access controls and encryption. The web crawlers may, or may not follow your instructions.

Okay so now that we have a basic understanding of web crawlers, what do they search on and what do they with the data?

1st using google, the bot crawls over links, these links  and words within the URLs are next collected for latter indexing. Certain words known as stop words are not  index ( e.g is , the , and , etc,.....)

Next, a indexer takes the collect information and index the search database.

you can get an ideal of what the search engine knows about your site via

"site: yourdomainname.com"

e.g


It's goal is to help a end user who executes a search, to find content about that site when he/she searches using the google search site.

Other ethical purposes, are to help you as a pen-tester find information and potential targets for a customer that you have an engagement with. As within any war campaign,  Reconnaissance is the 1st step with gaining information about the enemy. The same applies here with regards to a domain.

Okay now, you should have the basic on robots.txt and the purpose of that file,  and who uses them.

here's a few bot entries  you might see in your webaccess.log


66.249.73.142 - - [19/Mar/2013:12:11:30 +0000]  192.0.2.1 www.mydomain.com "Apache" "GET /robots.txt HTTP/1.1" 80 301 242 0 "-" "Mozilla/5.0 (compatible;
Googlebot/2.1; +http://www.google.com/bot.html)" 27701

184.75.210.186 - - [12/Mar/2013:01:34:12 +0000] 192.0.2.1
 www.mydomain.com "Apache" "GET / HTTP/1.0" 80 200 37113 0 "-" "Pingdom.com_bot_version_1.4_(http://www.pingdom.com/)" 56763



 Happy bot monitoring :)


Ken Felix
Freelance Network Security Engineer
kfelix  @  hyperfeed  d.o.t com






Tuesday, March 26, 2013

Review:Pwnie Express Plug

This post pertains to the pwnie express mini plug available from here;

http://pwnieexpress.com/products/

Since my purchase, that plug does not seem to be present on the website, but the  wireless plug is similar. This website gives you some details on the plug and with regards to mini-plugs formats.

http://www.minipwner.com/index.php/minipwner-compare-pwnie-express

To start;  the guys at PwnieExpress, have done their homework and offers a very good  functional plug. It's design around;  "ease and quick deployment". The plug only draw back; are the limited storage capacity and cost.

The plug has a superior usermanual  ( available online ) that's ship with the plug, & that goes over almost all the setup functions. It gives you example of what you need to do to operate this plug.

When you boot the plug, you will be welcome with the following,  after your ssh login


The plugs run with no manpages or other misc materials, due to the limited internal storage restrictions. So if you are weak on your linux skills, you better have access externally to Man Pages or other HOWTOs.



 

The plug supports both wireless and  bluetooth , along with the internal ethernet port. I found the wireless ethernet adapter some what protruding, but otherwise simple to operated. I would suggest using a extended usb cable,  to some how hide the antennae from visual view.

I used a few wireless cracking utilities and it ran brilliant.




The systems runs the following listeners ;


note:  Port 8443 is used primarily for the Plug webUI. 

Once you have the gui accessible, the plug interface is quick and straight forward for setup and configuration. It features quick  tabs, which covers  most of the plug functions, minus the pen-test tools.



I found  these function to be;

  • simple 
  • quick to configured
  • and ease for the novice to well experience pen-tester to follow

The plugWebUI also cover almost everything from something as simple as resetting the PlugUI password. They even warn you in the document and webGui that this password is not the same as  the shell








The plug ethernet is configured for DHCP , but allows you to re-configure it for static-ip,  and you can change almost everything that you might encounter.


For alerting you have a host of options;


note: They thought almost everything :)

The plug also has the function to conduct passive recon. This would be great for a tap or hub port, where all traffic is present and no active engagement from the plug. Passive recon would be more effective with a hub , monitor or tap port.



my plug has the ability to setup covert back channels;








So for back channels, the plug has all angles covered. And provides quick status as to what you have running.

note: I would suspect you would want to write a basic bash script, that could provide you all of these status details and could be ran under the user profile to execute at the login.



PwnieExpress also provide some what  of a simple on-the-plug help, just in case you get lost or confused.



For network connectivity wired/wireless the device function quite well and even has support for ipv6 natively. Which I'm investigating personally on how to engage my plug within a ipv6 topology and to build covert channels over a ipv6  connectivity. More to come  on that as I get going.






The biggest complaint from me , pertains to storage size. This plug is small form factor and this is to be expected, but it would be nice to have more than  250-500+ megs of storage access imho




conclusion

The plug overall is not bad and well thought out. Where they are lacking at in storage, they made up for with overall access and configuration.  You can get a list of the available pre-cannned pen-test tools included on the plug via the website.

http://downloads.pwnieexpress.com/pdfs/PwnplugManual_1.1.pdf


Pros:

  •  very well design
  •  design for ease of deployment
  •  effective management of covert  back channels
  •  
Cons:
  •   lack of onboard manuals pages
  •   the cost
  •   external 802.11/celluar wireless adapter could be suspicious
  •   storage capacity size



Ken Felix
Freelance Network/Security Engineer
kfelix at hyperfeed dot com

Hello or good-bye ! ( email refresher )

This post talks about the basic antispam protection that takes place way before anything else. A proper and legit mailer will have a valid FQDN that resolves.

Here's what' considered  general best mail practices;

  • upon connection, the domain give in the sender HELO/EHLO is not fully qualified domain = REJECT
  • if no HELO/EHLO is sent = REJECT
  • if the domain name given does not resolve = REJECT

Here's a snippet of bad senders from my mail gateway ;

2013-03-26,00:25:13,log_id=0300002085,type=spam,pri=information,session_id="r2Q5PDQq002084-r2Q5PDQr002084",client_name="1-163-25-112.dynamic.hinet.net [1.163.25.112]",dst_ip="10.150.252.150",from="f5470b3@noetzelnet.de",to="",subject="",msg="Invalid ehlo/helo domain. ( user )"
2013-03-26,00:24:55,log_id=0300002083,type=spam,pri=information,session_id="r2Q5Oscn002082-r2Q5Osco002082",client_name="121.247.65.175.static.pune.vsnl.net.in [121.247.65.175] (may be forged)",dst_ip="10.150.252.150",from="f2ab12cdf@sheldonpg.com",to="",subject="",msg="Invalid ehlo/helo domain. ( 121.247.65.175.static.pune.vsnl.net.in )"
2013-03-26,00:22:23,log_id=0300002079,type=spam,pri=information,session_id="r2Q5MM9l002078-r2Q5MM9m002078",client_name="178.91.242.79.megaline.telecom.kz [178.91.242.79] (may be forged)",dst_ip="10.150.252.150",from="ramroddedawd92@afes.com",to="",subject="",msg="Invalid ehlo/helo domain. ( 178.91.242.79.megaline.telecom.kz )"
2013-03-26,00:20:32,log_id=0300002075,type=spam,pri=information,session_id="r2Q5KWx6002074-r2Q5KWx7002074",client_name="windsorcars.plus.com [80.229.179.201]",dst_ip="10.150.252.150",from="4265598@maps.by",to="",subject="",msg="Invalid ehlo/helo domain. ( dsldevice.lan )"

Yes all of the above are bad senders, and either the domain or ip_address don't match, nor  resolve. To give you an ideal, my email filtering device picks up way over 99% of spam email attempts from just this process alone.

This is just one way to provide basic mitigation of bad senders.

Okay so how do you as email administrator to protect  yourself?

Simple,  ensure your mail sender or MTA has a valid domain name, and PTR dns record. The MTA ( mail transfer agent  ), should be legit if you want the world to accept email from you.

If your forged, mis-configured or flaw, than most proper secured recipients, will drop your connection and hence you mail attempts will never even get a chance.

Once  you have the above satisfied, than we can now use reputation scoring, session limits or other mail security policies , to allow mail. It's common to use some of these practice with mail security

  1. real time blacklist
  2. session limits based on connection attempts per sec
  3. greylisting
  4. whitelisting
  5. static blacklist
  6. recipient verification
  7. max message size limits
  8. max recipient counts limits
  9. throttling based on reputational scoring

With most email systems, all of  the above are used to some degree. But  the HELLO is the 1st step that you have to overcome. If you are not who you say you are,  than sorry



Ken Felix
freelance network/security engineer
kfelix  a-t hyperfeed.com dot com




    Friday, March 22, 2013

    Review: The Demyo PowerStrip Plug

    This thread is about my newly acquired demyo power strip plug  that I received a few months ago.

    First off who's Demyo?  Demyo,  is a Miami Based InfoSec  company, who offers the following security services;

    • penetration testing
    • system vulnerability assessments
    • network/security audit and hardening
    • forensic collection and incident handling
    • web app vulnerability assessments
    • risk management 
    • and a host of other security consulting services

    More can be found on their website ;  http://www.demyo.com/

    1st off the Demyo DemyoPowerStrip also  known simply  as DPS thru out this thread, looks well........like a power strip :)






    A pen-test plug is suppose to not be detectable or suspicious, and hardly noticeable. The ideal of a hardware pen-testing plugs, are to bring the ethical hacker/pen-tester tools local & at the place of engagement. These devices will usually have the engineer  toolboxes, with contains the various  tools such as; vulnerability scanners, probes, possible compilers, scripts,  and other tools commonly used within vulnerability  assessment work. They are geared to perform any of the following;

    • network/system  recon
    • pentest ( hardwire/wireles devices )
    • vulnerabilities assessments
    • launching exploits
    • data collection  & harvesting  ( packets, passwords,etc...)
    • services for a reverse shells and remote access  options
    • packet forgery or interception 
    • etc..


    The demo plug as tested and as of this review is their 1st and only hardware device. It boasts one of the highest  local storage at a whooping 32gig. It's also priced modestly for the features and function that it offers & specially when compared to the competition.


    note:  During my initial review, I did not test any of the wireless features ( 802.11 or BlueTooth ) At the time of my acquisition the plug didn't have a full completed manual nor  was the  full "canned" pen-test tools installed as listed on the demyo.com website.

    After booting the  DPS you will be able to access the unit via ssh. It has no WebUI or any graphical interface enabled by default. But you can run a simple vnc-server script after boot-up.



    The devices specs as pulled from their website;


    Hardware
    • CPU 700Mhz, boostable to 1Ghz
    • RAM 512M
    • HDD 32GB
    • High gain WiFi adapter, 4dB, IEEE 802.11b/g/n
    • High gain bluetooth adapter, 300 yards range
    • Ethernet 10M/100M
    • MicroSD card slot. It is required to take back cover off for access
    • Serial Console. It is required to take back cover off for access
    • Functional power outlets, USB charging ports, Ethernet surge protection, Coaxial surge protection.









    You have the ability to run a small vncserver after  the initial login, if you so desire. I didn't find this method very beneficial, but it does function and seems to be stable in operation.











    One thing you will find out  very quickly,  the CPU shows a steady utilization & upwards to 100% usage at some times. Due to this small form and packaging,  this is to be expected & is normal. This device like other hardware plugs, are not  really gear'd for heavy cpu tasks. So you would not use this plug to compile a linux kernel or a re-work of your compiler & libraries.

    I would recommend  the end-user to pre-seed this device  and before deploying at the local engagement. The local gcc compiler seems function, and  with most libs and works very well. I must warn you,  that the speed is not blazing fast by any means. Building your tools ahead of time, or using the apt pkg management, might be more effective tho.

    But having the means to build and compile code locally, could be  a strong benefit and for any special projects or situations that might come up.

    To give you some time examples, I tarball and gzip compress the demyo provided wordlist;



    and gzip





    A simple compile of the unix arpwatch tool  over 9min to build from start to finish, I would suspect as more line of codes are encountered, your compile times would grow dramatically.

    Where the DPS shines at;  is the user has full control on what he/she want to install and plenty of space to do it in. Most other plugs like those from pwnie-express,  are limited in  internal storage size. A similar pwnie-express power-strip plug,  is almost at double the price, and at half the storage capacity.

    The creator of the  Demyo plug has crafted their plug for the experienced pen-tester, and to allow them to build their plug for customization.

    I'll quote one of Demyo Security Engineer;

    " Our plug allows the end user to install pkgs and tools that fit the type of engagement being present. It also allows the end-user full control to modify the DPS via the common apt-get pkg management or to compile tools as the need arises."

    One area of weakness, the plug has a very limited user guided setup and will require the end user to know and understand linux administration. Other available plugs, typically has a very quick and effective setups menus within their WebGUI. This allows for quick manipulation and for conducting  a host of tasks with ease.

    Another issues that was found, the plug runs a simple LAMP server, but you probably do not want to run the plug on a well-known services port if you want to keep it covert and immune from discovery.








    This can be rectified by changing the apache2 conf,  and by selecting a different listener port. I would also look at securing the data  via certificates. These 2 fixs, could probably keep it more hidden, and from view of any internal network monitor or probes. Ideally, this traffic would be tunnel within something like ssh.

    I would like  to wrap up the Demyo review; it's a serious contender with regards to hardware base pen-test  devices. The plug is reasonable priced, and built with flexibility for  the end-user to customize his pen-testing appliance and for his needs.

    Key areas that we could see improvement  in  imho;
    • a slightly faster processor to match the extended storage
    • possible a faster IO performance with the  internal storage device ( 2.5" notedrive or a ssd ide/ata devices from transcend comes to mind )
    • user mangement via scripts or easy-wizzard ( call-home, reverse-shell,etc...)
    • 3g/4g celluar connectivity as option, and integral to the strip would be a strong point

    Strong points for the DPS;
    • internal storage capacity
    • full end-user customization
    • wide option of connectivity ( BlueTooth/wifi/ethernet )
    • appearance
    • price $$$.$$


    I will keep my eye open on Demyo, and any future services or products from them.

    Ken Felix
    Freelance Network/Security Engineer
    kfelix   at  hyperfeed  dot com


    Thursday, March 21, 2013

    Why friends don't let friends, buy cisco ASA firewalls

    Here's a missed information, that consumers of cisco ASA don't realize. The ASA is a liscense hungry device & filled with restrictions.

    Take this for example, & from a ASA5505 running 9.1.1-4;


    -->
    ERROR: This license does not allow configuring more than 2 interfaces with

    nameif and without a "no forward" command on this interface or on 1 interface(s)

    with nameif already configured.


    Okay so what does that really mean ?  Will 1st let's look at our  show version output;

     
    Licensed features for this platform:
    Maximum Physical Interfaces       : 8              perpetual
    VLANs                             : 3              DMZ Restricted

    Dual ISPs                         : Disabled       perpetual
    VLAN Trunk Ports                  : 0              perpetual
    Inside Hosts                      : 10             perpetual
    Failover                          : Disabled       perpetual
    Encryption-DES                    : Enabled        perpetual
    Encryption-3DES-AES               : Enabled        perpetual
    AnyConnect Premium Peers          : 2              perpetual
    AnyConnect Essentials             : Disabled       perpetual
    Other VPN Peers                   : 10             perpetual
    Total VPN Peers                   : 12             perpetual
    Shared License                    : Disabled       perpetual
    AnyConnect for Mobile             : Disabled       perpetual
    AnyConnect for Cisco VPN Phone    : Disabled       perpetual
    Advanced Endpoint Assessment      : Disabled       perpetual
    UC Phone Proxy Sessions           : 2              perpetual
    Total UC Proxy Sessions           : 2              perpetual
    Botnet Traffic Filter             : Disabled       perpetual
    Intercompany Media Engine         : Disabled       perpetual
    Cluster                           : Disabled       perpetual

    This platform has a Base license.

    Serial Number: JMX1515Z135
    Running Permanent Activation Key: 0x65285667 0x9c212c13 0x7c505978 0xbaecc4d4 0xc231aa90
    Configuration register is 0x1


    You notice the  DMZ restricted? Hmm....... I bet you didn't realize that.

    Will let's look at cisco website and the ASA5505 as they currently list it on the side as of today 03/21/2013;

    http://www.cisco.com/en/US/customer/prod/collateral/vpndevc/ps6032/ps6094/ps6120/product_data_sheet0900aecd802930c5.html

    I'm going to zero in on the cisco "gotcha", take alook at the interface counts and  for virtual as listed in the specifications. Look very  very  closely :)





    Okay I will help out some, by highlighting the area ( see above ). It simply says 3 virtual-interfaces. No hint or warning about any type of restrictions. Let's look farther into what's on the cisco website;



    No restrictions right ? Wrong !

    So what about the based license, any clues in that? Will let's look at it?





     Nothing here either :(


    The earlier posted warning,  is basically saying; " your screwed and because we ( cisco ) are  greedy and want to charge you for everything ". You have 3 interfaces ( virtually ) , but you can't use this as what most individuals would think or expect to use this as.


    To wrap up my  post;


    Here's my current virtual interfaces?


    asaken# show ip add
    System IP Addresses:
    Interface                Name                   IP address      Subnet mask     Method
    Vlan1                    inside                 192.168.110.1   255.255.255.0   CONFIG
    Vlan2                    outside                0.0.1.175     255.255.255.0   DHCP 
    Current IP Addresses:
    Interface                Name                   IP address      Subnet mask     Method
    Vlan1                    inside                 192.168.110.1   255.255.255.0   CONFIG
    Vlan2                    outside                0.0..1.175     255.255.255.0   DHCP 
    asaken#



    route table;

    Gateway of last resort is xx.xx.52.1 to network 0.0.0.0

    C    192.168.110.0 255.255.255.0 is directly connected, inside

    C    xx.xx.1.0 255.255.255.0 is directly connected, outside
    d*   0.0.0.0 0.0.0.0 [1/0] via xx.52.1.1, outside
    asaken# 


    So I have a 2 interface model , a simple inside+outside on vlan1 and 2. So in order to create a 3rd interface, I can only create it with forwarding disable to one of the existing two.

    asaken(config-if)# no forward interface ?

    interface mode commands/options:
      Vlan  Catalyst Vlans
    asaken(config-if)# no forward interface vlan 1
    asaken(config-if)#



    Okay fine, I picked my  outside  interface only, So inside can only speak to the outside and my newly crafted inside1 can only speak to the outside.

    !
    interface Vlan3
     description inside1
     no forward interface Vlan1
     nameif inside1
     security-level 100
     ip address 192.168.111.1 255.255.255.0 



    Okay so now, I have my 3rd interface. And can configure rules, policy and so on. So now we can configure the rest of the unit, with the  exception that vlan1 and vlan3 would never talk. Let's explore that;

    here's my  dhcp binding for  vlan1 and vlan3,


    asaken# show dhcpd bind

    IP address       Client Identifier        Lease expiration        Type

      192.168.110.2    0140.6c8f.0318.c4            3451 seconds    Automatic
      192.168.110.3    01c8.2a14.0567.78            3588 seconds    Automatic
      192.168.111.2    0140.6c8f.0318.c4            3516 seconds    Automatic
    asaken# 


    and route table;

    Gateway of last resort is xx.xx.1.1 to network 0.0.0.0

    C    192.168.110.0 255.255.255.0 is directly connected, inside
    C    192.168.111.0 255.255.255.0 is directly connected, inside1
    C    xx.xx.1.0 255.255.255.0 is directly connected, outside
    d*   0.0.0.0 0.0.0.0 [1/0] via xx.xx.1.1, outside
    asaken#


    So if a person in vlan1 tries to ping a machine in vlan3;

    Last login: Thu Mar 21 05:19:21 on ttys000KenENG009:~ kfelix$ ifconfig en0
    en0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
        options=2b<RXCSUM,TXCSUM,VLAN_HWTAGGING,TSO4>
        ether 40:6c:8f:03:18:c4
        inet6 fe80::426c:8fff:fe03:18c4%en0 prefixlen 64 scopeid 0x4
        inet 192.168.111.2 netmask 0xffffff00 broadcast 192.168.111.255
        inet6 2001:db8::426c:8fff:fe03:18c4 prefixlen 64 autoconf
        inet6 2001:db8::ecd5:27ab:d636:ab62 prefixlen 64 autoconf temporary
        media: autoselect (100baseTX <full-duplex>)
        status: active


    KenENG009:~ kfelix$ ping 192.168.110.3
    PING 192.168.110.3 (192.168.110.3): 56 data bytes
    Request timeout for icmp_seq 0
    Request timeout for icmp_seq 1
    ^C
    --- 192.168.110.3 ping statistics ---
    3 packets transmitted, 0 packets received, 100.0% packet loss


    KenENG009:~ kfelix$ ping 192.168.110.2
    PING 192.168.110.2 (192.168.110.2): 56 data bytes
    Request timeout for icmp_seq 0
    Request timeout for icmp_seq 1
    cRequest timeout for icmp_seq 2
    ^C
    --- 192.168.110.2 ping statistics ---
    4 packets transmitted, 0
    packets received, 100.0% packet loss



    And this is regardless if we have the same security zone or even allow inter-zone traffic

    asaken# show run int vlan 1 | i security
     security-level 100
    asaken# show run int vlan 3 | i security
     security-level 100
    asaken# show run sma                   
    asaken# show run sam
    asaken# show run same-security-traffic
    same-security-traffic permit inter-interface
    asaken# 


    What I found out that's happening; the  firewall NAT's you thru, even tho you would not expect this activity;

    asaken# show xlate  interface inside1
    19 in use, 441 most used
    Flags: D - DNS, e - extended, I - identity, i - dynamic, r - portmap,
           s - static, T - twice, N - net-to-net
    ICMP PAT from inside1:192.168.111.2/55319 to outside:xx.xx.1.175/55319 flags ri idle 0:00:02 timeout 0:00:30
    ICMP PAT from inside1:192.168.111.2/54807 to outside:xx.xx.1.175/54807 flags ri idle 0:00:04 timeout 0:00:30



    So plan accordingly if your going to buy a cisco ASA product. You will run into hurdles and limitations. Cisco main goal as I see it;

    •  is for you to forklift into a bigger chassis 
    or
    •  purchase some type of license-enhancement upgrade

    Ken Felix
    Freelance Network/Security Engineer
    kfelix at hyperfeed  d-o-t com

    Friends don't let friends buy ASA :)






    ipv6 and how to test ( google style )

    Google has been an a big player with rolling the ball on ipv6, and been ipv6 enabled,  for at least 5+ years from what I recall.

    Since ipv6 world day, the push to get ipv6 knowledge from hosting partners, network vendors, application providers, etc...... have been growing at a  slow turtle pace.


    For testing if your host is  ipv6  aware, google has created a websitehttp://ipv6test.google.com 


    I find it ironic,  that the Google's own  ipv6test site is not on ipv6



    $ host -6 www.google.com 2001:4860:4860::8888
    Using domain server:
    Name: 2001:4860:4860::8888
    Address: 2001:4860:4860::8888#53
    Aliases:

    www.google.com has address 74.125.224.209
    www.google.com has address 74.125.224.212
    www.google.com has address 74.125.224.208
    www.google.com has address 74.125.224.210
    www.google.com has address 74.125.224.211
    www.google.com has IPv6 address 2001:4860:4007:801::1014


    and now the ipv6test site;


    $ host -6 ipv6test.google.com 2001:4860:4860::8888
    Using domain server:
    Name: 2001:4860:4860::8888
    Address: 2001:4860:4860::8888#53
    Aliases:

    ipv6test.google.com is an alias for ipv6test.l.google.com.
    ipv6test.l.google.com has address 74.125.129.105
    ipv6test.l.google.com has address 74.125.129.103
    ipv6test.l.google.com has address 74.125.129.99
    ipv6test.l.google.com has address 74.125.129.147
    ipv6test.l.google.com has address 74.125.129.106
    ipv6test.l.google.com has address 74.125.129.104
    $  


    and  their 2nd dns server ;

    $ host -6 ipv6test.google.com  2001:4860:4860::8844
    Using domain server:
    Name: 2001:4860:4860::8844
    Address: 2001:4860:4860::8844#53
    Aliases:

    ipv6test.google.com is an alias for ipv6test.l.google.com.
    ipv6test.l.google.com has address 74.125.129.105
    ipv6test.l.google.com has address 74.125.129.103
    ipv6test.l.google.com has address 74.125.129.99
    ipv6test.l.google.com has address 74.125.129.147
    ipv6test.l.google.com has address 74.125.129.106
    ipv6test.l.google.com has address 74.125.129.104
    $



     So even the leaders , do not always lead in all areas for ipv6 encouragement






    Ken Felix
    Freelance Network/Security Engineer
    kfelix @  hyperfeed      com

    A look at the reverse of Unix "cat"

     
    How to look at log events with the opposite of our unix cat commands. The opposite of “Cat” is a “Dog” , but in this post was are going to look at “tac” which is the linux version of "cat", but backwards.


    The linux command tac , is one of the most helpful linux command  & with regards to log parsing. And most don’t know about it,  or that it even exists.

    Here’s a cat btw;




    tac, allows for one to start at the ending of the page and work your way back up. It’s similar to how cat starts at the top of the file and works it’s way downward.

    So let’s say you have a text.file of ip address;
    [kfelix@aa1ab:~]> cat file | more
    172.16.0.1

    172.16.0.2

    172.16.0.3

    172.16.0.4

    172.16.0.5

    172.16.0.6

    172.16.0.7

    172.16.0.8

    172.16.0.9

    172.16.0.10

    172.16.0.11

    172.16.0.12

    172.16.0.13

    172.16.0.14

    172.16.0.15

    172.16.0.16

    172.16.0.17

    172.16.0.18

    172.16.0.19

    172.16.0.20

    172.16.0.21

    172.16.0.22

    172.16.0.23

    172.16.0.24

    172.16.0.25

    172.16.0.26

    172.16.0.27

    172.16.0.28

    172.16.0.29

    172.16.0.30
    (and so on)

    So If I wanted to  review the bottom of the  file and work my way back up, I could use the unix tac cmd to achieve this.

    [kfelix@aa1ab:~]> tac file | more

    172.16.0.254

    172.16.0.253

    172.16.0.252

    172.16.0.251

    172.16.0.250

    172.16.0.249

    172.16.0.248

    172.16.0.247

    172.16.0.246

    172.16.0.245

    172.16.0.244

    172.16.0.243

    172.16.0.242

    172.16.0.241

    172.16.0.240

    (and so on )


    So it’s the reverse of the standard unix cat. Great for stringing logged data from bottom to top, like in a systems log file. With grep and tac, you can easily find information within a text log file, from most current to past.

    Note:  tac is a utility for most linux distros, it has no availability to read compressed files in the same manner of  zcat

    Reference



    So remember, that we have tac as an alternative to cat, and both commands are helpful with parsing logs or other files.


    Ken Felix
    Freelance Network/Security Engineer
    kfelix a-t hyperfeed d-o-t com

    flow diagnostic ( cisco ASA )


    In these next series of posts, I went over some of the basic diagnostic  methods for netscreen, fortigate. I'm wrapping this series up with the cisco ASA, which is similar but quite different and even simpler.

     As firewall admins, we need to know how to aid in t-shooting. Blindly changing rules, rebooting, and host of other steps are typically a hail mary and accomplish nothing.


    1st up,

    Flow diagnostic  on the cisco ASA are just as simple as juniper/fortigate;


    2nd, unlike the previous flow diagnostic posted earlier, the cisco ASA does not require real user data, you can simulate the traffic in order to validate the flow and fwpolicy handling. This is process is known simply as packet-tracer. So you can test your fwpolicy, encryption,nat,etc...... with out having REAL data.

    So look at it as pre-trouble-shooting before going live :)

    3rd

    we need to used the intergral packet-tracer cmd and specify the following;

    • src interface
    • protocol
    • src/dst port ( if proto = udp/tcp )
    • icmp type  ( if proto #1 icmp )
    • detail is optional
    • XML format is optional
    • asaken# packet-tracer  input  inside ?
       
        icmp   Enter this keyword if the trace packet is ICMP
        rawip  Enter this keyword if the trace packet is RAW IP
        tcp    Enter this keyword if the trace packet is TCP
        udp    Enter this keyword if the trace packet is UDP


    4th

    Here's a few samples ( ipv4 ) using the same example a host inside going to one of Google DNS servers;

     cmd
     
    -->
    asaken# packet-tracer  input  inside udp 192.168.110.11 1234 8.8.8.8 53

    -->
    And the following diagnostic will be learned;



    Phase: 1

    Type: ACCESS-LIST

    Subtype:

    Result: ALLOW

    Config:

    Implicit Rule

    Additional Information:

    MAC Access list



    Phase: 2

    Type: ROUTE-LOOKUP

    Subtype: input

    Result: ALLOW

    Config:

    Additional Information:

    in   0.0.0.0         0.0.0.0         outside



    Phase: 3

    Type: NAT

    Subtype:

    Result: ALLOW

    Config:

    object network inside

     nat (inside,outside) dynamic interface

    Additional Information:

    Dynamic translate 192.168.110.11/1234 to 192.0.2.1/1234



    Phase: 4

    Type: NAT

    Subtype: per-session

    Result: ALLOW

    Config:

    Additional Information:



    Phase: 5

    Type: IP-OPTIONS

    Subtype:

    Result: ALLOW

    Config:

    Additional Information:



    Phase: 6

    Type: INSPECT

    Subtype: np-inspect

    Result: ALLOW

    Config:

    Additional Information:



    Phase: 7     

    Type: HOST-LIMIT

    Subtype:

    Result: ALLOW

    Config:

    Additional Information:



    Phase: 8

    Type: NAT

    Subtype: per-session

    Result: ALLOW

    Config:

    Additional Information:



    Phase: 9

    Type: IP-OPTIONS

    Subtype:

    Result: ALLOW

    Config:

    Additional Information:



    Phase: 10

    Type: FLOW-CREATION

    Subtype:

    Result: ALLOW

    Config:

    Additional Information:

    New flow created with id 347, packet dispatched to next module



    Result:

    input-interface: inside

    input-status: up

    input-line-status: up

    output-interface: outside

    output-status: up

    output-line-status: up

    Action: allow

     here's a deny for example;

    -->
    And here’s a deny for example;

    asaken# packet-tracer  input  inside udp 192.168.110.11 1111 192.168.110.12 53$



    Phase: 1

    Type: ROUTE-LOOKUP

    Subtype: input

    Result: ALLOW

    Config:

    Additional Information:

    in   192.168.110.0   255.255.255.0   inside



    Phase: 2

    Type: ACCESS-LIST

    Subtype:

    Result: DROP

    Config:

    Implicit Rule

    Additional Information:

     Forward Flow based lookup yields rule:

     in  id=0xda05f258, priority=111, domain=permit, deny=true

                hits=1, user_data=0x0, cs_id=0x0, flags=0x4000, protocol=0

                src ip/id=0.0.0.0, mask=0.0.0.0, port=0, tag=0

                dst ip/id=0.0.0.0, mask=0.0.0.0, port=0, tag=0 dscp=0x0

                input_ifc=inside, output_ifc=inside



    Result:

    input-interface: inside

    input-status: up

    input-line-status: up

    output-interface: inside

    output-status: up

    output-line-status: up

    Action: drop

    Drop-reason: (acl-drop) Flow is denied by configured rule

    The above was deny due to the src/dst was the same as the inside subnet  I also used the  detail option for that above example.

    Here's  another deny, but with the format changed to xml;


    asaken# packet-tracer  input  inside udp 192.168.111.11 1111 192.168.110.12 53$



    <Phase>

    <id>1</id>

    <type>ROUTE-LOOKUP</type>

    <subtype>input</subtype>

    <result>ALLOW</result>

    <config>

    </config>

    <extra>

    in   192.168.110.0   255.255.255.0   inside

    </extra>

    </Phase>



    <Phase>

    <id>2</id>

    <type>ACCESS-LIST</type>

    <subtype></subtype>

    <result>DROP</result>

    <config>

    Implicit Rule

    </config>

    <extra>

     Forward Flow based lookup yields rule:

     in  id=0xda05f258, priority=111, domain=permit, deny=true

                hits=3, user_data=0x0, cs_id=0x0, flags=0x4000, protocol=0

            src ip/id=0.0.0.0, mask=0.0.0.0, port=0, tag=0

                dst ip/id=0.0.0.0, mask=0.0.0.0, port=0, tag=0 dscp=0x0

                input_ifc=inside, output_ifc=inside

    </extra>

    </Phase>



    <result>

    <input-interface>inside</input-interface>

    <input-status>up</input-status>

    <input-line-status>up</input-line-status>

    <output-interface>inside</output-interface>

    <output-status>up</output-status>

    <output-line-status>up</output-line-status>

    <action>drop</action>

    <drop-reason>(acl-drop) Flow is denied by configured rule</drop-reason>

    </result>





    and finally, here's a ipv6 packet-trace


    -->
    asaken#   packet-tracer input inside tcp 2002:100::44bf:21b9:296f:9656 1234 2$  -->

    Phase: 1

    Type: ACCESS-LIST

    Subtype:

    Result: ALLOW

    Config:

    Implicit Rule

    Additional Information:

    MAC Access list



    Phase: 2

    Type: ROUTE-LOOKUP

    Subtype: input

    Result: ALLOW

    Config:

    Additional Information:

    in   2001:db8::      ffff:ffff:ffff:ffff:: outside



    Phase: 3

    Type: NAT

    Subtype: per-session

    Result: ALLOW

    Config:

    Additional Information:



    Phase: 4     

    Type: HOST-LIMIT

    Subtype:

    Result: ALLOW

    Config:

    Additional Information:



    Phase: 5

    Type: NAT

    Subtype: per-session

    Result: ALLOW

    Config:

    Additional Information:



    Phase: 6

    Type: FLOW-CREATION

    Subtype:

    Result: ALLOW

    Config:

    Additional Information:

    New flow created with id 882, packet dispatched to next module



    Result:

    input-interface: inside

    input-status: up

    input-line-status: up

    output-interface: outside

    output-status: up

    output-line-status: up

    Action: allow


    Each trace is marked and the key take aways are the following;
      
        
    •   Interface dst/src ( directionality ) 
    •     Session allocation
    •   if SNAT/DNAT is applicable ( NAT )
    •   the Allowed or Denied ( action )
    I hope these series of post are helpful in your l3/l4 diagnostic.

    Ken Felix
    Freelance Network/Security Engineer
    kfelix a-t hyperfeed-d-o-t-com