[CentOS] an actual hacked machine, in a preserved state

Bennett Haselton bennett at peacefire.org
Tue Jan 3 02:30:04 UTC 2012

On 1/2/2012 9:18 AM, Les Mikesell wrote:
> On Mon, Jan 2, 2012 at 6:03 AM, Bennett Haselton<bennett at peacefire.org>  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 

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.


More information about the CentOS mailing list