Hi Nanog
I'm curious.
I have been receiving some major ssh brute-force attacks coming from random
hosts in the 116.8.0.0 - 116.11.255.255 network. I have sent a complaint to
the e-mail addresses obtained from a whois query on one of the IP Addresses.
My e-mail bounced back from both recipients.
It would appear you've done your part in trying to reach out (and
subsequently failed), so the next step to go is dropping all traffic
from it.
Nothing wrong with trying to protect your own customer from people who
cannot be bothered to do their own due diligence.
On 8/11/2014 午前 12:19, Gabr
On 08/10/2014 08:19 AM, Gabriel Marais wrote:
> Hi Nanog
>
> I'm curious.
>
> I have been receiving some major ssh brute-force attacks coming from random
> hosts in the 116.8.0.0 - 116.11.255.255 network. I have sent a complaint to
> the e-mail addresses obtained from a whois query on one of the
>My e-mail bounced back from both recipients. Once being rejected by filter
>and the other because the e-mail address doesn't exist. I would have
>thought that contact details are rather important to be up to date, or not?
Opinions vary. Some providers would rather just cash the customers'
checks
On Sun, 10 Aug 2014, Gabriel Marais wrote:
I have been receiving some major ssh brute-force attacks coming from random
hosts in the 116.8.0.0 - 116.11.255.255 network. I have sent a complaint to
the e-mail addresses obtained from a whois query on one of the IP Addresses.
My e-mail bounced back
http://www.fail2ban.org/
2014-08-10 10:18 GMT-07:00 Jon Lewis :
> On Sun, 10 Aug 2014, Gabriel Marais wrote:
>
> I have been receiving some major ssh brute-force attacks coming from
>> random
>> hosts in the 116.8.0.0 - 116.11.255.255 network. I have sent a complaint
>> to
>> the e-mail addre
Move ssh to a non-standart port + fail2ban - best solution.
On 10 Aug 2014, at 22:20, Christopher Rogers wrote:
> http://www.fail2ban.org/
>
>
>
>
> 2014-08-10 10:18 GMT-07:00 Jon Lewis :
>
>> On Sun, 10 Aug 2014, Gabriel Marais wrote:
>>
>> I have been receiving some major ssh brute-forc
Well...is it really a problem though?
I mean, a good password will require how many centuries of effort to
brute force? I've never seen a single IP (or even a range of IPs)
trying to brute force the same user account over more than a day, much
less the huge amount of time required the crack the p
On Mon, 11 Aug 2014, Paul S. wrote:
It would appear you've done your part in trying to reach out (and
subsequently failed), so the next step to go is dropping all traffic from it.
Nothing wrong with trying to protect your own customer from people who cannot
be bothered to do their own due dili
On Aug 10, 2014, at 1:28 PM, goe...@anime.net wrote:
> On Mon, 11 Aug 2014, Paul S. wrote:
>> It would appear you've done your part in trying to reach out (and
>> subsequently failed), so the next step to go is dropping all traffic from it.
>>
>> Nothing wrong with trying to protect your own cu
Folks -
ARIN recently changed its lockbox service provider, and hence now has a
new mailing address for payments. If you coordinate the registration services
payments for your organization, it is worth confirming that payments are now
going to the new address (per attached).
FYI,
/John
On Aug 10, 2014, at 2:05 PM, Bill Woodcock wrote:
>> It would be nice if allocations would be revoked due to invalid/fake contact
>> info.
>
> That’s been debated many times, in most of the RIRs, and has not resulted in
> any persistent policies that I remember offhand. The tide may turn, as i
On Aug 10, 2014, at 1:28 PM, goe...@anime.net wrote:
> On Mon, 11 Aug 2014, Paul S. wrote:
>> It would appear you've done your part in trying to reach out (and
>> subsequently failed), so the next step to go is dropping all traffic from it.
>>
>> Nothing wrong with trying to protect your own cu
In message , Owen DeLong
writes:
>
> On Aug 10, 2014, at 1:28 PM, goe...@anime.net wrote:
>
> > On Mon, 11 Aug 2014, Paul S. wrote:
> >> It would appear you've done your part in trying to reach out (and
> >> subsequently failed), so the next step to go is dropping all traffic from
> >> it.
> >>
>
On Sun, 10 Aug 2014, David Conrad wrote:
On Aug 10, 2014, at 2:05 PM, Bill Woodcock wrote:
It would be nice if allocations would be revoked due to invalid/fake contact
info.
That?s been debated many times, in most of the RIRs, and has not resulted in
any persistent policies that I remember o
i have numerous servers that must have open ssh access to everyone in
multiple datacenters for several hundred users from many different and
varying origins that change frequently. whitelist/blacklisting would be
a nightmare.
i use a PAM module that automatically adds every new ssh connection
Good luck getting action from foreign LE through the mlat system
You might get a response, oh, in the next two years or so. IF you can find
local LE willing to push the case forward.
Beyond that while RIRs are not the internet police they do owe it to the
community to be more vigilant on dud cont
I have found the scaling is better if you make it the abusing providers problem
to contact you. Whenever a range gets blocked, the bounce message tells the
mail originator to take their money and find a new hosting provider that does
not support/tolerate spam. When legitimate originators have co
On Mon, Aug 11, 2014 at 9:06 AM, Tony Hain wrote:
> I have found the scaling is better if you make it the abusing providers
> problem to contact you.
It scales BEAUTIFULLY .. until your peer in support starts to yell at
you about the off the scale ticket volume you've managed to dump on
him with
Hello NANOGers!
We are once again approaching the annual NANOG election and appointment time.
In addition to the Call for Nominations message, the following is an overview
and timeline of the actual election process. We encourage those in the
community who are not currently NANOG Members to con
21 matches
Mail list logo
