[CentOS] CentOS-announce Digest, Vol 137, Issue 1

[centos-announce-request]

Send CentOS-announce mailing list submissions to
centos-annou...@centos.org

To subscribe or unsubscribe via the World Wide Web, visit
https://lists.centos.org/mailman/listinfo/centos-announce
or, via email, send a message with subject or body 'help' to
centos-announce-requ...@centos.org

You can reach the person managing the list at
centos-announce-ow...@centos.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of CentOS-announce digest..."


Today's Topics:

   1. CEEA-2016:1375 CentOS 7 qla2xxx Enhancement Update (Johnny Hughes)


--

Message: 1
Date: Thu, 30 Jun 2016 17:45:38 +
From: Johnny Hughes 
To: centos-annou...@centos.org
Subject: [CentOS-announce] CEEA-2016:1375 CentOS 7 qla2xxx Enhancement
Update
Message-ID: <20160630174538.ga46...@n04.lon1.karan.org>
Content-Type: text/plain; charset=us-ascii


CentOS Errata and Enhancement Advisory 2016:1375 

Upstream details at : https://rhn.redhat.com/errata/RHEA-2016-1375.html

The following updated files have been uploaded and are currently 
syncing to the mirrors: ( sha256sum Filename ) 

x86_64:
08a6bc752e27c15e9416e7e517f3d8196230222a0b48500feabb503a51526233  
kmod-qla2xxx-8.07.00.33.07.3_k-1.el7_2.x86_64.rpm

Source:
8c3640fe32a123a6f1630d3f3be4007be5c3a3bcbac94a6ea37c5ff21b921456  
qla2xxx-8.07.00.33.07.3_k-1.el7_2.src.rpm



-- 
Johnny Hughes
CentOS Project { http://www.centos.org/ }
irc: hughesjr, #cen...@irc.freenode.net
Twitter: @JohnnyCentOS



--

___
CentOS-announce mailing list
centos-annou...@centos.org
https://lists.centos.org/mailman/listinfo/centos-announce


End of CentOS-announce Digest, Vol 137, Issue 1
***
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Securing RPC

[Brian Mathis]

You need to setup a firewall (either a separate hardware box or iptables on
this server) that allows only those IPs you need to connect to those
ports.  You should never expose a service like this to the entire Internet.

~ Brian Mathis
@orev


On Fri, Jul 1, 2016 at 8:38 AM, Leon Vergottini 
wrote:

> Dear Community
>
> I hope you are all doing well.
>
> Recently I have been receiving several complaints from our service
> provider.  Please see the complaint below:
>
> A public-facing device on your network, running on IP address
> XXX.XXX.XXX.XXX, 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).
>
>
>
> Unfortunately, I cannot disable NFS which lies at the root of this
> problem.  In addition, I am struggling to find a proper tutorial of moving
> NFS from udp over to tcp.
>
> May I kindly ask you to point me in a direction or provide me with ideas on
> how to nail this thing in the 
>
> Kind Regards
> Leon
> ___
> CentOS mailing list
> CentOS@centos.org
> https://lists.centos.org/mailman/listinfo/centos
>
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Securing RPC

[Eero Volotinen]

Are you really exposing portmapper (RPC) and NFS to public network?

Eero

2016-07-01 9:38 GMT+03:00 Leon Vergottini :

> Dear Community
>
> I hope you are all doing well.
>
> Recently I have been receiving several complaints from our service
> provider.  Please see the complaint below:
>
> A public-facing device on your network, running on IP address
> XXX.XXX.XXX.XXX, 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).
>
>
>
> Unfortunately, I cannot disable NFS which lies at the root of this
> problem.  In addition, I am struggling to find a proper tutorial of moving
> NFS from udp over to tcp.
>
> May I kindly ask you to point me in a direction or provide me with ideas on
> how to nail this thing in the 
>
> Kind Regards
> Leon
> ___
> CentOS mailing list
> CentOS@centos.org
> https://lists.centos.org/mailman/listinfo/centos
>
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

[CentOS] Securing RPC

[Leon Vergottini]

Dear Community

I hope you are all doing well.

Recently I have been receiving several complaints from our service
provider.  Please see the complaint below:

A public-facing device on your network, running on IP address
XXX.XXX.XXX.XXX, 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).



Unfortunately, I cannot disable NFS which lies at the root of this
problem.  In addition, I am struggling to find a proper tutorial of moving
NFS from udp over to tcp.

May I kindly ask you to point me in a direction or provide me with ideas on
how to nail this thing in the 

Kind Regards
Leon
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] [CENTOS ]IPTABLES - How Secure & Best Practice

[Ned Slider]

On 30/06/16 23:19, Mike wrote:

Ned,

Thank you very much for the response.
Great example following through on the premise.
It sounds like I need to have a better understanding of the traffic
patterns on my network to know the optimal order for iptables
filtering rules.



Try running:

iptables -nv -L

which will show you in the left hand column a counter for the number of 
packets that has matched each rule. That will give you an exact 
breakdown of how often your rules are being hit.



My brief example -

Premise:  I want to limit outsiders from interfering with LAN client machines.
So, I have the following rules regarding forwarding traffic:

-A FORWARD -m state --state INVALID -j DROP
-A FORWARD -p tcp --tcp-flags ACK,FIN FIN -j DROP
-A FORWARD -p tcp --tcp-flags ACK,PSH PSH -j DROP
-A FORWARD -p tcp --tcp-flags ACK,URG URG -j DROP
-A FORWARD -p tcp --tcp-flags FIN,RST FIN,RST -j DROP
-A FORWARD -p tcp --tcp-flags SYN,FIN SYN,FIN -j DROP
-A FORWARD -p tcp --tcp-flags SYN,RST SYN,RST -j DROP
-A FORWARD -p tcp --tcp-flags ALL ALL -j DROP
-A FORWARD -p tcp --tcp-flags ALL NONE -j DROP
-A FORWARD -p tcp --tcp-flags ALL FIN,PSH,URG -j DROP
-A FORWARD -p tcp --tcp-flags ALL SYN,FIN,PSH,URG -j DROP
-A FORWARD -p tcp --tcp-flags ALL SYN,RST,ACK,FIN,URG -j DROP
-A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
-A FORWARD -i LAN-NIC -s 10.100.100.0/24 -o INET-NIC -m state --state
NEW -j ACCEPT
-A FORWARD -i INET-NIC -o LAN-NIC -d 10.100.100.0/24 -m state --state
NEW -j ACCEPT



The first thing I would do is move your ESTABLISHED,RELATED rule to the 
top of the chain. Once you've accepted the first packet you may as well 
accept the rest of the stream as quickly and efficiently as possible as 
you've established the connection is not malicious.


What is the default policy for the FORWARD table? Assuming it is accept 
then the last two accept rules can be removed.



But I don't know if this is interfering with, or delaying DNS requests
between LAN clients and the DHCP server.


The FORWARD chain only processes packets being router through the 
machine, so in your case that would be packets from the lan destined for 
the wan, or packets from the wan destined to the lan. All internal lan 
traffic such as dns requests from clients to the dchp server are 
internal and not subject to the FORWARD chain. Of course the dhcp server 
probably forwards those dns requests to a dns server outside of the lan 
so those requests will pass through the FORWARD chain at that point.


Assuming your hardware is not crippled or the cpu constantly overloaded, 
it's not going to have any problems routing traffic through your rule 
set. But if you want to ensure particular traffic is processed quickly 
and bypasses all other rules, place a rule matching it near the top to 
accept that traffic. For example, if you trust all traffic coming from 
inside your network that is destined for the outside and want to pass 
that traffic without testing for all those tcp flags (and any other 
rules), you could do something like:


-A Forward -p all -i LAN-NIC -o INET-NIC -j ACCEPT

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos