If there was actually a system breach, there'd a lot more than what the OP posted.
I conduct first-, second-, and third-level attack and compromise analysis for a living. IMO, kernel logs don't always mean what people think they mean (at least regarding compromise). You can't just run some exploit against a kernel without having a vector (avenue of attack, which is more than likely a network service). Kernel logs don't define the endgame of security, unless it is actually a kernel-level attack, which would suggest that someone is logged in locally to the machine (although this may NOT be the case with the OP). conntrack is a kernel-level function of network connectivity, which means that anyone conducting a DoS will affect connection tracking.
You're doing this admin a disservice if you think that what he described is an actual compromise.
Looking at 'atack segfault' under Google shows the following:
http://www.google.com/search?hl=en&q=at ... art=0&sa=N
Almost ALL of those links suggest a denial of service and have similar content as the OP posted. If it quacks and waddles like a duck, its either a relative to the duck or IS a duck, IMO.
Here's a GOOD one (from
http://kerneltrap.org/mailarchive/linux ... 23/5223214):
Code:
doing a "ping -f -l 3" on my host towards my board on linus tree as of
Friday results in lots of:
nf_conntrack: table full, dropping packet.
nf_conntrack: table full, dropping packet.
nf_conntrack: table full, dropping packet.
__ratelimit: 11 callbacks suppressed
nf_conntrack: table full, dropping packet.
nf_conntrack: table full, dropping packet.
nf_conntrack: table full, dropping packet.
nf_conntrack: table full, dropping packet.
for ucc_geth on a MPC832x.
This really looks strange to me, ideas?
If this type of activity is directed against an application, there's where the segfault comes in. Regarding the 'atack' tag, I've no idea where that is coming from but to suggest that someone injected that onto the system is to pull suppositions out of thin air. People in my field actually need data to prove that something like this occurred. That's where application logs
All of this is circumstantial, since there are only kernel logs that were provided. Still...
Secondly, there's the issue of him reinstalling (because he was told to do so) without understanding the nature of the attack. There's a chance it may happen, again, within hours/days of his reinstall if he doesn't understand the who/what/where/why of the prior attack. I've seen machine owners reinstall 3-4 times and get compromised 3-4 times afterward...all because the admins didn't understand the underlying issue.
FAQ
Search
Members
Register
Login [ Anonymous ]
