[Discuss] Limit the number of ip addresses which can connect to a port

Derek Atkins warlord at MIT.EDU
Thu Nov 2 10:23:11 EDT 2017


Hi,

Tom Luo <mariolzx at gmail.com> writes:

> Hi, Derek,
>
> Thanks for your suggestions. However, this is not exactly what I want.
> The service is running in the server. Users can only connect to the server
> using an assigned TCP port and a password.
> This service using port/password to identify a user. Different users will get
> different ports and their own unique password.
> For example, user A will connect to port 8001 using password "testpassword".
> User B will connect to port 8002 using password "testpassword2".
> Every user has to pay a fee to use the service.
> This works very well if no user shares port/password with other people.
> To reduce this passowrd/port sharing issue, I propose to limit the number of
> ip addresses connected to a port.
> If a user A (assigned port 8010) shares his/her password with a person C, user
> A can connect to port 8010 and use the service.
> If at the same time the person C tries to connect to port 8010 from another ip
> address. the firewall should decline the new connection.
> I also check the connections and I see one user can have many connections to
> the assigned port at the same time. So, I cannot use the number of active
> connections on a port to solve this issue.
> The only thing I can think about is using IP address. I think video service
> providers like hulu and netflix face the same issue. But, I don't know how
> they deal with the password sharing issue.
>
> I hope I explained the issue clearly. BTW, I don't have the source code of the
> service, so I cannot change the service itself.

You did, but I have a few more questions:

1) What is the client?  Is this a Web-App (using a browser client)?  Or
   is there some special client?

2) Based on #1:  How are you expecting the service to request a password
   from the client, and how is the client supposed to deliver it?

I'll note that the way Netflix handles it is # of flows.  You can be
logged in from any number of places, but your account is only allowed to
have N flows (based on your account status).  I'll also note that this
is enforced by the netflix server, not by a wrapper.  It's an integrated
limitation process.

On a side note, if you cannot change the server, then why do you care
how it's used?  Clearly the server-creators don't care about limiting
its use.

> Thanks a lot!

-derek

> Tom
>
> On Wed, Nov 1, 2017 at 10:54 AM, Derek Atkins <warlord at mit.edu> wrote:
>
>     Tom,
>    
>     Tom Luo <mariolzx at gmail.com> writes:
>    
>     > Yes. I want only one IP gets access to the service. However, I don't own
>     > this application and I don't have the source code. That is why I can
>     only
>     > using firewall to handle it.
>     > If there is no software capable to handle this, I am thinking about
>     writing
>     > a shell script to do it myself.
>    
>     Just so I understand:   You have a service running on a server which
>     *anyone* can use.  But once *someone* is using it, further connections
>     can only come from that single IP address.   And then, once all
>     connections drop again (i.e., nobody is using the service), then it
>     opens up to anyone on any IP address again until someone else connects?
>    
>     Do I have this right?
>    
>     If so, I'm honestly not sure how to do this outside the application
>     itself.  You MIGHT be able to do it with tcp_wrappers with some state on
>     the machine for the number of open connections.
>    
>     Another option is that you MIGHT be able to do this with something like
>     fail2ban + firewalld.  Every time there is a first-time connection then
>     you add a firewall rule that limits access to only that IP address, and
>     then once the user "logs out" you remove that restriction.  Of course
>     you would need to ensure that the connection/disconnection get logged
>     properly, and you'd need to write the fail2ban scripts.
>    
>     If you cannot modify the application itself then this might be
>     challenging to get all the connect/disconnect messages to properly line
>     up.
>    
>     > Thanks,
>    
>     -derek
>    
>     --
>            Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
>            Member, MIT Student Information Processing Board  (SIPB)
>            URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
>            warlord at MIT.EDU                        PGP key available
>

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       warlord at MIT.EDU                        PGP key available



More information about the Discuss mailing list