how it sends packets...

Discussion in 'Colasoft Free Network Tools' started by guest, Jul 23, 2009.

Thread Status:
Not open for further replies.
  1. guest

    guest Guest

    All in the title...

    I am trying look 'n' stop firewall and there is two types of rules... the internet rules that are rules to allow or block some traffic, and the apps rules, that allow or deny a specific app...

    When I send a packet using packet builder, the firewall can see it and block it using network rules but there is no way to see it in the applications rules... Like if the app doesn't exist...

    Any idea why??

    Thanks

    Alex
     
  2. Nelson

    Nelson Registered Member

    Joined:
    May 26, 2005
    Posts:
    36
    Knowledge of the structure of packets and OSI model or TCP/IP Four Layers Architecture Model is required to understand this.

    The network rules are mostly based on IP addresses like ACL. Standard ACL which includes only destination IP address is typical. Such rule will determind let go or block the traffic based on purely the IP address. For example, external IP address 221.182.77.x can not initiate a connection to internal IP address 192.168.1.y.

    The application rules are mostly based on layer 4 or hight protocol. Extended ACL with source/destination port number is a app rule. And there are also other technology like context-based, pattern-based, DPI been used to determind whether let go or block the traffic flow.

    To make it simple, I say both network rules and app rules are all based on packets, but the former inspect only IP header, while the latter will check at leat transport layer.
     
  3. guest

    guest Guest

    yeah well, with the "internet rules" you can go lower than the ip level in look 'n' stop and other firewalls I used...


    So the applications rules a looking for a specific higher level protocol to be sent... That's why my simple IP packet without any payload isn't detected as being part of that application... o_O??

    Thanks
     
  4. Nelson

    Nelson Registered Member

    Joined:
    May 26, 2005
    Posts:
    36
    That's true. If only IP header being there. They are just IP packets with no characteristics the firewall can use to identify. So the firewall said "oh, it is not what I am looking for".
     
  5. guest

    guest Guest

    I'm returning to an old topic here....

    But I don't understand what you said...Even if my firewall (eset smart security) is set to block EVERYTHING, it still won't block this! When I try with look n stop, it sees the packet on the internet filtering (that uses a NDIS driver) but the application filtering (TDI) can't...

    So... How can it be?...

    Thanks

    Alex
     
  6. Colasoft Support

    Colasoft Support Colasoft Moderator

    Joined:
    Dec 6, 2007
    Posts:
    254
    As Nelson mentioned, both network rules and app rules are all based on packets, but the former inspect only IP header, while the latter will check at least transport layer. It is the point.
    I suggest you to check the information in Knowledge of the structure of packets and OSI model or TCP/IP Four Layers Architecture Model carefully again.
     
  7. Phant0m

    Phant0m Registered Member

    Joined:
    Jun 7, 2003
    Posts:
    3,684
    Location:
    Canada
    Is it something else besides TCP and UDP packets?

     
  8. guest

    guest Guest

    I tried again. Eset will see the packets unless it is something else than IP (other EtherType)... So this is normal


    My last question is to understand how application rules are implemented in LookNstop and why they don't see those packets...

    I also would like to know how the packet builder REALLY sends packets... There is no more RAW sockets support in windows...

    So... Is the app using a low level driver to send raw ethernet frames (with the content edited to make ip, tcp, udp or other types of packets...)?? That would explain why the TDI filter of the app rules can't see them! But if it is so, I wonder how ESET sees them! I thought that ESET used a TDI filter too for the firewall and the only way to see those packets would be to use a NDIS driver.



    Thanks

    Alex
     
Thread Status:
Not open for further replies.