Re: an actual hacked machine, in a preserved state

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



On Jan 2, 2012, at 9:30 PM, Bennett Haselton wrote:

> On 1/2/2012 9:18 AM, Les Mikesell wrote:
>> On Mon, Jan 2, 2012 at 6:03 AM, Bennett Haselton<bennett@xxxxxxxxxxxxx>  wrote:
>>> I tried SELinux but it broke so much needed functionality on the server
>>> that it was not an option.
>> Pretty much all of the stock programs work with SELinux, so this by
>> itself implies that you are running 3rd party or local apps that have
>> write access in non-standard places.  Which is a good start at what
>> you need to break in.   What apps are those (i.e. the ones that
>> SELinux would have broken) and if they are open source, have those
>> projects updated the app or the underlying language(s)/libraries since
>> you have?
> 
> So here's a perfect example.  I installed squid on one machine and 
> changed it to listen to a non-standard port instead of 3128.  It turns 
> out that SELinux blocks this.  (Which I still don't see the reasoning 
> behind.  Why would it be any less secure to run a service on a 
> non-standard port?  A lot of sources say it's *more* secure to run 
> services on a non-standard port if you don't want people poking around!  
> In general I don't think it's any more secure to run a service on a 
> non-standard port -- all it buys you is time, as it's trivial for an 
> attacker to scan all your ports, especially with a botnet -- but even if 
> it's not more secure, it certainly shouldn't be *less* secure.)
> 
> But here's the real problem.  Since I didn't know it was caused by 
> SELinux, all the cache.log file said was:
> 
> 2012/01/02 17:40:40| commBind: Cannot bind socket FD 13 to *:[portnum 
> redacted]: (13) Permission denied
> 
> Nothing indicating why.  Even worse, if you Google
> +squid +"cannot bind socket" +"permission denied"
> *none* of the first ten pages that come up, mention SELinux as a 
> possible source of the problem.  (One FAQ mentions SELinux but only as 
> the source of a different problem.)  All they do is recommend other 
> workarounds, each of which takes time to test out, and may have other 
> side-effects.
> 
> In other words, when SELinux causes a problem, it can take hours or days 
> to find out that SELinux is the cause -- and even then you're not done, 
> because you have to figure out a workaround if you want to fix the 
> problem while keeping SELinux turned on.
> 

How is it SELinux's problem? Its like running iptables with the default http ports open and then blaming iptables when you change Apache to a non-standard port.

SELinux's list of open ports is pretty extensive. You can use the semanage (part of policycoreutils-python package) to get the list of allowed ports and grep for specific items that are open by default (like http and squid):
[root@kerberos kvm]# semanage port -l | grep http
http_cache_port_t              tcp      3128, 8080, 8118, 8123, 10001-10010
http_cache_port_t              udp      3130
http_port_t                    tcp      80, 443, 488, 8008, 8009, 8443
pegasus_http_port_t            tcp      5988
pegasus_https_port_t           tcp      5989

 - Rilindo
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos


[Index of Archives]     [CentOS]     [CentOS Announce]     [CentOS Development]     [CentOS ARM Devel]     [CentOS Docs]     [CentOS Virtualization]     [Carrier Grade Linux]     [Linux Media]     [Asterisk]     [DCCP]     [Netdev]     [Xorg]     [Linux USB]
  Powered by Linux