Help filtering HTTP_responses by IP address


#1

Hi, I need some help nesting IP address filtering into a larger trigger. I will paste the actual, functioning, source trigger which is built to pull packets based on an xml error, at the bottom. But the full trigger isn’t important. I want to understand the logic of using IP filtering with multiple events.

Current Trigger flow:

If [Http Request]
Then [store]

If [http response]
If[response code = error]
Then [packet capture]

The above is the basic logic flow (skipping the much deeper flow store xml stuff: not important to the question). If I want to filter those by the IP, where does that logic go? It’s kind of tricky because the request is the client, the response is the server…

So… if I put the IP filtering on the request but not the response, I still get packets but they don’t have the needed IP (probs because the actual “then’s” on the response don’t have the Ip filtering. But, if I put the IP filtering in the Response, I get nothing (possibly because no active traffic). I also want to check how does the server/client thing work? I know sometimes things devices can get confused and always think the “sender” in a single conversation is the server. Is that the case here too, or will Extra Hop still recognize that the response is coming from the “server”. Can I even filter a server response by client IP? Thanks for the help guys, basic logic questions below:

So do I need (this pulled packets, but didn’t filter by IP):
If [Http Request]
If [client IP]
Then [store]

If [http response]
If[response code = error]
Then [packet capture]

Or (this pulled no packets):
If [Http Request]
Then [store]

If [http response]
If[response code = error]
If [client IP]
Then [packet capture]

Or should any of these be ‘server’ not client?

Thanks again. Source trigger:

if (event == “HTTP_REQUEST”){
Flow.store.httpQuery = HTTP.query;
Flow.store.httpHead = HTTP.headersRaw;
Flow.store.ClientPayLoad = HTTP.payloadText;
}

if (event == “HTTP_RESPONSE”){
if (HTTP.statusCode >= 200){
debug(“Query:” + Flow.store.httpQuery);
debug("ReqHeaders: " + Flow.store.httpHead);
debug(“Req Payload:” + Flow.store.ClientPayLoad);
debug("Resp Headers: " + HTTP.headersRaw);
debug("Resp Payload: " + HTTP.payload);
debug(“Resp Payloadtext:” + HTTP.payloadText);
if (HTTP.payload.toString().indexOf(“500.113”) > -1){
debug(“Found 500.113”);
Flow.captureStart(“500_113_errors”, {maxPackets : 500}) ;
}
}}

***Appended: Just noticed there is one similar question in “general” (not trigger, which is why I missed it), but I"m submitting anyway as the flow of the trigger is completely different and I’d like to understand more about using client IP vs server IP and where in the flow to use them. Thanks


#2

Hi @krisblouch! When I do a precision pcap due to a specific status code, I keep my logic in the RESPONSE of the event.

If this trigger is meant to ONLY fire the capture, then I would add the IP filtering first before checking for the status code. This will prevent the trigger from firing unnecessarily from other flows. However, doing it either way will still give the end goal.

I’m assuming you already enabled the packet bytes to buffer for packet capture in your trigger, or else, you probably wouldn’t get anything. But, I’m not sure why you are getting nothing on the response side of the event. The Flow is still the same, whether the capture is fired on REQUEST or RESPONSE. Can you remove your maxPackets option (then you’ll just grab everything in that flow).

if (event === "HTTP_RESPONSE") {
    if (Flow.server.ipaddr == "1.2.3.4") {
        if (HTTP.statusCode >= 200) {
            if (HTTP.payload.toString().indexOf("500.113") > -1) {
                Flow.captureStart("500_113_errors");
            }
         }
    }
}

Also, I see you are using both HTTP.payload and HTTP.payloadText. The payloadText is deprecated, and it’s going to be best practice in the future to use HTTP.payload.toString().


#3

Thanks APAX!

I did find that the reason it wasn’t filtering was because there wasn’t enough traffic (I created a really simple trigger and tried it in all states in a known traffic flow). It is the “client” on the response, just for anyone else who was wondering.

And thanks for the tip on the depreciated metric!