Extend FirewallCallBack To support 3 states

[Hesham-Elbadawi]

I have one suggestion regarding the FirewallCallBack which will add an extra feature to the Filtering Engine.
Currently the behavior is return true for applications you would like the engine to filter (this makes the application packet undergo diversion of packets and therefore gets redirected to the listener port) while return false and the filter will completely ignore it and it's packet will not reach the filter but rather get re-injected to the stack.
My suggestion is have FirewallCallBack return ALLOW, INSPECT or DROP, then the behavior would be if allowed then just treat is as false in the current behavior, if INSPECT then treat is as ALLOW, otherwise if DROP then do not re-inject the packet into the network stack and just continue;

Also the callback will have to return an ordinal instead of the current bool and some changes are required.

I believe this can present application level blocking for HTTP(s) access as well which currently is not available.

Kind Regards,
Hesham

[TechnikEmpire]

@Hesham-Elbadawi Thanks for the suggestion. I suppose that acting as a protocol specific firewall would sort of fall under the banner of "filtering". My concern though is that we're venturing into a new territory and sort of beginning to act as a firewall on the machine when we really are not. The idea behind the callback was to enable users to ensure that the engine wasn't usurping the role of whatever firewall is already installed, and by changing this behavior we're leaning hard in the other direction instead.

I'll have to think about this. Either way thanks for the ticket/suggestion.

[Hesham-Elbadawi]

no problem, will wait and see what you decide.

…

On Tue, Sep 19, 2017 at 5:26 PM, Jesse Nicholson ***@***.***> wrote: @Hesham-Elbadawi <https://github.com/hesham-elbadawi> Thanks for the suggestion. I suppose that acting as a protocol specific firewall would sort of fall under the banner of "filtering". My concern though is that we're venturing into a new territory and sort of beginning to act as a firewall on the machine when we really are not. The idea behind the callback was to enable users to ensure that the engine wasn't usurping the role of whatever firewall is already installed, and by changing this behavior we're leaning hard in the other direction instead. I'll have to think about this. Either way thanks for the ticket/suggestion. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#123 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AGy0WZ5usY-L_m5LlvrnZGdL7ALDLDCcks5sj90NgaJpZM4Pcj_3> .

[Hesham-Elbadawi]

Just for further consideration, the change will not break the idea of the user respecting already installed firewalls since the option to ALLOW without inspection will still available. Maybe provide the user in documentation a hint that a necessary check for other FW applications is required not to break any expected behavior on the device for these applications. Also i think the application became a firewall the moment it was decided to use WFP to reroute packets, at least i think of it as an HTTP(s) firewall more than a filter (since filtering is now external) so it should be up to the user to decide the functionality now. Just for extra consideration. Regards, Hesham On Tue, Sep 19, 2017 at 5:27 PM, Hesham Saad El Dien <[email protected]> wrote:

…

no problem, will wait and see what you decide. On Tue, Sep 19, 2017 at 5:26 PM, Jesse Nicholson ***@***.*** > wrote: > @Hesham-Elbadawi <https://github.com/hesham-elbadawi> Thanks for the > suggestion. I suppose that acting as a protocol specific firewall would > sort of fall under the banner of "filtering". My concern though is that > we're venturing into a new territory and sort of beginning to act as a > firewall on the machine when we really are not. The idea behind the > callback was to enable users to ensure that the engine wasn't usurping the > role of whatever firewall is already installed, and by changing this > behavior we're leaning hard in the other direction instead. > > I'll have to think about this. Either way thanks for the > ticket/suggestion. > > — > You are receiving this because you were mentioned. > Reply to this email directly, view it on GitHub > <#123 (comment)>, > or mute the thread > <https://github.com/notifications/unsubscribe-auth/AGy0WZ5usY-L_m5LlvrnZGdL7ALDLDCcks5sj90NgaJpZM4Pcj_3> > . >

[TechnikEmpire]

I'll consider it. I have planned additions that will make it act as a firewall and IPS/IDS but these changes are still a long ways away. At that time I'd have to rebrand this to be more than a HTTP filtering engine, but there's dozens of other things that have my attention for some time. Plus there's other considerations that are legal in nature (I'd be in effect making this a security product which brings export control questions up) and if I'm going to venture into security land I'd want an expert at least consulting on it.

[Hesham-Elbadawi]

Can i get your email because some of the stuff i write in the issue tracker are not meant to be there and would better be handed over to your email. I will delete the last entry.

…

On Tue, Sep 19, 2017 at 5:45 PM, Jesse Nicholson ***@***.***> wrote: I'll consider it. I have planned additions that will make it act as a firewall and IPS/IDS but these changes are still a long ways away. At that time I'd have to rebrand this to be more than a HTTP filtering engine, but there's dozens of other things that have my attention for some time. Plus there's other considerations that are legal in nature (I'd be in effect making this a security product which brings export control questions up) and if I'm going to venture into security land I'd want an expert at least consulting on it. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#123 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AGy0WcDRsudTu8poq4EQ-5rmojxwfKNvks5sj-EqgaJpZM4Pcj_3> .

[TechnikEmpire]

@Hesham-Elbadawi [email protected]

[TechnikEmpire]

I'm in Canada and there are some really stupid laws around exporting software. Fortunately and conveniently, exporting the USA typically lifts all of these restrictions (github = USA as far as I'm concerned). I need to read over the export control list again because there's a stupid remark in there about "security software" so if I start venturing into security land I need to make sure I don't get entangled in some bureaucratic web of nonsense.