Following on from the last post lets quickly see how we go using TCPDUMP with reth interfaces;
Using the same methodology as in my last post...I.e having separate input and output filters and applying those filters on the reth interface, I find that the SRX generates 2 files, one for the reth and one for the (I assume active) physical interface.Eg.
-rw-r--r-- 1 root wheel 1878 Apr 27 18:15 dumptest.fe-0.0.2
-rw-r--r-- 1 root wheel 1298 Apr 27 18:15 dumptest.reth0
Looking at the 2 files we can capture what we want however each file only shows the traffic in one direction. So you need to look at both files to see everything that is going on. For sure not too handy.
At any rate in the Junos release notes (Branch SRX) they state..
Sampling features like J-FLow, packet capture, and port mirror on the reth interface are not supported.
And thats from 12.1! So its not a limitation that will disappear soon if ever.
If your insistent and put the filters on the physical interface instead of the reth like this ..
fe-0/0/2 {
fastether-options {
redundant-parent reth0;
}
unit 0 {
family inet {
filter {
input INGRESS-TCPDUMP;
output EGRESS-TCPDUMP;
}
}
}
}
Well your out of luck there as that will again only show the one direction. Not recommended!
So Is there another way to see whats going on at a very raw level on the firewall?
Yup..Hello traceoptions.Setup
Lets consider the situation where we made a rule in
a firewall but the traffic is not going through. Could be a lot of reasons why.
But first thing I might like to know is "Is the traffic even hitting the
firewall". If not then it could be a host
issue or something to do with the network connected to or beyond the firewall but
not including the firewall itself.
If we see the traffic is hitting the firewall we better take a closer look at the firewall setup.
1) First choose which type of traceoption you want to run and setup the file to capture that information.
blogger@LEFTY# set security flow traceoptions file trc-sec-flow files 3 size 30k world-readable
So here we are setting the "security flow" traceoption type which will go into a file named trc-sec-flow (Located in /var/log/), there will be a max of 3 files (The current capture and 2 archives), the size of the capture file will be 30k and it will be readable by eveyone.
2) Set the traceoptions flag. I.e the type of capture you want to make. For "security flow" we have this choice to make..
blogger@LEFTY# set security flow traceoptions flag ?
Possible completions:
all All events
basic-datapath Basic packet flow
packet-drops Packet drops
[edit]blogger@LEFTY# set security flow traceoptions flag basic-datapath
And we select the basic-datapath choice to start with.
As soon as the above was committed I check to see if the files were there.
blogger@LEFTY> file list /var/log/trc*
/var/log/trc-sec-flow
/var/log/trc-sec-flow.0.gz
/var/log/trc-sec-flow.1.gz
Wow that was quick! Ok so the point here is that traceoptions will capture an overwhelming amount of information very quickly so you REALLY want to use filters with them.
3) Set the traceoption filter
blogger@LEFTY# set security flow traceoptions packet-filter p-f-1 ?
Possible completions:
+ apply-groups Groups from which to inherit configuration data
+ apply-groups-except Don't inherit configuration data from these groups
destination-port Match TCP/UDP destination port
destination-prefix Destination IP address prefix
interface Logical interface
protocol Match IP protocol type
source-port Match TCP/UDP source port
source-prefix Source IP address prefix
[edit]blogger@LEFTY# set security flow traceoptions packet-filter p-f-1 destination-prefix 172.20.123.2/32
blogger@LEFTY# set security flow traceoptions packet-filter p-f-1 source-prefix 192.168.56.50/32
Above we can see the filter options and we choose to filter from a specific source to a specific destination.
Below is all the above config together in hierarchical format.
blogger@LEFTY> show configuration security flow traceoptions
file trc-sec-flow size 30k files 3 world-readable;
flag basic-datapath;
packet-filter p-f-1 {
source-prefix 192.168.56.50/32;
destination-prefix 172.20.123.2/32;
}
Examining the log
I found that when I had the file set to 30k, the trace captured so much info on the initial packet that the SYN packet was in the first archive...trc-sec-flow.0.gz
So increased the size if the capture file to 256k. Default by the way is 128k.
Lets look at the captured info with reference to the SRX flow diagram. We will examine the output with and makes comments where appropriate.
First note that Packet filters may stop or even bypass flow module.A screen may also stop the packet getting to the flow module as well. So check those features or logs referencing those features if your flow based forwarding isn't processing the traffic you expect it to.
blogger@LEFTY> show log trc-sec-flow | trim 42
Note: Trim 42 gets rid of this common information from every line of output - Apr 29 16:46:09 16:46:09.974493:CID-0:RT
Trim 16 would get rid of just the date but leave the time.
A) Match Session?
:<192.168.56.50/1078->172.20.123.2/22;6> matched filter p-f-1:
Here it sees the flow matching the traceoption filter we previously set
:packet [48] ipid = 5980, @423ff39a
:---- flow_process_pkt: (thd 1): flow_ctxt type 13, common flag 0x0, mbuf 0x423ff180, rtbl_idx = 0
: flow process pak fast ifl 69 in_ifp vlan.0
The packet arrived on interface vlan.0
: vlan.0:192.168.56.50/1078->172.20.123.2/22, tcp, flag 2 syn
Its a syn packet
: find flow: table 0x494f3dd0, hash 23119(0xffff), sa 192.168.56.50, da 172.20.123.2, sp 1078, dp 22, proto 6, tok 6
Tries to find a flow matching all the above information
: no session found, start first path. in_tunnel - 0, from_cp_flag - 0
Its a new flow and so first path processing starts
:self ip check: not for self (address=ac147b02)
Check to see if the packet is addressed to itself
: flow_first_create_session
Creates the session
B) Screens - I don't see anything in the security flow output relating to screen checking.
The Screens have there own traceoptions so we will check that later.
C) Static NAT / Dest NAT
: flow_first_in_dst_nat: in <vlan.0>, out <N/A> dst_adr 172.20.123.2, sp 1078, dp 22
: chose interface vlan.0 as incoming nat if.
:flow_first_rule_dst_xlate: DST no-xlate: 0.0.0.0(0) to 172.20.123.2(22)
No destination nat to be performed.
D) Route Lookup
:flow_first_routing: call flow_route_lookup(): src_ip 192.168.56.50, x_dst_ip 172.20.123.2, in ifp vlan.0, out ifp N/A sp 1078, dp 22, ip_proto 6, tos 0
Doesn't yes know the destination interface to route to.
:Doing DESTINATION addr route-lookup
Performs the destination address lookup
: routed (x_dst_ip 172.20.123.2) from trust (vlan.0 in 0) to fe-0/0/0.0, Next-hop: 172.20.123.2
Figures out how to route the packet to the destination
E) Policy
: policy search from zone trust-> zone untrust (0x0,0x4360016,0x16)
Having previously identified the ingress and egress interfaces they are now matched to zones for a policy lookup.
: app 22, timeout 1800s, curr ageout 20s
Default timeout for the ssh connection
: packet dropped, denied by policy
The packet is dropped! But it doesn't say by which policy.
So back to the original premise, we can see from the above traceoption that the packet did hit the firewall but was dropped by policy.
Lets now compare, for reference, what a permitted flow looks like.
Its all the same up to step E) from above so we will take it from there again
E) Policy
: policy search from zone trust-> zone untrust (0x0,0x45e0016,0x16)
Having previously identified the ingress and egress interfaces they are now matched to zones for a policy lookup.
: app 22, timeout 1800s, curr ageout 20s
Default timeout for the ssh connection
F) Source NAT
:flow_first_src_xlate: nat_src_xlated: False, nat_src_xlate_failed: False
:flow_first_src_xlate: src nat returns status: 1, rule/pool id: 1/32770, pst_nat: False.
Source nat will happen (Status:1)
: dip id = 2/1, 192.168.56.50/1118->172.20.123.1/57032
DIP! Whats that doing here? We tore open the heart of Junos and found ScreenOS DNA - hehe.
: choose interface fe-0/0/0.0 as outgoing phy if
The packet will go out via the above interface.
Compare the above Source nat section to where a flow where there is no source nat..
:flow_first_src_xlate: nat_src_xlated: False, nat_src_xlate_failed: False
:flow_first_src_xlate: src nat returns status: 0, rule/pool id: 0/0, pst_nat: False.
: dip id = 0/0, 192.168.56.50/1123->192.168.56.50/1123
A quick way to see if a packet hit the firewall would be to just search for a syn in the log..
blogger@LEFTY> show log trc-sec-flow | match syn
Apr 29 16:46:07 16:46:06.1022694:CID-0:RT: vlan.0:192.168.56.50/1078->172.20.123.2/22, tcp, flag 2 syn
Apr 29 16:46:09 16:46:09.974493:CID-0:RT: vlan.0:192.168.56.50/1078->172.20.123.2/22, tcp, flag 2 syn
Apr 29 19:05:59 19:05:57.1926516:CID-0:RT: vlan.0:192.168.56.50/1106->172.20.123.2/22, tcp, flag 2 syn
Looking at all of the above, it seems to me that traceoptions are the equivalent of ScreenOS flow filters rather than ScreenOS Snoop.
No comments:
New comments are not allowed.