lkml.org 
[lkml]   [2009]   [Apr]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectGoogle Summer of Code 2009: Student applies to create a Better IPTables Management Tool
    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@gmail.com.

    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@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2009-04-03 13:41    [W:5.692 / U:0.012 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site