How to accept specific protocol and drop the other about ndpi-netfilter

[GreatBahram]

I think the problem is when we drop all the packet by default and then try to accept some specific protocols, literally, iptables drop all SYN packet. What I mean is this iptables does not allow any connection to be established. Therefore, it drops those specific protocols as well.
Am I right? is there any solution to solve this problem?

[GreatBahram]

It seems someone has been reported this before #22
But I don't wanna use TrafficController or something else like that. How can I solve this problem? Any idea?

[rightkick]

It is usually intended to be used as a blacklist approach and not whitelist, hence the drop examples. Having said that, you can easily test your scenario to see if it works: accept skype first then add a rule to drop everything else. Since the dpi match might need some packets to first flow back and forth before making the verdict this approach probably will have issues. Alex

…

On Tue, May 29, 2018, 11:17 Bahram Aghaei ***@***.***> wrote: It seems someone has been reported this before #22 <#22> — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#71 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AOedfICH_-D_jQ2q2-tCZmNxSRjZjFTZks5t3QQfgaJpZM4UP2Qf> .

[GreatBahram]

@rightkick
Actually in this scenario order does not matter, I've tested, the guy in issue #22 had also tested that too.

[rightkick]

Hi Bahram, Order is important. If you first drop then caput, packets is dropped.

…

On Wed, May 30, 2018, 12:28 Bahram Aghaei ***@***.***> wrote: @rightkick <https://github.com/rightkick> Actually in this scenario order does not matter, I've tested, the guy in issue #22 <#22> had also tested too. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#71 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AOedfI1Ufs24ozwy75JgPa4DLkyZfo2bks5t3mZKgaJpZM4UP2Qf> .

[elico]

@GreatBahram if you want skype to be allowed and all others to be disallowed you should start by making sure that you distinguish between tcp and udp connections and streams.
On a tcp connection it would not do any harm to allow the first 3 way handshake.
Once you get the rules to let you this work then you would be able to try and maybe make some list of conditional rules that will eventually allow skype and couple other necessary services like Microsoft.

The order of the rules is crucial and also the direction of it...
A DROP policy at #22 is not smart in any way possible and I believe you should not take an example from it.
There specific very basic services that you must allow for the setup to work....
Drop here a snapshot of iptables-save and we might be able to try and help you to move one step forward towards a basic solution.
Also notice that allowing all ESTABLISHED,RELATED connections is nice but doesn't fit for all scenarios of nDPI.
I can point out that nDPI rules probably will apply on the first 16kB of the connection and later on it's history so this might be a shortcut when specific connections should not be inspected more then they needed to be.

It's crucial you will try to see and understand what the Skype nDPI module inspects in a connection to identify it as a SKYPE one.
If you do not understand these basics you might waste lots of hours.

[GreatBahram]

@elico
Thanks for your explanation. I understand what you're saying. But the problem is Skype is just an example, I don't wanna do a lot these work by creating bunch of iptables rules. About #22 I agree with you it can't be useful.
I'm searching for something to negate ndpi-netfilter rules with the lowest legwork. I want to specify some protocols and application, they can't different protocol and application. Then ndpi-netfilter allows these items and about the unknown ones just DROP them.

[elico]

@GreatBahram a resolution or a solution to your need\desire will depend on the resources and the purpose.
ndpi-netfilter is a very "generic" solution which is an add-on to a very targeted solution.
iptables is a firewall and the kernel is giving developers the access to resources which they normally need such as enhanced stdin/out/err and/or running and creating tools.
There are solutions out there in the market for your requirement but these are all either a full fledged proxy solution that run's mainly on CPU or a specially crafted kernel which also... uses mainly CPU.

Indeed ndpi-netfilter provides some of a full proxy features which for some deployments is enough.
From what I have seen there are couple very good products in the market which provides a better ACL logic then what raw iptables offers.
Any busy IT business that I know uses products from:

• Forti(Net\Gate)
• Palo Alto
• Huawei

and couple other vendors which some are local and some are global.

The main issue with netfilter/iptables/ipchains logic is that the ACL is "first HIT" while in real applications the connection/stream is dynamic and a generic solution can never replace that.
This is one of the reasons many security products vendors requires from the client to acquire "extra support" or what ever name they give a subscription.
Any dynamic product require updates and development since the world is moving forward.
Couple years ago HTTP/1.1 was the cutting edge of web development while even at the time you could have seen a connection that looks like HTTP/1.X works like HTTP/X but once you push the connection into a device that only able to handle HTTP/X the connection was categorized as "UNKNOWN".

The basic rule of thumb is that "a proxy should be able to absorb enough details for a verdict".
I have tried in the past to configure Suricata but I have better things to do with my free time then trying to understand some twisted minds.

[GreatBahram]

@elico
Thank you dude a lot. You have clarified my doubts. The last thing I want to know is that have you ever worked with OpenAppID? I think in this case, maybe it's a better choice, isn't it? I have also noticed pfSense uses that with their firewall. I think maybe that's a better choice.

[elico]

@GreatBahram Depends on the system.
To some OpenAppID is good and other don't due to licensing and other things.
If you are managing to use Snort with OpenAppID I think it is good for the 1Gbit network and below while above needs testing.