I want to filter tcp packets depending upon the payload. is it possible.?
 

Hi ,

I am trying to implement SCADA aware firewall in RHEL 4 (2.6.16.14). Here using modbus/TCP for communcation.Here modbus packet is attached in the payload of tcp.Required kernel module for modbus is added in the netfilter.Iptables rules are added to filter undesirable modbus packets. here i face a problem :- Once a modbus packet is dropped , none of the packets from the client reaches the server. Client resends the dropped tcp packet(in the server) again and again for the ack. if no packets dropped no problem at all.Problem occurs only after when drop a packet from client. Here firewall and modbus server is in the same machine. i tried the same with firewall and server as separate machines, but again the results are same.

When i check the connection status in the server using netstat -a , is ESTABLISHED.

So is it possible to drop a tcp packet in an ESTABLISHED connection state of TCP.?

Please help me to solve this problem.

Well TCP connections are streams of data, it doesn't make sense to disrupt data in the middle of the connection at a per packet level. Some systems will permit interception and rewriting of TCP data, but this is still at a higher level than a per packet thing. As you're seeing, if you remove a packet, then TCP's job is to resend it, that has to happen.

Hai,
Thanks for the reply.
Is it possible to modify payload of a tcp packet using netfilter.?

I think if an undesirable packet arrives ,firewall will change the payload of that packet to a default value.

Generally speaking there are two opposing views: one states it is OK to normalize or modify user input to allow further processing, the other says user input that does not conform to specifications should be discarded, making the user responsable for "getting things right". In the first one the developer tries to think from a users perspective, trying to make the ride as smooth as possible by interpreting things and mitigate errors. This causes more (interpretation) errors, overhead, kludgy workarounds and the approach is fundamentally flawed regardless because user input should never be trusted anyway. Making the user responsable for "getting things right" avoids all of that and should be the default way to do things.

I'm saying this because from what I've read sofar I am quite certain you are trying to fix the right solution with the wrong problem. If you want MBAP (Layer 7) dissectors please have a look at Digitalbonds SCADA IDS Preprocessors, Searching File Content with Nessus the other SCADA-related stuff they provide, DHS CSSP and sans.org best practice whitepapers instead.