On 27/03/2013 12:59 PM, Michael Ross wrote:
I'd like to be able to change the time window:
http://gurder.ross.cx/misc/ratelimit.patch
Neat. Thanks for that.
Danny
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listin
On Wed, 27 Mar 2013 01:37:36 +0100, Daniel O'Callaghan
wrote:
On 27/03/2013 10:37 AM, Michael Ross wrote:
I'm happy to share a program I wrote which slows down the brute force
attackers.
It simply counts the SYN packets from a given IP and limits the rate
per minute by dropping the packet
On 27/03/2013 10:37 AM, Michael Ross wrote:
I'm happy to share a program I wrote which slows down the brute force
attackers.
It simply counts the SYN packets from a given IP and limits the rate
per minute by dropping the packet if they are coming too fast.
Uses ipfw divert sockets, so would wo
On Tue, 26 Mar 2013 22:56:37 +0100, Daniel O'Callaghan
wrote:
On 27/03/2013 4:18 AM, Joseph Olatt wrote:
Any ideas/suggestions on this will be appreciated. Thanks,
>
>-- Doug
A little while back I wrote a system to do a simple Two Factor
Authentication and dynamic manipulation of PF (Packe
On 27/03/2013 4:18 AM, Joseph Olatt wrote:
Any ideas/suggestions on this will be appreciated. Thanks,
>
>-- Doug
A little while back I wrote a system to do a simple Two Factor
Authentication and dynamic manipulation of PF (Packet Filter) Tables. I
created it to prevent brute-force attacks on th
nges as they probably would not
> remember any other password (or where they wrote down the password). This
> situation requires a technical solution.
>
> I have been investigating the use of client authentication through SSL. DoD
> uses this approach by having the certificates
Jerry wrote:
> > > How about refusing to
> > > relay mail from addresses in a good DNSBL?
> >
> > Bad idea. Legitimate users connecting from dynamic IP-addresses is normal.
>
> I disagree. There is no legitimate reason a user cannot use a bonafide
> ISP to send mail.
The talk is about RELAYING
On Sun, 24 Mar 2013 18:59:09 +0200
l...@lena.kiev.ua articulated:
> Bad idea. Legitimate users connecting from dynamic IP-addresses is
> normal.
I disagree. There is no legitimate reason a user cannot use a bonafide
ISP to send mail. I block dynamic ISPs by default. I have found that
99% of it is
On 24/03/2013 17:50, Waitman Gobble wrote:
On Sun, Mar 24, 2013 at 1:25 AM, Doug Hardie wrote:
One idea is to run a different server process on 25 which does not do SMTP
AUTH,, then run SMTP AUTH on 465 or 587. I don't really see a reason to
advertise SMTP AUTH on 25, for some reason all mail s
> How about refusing to
> relay mail from addresses in a good DNSBL?
Bad idea. Legitimate users connecting from dynamic IP-addresses is normal.
DNSBLs list a dynamic IP-address permanently
or for long time after a zombied Windows spewed spam from it.
Some DNSBLs warn about that explicitly, for exa
On Sun, Mar 24, 2013 at 1:25 AM, Doug Hardie wrote:
>
> On 24 March 2013, at 01:10, Waitman Gobble wrote:
>
> >
> >
> > You might consider disabling external smtp auth service and using ssh
> tunnel to server to connect to mail. Also provide web based convenience
> service.
>
> I am not convince
On Sat, 23 Mar 2013, Doug Hardie wrote:
On 23 March 2013, at 21:51, Mehmet Erol Sanliturk
wrote:
Using Static IP in the client side , and checking Static IP of the user
may be a possibility : In that way , any message from another IP will
not be accepted .
If this is possible for you
Doug Hardie wrote:
> my outgoing mail server is being systematically attacked to try
> passwords looking for one that works. When they do find one,
> we get inundated by spam sent through that account throughout the world.
How such spam is injected into your mail relay - via SMTP?
> most of our
Doug Hardie writes:
> That is an interesting idea, but unfortunately our users tend to
> travel a lot and need to be able to access mail from anywhere. Also,
> static IPs can get quite expensive from some ISPs. Our users are
> pretty much on fixed incomes and any expense is a hardship for them.
have been investigating the use of client authentication through SSL.
With certificates you will likely encounter user problems as with passwords:
You can install the certificates in the users keychain, with or without
password protection or protected by the system password. This may
actually be
At 11:22 PM 3/23/2013, you wrote:
>I am not sure this is the best place to ask this, but I didn't see any other
>maillists that seemed more appropriate.
>
>Basically, my outgoing mail server is being systematically attacked to try
>passwords looking for one that works.
brute force attacks are ea
On Sun, Mar 24, 2013 at 1:21 AM, Doug Hardie wrote:
>
> On 23 March 2013, at 22:59, Mehmet Erol Sanliturk
> wrote:
>
> > The following steps may be another idea :
> >
> > Assume that you supply to your users a small login program prepared for
> them specifically ( since you are using SSH ) :
>
On 24 March 2013, at 01:22, Polytropon wrote:
>
> Wouldn't there be a possibility to combine key _and_ password?
> The key shouldn't have to be removed, but it should only work
> with a password (which again is kept individual to each user).
> The process has to be made "more uncomfortable" to
Certificate + Password/PIN should be okay. You can maybe create a
policy for the target system to enable a screensaver to block the
screen after short period that will force user to enter his/hers
password..? I know in theory all seems easy :-) :-) Good luck! :-)
--
CeDeROM, SQ7MHZ, http://www.to
On 24 March 2013, at 01:10, Waitman Gobble wrote:
>
>
> You might consider disabling external smtp auth service and using ssh tunnel
> to server to connect to mail. Also provide web based convenience service.
I am not convinced that a ssh tunnel is going to be easy for my users. We do
pro
On Sun, 24 Mar 2013 01:16:33 -0700, Doug Hardie wrote:
>
> On 24 March 2013, at 01:03, CeDeROM wrote:
>
> > Why don't you just use PKI for authentication (you can generate your
> > own certificates)? You can easily upload keys/certificated to client
> > machines (PC, Android, Apple, ...). That s
On 23 March 2013, at 22:59, Mehmet Erol Sanliturk
wrote:
> The following steps may be another idea :
>
> Assume that you supply to your users a small login program prepared for them
> specifically ( since you are using SSH ) :
>
> Compile that program for each user with a special identifier
On 24 March 2013, at 01:03, CeDeROM wrote:
> Why don't you just use PKI for authentication (you can generate your
> own certificates)? You can easily upload keys/certificated to client
> machines (PC, Android, Apple, ...). That should work :-)
>
Thats exactly what I have been testing. Its eas
On Sat, Mar 23, 2013 at 9:22 PM, Doug Hardie wrote:
>
> Basically, my outgoing mail server is being systematically attacked to try
> passwords looking for one that works. When they do find one, we get
> inundated by spam sent through that account throughout the world. The
> situation is such th
On Sun, Mar 24, 2013 at 9:03 AM, CeDeROM wrote:
> Why don't you just use PKI for authentication (you can generate your
> own certificates)? You can easily upload keys/certificated to client
> machines (PC, Android, Apple, ...). That should work :-)
You can additionally encrypt keys/vertificates w
Why don't you just use PKI for authentication (you can generate your
own certificates)? You can easily upload keys/certificated to client
machines (PC, Android, Apple, ...). That should work :-)
--
CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
___
freebs
On Sat, Mar 23, 2013 at 10:16 PM, Doug Hardie wrote:
>
> On 23 March 2013, at 21:51, Mehmet Erol Sanliturk
> wrote:
>
> >
> > Using Static IP in the client side , and checking Static IP of the user
> may be a possibility :
> > In that way , any message from another IP will not be accepted .
> >
On 23 March 2013, at 21:51, Mehmet Erol Sanliturk
wrote:
>
> Using Static IP in the client side , and checking Static IP of the user may
> be a possibility :
> In that way , any message from another IP will not be accepted .
>
> If this is possible for your systems , it may be checked for us
bly would not
> remember any other password (or where they wrote down the password). This
> situation requires a technical solution.
>
> I have been investigating the use of client authentication through SSL.
> DoD uses this approach by having the certificates on an ID card and a c
res a technical solution.
I have been investigating the use of client authentication through SSL. DoD
uses this approach by having the certificates on an ID card and a card reader
on each computer. We don't have the money to use that approach no could we
every get our users to spring for th
30 matches
Mail list logo
