[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

summary? Re: timer restrictions



Christopher McCrory wrote:
> 
> Hello...
> 
>         I had a problem user today.  For some reason he decided to pop his mail
> every 5 seconds for a while.  This caused inetd to shut off pop for 15
> minutes (failing looping...).  Has anyone done any "time between
> invocations" modules.  i.e.  max connects=10 per hour, etc.  With
> ipop3d, AFAIK,  one reject will show the client down.   Yes, no, maybe?
> This might be my new project...
> 


	Hello...
		I looked into this some more.   I think for this situation I am going
with xinetd or qpopper.  They both can solve the problem quickly.


Other points:  

>I am afraid a PAM module would not help you. Many MUAs for the platform
>whose name I shall not utter ignore any errors, including authentication
>errors, and keep trying to connect without indicating any error to the
>user.
	If I here one more "I'm having problems with outlook."  I will...  


>Is there any reason why you could not make a module that would trigger
>such a firewalling event? I can imagine it having a use for things
>besides POP.

	In this case we have about one hundred users from this company, all
coming in through a firewall.  Cut one off cut them all off  :(  

>Of course, it could be a module. But it would not work for
>non-autheticated protocols (SMTP) and in situations when a misbehaving
>client does not even attempt to authenticate itself.

	I was thinking it would be useful with pop/imap/ftp/etc. which do
authinticate.  SMTP doesn't use pam anyway.

>I do not know if this function would fit completely within the scope of
>PAM.  Dynamically altering your TCP wrapper access file.  You could hack
>the tcpd stuff so that it updated a db type file.

	This is the problem as I see it.  inetd with or without pam is
stateless.  Therefore, to solve this problem there needs to be some
statefull access log.  Something along the same line as DRAC
(http://mail.cc.umanitoba.ca/drac/index.html) does for SMTP pop before
relay control using RPC.  

auth       required     /lib/security/check_rpc_auth_daemon.so 

>Are you thinking that embedding the daemon inside a module is a bad
>idea? I completely agree with that.

auth       required     /lib/security/check_rpc_auth_daemon.so 

	Call a running daemon?


Going back to DRAC.  DRAC need a change in the pop sources to do a RPC
call the the DRAC daemon.  Is there any reason why this cannot be a pam
module?  imap sounds to hard since the connection stays up.  But this is
for another time.



Thanks for all the responses. 

-- 

Christopher McCrory
BOFH ^H^H^H^H^H Lead Bithead, Netus Inc.
chrismcc@netus.com
admin@netus.com

"Linux: Because rebooting is for adding new hardware"



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index] []