Workshop inInformation Security: Building a Firewall within the Linux Kernel0368-3500-34, Spring 2015 Lecturer: Eran Tromer Teaching assistant: Roei Ben Harush Student: Lior Bomwurzel 

1. Workshop in
Information Security:
Building a Firewall within the Linux Kernel
0368-3500-34, Spring 2015
Lecturer: Eran Tromer
Teaching assistant: Roei Ben Harush
Student: Lior Bomwurzel

2. General description
• kernel module that inspect packets using Netfilter-
each packet that traverses the NF_INET_FORWARD
stage will be inspected by the ip headers,TCP flags,and
the data.
• stateless packet inspection with static rule table for
packet that are not part of a open connection
• stateful packet inspection for TCP packets we
inspect that the TCP flow and the protocols (HTTP and
FTP) are ok.
• Vulnerability check- each packet of an open
connection will be checked for DLP for C
code,Webster,Zabbix vulnerabilities

3. stateless packet inspection
• each packet that is not a part of a open connection will be
inspect to find if there is a rule that match its headers of ip
src/dst port src/dst and protocol and direction.
• if there is a matching rule the packet reason will be logged
as the rule number and the action accept the packet will be
with accordance of the rule.
• if the packet match a rule that accept it, and the packet is
with protocol TCP, we create a new dynamic connection
and we inspect its flow in the stateful packet inspection
• if there isn't a matching rule the packet will be dropped
with the reason REASON_NO_MATCHING_RULE

4. stateful packet inspection
I define a state machine that follows the
protocols of the connection and the state of the
protocols.
For new connection (first packet of TCP that
accepted by the stateless inspection) I open new
dynamic connection ,direction of the connection
is defined by the first side who started the
connection ,first the connection protocol is
defined as TCP

5. • State TCP_SYN (0)-first try to establish tcp connection, (handle in
handle_static_inspection) if there is SYN flag and the connection is
approved in the static rule table, we open new connection. we open
timer of 25 seconds to end of the handshake.
• State TCP_SYN_ACK (1)- second send SYN ACK
• State OPEN_CONN (2)-first send ACK , we close the timer and by that
we treat the connection as finished the handshake and until the end of
the session it will stay open.
• stateEND_SERVER (3),stage END_CLIENT (5)- if packet comes with FIN
flag , and the state of the packet is above OPEN_CONN we forward
the state of the connection to one of the stages (3/5 depend from
which side the FIN arrived)
• state4,6(logical stages) - packet arrived from the other side with the
FIN flag, we open the timer again and by that we let the last ACK of the
tcp termination to arrive,if its arrived we delete the connection, if it
doesn't we delete the connection anyway after 25 second.
• state READY_TO_NEW (-1) -when we know that a packet of a new
connection is going to come with a SYN flag

6. • FTP-1)the server need to send from port 21 data with 220 (server waits for
open connection) we forward the state to be FTP_READY_TO_CLIENT. And
the protocol to be FTP_PROT
2) we validate the connection as successfully established by that the
server send 230 in the data ,we forward the state to be
FTP_ACCEPT_CLIENT, 3)in that
state we parse the data to find PORT command form the client in order to
open new connections for the receiving of the data.
4) if we find PORT command we open new
dynamic connection on the right ports and ips as the protocol define ,the
state of the connection READY_TO_NEW (-1) and the protocol will be
FTP_PROT
• HTTP-for defining a session as HTTP the client need to send to port 80 data
with “GET” string we then forward the connection to be in state
HTTP_GET_REQUEST. in that state we parse the data for finding http
redirect ( “HTTP/1.1 3”) means we need to open new connection, I
preparing place in the dynamic connections in the form of source ip and
port are any(to let the fw the ability to defend on several hosts), and the
destination is like the port and ip we got in the http redirect,the protocol is
HTTP_PROT, the state of the connection is READY_TO_NEW (-1) .after the
first match of the rule I replace the port and the ip to be as the source port

8. General concept
• the DLP for C code inspection is measured
between ratio of number of words in the
packet and the weight defined
• if the weight is higher than the number of
words, the packet will be dropped, and logged
as DLP, and the connection will be deleted
• each weight form the weight rules will be
multiple by the number of brackets (“ { }”)
surround it +1

9. Weight rules
1.
I search for patterns #include and #define in the following manner,
#include -have to be with 2 words, and ends with .h or .c at end of the second word
#define- have to be with 3 words.
I weight each #include and #define as the number of words they have multiply by 5
the code of this rule is found in weight_macros function
2.
each line with the pattern print#(#“#”); or scan#(#“#”); will be count as the number of words the
pattern took from start to end.
If there are inside the pattern %d %s /n I increase the weight by one for each
the code of this rule is found in weight_known_pattern function
3.
Each line with the pattern if#(#) for#(#;#;#) while#(#) will be count as the number of words the pattern
took from start to end.
If there are inside the pattern == <&& || > I increase the weight by one for each
the code of this rule is found in weight_flow function
4.
I weight each “;” I found as 1 and each “->” as 2

10. DLP inspection example
2*5 #include 2 words and the last with .h
0 no .h or .c at last word
0 #define with more then 3 words
3*5 define with 3 words
0 not in the right pattern
2 ->
5+3 (number of words + special chars)
0 no ; at end
1*2 in{} and one word
0
2*3 in {{ }} and equal 2
0
(4+3)*2 in {} , 4 words+3 special chars
0
Sum=10+15+2+8+2+6+14=57
Number of words=31
The packet will be dropped

11. DLP inspection example

13. Reply on normal sized url that not
found

14. Code flow

15. Vulnerability

16. Flow in ollydbg

17. 64 size url

18. Buffer overflow

19. Vulnerability 2

20. Code flow ollydbg

21. Buffer overflow

22. FW inspectoin
if packet came with port 80 and with the GET
request ,I inspect the packet that the requested
url length is last then 64 chars because of the
Webster vulnerability, else I dropped the packet
with reason WEBSTER (enum -8) and the
connection will be deleted

23. Fw logs on detect

25. Zabbix today

28. previous zabbix

29. Metasploit code

30. Metasploit explit

31. Fw inspection
• iftheTCPdatacontainsthefollowingstring:
“GET/zabbix/httpmon.php?applications=“ IinspectthenextcharstovalidatethattheyrepresentanumberbecauseofthisiswhatZabbixserver
expecttoget,
elsethepacketwillbedroppedandloggedasZABBIX(enum-10),
andtheconnectionwillbedeleted.

32. FW log