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
Sunday, March 31, 2013
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
Happy bot monitoring :)
Ken Felix
Freelance Network Security Engineer
kfelix @ hyperfeed d.o.t com
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;
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.
note: They thought almost everything :)
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:
Ken Felix
Freelance Network/Security Engineer
kfelix at hyperfeed dot com
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.
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
- 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;
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
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
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
- real time blacklist
- session limits based on connection attempts per sec
- greylisting
- whitelisting
- static blacklist
- recipient verification
- max message size limits
- max recipient counts limits
- 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;
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;
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
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;
Strong points for the DPS;
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
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;
-->
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;
Ken Felix
Freelance Network/Security Engineer
kfelix at hyperfeed d-o-t com
Friends don't let friends buy ASA :)
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
- 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 website; http://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
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 website; http://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.
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.
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.
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
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 )
Ken Felix
Freelance Network/Security Engineer
kfelix a-t hyperfeed-d-o-t-com
Subscribe to:
Posts (Atom)