Is the ovirt-infra list set to reject email from non-members? That would
result in the behaviour you describe (and would be an error that would
need to be fixed).
Thanks,
Dave.
On 06/28/2016 10:24 AM, Michael Scherer wrote:
Le mardi 28 juin 2016 à 10:14 -0400, Dave Neary a écrit :
> FYI.
> ----- Forwarded Message -----
> From: Hervé Leclerc <herve.leclerc(a)alterway.fr>
> To: Dave Neary <dneary(a)redhat.com>, Infra(a)ovirt.org
> Cc: Arnaud CAZIN <arnaud.cazin(a)alterway.fr>, Stéphane Vincent
<stephane.vincent(a)alterway.fr>
> Sent: Mon, 27 Jun 2016 13:06:17 -0400 (EDT)
> Subject: Re: [oVirt-Infra] : New Gateway
>
> Hello,
>
> Did you made the changes asked ?
> Can you please give us a status on your actions.
I stopped rpcbind, which sould solve the problem.
But I wonder why we didn't got the mail in the first time, it didn't
appear on the list, nor in moderation.
> Regards
>
>
>
> Hervé Leclerc
> CTO
> Alter Way
> 227 Bureaux de la colline
> 1 rue Royale - Bât. D
> 92210 Saint-Cloud
> France
> *+33 141168336*
> +33 6 83979598
>
>
>
> `like a halo in reverse`
>
>
>
> On Sun, Jun 26, 2016 at 3:54 PM, Hervé Leclerc <herve.leclerc(a)alterway.fr>
> wrote:
>
>> Hello
>>
>> Your vm
alterway02.ovirt.org is participating in a ddos attack. Could
>> please correct the problem rapidly !
>> eg.
>> iptables -A INPUT -p udp --dport 111 -j DROP
>>
>>
>>
>> Regards
>>
>> Original message
>> A public-facing device on your network, running on IP address 89.31.
>> 150.216, operates a RPC port mapping service responding on UDP port 111
>> and participated in a large-scale attack against a customer of ours,
>> generating responses to spoofed requests that claimed to be from the attack
>> target.
>>
>> Please consider reconfiguring this server in one or more of these ways:
>>
>> 1. Adding a firewall rule to block all access to this host's UDP port 111
>> at your network edge (it would continue to be available on TCP port 111 in
>> this case).
>> 2. Adding firewall rules to allow connections to this service (on UDP port
>> 111) from authorized endpoints but block connections from all other hosts.
>> 3. Disabling the port mapping service entirely (if it is not needed).
>>
>> More information on this attack vector can be found at this third-party
>> website (we did not create this content):
>>
http://blog.level3.com/security/a-new-ddos-reflection-attack-portmapper-a...
>>
>> Example responses from the host during this attack are given below.
>> Date/timestamps (far left) are UTC.
>>
>> 2016-06-25 22:46:44.588895 IP 89.31.150.216.111 > 74.201.57.x.80: UDP,
>> length 628
>> 0x0000: 4500 0290 0000 4000 3111 d378 591f 96d8 E.....@.1..xY...
>> 0x0010: 4ac9 3924 006f 0050 027c dc65 6572 0a37 J.9$.o.P.|.eer.7
>> 0x0020: 0000 0001 0000 0000 0000 0000 0000 0000 ................
>> 0x0030: 0000 0000 0000 0001 0001 86a0 0000 0004 ................
>> 0x0040: 0000 0006 0000 006f 0000 0001 0001 86a0 .......o........
>> 0x0050: 0000 ..
>> 2016-06-25 22:46:44.588939 IP 89.31.150.216.111 > 74.201.57.x.80: UDP,
>> length 628
>> 0x0000: 4500 0290 0000 4000 3111 d378 591f 96d8 E.....@.1..xY...
>> 0x0010: 4ac9 3924 006f 0050 027c dc65 6572 0a37 J.9$.o.P.|.eer.7
>> 0x0020: 0000 0001 0000 0000 0000 0000 0000 0000 ................
>> 0x0030: 0000 0000 0000 0001 0001 86a0 0000 0004 ................
>> 0x0040: 0000 0006 0000 006f 0000 0001 0001 86a0 .......o........
>> 0x0050: 0000 ..
>> 2016-06-25 22:46:45.048914 IP 89.31.150.216.111 > 74.201.57.x.80: UDP,
>> length 628
>> 0x0000: 4500 0290 0000 4000 3111 d378 591f 96d8 E.....@.1..xY...
>> 0x0010: 4ac9 3924 006f 0050 027c dc65 6572 0a37 J.9$.o.P.|.eer.7
>> 0x0020: 0000 0001 0000 0000 0000 0000 0000 0000 ................
>> 0x0030: 0000 0000 0000 0001 0001 86a0 0000 0004 ................
>> 0x0040: 0000 0006 0000 006f 0000 0001 0001 86a0 .......o........
>> 0x0050: 0000 ..
>> 2016-06-25 22:46:45.048963 IP 89.31.150.216.111 > 74.201.57.x.80: UDP,
>> length 628
>> 0x0000: 4500 0290 0000 4000 3111 d378 591f 96d8 E.....@.1..xY...
>> 0x0010: 4ac9 3924 006f 0050 027c dc65 6572 0a37 J.9$.o.P.|.eer.7
>> 0x0020: 0000 0001 0000 0000 0000 0000 0000 0000 ................
>> 0x0030: 0000 0000 0000 0001 0001 86a0 0000 0004 ................
>> 0x0040: 0000 0006 0000 006f 0000 0001 0001 86a0 .......o........
>> 0x0050: 0000 ..
>>
>> (The final octet of our customer's IP address is masked in the above
>> output because some automatic parsers become confused when multiple IP
>> addresses are included. The value of that octet is "36".)
>>
>> -John
>> President
>> Nuclearfallout, Enterprises, Inc. (
NFOservers.com)
>>
>> (We're sending out so many of these notices, and seeing so many
>> auto-responses, that we can't go through this email inbox effectively. If
>> you have follow-up questions, please contact us at noc(a)nfoe.net.)
>>
>> Hervé Leclerc
>> CTO
>> Alter Way
>> 227 Bureaux de la colline
>> 1 rue Royale - Bât. D
>> 92210 Saint-Cloud
>> France
>> *+33 141168336 <%2B33%20141168336>*
>> +33 6 83979598
>>
>>
>>
>> `like a halo in reverse`
>>
>>
>>
>> On Wed, Feb 19, 2014 at 10:46 AM, Hervé Leclerc <herve.leclerc(a)alterway.fr
>>> wrote:
>>
>>> Hello,
>>>
>>> Our Internet gateway is changing.
>>> Could you please change your actual gateway (*89.31.150.249*) on your
>>> machines (89.31.150.215 and 216) and vms to *89.31.150.253*
>>> Thanks
>>>
>>> Let us know when this modification is done.
>>>
>>> Cheers
>>>
>>> Hervé Leclerc
>>> CTO
>>> Alter Way
>>> 1, rue royale
>>> 9 ème étage
>>> 92210 St Cloud
>>> *+33 1 41 16 83 36 <%2B33%201%2041%2016%2083%2036>*
>>> +33 6 83979598
>>>
>>>
>>>
>>>
>>> <
http://www.alterway.fr/signatures/url/1>
>>>
>>>
>>>
>>>
>>
>
--
Dave Neary - NFV/SDN Community Strategy
Open Source and Standards, Red Hat -