Connection direction - incoming outcoming filter

Discussion in 'LnS English Forum' started by ilgriso, Jul 17, 2005.

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

    ilgriso Registered Member

    Joined:
    Jul 17, 2005
    Posts:
    2
    A feature that I miss in looknstop is the possibility to choose the connection direction in filter rules.
    Example. I add a rule to allow outcoming connection to the remote port 1500.
    That rule also will allow remote incoming connection from remote port 1500, is it?

    There's a way to solve this problem?
     
  2. Frederic

    Frederic LnS Developer

    Joined:
    Jan 9, 2003
    Posts:
    4,353
    Location:
    France
    Hi,

    Are you talking about the Internet Filtering or the Application Filtering ?

    Frederic
     
  3. bloodscourge

    bloodscourge Registered Member

    Joined:
    Jul 3, 2004
    Posts:
    372
    Location:
    France
    Hi,

    If I understood correctly, Ilgriso's question is about internet filtering, more specifically packet direction. I'll try to reformulate it: when a rule is specified with both (inbound/outbound) packet direction, is there any control on who's iniating connection? Could it be possible, or is it implied by features|rules|context?

    PS: packet direction has already been discussed in french forum. Frederic, could you clarify the "packet direction: both" case? It's confusing. Thanks in advance :)
     
  4. ilgriso

    ilgriso Registered Member

    Joined:
    Jul 17, 2005
    Posts:
    2
    Exactly Bloodscourge, that's my question. .
     
  5. Frederic

    Frederic LnS Developer

    Joined:
    Jan 9, 2003
    Posts:
    4,353
    Location:
    France
    Hi,

    Using "In & Out" or "Both" for the direction of a rule is just a way to combine two rules in one.
    So, it doesn't provide less protection than creating two rules.

    Suppose you create 2 rules to have your PC to connect to port 1500:
    - one rule PC>>Net (Out) for which you have to specify Dest port to be 1500
    - one rule Net>>PC (In) for which you have to specify Source port to be 1500

    With one rule, you would have to specify 1500 only one time in Dest (PC>>Net) / Source (Net>>PC) part of the rule edition dialog box.

    The same applies for IP address. The remote IP address is the dest for packets sent from the PC to Internet and is a source for packets sent from internet to the PC.

    Frederic
     
  6. bloodscourge

    bloodscourge Registered Member

    Joined:
    Jul 3, 2004
    Posts:
    372
    Location:
    France
    Hi Frederic,

    Thanks for your reply but... that's not exactly what we were talking about :doubt: I understand the "both" direction mechanism. Let's take your example:

    Ilgriso's question (and mine too ;)) is how can I ensure that a packet filtered by the second rule belongs to an existing connection (request filtered by first rule) and not a connection request or scan? How can I restrict connection request in one direction? with TCP flags (SYN, ACK)? TCP SPI?

    Hope I'm clear enough :(
     
  7. Frederic

    Frederic LnS Developer

    Joined:
    Jan 9, 2003
    Posts:
    4,353
    Location:
    France
    Hi,

    Actually I have just answered to "could you clarify the "packet direction: both" case? It's confusing" ;)

    So the question is more related to client/server packets for TCP connections.

    Firstly, usually the rule "Block Incoming connection" is used (from the Enhanced Ruleset) and it blocks all the incoming packets with the SYN flag alone. So, all servers connection are blocked.

    For data TCP Packets there is nothing special inside the packet telling if the packet belongs to a client connection or a server connection (that's why there is no "connection direction" selection in filter rules).
    Here comes the TCP SPI: it will verify the incoming packets (other than the ones with the SYN flag alone) belong to an open (and so, already allowed) connection.
    So, if you activated the TCP SPI, and if you have enabled the rule "Block incoming connections", you are sure that all allowed packets are belonging to a client connection initiated by the PC.

    Frederic
     
  8. bloodscourge

    bloodscourge Registered Member

    Joined:
    Jul 3, 2004
    Posts:
    372
    Location:
    France
    Hi,

    That's the kind of explanation I like, thanks a lot :D Ilgriso's, hope you're satisfied too ;)

    PS: maybe I'll come back with some questions about this... if so, sorry in advance! lol
     
Thread Status:
Not open for further replies.
  1. This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
    By continuing to use this site, you are consenting to our use of cookies.