Cowboy Denny
-
Posts
357 -
Joined
-
Last visited
About Cowboy Denny
Cowboy Denny's Achievements
-
Basic Commands Identify Version tcpdump --version The general syntax for the tcpdump command is as follows: tcpdump [options] [expression] The command options allow you to control the behavior of the command. The filter expression defines which packets will be captured. Use the -D option to print a list of all available network interfaces that tcpdump can collect packets from: sudo tcpdump -D For each interface, the command prints the interface name, a short description, and an associated index (number) To specify the interface on which you want to capture traffic, invoke the command with the -i option followed by the interface name or the associated index. For example, to capture all packets from all interfaces, you would specify the any interface: sudo tcpdump -i any By default, tcpdump performs reverse DNS resolution on IP addresses and translates port numbers into names. Use the -n option to disable the translation: sudo tcpdump -n Instead of displaying the output on the screen, you can redirect it to a file. Two options and its important you use the correct one depending on how you plan on reading the output. OPTION 1: text file This is great if you just want what would be displayed on the screen to be captured in a text file. NOTE: this will more then likely not be readable by any of the software packages designed to analyze captures like the very popular Wireshark sudo tcpdump -n -i any > file.out You can also watch the data while saving to a file using the tee command: sudo tcpdump -n -l | tee file.out The -l option in the command above tells tcpdump to make the output line buffered. When this option is not used, the output will not be written on the screen when a new line is generated. OPTION 2: binary file This is the way you want to go if you plan on sending to someone or even yourself to analyze the capture in a tool such as Wireshark. sudo tcpdump -w <filename> Example sudo tcpdump -n -i any -w file.pcap or a more intense version of the command tcpdump -s0 -nnnvi 0.0:nnnp -vw /var/tmp/appname_$(date +%d_%b_%H_%M_%S)_$HOSTNAME.pcap host 10.47.78.103 Capture Filters WORKING DOCUMENT... sorry for how incomplete it is -
SCP Linux Command – How to SSH File Transfer from Remote to Local SCP Syntax scp [OPTIONS] [[user@]src_host:]file1 [[user@]dest_host:]file2 scp - It initializes the command and ensures a secure shell is in place. OPTIONS - They grant different permissions depending on how they have been used. Some of the most common options include: P(Caps) - specifies the port to establish connection with the remote host. p(lowercase) - preserves the times-tamp for ease of modification and access. r - copies the entire directory recursively q - copies files quietly, doesn't display the progress messages. Also known as quiet mode. C - for compression of data during transmission. To understand more about OPTIONS read scp options src_host - where the file is hosted. The source can either be a client or server depending on the origin of the file. dest_host - where the file will be copied to. Examples Copy File from Local Host to Remote Host scp test.txt user@destination:/location Copy all files ending in php to Remote Host scp *.php user@destination:/~/ *.php - copies all the files with the .php extension in the currently specified folder. /~/ - means copy them to the home directory. Copy a file with one name but save it on remote host with a different filename scp -P 8080 test.txt user@destination:/user/home/test2.txt Copy Files from Remote Host to Local Host scp <remote_username>@<IPorHost>:<PathToFile> <LocalFileLocation> Copy File test2.txt from Remote Host to Local Host scp user@remotehost:test2.txt . Copy Files from Remote Host to another Remote Host scp [email protected]:/files/test.txt [email protected]:/files Copy Multiple Files scp file1 file2 ... user@<ip_address_of_user>: Destination So SCP is a very powerful tool when needing to move files around between systems over the network -
curl is a command-line tool to transfer data to or from a server, using any of the supported protocols (HTTP, FTP, IMAP, POP3, SCP, SFTP, SMTP, TFTP, TELNET, LDAP, or FILE). curl is powered by Libcurl. This tool is preferred for automation since it is designed to work without user interaction. curl can transfer multiple files at once. Syntax: curl [options] [URL...] URL: The most basic use of curl is typing the command followed by the URL. curl https://www.hosangit.com This should display the content of the URL on the terminal. The URL syntax is protocol dependent and multiple URLs can be written as sets like: curl http://site.{one, two, three}.com URLs with numeric sequence series can be written as: curl ftp://ftp.example.com/file[1-20].jpeg Progress Meter: curl displays a progress meter during use to indicate the transfer rate, amount of data transferred, time left, etc. curl -# -O ftp://ftp.example.com/file.zip curl --silent ftp://ftp.example.com/file.zip If you like a progress bar instead of a meter, you can use the -# option as in the example above, or –silent if you want to disable it completely. Options: -o: saves the downloaded file on the local machine with the name provided in the parameters. Syntax: curl -o [file_name] [URL...] Example: curl -o hello.zip ftp://speedtest.tele2.net/1MB.zip -
So for a year or two I have been looking for a Point of Sale system that accomodates all my needs which isn't alot but most POS's are focused on the restaurant business or retail and thats pretty much it. We end up having to try and make one or the other work for events. I'll start off with the requirements then work give a review of each POS I've tried so far. Requirements Let's first start with my least liked POS but it didn't start that way... Mobi POS At the beginning this was a great little POS with some custom options but its really focused around a restaurant which I'm not but made it work. A few years back they introduced the cloud version which I loved the idea of.. build everything in the cloud and push your changes down to your Terminals. MOBI is not good at this at all. Originally (and they still have) a peer network where you have one iPad acting as the server and another iPad can be a terminal but that extra terminal is very limited on what it can do. Pricing was okay but still pricey for what you get. I found for the same price you can get into a nicer POS but MOBI was very easy to get up and going quickly if you have on one register. They do offer a 14 day risk free trial at the time of this writing so give them a look, maybe they'll work for what you need. Unfortunately MOBI isn't strong enough with features to do what we need a POS to do so they are now no longer a part of our infrastructure. AirPOS This POS felt like a step up from MOBI but more so in the cloud aspect. Getting multiple terminals up is easy as well as configuring your products but it felt still like the feature set was lacking. For example there is no discount or coupon area to add pre-populated information or an ability to run reports on discounts. When you log in via an assigned PIN there was a huge lag between each press of the number to where you would continue to enter the wrong number because the lag is so bad. Pricing I never got into but they are currently very generous with there trial period of 30days which I was blown away with. Thank You! Support wasn't horrible but needs improvement but that could be because airpos is headquartered in Northern Ireland. I'm sure the time difference has something to do with it. Again, like MOBI if you have a simple setup then airpos may be fine for your needs but when you run into complicated environments like ours then it just won't do. talech My next attempt was talech which was found off a google search for a Point of Sale system that would work on an iPad. I have much frustration with talech for mainly they have promise but I should of known I was in trouble right from the start. Salesman did a nice demo of the system and showed what I could do. My staff and I brought up questions to the salesman which was answered no problem, talech can do that. SOLD! Paid for the product but it took a days to get the login information and to process the purchase. Once I received the information I learned that you don't get all the features as demonstrated without purchasing the upgraded premium package. Also an odd thing but you cant apply discount coupon to one item. It says you can but if you have 5 of the same product and you only want to discount 2 of them you can't, the system applies the discount to all 5 of the same item. Weird. Also trying to edit items on the backend in the browser the system would just spin. Also I can not run the reports on discount/coupons used. It took awhile but I learned that talech, yet more feature reach than the other two, wasn't going to be our Point of Sale system. iConnect With the 7 day free trial of iConnect POS I thought I may of found a winner. It is very feature rich and pretty easy to use. In fact it had the most features of any POS I tested. Also impressed with the support for iOS, Android and Web based. So it sounds great right? Nope, just a dress on a pig. You will get different features based on what operating system you use so since you have three possible ways to connect to iConnect you also get three different environments. For example the Android and Web interface supports drop down discounts but the iPad does not. The iPad will support USB Printer where the Android Tablets do not... just to name a few differences. Something I definitely did not like is if you apply a discount to an item it spreads the discount all over every items (like a percentage off). It looks ugly and not sure who would want that. Finally a feature that I feel is a serious bug. If you process a refund on a sale it doesn't mark it in the system that you refunded an item off that ticket so that customer can go back as many times as they want and get a refund on the same ticket. That was the final straw that broke the iConnect POS back. I can easily see this happening in our environment. I did love the ability to place an order on HOLD and pull it back up. I could see the ladies in the office doing sales during the week enter all these sales in a HOLD pattern and finalize it on the weekend when they customer comes to the gate. ShopKeep Thank goodness for shopkeep. I have tried all these and lost alot of money in the process. The staff is very friendly and helpful. After introduction from Nick which handed me off to a specialist named Tim which showed me what I needed to see. I was up and running in less than an hour. Now no one is perfect and I didn't see the ability to get a free trial of the system to play around. I had to pay $138 for two terminals/month which is the most expensive of all that I tried but it works. iConnect does have more features than shopkeep but Shopkeep just does what I need it to do. Sometimes more isn't always better. Unlike Revel we can shut down the terminals when not in use and I don't get billed the $69 for each terminal a month but if you want access to your reports still and keep all your products entered then you may a small price of $10/month. When your season starts back up you pay the $69/terminal and it downloads what you need. For me its a no brainer and I'm still on my first day with the product but what I learned from using all the other POS systems, this product is really great. -
A browser connecting to the secure server will use the SSL protocol to connect and verify the server’s certificate. However, customers can also use Mutual Authentication to have both the client and server use signed certificates to authenticate each other. With Mutual Authentication, both client and server will provide signed certificates for verification. How Mutual Authentication Works Client sends ClientHello message proposing SSL options. Server responds with ServerHello message selecting the SSL options. Server sends Certificate message, which contains the server's certificate. Server requests client's certificate in CertificateRequest message, so that the connection can be mutually authenticated. Server concludes its part of the negotiation with ServerHelloDone message. Client responds with Certificate message, which contains the client's certificate. Client sends session key information (encrypted with server's public key) in ClientKeyExchangemessage. Client sends a CertificateVerify message to let the server know it owns the sent certificate. Client sends ChangeCipherSpec message to activate the negotiated options for all future messages it will send. Client sends Finished message to let the server check the newly activated options. Server sends ChangeCipherSpec message to activate the negotiated options for all future messages it will send. Server sends Finished message to let the client check the newly activated options. How the Client and Server Accomplish Each of the Checks for Client Authentication Digital Signature: The client sends a "Certificate Verify" message that contains a digitally signed copy of the previous handshake message. This message is signed using the client certificate's private key. The server can validate the message digest of the digital signature by using the client's public key (which is found in the client certificate). Once the digital signature is validated, the server knows that the public key belonging to the client matches the private key used to create the signature. Certificate Chain: The server maintains a list of trusted Client Authorities (CAs), and this list determines which certificates the server will accept. The server will use the public key from the CA certificate (which it has in its list of trusted CAs) to validate the CA's digital signature on the certificate being presented. If the message digest has changed or if the public key does not correspond to the CA's private key used to sign the certificate, the verification fails and the handshake terminates. Expiration Date and Validity Period: The server compares the current date to the validity period listed in the certificate. If the expiration date has not passed and the current date is within the period, then this check succeeds. If it is not, then the verification fails and the handshake terminates. Certificate Revocation Status: The server compares the client certificate to the list of revoked certificates on the system. If the client certificate is on the list, the verification fails and the handshake terminates. Additional Information Verify the Client Certificate with auth-root Run the following command to verify the client certificate: openssl verify -purpose sslclient -CAfile auth-root.crt testcert.crt Test Connection with Client Cert Run the following command to test the connection with the client: openssl s_client -servername example.com -connect example.com:443 -key client-cert.key -cert client-cert.crt Below is an example of two-way SSL authentication on the BIG-IP system and how to configure mutual or two-way (mutual) authentication using a Client SSL profile to protect application traffic. One-way authentication Using one-way authentication, clients perform SSL handshakes when initiating a new connection with SSL protected applications. During the SSL handshake, the protected application sends its public SSL certificate to the remote client for validation (referencing the photo on the right the remote client is shown as Server). The remote client (Server) validates the application's public SSL certificate by searching for the signing Certificate Authority (CA) certificate in its trusted CA store. If the remote client (Sever) is unable to validate or find the signing CA for the public SSL certificate, it should not complete the SSL handshake and abandon the new connection attempt. Two-way authentication Two-way authentication is a less popular method for protecting application traffic as it requires an additional layer of security. When using two-way authentication, clients perform a slightly modified SSL handshake when initiating a new connection with SSL-protected applications. During the modified SSL handshake, the protected application sends its public SSL certificate to the remote client for validation and requests that the remote client sends its Client SSL certificate for validation as well. Both the remote client and protected application validate the SSL certificates they receive by searching for the signing CA certificates in their respective trusted CA stores. If the remote client or the protected application is unable to validate the received SSL certificate, they should not complete the SSL handshake and abandon the new connection attempt. REFERENCE: K12140946 K15137 -
Many companies regardless if its I.T. related, medical or anything really, businesses have discovered they can save a ton of money but utilizing resources over sea's where the cost of living is much cheaper which in turn means talent is also less expensive. Obviously some downfalls come with using overseas no face to face via in office conversations no participation in out of office gatherings biggest issue many times is language barrier as recorded below -
Some of us dabble a bit in Wordpress but we had to start somewhere which means we got help from somewhere. This blog entry is in hopes to give some material to help a newbie in the world of Wordpress. There are a few different great tools to use to build/customize your site and one of them I like to use is called Elementor. Here is a great starter guide/video that is a bit older but he does a great job at walking you through building a wordpress site. This video focuses mainly on how to use Elementor to customize the site for you This video is more about creating everything for an eCommerce site using Woo Commerce (the free plugin) installed on the free Wordpress.com And you can Google search Elementor Wordpress Theme and come across lots and lots of video tutorials. No other Web platform has as many tutorials available. Going to add that you should leverage helpful free tools to evaluate your site to make it more SEO compliant so you show on searches. You should make sure you have meta content on everything, especially your photos. Make sure your website is using Google Developer Tools (formerly known as webmaster) Also check out this tool that goes through and check out your site for issue/errors. Meta Data Google Developer Tools WAVE -
Being a mac user and sometimes linux user (never Windows), I miss Visio since that's how I created my diagrams. I tried many different software replacements to just be let down. I stumbled on lucid.app which my initial reaction was, no way a web based anything could come close to Visio but man was I wrong. Yes you can import stencils Yes you can import Visio diagrams, OmniGraffle, Gliffy, Draw.io Yes you can export Visio Is it free? No but its very affordable or I wouldn't be using it. I haven't done the compare in cost but I'm fairly confident it's less expensive than the subscription to Visio and no obligation. As you can see I use the Individual plan which runs $95/year but includes more than enough to be a competitor with Visio and other similar tools. -
My MacBook Pro got updated to MacOS Monterey (12.2.1) and since then, I can't use git at all. When I run git I get this USDETMNBSJEMD6R:~ iSupport$ git xcrun: error: invalid active developer path (/Library/Developer/CommandLineTools), missing xcrun at: /Library/Developer/CommandLineTools/usr/bin/xcrun So in reading about others having this issue they just run USDETMNBSJEMD6R:~ iSupport$ xcode-select --install xcode-select: note: install requested for command line developer tools This popped open a window showing the install (which isn't a fast install at all) Eventually it will give you a pop up like the one shown below that states the software is installed. For my own sanity I just check version to see if the command git will work now and it does USDETMNBSJEMD6R:~ iSupport$ git --version git version 2.30.1 (Apple Git-130) -
Many of us have to supply a report showing our devices are compliant based on auditors requirements. What tool out there does compliancy checks? A great free opensource compliancy tool is called netshot. The open source compliance network software. Freely available : www.netfishers.onl/netshot -
There are a total of three (3) copies of your marriage license. You must give the entire packet to the person who performs your ceremony on the day of the wedding. They are responsible for filling out the licenses and mailing two (2) copies back in the envelope provided. The third copy will be presented to you as a keepsake, but it is not good for any legal purpose. If you need a legal copy of your marriage license, known as a marriage certificate, you may purchase these separately approximately 7-10 days after your wedding. This type of copy is necessary if the bride intends on changing her last name. You may come to the office to purchase these copies in person or order online at www.oakgov.com and they will be mailed to you. The cost is $15 for the first copy and $5 for any additional. When you receive you marriage licenses you will get something like this with it -
Check how each DNS Server is doing. NOTE: DNS can use UDP or TCP port 53 Zone transfers use TCP Queries use UDP ALSO DNS is considered Layer7 (Application Layer) ARCHITECTURE EXAMPLE External/Internet Facing Utilize F5 BIG-IP DNS (GTM) as the name server since they are practically impossible to kill Internal/Intranet Utilize Infoblox with a minimum of two DNS Views (Internal DNS View for intranet only DNS and External DNS View for internet only) REFERENCE LOGICAL DIAGRAM BELOW <insert photo> Of course we could configure many different ways for DNS but let's just concentrate on the External DNS for now since Internal DNS could get complicated with Microsoft Active Directory and using F5 BIG-IP DNS (GTM) for WideIPs and leveraging Anycast then dealing with DDNS.. as you can see, internal DNS is much more complicated then External DNS. To add an External facing DNS Domain (adding a subdomain is the same process) First create the new external domain in Infoblox. I personally like using the csv import process that Infoblox supports. You just populate a CSV like this one here and then go into Infoblox and import the CSV to create the domain (or subdomain). Using the same process (just a different csv) I would add any records that belong in that new domain. Second create the new external domain on your F5 BIG-IP DNS by running command but you need to know a couple things before you can run the command. What name servers are defined on your F5 device that point to the IP address of your Infoblox GridMaster. You can identify this by running this command: iSupport@(mifnt1slbgtm03)(cfg-sync Standalone)(Active)(/Common)(tmos)# list ltm dns nameserver ltm dns nameserver dnsx_server_0 { address 10.11.12.205 route-domain 0 tsig-key Sup3Rs3CreT } ltm dns nameserver dnsx_server_1 { address 10.11.12.205 route-domain 0 } tmsh create ltm dns zone eventguyz.com dns-express-server dnsx_server_0 dns-express-notify-tsig-verify no Explanation dns-express-server TSIG Notes Use transaction signature (TSIG) keys to authenticate communications about zone transfers between the BIG-IP system and authoritative DNS servers, and between the BIG-IP system and DNS nameservers (clients).
-
Many exports limits to 10,000 entries but what if you have more than that then what? Using an API call is the way to go. Here are instructions on how to export DHCP Leases from Infoblox using an API call. Pre-Req: Must have a user account with API access Must have the FQDN or IP of the GridMaster Instructions: (I'm using a Mac of course so if you are using Windows it will look different but Linux it will look the same) From the machines command prompt run curl -k -u 'admin:infoblox' -H 'content-type: application/json' -X POST "https://gm.eventguyz.corp/wapi/v2.9/fileop?_function=csv_export" -d '{"_object": "lease" }' { "token": "eJytjk0LgjAYx7+K7Jxu0/mCN8OCQBQi6DjEPdnAt7YVRfTd2w517dL19399IrgvUj24kSOg3KNJ\nzChJszAJQpKFGaErD13VYCV0NmbROcaUBCwKKGPWEmNHuZAKOsNPcgAuZ6zgwqXwy+ZYV01R+iQh\nlKZhxBKbyBjBFbQadNDpG7L9ojUth6mbhZx6t7Te1V8+zsIdQ2VxKPh+s/0IjmFtZtX2gM24/OOI\nFK71Vwi93qrJWuw=\n", "url": "https://gm.eventguyz.corp/http_direct_file_io/req_id-DOWNLOAD-0601172346205840/Leases.csv" Now download the file using the link in the output above curl -k -u 'admin:infoblox' -H 'content-type: application/force-download' "https://gm.eventguyz.corp/http_direct_file_io/req_id-DOWNLOAD-0601172346205840/Leases.csv" -o "Leases.csv" % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 8221k 100 8221k 0 0 359k 0 0:00:22 0:00:22 --:--:-- 286k As cleanup, remove the token provided in step 1 curl -k -u 'admin:infoblox' -H 'content-type: application/json' -X POST "https://gm.eventguyz.corp/wapi/v2.9/fileop?_function=downloadcomplete" -d '{"token" : "eJytjk0LgjAYx7+K7Jxu0/mCN8OCQBQi6DjEPdnAt7YVRfTd2w517dL19399IrgvUj24kSOg3KNJ\nzChJszAJQpKFGaErD13VYCV0NmbROcaUBCwKKGPWEmNHuZAKOsNPcgAuZ6zgwqXwy+ZYV01R+iQh\nlKZhxBKbyBjBFbQadNDpG7L9ojUth6mbhZx6t7Te1V8+zsIdQ2VxKPh+s/0IjmFtZtX2gM24/OOI\nFK71Vwi93qrJWuw=\n"}' That's all there is to it and now you have ALL the DHCP Leases in Leases.csv on your machine that you downloaded from Infoblox
-
For this to work you need to decrypt the traffic as it comes in. Its too late if you did a capture and all the traffic is encrypted. So this entry is for those of you that would like to do some work ahead of time on the F5 and then have the user do some application testing while you are running a tcpdump. In many cases for me, I have only needed to do this on our DMZ LTM which is where the our F5 works as an SSL Bridge SETUP Put the source IPs in a txt file. I'm calling mine /var/tmp/app1_dg_nonprod_address.txt Create a datagroup tmsh create /sys file data-group dg.app1.nonprod separator ":=" source-path file:/var/tmp/app1_dg_nonprod_address.txt type ip Create iRule and reference datagroup ## irule.ssl.decrypt.app1.nonprod when CLIENTSSL_HANDSHAKE { if {[class match [getfield [IP::client_addr] "%" 1] equals dg.app1.nonprod] } { log local0. "CLIENT_Side_IP:TCP source port: [IP::client_addr]:[TCP::remote_port]" log local0. "CLIENT_RANDOM [SSL::clientrandom] [SSL::sessionsecret]" log local0. "RSA Session-ID:[SSL::sessionid] Master-Key:[SSL::sessionsecret]" } } when SERVERSSL_HANDSHAKE { if {[class match [getfield [IP::client_addr] "%" 1] equals dg.app1.nonprod] } { log local0. "CLIENT_Side_IP:TCP source port: [IP::client_addr]:[TCP::remote_port]" log local0. "CLIENT_RANDOM [SSL::clientrandom] [SSL::sessionsecret]" log local0. "RSA Session-ID:[SSL::sessionid] Master-Key:[SSL::sessionsecret]" } } Add iRule to Virtual Server you want to capture traffic on Start Capture via cli where the iRule is tcpdump -ni 0.0:nnn -s0 --f5 ssl host 198.200.19.151 or host 10.46.69.31 -w /var/tmp/app1-ext.hosangit.com_tcpdump_VS_$(date +%d_%b_%H_%M_%S)_$HOSTNAME.pcap Start Capture via cli on downstream F5 (optional) tcpdump -ni 0.0:nnn -s0 --f5 ssl host 10.46.69.31 or host 10.46.126.197 or host 10.46.126.242 or host 10.46.126.253 -w /var/tmp/app1-int.hosangit.com_tcpdump_VS_$(date +%d_%b_%H_%M_%S)_$HOSTNAME.pcap BEGIN testing application to reproduce the error, once error occurs STOP captures by issuing a CTRL + C Download .pcap file(s) Get those secrets off the F5 that you have the iRule running sed -e 's/^.*\(RSA Session-ID\)/\1/;tx;d;:x' /var/log/ltm > /var/tmp/app1-ext.hosangit.com-sessionsecrets_$(date +%d_%b_%H_%M_%S)_$HOSTNAME.pms Download the sessionsecrets (.pms file) example: /var/tmp/appi-ext.hosangit.com-sessionsecrets_$(date +%d_%b_%H_%M_%S)_$HOSTNAME.pms
-
You can use the ssldump utility to examine, decrypt, and decode SSL-encrypted packet streams managed by the BIG-IP system. The ssldump utility can act on packet streams real-time as they traverse the system, or on a packet capture file saved in the libpcap format, such as that produced by the tcpdump utility. Although it is possible for the ssldump utility to decode and display live traffic real-time as it traverses the BIG-IP system, it is rarely the most effective method to examine the voluminous and complex output of the ssldump utility. Capturing the target traffic to a file using the tcpdump utility, then decoding the file using the ssldump utility offers a better opportunity to examine the traffic in detail. Here are the steps Capture the traffic Examine the SSL handshake and other SSL traffic Examine the decrypted application data Capture the traffic Capture traffic that contains the SSL traffic you want to examine. When you capture SSL conversations for ssldump examination, follow these guidelines: If you use a browser to test, first close all existing browser windows and then use a newly-opened browser window to reproduce the issue to ensure a new session key is used. The ssldump utility cannot decrypt traffic for which the handshake including the key exchange was not seen. To write the captured packets to a file for examination with the ssldump utility, you must specify the -w option with the name of the file to which the captured data should be stored. Use the -i option to specify the interface or VLAN from which traffic is to be captured. Use the appropriate tcpdump filters to include only the traffic you want to examine. If you want to decrypt and examine the application data, you must capture the entire packet by specifying a value of 0 or the maximum size of the target packet to the -s option. Consider using the -v (verbose) option to increase the level of detail captured. Capturing traffic examples if you want to save for examination client-side traffic to a specific SSL virtual server listening on the VLAN external, the following command includes the appropriate options and filters on the virtual server's IP address and port: tcpdump -vvv -s 0 -nni external -w /var/tmp/www-ssl-client.cap host 10.1.1.100 and port 443 If you want to examine server-side traffic from one client to any pool member, use the -i option to specify the VLAN on which the servers reside, and filter on the client IP address, the server subnet, and the port on which the servers are listening. To do so, use the following command: tcpdump -vvv -s 0 -nni internal -w /var/tmp/www-ssl-server.cap host 192.168.22.33 and net 10.1.1.0/24 and port 8080 The traffic matching the specified filter is saved to the indicated capture file. The options used are: -vvv Maximum verbosity -s Snaplength (0 captures full packets) -nn Do not resolve host or service names -i Interface - can be ifname or vlan name -w Write output to file Examine the SSL handshake and other SSL traffic SSL connections are established on top of an existing TCP connection using an SSL handshake that accomplishes the following: The client and server negotiate security capabilities, such as the public-key algorithm, the symmetric key algorithm, and compression algorithms. The server transmits its certificate to the client, allowing the client to validate the identity of the server. The client and server exchange session key information. The client may also send its certificate to the server, allowing the server to validate the identity of the client. The handshake transactions consist of a number of SSL record messages. These messages can be examined by executing the ssldump utility using the -r option to specify the path and name of the tcpdump capture file to be examined. Other useful options include the following: -n Do not resolve host names. -A Print all fields (ssldump, by default, prints only the most interesting). -e Print absolute timestamps. -d Display application data, including traffic before session initiates. -M Output a pre-master secret log file (v. 11.2.0 and later) For example, the following command displays all of the SSL record messages found in the tcpdump capture file named www-ssl-client.cap: ssldump -nr /var/tmp/www-ssl-client.cap The SSL records printed by the ssldump utility appear similar to the following example: New TCP connection #2: 172.16.31.22(32866) <-> 192.168.1.8(8389) 2 1 0.0002 (0.0002) C>S Handshake ClientHello Version 3.0 resume [32]= a3 ca ad 46 95 5d 64 bb 33 ec b5 12 91 21 a3 50 d2 c0 c5 f6 67 c3 cc 9e c0 4a 71 1b 92 dc 58 55 cipher suites SSL_DHE_RSA_WITH_AES_256_CBC_SHA SSL_DHE_DSS_WITH_AES_256_CBC_SHA SSL_RSA_WITH_AES_256_CBC_SHA SSL_DHE_RSA_WITH_AES_128_CBC_SHA SSL_DHE_DSS_WITH_AES_128_CBC_SHA SSL_RSA_WITH_RC4_128_MD5 SSL_RSA_WITH_RC4_128_SHA SSL_RSA_WITH_AES_128_CBC_SHA SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA Unknown value 0xfeff SSL_RSA_WITH_3DES_EDE_CBC_SHA SSL_DHE_RSA_WITH_DES_CBC_SHA SSL_DHE_DSS_WITH_DES_CBC_SHA Unknown value 0xfefe SSL_RSA_WITH_DES_CBC_SHA SSL_RSA_EXPORT1024_WITH_RC4_56_SHA SSL_RSA_EXPORT1024_WITH_DES_CBC_SHA SSL_RSA_EXPORT_WITH_RC4_40_MD5 SSL_RSA_EXPORT_WITH_RC2_CBC_40_MD5 compression methods NULL 2 2 0.0277 (0.0274) S>C Handshake ServerHello Version 3.0 session_id[32]= a3 ca ad 46 95 5d 64 bb 33 ec b5 12 91 21 a3 50 d2 c0 c5 f6 67 c3 cc 9e c0 4a 71 1b 92 dc 58 55 cipherSuite SSL_RSA_WITH_3DES_EDE_CBC_SHA compressionMethod NULL 2 3 0.0277 (0.0000) S>C ChangeCipherSpec 2 4 0.0277 (0.0000) S>C Handshake 2 5 0.0282 (0.0005) C>S ChangeCipherSpec 2 6 0.0282 (0.0000) C>S Handshake 2 7 0.0282 (0.0000) C>S application_data 2 8 0.0289 (0.0006) S>C application_data 2 9 0.0289 (0.0000) S>C application_data 2 10 0.0292 (0.0003) C>S application_data 2 11 0.0296 (0.0003) S>C application_data 2 12 0.0296 (0.0000) S>C application_data 1 24 3.5016 (0.5372) S>C application_data 1 25 3.5016 (0.0000) S>C application_data 2 13 0.5424 (0.5128) C>S application_data 2 14 0.5429 (0.0005) S>C application_data 2 15 0.5429 (0.0000) S>C application_data 1 26 6.0378 (2.5362) C>S application_data 1 27 6.0411 (0.0033) S>C application_data 1 28 6.0411 (0.0000) S>C application_data 2 16 3.1243 (2.5814) C>S application_data 2 17 3.1455 (0.0212) S>C application_data 2 18 3.1455 (0.0000) S>C application_data 1 29 9.2325 (3.1914) C>S application_data 1 30 9.2359 (0.0033) S>C application_data 1 31 9.2359 (0.0000) S>C application_data 1 32 9.3185 (0.0826) C>S application_data 2 19 6.3589 (3.2133) C>S application_data 1 33 9.3276 (0.0090) S>C application_data 1 34 9.3276 (0.0000) S>C application_data 2 20 6.3632 (0.0043) S>C application_data 2 21 6.3632 (0.0000) S>C application_data 1 35 12.3565 (3.0289) C>S application_data 1 36 12.3682 (0.0116) S>C application_data 1 37 12.3682 (0.0000) S>C application_data The first line defines a new TCP connection which appears similar to the following example: New TCP connection #2: 172.16.31.22(32866) <-> 192.168.1.8(8080) To differentiate records belonging to different connections, each connection is numbered. The example defines connection 2. The host that sends the first SYN is printed on the left and the host that responds is printed on the right. In most cases, the SSL client is printed on the left with the SSL server on the right. In this case we have a connection from 172.16.31.22 port 32866 to 192.168.1.8 port 8080. Subsequent lines represent SSL records sent between the client and the server. The printout of each SSL record begins with a record line. It contains the connection number with which the record is associated, and the sequence number of the record itself, followed by two time stamps. The first time stamp is the time, in seconds, since the beginning of the connection. The second time stamp is the time, in seconds, since the previous record on the same connection. The next column indicates the origin of the message. Communications originating from the client are indicated in the next column by C>S (client to server), while messages originating from the server are marked with S>C (server to client). The last column indicates the type of SSL record message that was received, which can be either Handshake, Alert, ChangeCipherSpec, or application_data. Finally, the ssldump utility may print record-specific data on the rest of the line. For Handshake records, the utility prints the handshake message. For application_data messages, the utility prints the decrypted application data. By default, the ssldump utility decodes and displays useful details of some SSL record messages. For example: ClientHello Details the version, offered cipher suites, and session id, if provided. ServerHello Details the version, session_id, chosen cipher suite, and compression method. Alert Details type and level, if provided. The following example is the ssldump output for the second record on connection 2: 2 2 0.0277 (0.0274) S>C Handshake ServerHello Version 3.0 session_id[32]= a3 ca ad 46 95 5d 64 bb 33 ec b5 12 91 21 a3 50 d2 c0 c5 f6 67 c3 cc 9e c0 4a 71 1b 92 dc 58 55 cipherSuite SSL_RSA_WITH_3DES_EDE_CBC_SHA compressionMethod NULL The record was sent by the server, and it is a Handshake record that contains a Server Hello message. Examine the decrypted application data The ssldump utility must have access to either the (asymmetric) private key from the server you want to debug, or the (symmetric) pre-master secret keys. Using the pre-master secret keys allows you to examine the decrypted application data in Wireshark without having access to the (asymmetric) private key. Examine the decrypted application data using the (symmetric) pre-master secret keys Beginning in BIG-IP 11.2.0, the ssldump -M option allows you to create a pre-master secret (PMS) key log file. You can load the PMS log file into Wireshark (1.6 and later) along with the capture file and use it to decrypt the application data without having access to the server's private key. This option gives F5 Support the ability to fully decrypt sessions in the targeted capture file without revealing sensitive information about the private key. To run ssldump using the -M option to create a pre-master secret key log file, perform the following procedure: Log in to the BIG-IP command line. Capture the packet trace containing the SSL traffic (refer to the Capturing the target traffic section). To create a pre-master secret key log file, use the following ssldump syntax: ssldump -r /path/to/capture_file -k /path/to/private_key -M /path/to/pre-master-key_log_file For example, the following ssldump command reads the www-ssl-client1.cap capture file using the test.org key file to decrypt the session, and creates the PMS log file called client1.pms: ssldump -r /var/tmp/www-ssl-client1.cap -k /config/filestore/files_d/Common_d/certificate_key_d/\:Common\:test.org.key_1 -M /var/tmp/client1.pms You can now load the capture file and the PMS log file into Wireshark (1.6 and later). Note: To load the pre-master secret (PMS) key log file in Wireshark, go to Edit > Preferences > Protocols > TLS, and enter the path and file name of the PMS key in the (Pre)-Master-Secret log filename field. Examine the decrypted application data using the (asymmetric) private key To decrypt and display application data, the ssldump utility will need a copy of the private key from the server you want to debug. If you do not have the key, the application data cannot be decrypted, and you will only be able to examine and decode the SSL handshake packets. In the previous example, the ssldump command that is provided prints the application_data record type but does not display the application data itself. Since no key was provided, the application data has not been decrypted. To print the decrypted application data, use the -k option to specify the path and name of the file containing the server's private key. For example: ssldump -Aed -nr /var/tmp/www-ssl-client.cap -k /config/ssl/ssl.key/www-ssl.key Decoded application data records printed by ssldump appear similar to the following example: 3 7 1247932735.6286 (0.0031) C>SV3.1(436) application_data --------------------------------------------------------------- GET / HTTP/1.1 Accept: image/gif, image/jpeg, image/pjpeg, image/pjpeg, application/x-shockwave-flash, application/vnd.ms-excel, application/vnd.ms-powerpoint, application/msword, */* Accept-Language: en-us User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0; InfoPath.2; .NET CLR 1.1.4322; msn OptimizedIE8;ENUS) Accept-Encoding: gzip, deflate Host: 172.24.72.169 Connection: Keep-Alive 3 8 1247932735.8015 (0.1728) S>CV3.1(1540) application_data --------------------------------------------------------------- HTTP/1.1 200 OK Date: Sat, 18 Jul 2009 15:25:37 GMT Server: Apache/2.2.3 (Debian) PHP/4.4.4-8+etch4 mod_ssl/2.2.3 OpenSSL/0.9.8g mod_perl/2.0.2 Perl/v5.8.8 Last-Modified: Tue, 08 Jan 2008 22:59:06 GMT ETag: "3306ee-8be-ec750280" Accept-Ranges: bytes Content-Length: 2238 Keep-Alive: timeout=15, max=100 Connection: Keep-Alive Content-Type: text/html Locate a BIG-IP virtual server's private key The private key that the BIG-IP system uses for a virtual server is specified in the Client SSL profile applied to the virtual server. The key file locations are listed below: BIG-IP 11.x - 16.x: /config/filestore/files_d/<partition_name>_d/certificate_key_d/ For example: /config/filestore/files_d/Common_d/certificate_key_d/:Common:test.org.key_1 To determine the key used for a particular virtual server, examine the virtual server configuration to determine the name of the SSL profiles applied to the virtual server, then examine the SSL profile configuration to determine the name of the key file. Resumed TLS handshake One of the most common reasons an ssldump may not decrypt application data, is if the data is contained within a resumed TLS session. Public key operations are expensive in terms of processing power during the initial setup and key exchange. TLS specifications allow a secure shortcut by using the session_id to resume an SSL connection for which the key exchange was already performed. In situations where the SSL communication is using a resumed session, ssldump will not be able decrypt the application data unless the capture file contains the initial handshake containing the asymmetric key exchange and session_id. The ssldump utility relies on the information that is exchanged during the initial session setup to decrypt the data. The following packet capture output example shows a resumed connection: A client requesting to resume an SSL session appears similar to the following example: New TCP connection #2: 192.0.2.42(37811) <-> 198.51.100.47(443) 2 1 1296947622.6312 (0.0006) C>SV3.1(156) Handshake ClientHello Version 3.1 random[32]= 4d 4d d9 b3 c1 db aa 8e 2a fc 95 ce c0 66 dc 49 a9 49 a5 bf bc c3 3d 67 e5 ba be 77 44 44 6f 8b resume [32]= c4 44 ea 86 e2 ba f5 40 4b 44 b4 c2 3a d8 b4 ad 4c dc 13 0d 6c 48 f2 70 19 c3 05 f4 06 e5 ab a9 cipher suites TLS_DHE_RSA_WITH_AES_128_CBC_SHA Unknown value 0x45 TLS_DHE_RSA_WITH_AES_256_CBC_SHA Unknown value 0x88 TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA TLS_DHE_DSS_WITH_AES_128_CBC_SHA Unknown value 0x44 TLS_DHE_DSS_WITH_AES_256_CBC_SHA Unknown value 0x87 TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA TLS_DHE_DSS_WITH_RC4_128_SHA Unknown value 0x90 Unknown value 0x91 Unknown value 0x8f Unknown value 0x8e TLS_RSA_WITH_AES_128_CBC_SHA Unknown value 0x41 TLS_RSA_WITH_AES_256_CBC_SHA Unknown value 0x84 TLS_RSA_WITH_3DES_EDE_CBC_SHA TLS_RSA_WITH_RC4_128_SHA TLS_RSA_WITH_RC4_128_MD5 Unknown value 0x8c Unknown value 0x8d Unknown value 0x8b Unknown value 0x8a compression methods NULL A server agreeing to resume the session returns the ServerHello with the same session_id as displayed below: 2 2 1296947622.6313 (0.0001) S>CV3.1(74) Handshake ServerHello Version 3.1 random[32]= 19 21 d7 55 c1 14 65 63 54 23 62 b7 c4 30 a2 f0 b8 c4 20 06 86 ed 9c 1f 9e 46 0f 42 79 45 8a 29 session_id[32]= c4 44 ea 86 e2 ba f5 40 4b 44 b4 c2 3a d8 b4 ad 4c dc 13 0d 6c 48 f2 70 19 c3 05 f4 06 e5 ab a9 cipherSuite TLS_RSA_WITH_RC4_128_SHA compressionMethod NULL The previous example is a resumed session; the client sends a ClientHello that includes a resume[], the server responds with a ServerHello that contains the same session_id the client sent. The server is under no obligation to resume a session. This is specified within the TLS 1.0 specification RFC2246: session_id This is the identity of the session corresponding to this connection. If the ClientHello.session_id was non-empty, the server will look in its session cache for a match. If a match is found and the server is willing to establish the new connection using the specified session state, the server will respond with the same value as was supplied by the client. This indicates a resumed session and dictates that the parties must proceed directly to the finished messages. Otherwise this field will contain a different value identifying the new session. The server may return an empty session_id to indicate that the session will not be cached and therefore cannot be resumed. If a session is resumed, it must be resumed using the same cipher suite it was originally negotiated with. To avoid this situation, you can use one of the following methods: Temporarily disable the SSL session cache in the Client SSL profile by disabling the Renegotiation option. Disabling the SSL session cache causes the BIG-IP system to perform a full SSL handshake for each connection. Force the client to start a new session. Here is a nice video / tutorial that you may also find helpful And this video might be helpful as well
