restrict a tcp port to only a specific program - Security

This is a discussion on restrict a tcp port to only a specific program - Security ; How to restrict a tcp port to only a specific program (i.e. other program are not allowed access)? e.g. restrict the tcp port 1600 access to only the myprog program. I want to ensure that only myprog can run on ...

+ Reply to Thread
Results 1 to 10 of 10

Thread: restrict a tcp port to only a specific program

  1. restrict a tcp port to only a specific program

    How to restrict a tcp port to only a specific program (i.e. other
    program are not allowed access)?
    e.g. restrict the tcp port 1600 access to only the myprog program. I
    want to ensure that only myprog can run on tcp port 1600, so if
    another program is running on port 1600 before myprog try to run on
    port 1600, then myprog cannot run.


  2. Re: restrict a tcp port to only a specific program

    wong_powah@yahoo.ca wrote:
    > How to restrict a tcp port to only a specific program (i.e. other
    > program are not allowed access)?
    > e.g. restrict the tcp port 1600 access to only the myprog program. I
    > want to ensure that only myprog can run on tcp port 1600, so if
    > another program is running on port 1600 before myprog try to run on
    > port 1600, then myprog cannot run.
    >


    You could start the program with a script that includes a "netstat -l"
    command to see if anything is already listening on the port. This does
    not handle a potential race condition where another program starts
    between when you check for the listener and you start your program.

    Phil Sherman

  3. Re: restrict a tcp port to only a specific program

    wong_powah@yahoo.ca wrote:

    > How to restrict a tcp port to only a specific program (i.e. other
    > program are not allowed access)?
    > e.g. restrict the tcp port 1600 access to only the myprog program. I
    > want to ensure that only myprog can run on tcp port 1600, so if
    > another program is running on port 1600 before myprog try to run on
    > port 1600, then myprog cannot run.


    Generally you cannot. Ports <1024 can only be bound by root (or in linux,
    the appropriate capability bit set) and everything else is fair game.

    I'm not up on SELinux or similar things, but you *might* manage it within
    that sort of enhanced security framework. Don't know - wait for an SELinux
    expert to appear...

    In modern linux netfilter layers (firewall) you can affect packets by the
    uid or the (local) sender - however this doesn't stop another uid bind-ing
    to the port - they may just not get any data.

    It might help if you restate your problem in a more general way - what are
    you *really* trying to do?

    Cheers

    Tim

  4. Re: restrict a tcp port to only a specific program

    On Apr 18, 12:37 pm, Tim Southerwood wrote:
    > wong_po...@yahoo.ca wrote:
    > > How to restrict a tcp port to only a specific program (i.e. other
    > > program are not allowed access)?
    > > e.g. restrict the tcp port 1600 access to only the myprog program. I
    > > want to ensure that only myprog can run on tcp port 1600, so if
    > > another program is running on port 1600 before myprog try to run on
    > > port 1600, then myprog cannot run.

    >
    > Generally you cannot. Ports <1024 can only be bound by root (or in linux,
    > the appropriate capability bit set) and everything else is fair game.
    >
    > I'm not up on SELinux or similar things, but you *might* manage it within
    > that sort of enhanced security framework. Don't know - wait for an SELinux
    > expert to appear...
    >
    > In modern linux netfilter layers (firewall) you can affect packets by the
    > uid or the (local) sender - however this doesn't stop another uid bind-ing
    > to the port - they may just not get any data.
    >
    > It might help if you restate your problem in a more general way - what are
    > you *really* trying to do?
    >
    > Cheers
    >
    > Tim


    I have a client and server program which the server program server
    program binds to 1600 and the client program connects to port 1600 on
    the server computer, in order to talk to the server program. For
    backward compatibility I cannot change the tcp port value.
    The problem is that if another program connect to the same port on the
    server but then exits or dies (denial of service attack?), then a
    connection can (and quite correctly) stay in CLOSE_WAIT forever while
    the server program holds the connection open. Therefore one solution
    is to ensure that only my program (myprog) can use that tcp port on
    the server.




  5. Re: restrict a tcp port to only a specific program

    wong_powah@yahoo.ca wrote:

    > I have a client and server program which the server program server
    > program binds to 1600 and the client program connects to port 1600 on
    > the server computer, in order to talk to the server program. For
    > backward compatibility I cannot change the tcp port value.
    > The problem is that if another program connect to the same port on the
    > server but then exits or dies (denial of service attack?), then a
    > connection can (and quite correctly) stay in CLOSE_WAIT forever while
    > the server program holds the connection open. Therefore one solution
    > is to ensure that only my program (myprog) can use that tcp port on
    > the server.



    Firstly, can't you fix the server? Or do you not have the code? ie make the
    server a proper multi-connect server - even converting the server to talk
    on STDIN/STDOUT and hiding it behind (x)inetd sounds like it would work
    better.

    Failing that, is the client program also running on the server computer (ie
    connecting over loopback)?

    If the client is connecting from another computer, you have no chance to
    identify the program generating packets.

    If it is local, then the bit I mentioned about firewall rules based on the
    uid of the process originating the connection might work. Fix it so that
    the client runs as a known and fixed uid. Then make up a rule based on
    the "--uid-owner" match test (owner module) to block any program from
    sending packets to 1600 unless it holds the uid of your client.

    Would it work?

    Cheers

    Tim

  6. Re: restrict a tcp port to only a specific program

    On Wed, 18 Apr 2007 07:34:58 -0700, wong_powah wrote:

    > How to restrict a tcp port to only a specific program (i.e. other
    > program are not allowed access)?
    > e.g. restrict the tcp port 1600 access to only the myprog program. I
    > want to ensure that only myprog can run on tcp port 1600, so if
    > another program is running on port 1600 before myprog try to run on
    > port 1600, then myprog cannot run.


    You can use iptables and libipq but it will take some work. Develop
    an initial handshake between your client and server (if you don't have
    one already). Your libipq process can monitor the handshake and
    permanently drop packets from any ip address that fails the handshake.

    I don't know how this would interact with the CLOSE_WAIT state. Perhaps
    someone else can comment on this?

    I would also consider selinux.

    Mike.


  7. Re: restrict a tcp port to only a specific program

    On Apr 18, 6:24 pm, Tim S wrote:
    >
    > Firstly, can't you fix the server? Or do you not have the code? ie make the
    > server a proper multi-connect server - even converting the server to talk
    > on STDIN/STDOUT and hiding it behind (x)inetd sounds like it would work
    > better.
    >
    > Failing that, is the client program also running on the server computer (ie
    > connecting over loopback)?
    >
    > If the client is connecting from another computer, you have no chance to
    > identify the program generating packets.
    >
    > [...]
    >
    > Cheers
    >
    > Tim


    I have the source code so I can fix the server.
    What is a proper multi-connect server (why the current server is not)?
    (x)inetd can disallow a port or a service acess, can it disallow both
    port and a service access (e.g. telnet at tcp port 1600)?
    The client is connecting from another computer.


  8. Re: restrict a tcp port to only a specific program

    wong_powah@yahoo.ca wrote:

    > On Apr 18, 6:24 pm, Tim S wrote:
    >>
    >> Firstly, can't you fix the server? Or do you not have the code? ie make
    >> the server a proper multi-connect server - even converting the server to
    >> talk on STDIN/STDOUT and hiding it behind (x)inetd sounds like it would
    >> work better.
    >>
    >> Failing that, is the client program also running on the server computer
    >> (ie connecting over loopback)?
    >>
    >> If the client is connecting from another computer, you have no chance to
    >> identify the program generating packets.
    >>
    >> [...]
    >>
    >> Cheers
    >>
    >> Tim

    >
    > I have the source code so I can fix the server.
    > What is a proper multi-connect server (why the current server is not)?


    One which would handle 2 or more simulateous client connections - which
    means that if someone telnet-ed to port server:1600, it would not matter
    nor would it stop the correct client from connecting to server:1600 at the
    same time.

    > (x)inetd can disallow a port or a service acess, can it disallow both
    > port and a service access (e.g. telnet at tcp port 1600)?


    In thsi context, service means port, according to the translation
    table /etc/services

    inetd has no knowledge of protocol contents - only a port number and tcp or
    udp.

    > The client is connecting from another computer.


    Right - so in fact you have absolutely no way to know what the program is
    who send a SYN packet (or any other packet) to server:1600

    Someone else suggested port-knocking, but I would say go and fix the core
    problem so it doesn't matter.

    The core problem sounds like a design or coding fault in the server code.
    I only have my limited understanding of what's going on based on what you've
    said to base my theory on - so I might be wrong...

    A sensible server will allow any number (upto a practical or configured
    limit) of client connections. You *might* want to telnet to 1600 to test
    the server. Some achieve this by fork()-ing a new process for each client
    connection, some make a new thread and some manage pools of connections via
    select() within a single process.

    It sounds like your server is doing none of these things so is jamming up
    when an erroneous client connects to it - am I correct?

    If security is an issue, then the client and server would normally exchange
    some security credentials so the the server can disregard bad clients.
    Sometimes the connection will be encrypted too.

    Out of interest, what does your server do, that it only has one client?

    Cheers

    Tim

  9. Re: restrict a tcp port to only a specific program


    > One which would handle 2 or more simulateous client connections - which
    > means that if someone telnet-ed to port server:1600, it would not matter
    > nor would it stop the correct client from connecting to server:1600 at the
    > same time.
    >
    > [...]
    >
    > Out of interest, what does your server do, that it only has one client?
    >

    My server should handle 2 or more simultaneous client connections, so
    the source code has a bug.


  10. Re: restrict a tcp port to only a specific program

    wong_powah@yahoo.ca wrote:

    >
    >> One which would handle 2 or more simulateous client connections - which
    >> means that if someone telnet-ed to port server:1600, it would not matter
    >> nor would it stop the correct client from connecting to server:1600 at
    >> the same time.
    >>
    >> [...]
    >>
    >> Out of interest, what does your server do, that it only has one client?
    >>

    > My server should handle 2 or more simultaneous client connections, so
    > the source code has a bug.


    OK - if it is not a design limitation... I think it will be easier and more
    satisfying to fix the bug, than to try to achieve a very difficult series
    of bodges to work around it.

    Good luck bug hunting

    Cheers

    Tim

+ Reply to Thread