Google Summer of Code 2009: Student applies to create a Better IPTablesManagement Tool

[Till Kamppeter]

Hi,

at the Linux Foundation we got the application shown below.

The student wants to create a better IPTables management tool. I do not 
know whether the kernel developers are really the best people to mentor 
him, but I have also no idea who else could mentor him and whether he 
should p[erhaps post the same application at another org and if yes, 
where. I appreciate your help very much.

The student did not include his e-mail address in the application. To
contact him directly you need to apply as a mentor on
http://socghop.appspot.com/ (this does not oblige you to actually mentor
a student) and select the Linux Foundation (organization link ID: LF) as 
the mentoring organization. If you do so, you can still be a mentor or 
admin at other orgs in parallel but not apply as a student any more. 
Note that student application deadline is TODAY, Friday, April 3, noon 
PDT or 7pm UTC, so contact him well before that date if you want to 
recommend him to apply at an additional org.

   Till

-------------------------------------------------------------------------

Title:  	 Proposal For Better IPTables Management Tool
Student: 	ashish sinha
Mentor: 	No mentor assigned
Possible Mentors: 	None
Abstract:
It focuses on helping the user to perceive what a specific chains of 
rules in a specific table does to a usr's pkt. It helps the user to 
modify the chains according to his wish . the first req. could be 
fulfilled with incorporation of RuleCheckingEngine into the tool. The 
second would require us to chk for the contradictory /already existing 
rules. There's an attempt to make the tool intelligent through 
autogeneration of speclzed rules.
Content:




         I am Ashish Sinha , currently pursuing graduation course 
(Bachelor in Infrmation Technology) from Indian Institute Of Information 
Technology, Allahabad,India. most of the coding is done on the linux 
platform.However the linux distros keep changing.Currently I am using 
Backtrack Linux 4.0 . As far as the hardware is concerned , its based 
upon Intel x86 architecture T2250 @ 1.73Ghz whith 1 Gb physical memory.I 
have been coding  in C/C++ since  my high school days . In my graduation 
years, I have gained an expertise over Java 2. Most of the coding is 
done in  Java becauses of its ease of use and portability features. As 
fas as java projects are concerned ,   I have successfully made an 
Online Examination Tool for my university which helps in faculties in 
uploading the test paper and its time and date . The registered student 
are sent the notifications automatically and the exam takes place on the 
agreed date and time with questions soretd in random order foe each 
login.Me along with my teammates have been successful in making a Cross 
Lingual Information retrieval Engine . It helps the user to query and 
search in different languages. One of my career milestones ,is the 
graphics project in C++  using OpenGL API . It has been recommended for 
a copyright. Right now, the application for the same has been filed.  I 
have successfully subscribed to the mailing list with my email id: 
imsinha@xxxxxxxxxx

I have been following  GCC open source projects during my graduation. 
One of my projects was  about enhancing the GCC compiler to detect the 
vulnerabilities in a C Code through static source code analysis .It 
mainly concentrates upon the Taint Analysis and Value Range propagation 
algorithms to detect the vulnerable use of some dubious functions in C 
like strcpy(), strcat(), memcpy() ,malloc(),calloc(),realloc() etc.   My 
tool would be able to detect errors like arithmetic overflow, stack 
overflow , heap overflow and out of bounds access in an array. I am 
taking the SSA Tree Web generated by the compiler as the input and then 
applying the Pattersonâs Value Propagation and Taint Analysis Algorithms.
I had also worked as a  project coordinator for  â Application Design 
Tool  â which is soon to be released as an open-source for further 
development .Its a university project from software-engineering 
helpdesk. This tools aims to capture the software engineering process 
which a designer follows while making his apps . It helps in maintaining 
the documentation of the project through version controls and also 
detects the changes which have been made to the source when compiled , 
so that it could be supported by the appropriate documentation. This 
habbit of maintaining documentation would help the new developers to 
track the progress and reverse engineer it more quickly. I intend to 
develop a tool for BetterIp table management . The tool focuses on 
helping the user to perceive what a particular chains of rules in a 
particular table does to a user specified packet. Moreover it should 
help the user to modify the chains according to the needs to of user.
I have been managing the networking related activities of my college 
since three years. Being system administrator for such a long amount of 
time , it implicitly enriches me with  an experience of working on 
variety of Linux distros ranging from Fedora 3-10 , Red Hat Linux 
Enterprise , SUSE , Centos , Backtrack Linux , Ubuntu and etc.  So 
working on Linux operating system  isnât  a problem as far as I am 
concerned . Its my system administration knowledge and experience which 
provides me with an edge over others . I have been greatly involved in 
configuration and maintenance  of the firewalls , web servers running on 
Apache , the database in LDAP and the Squid Web proxy . As the project 
aims for better IPtables management tool , I can contribute with my hard 
earned 3 years experience  in maintenance of firewalls . For example , 
my tool will offer certain additional  security options to the user to 
guard against activities like  IP spoofing in which an attacker can 
pretend to  have a private IP , thus trying to infiltrate  into the 
network and following the DROP policy as default.Another  valuable 
suggestion would be to help users to troubleshoot the common problems 
associated with iptables like helping the users in troubleshooting with 
the installation of  iptables , enabling the forwarding (/bin/echo "1" > 
/proc/sys/net/ipv4/ip_forward). By giving these  additional guidance and 
solutions to the common problems faced during iptables configuration , 
the user would neednât be looking on the internet for every miniscule 
problems and hence making the tool intelligent enough to cater to these 
problems.  There are hundreds of people around the world who have the 
knowledge regarding the iptables but itâs the experience of the 
developers in firewalling which would be helping in making a successful 
and intelligent  tool .The project is unique in itself as there are no 
such tools right now available which help the users in managing the 
iptables with "minimum redundancy". Hence , it s an effort to improve 
the management of the iptables through the develpopment of an 
intelligent tool which has some kind of power of autogeneration of rules 
depending upon the user's internal IP range , special services like Web 
server which are running . If the info is provided to the tool , then it 
will automatically generate the rules regarding DNAT prerouting reqd for 
Webserver requests arriving from external network and also helps us in 
negating IP spoofing.

Proposal for development of Tool for Better IPtables management

The tool focuses on helping the user to perceive what a particular 
chains of rules in a particular table does to a user specified packet. 
Moreover it should help the user to modify the chains according to the 
needs to of user.  Hence the overall tool use cases are directly 
identified as:

1  .)   User perceives what a particular chain does to the packet 
specified with the details like protocol , source ip , destination ip , 
Ethernet itâs arriving upon . The tools helps the user to either select 
all the rules in the chain or some particular rules and tells the impact 
of the application of selected rules upon the incoming/outgoing packet . 
The response of the tool could be in terms of whether the packet was 
ACCEPTED, DROP, REJECTED or forwarded to some other chain.

2   . )  The user specifies the packet with relevant details and asks 
the tool to                                  modify the particular chain 
to accept/drop/reject these kinds of packets. User has the flexibility 
of specifying the range of source ipâs and range of destination ipâs 
while providing the details of the packet.

In order to simplify the working of this tool, we can decide upon the 
various attributes which a rule could have .They are mainly reflected 
with the number of switches which are possible to be applied in a rule. 
For example the set of attributes of a rule are :

Attribute                                                        Switch

Table 
 -t ,

Chain                                                          -A INPUT

Rule Id                                                        -A => 
CurrentRuleID++

SourceIP                                                     -s

 DestinationIP                                             -d

 InputInterface                                            -i

 OutputInterface                                          -o

InputPort                                                    -sport

OutputPort                                                 -dport

Protocol                                                      -p (TCP/ICMP)

State 
                                                  -m state - - 
state(ESTABLISHED /NEW/RELATED)

Target                                                         -j 
(ACCEPT/DROP/REJECT)

Hence an abstract class CRule would have the above listed attributes as 
their

component data members and some pure virtual methods (get() and set()) 
to help user modify the attributes. It should be noted that user neednât 
specify each and every attribute of the  rule but the mandatory ones 
like table, chain ,target .Hence a validity of a user specified rule 
could be checked by ensuring that the mandatory attributes are duly 
supplied by the user. This way the tool helps user to make rules . Now 
the question comes regarding the storage of these rules in a way so that 
the information may be efficiently retrieved while rule checking. If all 
the rule sets are stored at one place , then we have to check across 
rules belonging  to different tables , thus decreasing our efficiency.

The class hierarchy could be given as :

    Table

___________|___________________
                                                      | 
            |                            |

Mangle                      Filter                            NAT


________________________|_______________


                 |                            | 
      |

          Input                      Output                     Forward

                                        ________________|__________

                                       |                       | 
        |
                                                     Rule1 
   Rule2          Rule n

The top of the hierarchy there should be an abstract CTable Class .The 
three subsequent subclasses would implement the CTables  class in their 
own way . Each of the tables would have different set of rules 
corresponding to each chain present in the table . For example , the 
Filter Table  would have 3 sets of rules for Input ,Forward  and Output 
Chain respectively. Each set comprises of number of rules which are 
merely instances of CRule Class described above. This kind of class 
hierarchy would help us to check the rules belonging to a particular 
chain and particular Table  only. We need not deal with other rules 
residing in other chains.

The first usecase  requirements could be met by having RuleChecking 
Engine incorporated into the tool. The user selects some rules in a 
particular chain discussed above or the entire chain and specifies the 
sample packetâs details such as source ip , destination ip, interface , 
Protocol. Then itâs left to the job of RuleChecking Engine to match the 
attributes of  each and every rule selected by the user to the 
attributes of the sample packet provided by the user , If it matches 
then the Engine should display the target attribute . If it doesnât get 
matched , then  it depends upon the default policy followed by the 
chain.  The packet is Accepted/Drop in accordance with the default 
policy of the chain. As from security point of view , normally drop 
should be followed as a Default Policy specially to negate the 
IPspoofing kind of attacks. In order to make the rule matching 
efficient, the engine should switch over to next rule as soon as an 
attribute in the rule doesnât match with their corresponding details 
supplied in the sample packet. There is no need of matching all the 
attributes of the rules.



Implementation of the Second Usecase :

The second usecase helps user modify the chains according to his own 
needs .In order to identify the possible cases where the packet could be 
filtered out , we need to have a look at the whole course of chains 
though which the intended packet has to go through. The passage followed 
could be broken in series of steps:

1 . Mangle Table Prerouting chains

2 . NAT Table Prerouting

3. If the data is intended for firewall ,

then go though Mangle Table INPUT chain Ãfilter table Input Chain ÃLocal 
Processing Ãmangle Table Output Chain à filter Table Output Chain

Else it needs to be forwarded then it passes through

ÃmangleTable forward Chain à Filter Table forward Chain .

3. Then it passes though Mangle Table PostroutingChain à NAT postrouting



These are the possible paths which a packet can traverse after arriving 
at the firewall.

There are four cases possible :

1.    Existence of some contradictory rules which work against the 
wishes of user .

For example : if one of our rules is

iptables -A INPUT  -i eth0 -j ACCEPT



while the user wants that  packets arriving at eth0 and having ip 
172.16.1.1/24 should be rejected.





2.    Existence of matching rules which work in accordance with userâs 
wishes but the attributes defined in the particular rule are the subset 
of the attributes provided in the sample packet .

For example: iptables âA input âI eth0 âj REJECT

Attributes are( input, eth0, reject)

Userâs wish is to packets arriving at eth0 and having ip 172.16.1.1/24 
should be rejected.

Attributes  are (input,eth0,sourceip,reject)





3.    No rules  found whose all attributes match with those of sample 
packet provided .

4.    Rule found whose attributes match with all the sample packetâs 
attribute



Case 1:

 In order to modify the existing rules , we need to have a knowledge 
about those rules in the chain which may be prohibiting  the flow of 
packet through the firewall, where user wants the specified packet to 
pass through the firewall. It also certainly possible that user can ask 
to modify rules such that the certain type of packet doesnât pass 
through the firewall, hence in this case we need to look for points in 
the different chains  where the packet may be ACCEPTED by a certain rule.



For example: if one of our rules is

iptables -A INPUT  -i eth0 -j ACCEPT



while the user wants that  packets arriving at eth0 and having ip 
172.16.1.1/24 should be rejected.

The corresponding rule would be :

Iptables âA INPUT âI eth0 âs 172.16.1.1/24  âj REJECT



Even though this rule is being appended in the INPUT chain , it would 
not help because the RULE 1 when checked makes the packet ACCEPTED. 
Hence we need to look forward to these set of conflicting rules.

In order to accomplish the task of finding the set of conflicting rule 
sets , we revert back to our RuleChecking Engine .The sample packets 
with relevant attributes had already been supplied by the user. Now the 
Rule Checking engine would be responsible for checking every rule in the 
chain and verifying that whether the attributes of the concerned rule 
match with the attributes specified in the sample packet , if yes then 
is the decision taken by the rule is in contradiction with the userâs 
wish. If it is so, then the user should be prompted to reconsider its 
decision as it violates a previously existing rule set. The prompt is 
necessary because it may happen that user may not be aware of the 
previous rules in the iptables. Hence in the above example, a prompt 
regarding violation of already existing contradictory rule âiptables -A 
INPUT  -i eth0 -j ACCEPTâ would be generated to user and the final 
decision would be dependent upon the userâs wish.

If the answer is NO , then its probably belongs to Case 2.

Case 2:

This  basically refers to the case when the user wish is already been 
taken care of by a less specific rule mentioned in the set . Hence no 
need to add a new rule . Itâs already performing the same job. This is 
an example of a case where we had checked for redundancy of the existing 
rules. If a new rule would have been added , the job would have been 
done in the same fashion but redundancy of the rules would be present in 
the iptables.



Case 3:

If there are no rules whose all attributes match with those of sample 
packet provided , then we have to simply add the rule corresponding to 
the user wishes. In the previous example:

Iptables âA INPUT âI eth0 âs 172.16.1.1/24  âj REJECT

This rule is simple added into the INPUT chain of Filter Table.



Case 4:

If a rule whose attributes are matching with the attributes of the 
sample packet and there exist no such attribute in the sample packet 
whose counterpart isnât present in the particular rule , then this means 
the rule regarding the userâs wish has been already added into the 
IPtable. Hence no need to add an extra new rule which is just a replica 
of an existing rule.



This is precisely the algorithm which we I wish to implement .I have 
already provided the implementation details of the proposal. My 
experience would help this tool to be more usable from the users point 
of view  as I intend to take an idea of the userâs network as an input 
from the user . This idea of userâs network would cover details like the 
private IP addresses and their subnet mask  and special services running 
on the internal network such as Web server .This information would help 
tool in following ways:

1.)  It helps to generate the rules regarding the NAT Tables 
automatically since the any HTTP request arriving from an external 
network with port 80 would be then requiring DNAT prerouting where the 
destination address of the packet would be changed to the ip address of 
the web server . Note that the ip address information has been collected 
already before. Hence the tool would help on autogeneration of rules 
depending upon the userâs internal network. Some kind of Metaprogramming 
stuff.



2.) It also helps me in negating IP spoofing . Suppose the user 
specifies the internal ip address as 172.16.1.1/255.255.255.0 . Now if 
any request from the source ip lying in the range 172.16.1.1/255.255.0.0 
 and arriving at the Ethernet connected to the external world would 
require the firewall to drop such packets .

Hence the tool would automatically generate a rule to be added into the 
Forward chain of Filter table

Iptables âA Forward âs 172.16.1.1/24  -I eth0 âj DROP



3.) DNS uses tcp for zone transfers, we might this need of rule sets on 
certains systems







//incoming DNS replies

iptables -A INPUT -i eth1 -p udp -s 172.16.1.5 --sport 53 -m state 
--state ESTABLISHED -j ACCEPT

iptables -A INPUT -i eth1 -p udp âs 172.16.1.6 --sport 53 -m state 
--state ESTABLISHED -j ACCEPT



//outgoing DNS requests

iptables -A OUTPUT âo eth1 -p udp -d 172.16.1.5 --dport 53 -m state 
--state NEW,ESTABLISHED -j ACCEPT

iptables -A OUTPUT -o eth1 -p udp -d 172.16.1.6 --dport 53 -m state 
--state NEW,ESTABLISHED -j ACCEPT



where 172.16.1.5 and 172.16.1.6 are the two name servers.



Eth1 are the Ethernet interfaces .



4 . Allowing FTP outband



iptables -A INPUT  -i eth1 -p tcp --sport 21 -m state --state 
ESTABLISHED -j ACCEPT

iptables -A OUTPUT -o eth1 -p tcp --dport 21 -m state --state 
NEW,ESTABLISHED -j ACCEPT



5.  Allowing SMTP outband

iptables -A INPUT  -I eth1  -p tcp --sport 25 -m state --state 
ESTABLISHED -j ACCEPT

iptables -A OUTPUT -o eth1 -p tcp --dport 25 -m state --state 
NEW,ESTABLISHED -j ACCEPT

All these kind of rules would be autogenerated after taking the idea of 
the internal network from the user .

The rough timeline for project could be stated as:

April 20-May 23 . Refining my designs with the help of mentor.

May23- July 5. Ensuring the usecase 1 is implemented.

July 5-July25. Ensuring the  second usecase is  implemented.

July25-August 10 â Testing of the code with the help of developers.

I intend to develop it on Java platform using the Swing Library.At the 
current period ,I can devote an hour or so . But when the summer 
holidays begin , then I can fulfill the promise of spending 40 hrs per 
week to the project.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/