The UNIX and Linux Forums  

Go Back   The UNIX and Linux Forums > Special Forums > Security
Google UNIX.COM


Security Anything involving computer security goes here.

More UNIX and Linux Forum Topics You Might Find Helpful
Thread Thread Starter Forum Replies Last Post
pc hacked naik_mit Linux 0 02-22-2006 01:18 AM
Are Your Device Drivers Wacked Or Hacked? ZOverLord Windows & DOS: Issues & Discussions 0 07-23-2005 01:35 PM

Reply
 
Submit Tools LinkBack Thread Tools Display Modes
  #1 (permalink)  
Old 10-01-2002
binhnx2000's Avatar
Registered User
 

Join Date: Jul 2002
Location: France
Posts: 78
How to know when you've been hacked

One of the most important ways to keep tou machine secure is to know when it has been broken
into. The less time hackers have on your system, the less they can do to it, and the greater you
chancens of kicking them off and repairing the damage.

The more sophisticated the hacker, the less likely you are to know what your machine has been compromised. Skillful hackers will cover their trails well, making it difficult to realize that they
have made any changes, and they can hide the fact that they are on your machine even when tou're looking at it. By hidding processes, open connection, file access, and system resource
use, hackers can make their actions almost entirely invisible. If they have hacked the root acc, they can do pretty much anything they want at the kernel level to hide their presence.

- Web Page Defacement: A popular time waster of newbie hackers (or those with an actual message) is to replace content on your web site to annoouce their successful hack. It usually
occurs on the home page itself, where it would be most noticeable. If hackers want to maintain access, they will seldom annouce their presence in this or other ways.

- Warez/Dramatic Decrease in Disk Space: Hackers wil often use your machine to store warez, hacking tools, porn and other files. They wish to have avaible or share with others. This "free"
disk space tends to be eaten up quickly, Output from df will tell you your current disk usage.

- High Network Usage: If your network activity seems high, even when you're not doing anything , someone may be using your machine to serve file or perhaps to attack other machine over
the network. Use "netstat -na" to see what connections exist.

- Contact from other administrators: If your machine is being used to launch attacke againstother machines, administrator who are being attacked may contact you and let you know. Mind
you, they may suspect you are the actual hacker, so don't expect to be greeted happily.

- Promiscuous network interfaces: If hacker want to sniff any of the network vaiable on your computer, they will put the interface into promiscuous mode. Use "ifconfig -a" to out put packet.

- Wiped/Truncated log file: Experienced hackers will remove individual lines from log files that show their inappropriate access to your system. A newbie hacker may instead simply delete
the logs entirely. Any log files that are missing chunks of time or are suspiciously erased may have been tampered with. A good way to assure that you can check these missing logs go to
additional servers . Which you can compare agianst the suspicious log files.

- Munged utmp/wtmp: Hackers may wipe out their login entries from the utmp and wtmp files
(program such as: vanish, zap, wipe...) or erase the files themselves to hide the fact the've
logged on. if you notice truncated "last" results, it is likely that the hacker simply erased the
files. Programs such as chkwtmp and chklatlog check these file for signs of tampering.

- New user on your system: New users in the password file are sure signs that someone has
compromiised yout system - most likely a newbie hacker, or one who doesn't think you'll notice
. They often use usernames that are similar to existing users to make them less noticeable,
such as lpr instead of lp, or uucp1, or name that play on hacming lingo, such as t00r or 0wn3d.

- Strange processes running: if you see processes running that you didn't start and that aren't
part of the system, they may belong to a hacker. Many programs run out of cron, so verify that
the suspicious process isn't merely a piece of the system itself. For example, slocate often
cause concern because it uses a decent amount of CPU and disk access, though it's a
legitimate (though optional) system resource.

- Unexplained CPU usage: Sophisticated hackers may hide their processes from view, or
merely name them after legitimate system program like cron, inetd or slocate, to avoid being
easily noticed. if the machine has high CPU usage, or just seems slow, it could be that your
machine is being used by hackers. Often hackers will run password cracking programs
(generally CPU intensive) on hacked computers rather than their own, relieving their machine
of the load.

- Local users have had remote accounts cracked: A hacker will often hack from one machine
to the next by following users as the access other machines. By hacking the first machine, the
hacker could watch those outbond connections and compromise the acc on the new machine.
This mean that a hack of a user on an external machine could indicate your machine may be
target soon, or your machine was already successfully hacked. In general, when one acc is
compromised, it's a good idea to check the security of all other accounts, and change
passwords during the process.

- Things just "seem-funny": Most of the hacks that are discovered started when the
administrator simply thought something was amiss and started searching. Sometimes this
leads to nonhacking-related problems, such as a failing disk, bad memory, or unannouced
networking changes, but often it leads instead to the realization that the machine has been
hacked. Put simply, if the machine is behaving other than normally, the cause should be
indentified. Hopefully, it's a hardware or software problem, rather than a hack, but there's only
one way to be sure, and that's to check it out.

What to do after a break in

Once you've discovered thst your system has been broken into, there are various remedies at
your disposal. Theories about the best way to approach recovering a machine after a break-in
differ widely, even in professional cirles. The one w present it the one we prefer, but it will not
fit all environments or needs.

Stopping the damage

The surest way to protect your machine from further harm by the hacker is drastic but effective:

1) Turn off all network interfaces (ethernet, ppp, isdn, etc...). This remove the ability of the
hacker to do anything else interactive tou your system, while running processes will continue.

2) Take the system into single-user mode. Turn off all official root processes and all user
processes. Anything left over may be from the hacker.

3) Reboot the machine from a pristine Linux boot floopy. By booting a clean boot floopy (or CD
ROM), you are now sure to be running a minial and untampered version of the Linux kernel,
and can now roam though your system (mounted read-only, preferably) to see what changes
have been made and see how the hacker got in.

4) Begin serious damage control

Between each step, you have a chance to look at the system and see what changes have been
made by the hacker, while splicing away at the hacker's avaible countermeasures.

Assessing the Breach

One you've booted your untampered Linux kernel, you can now traverse the disks of your
system knowing that nothing can be hidden by the hacker's use of kernel changes, modules,
and so on. To prevent yourself from losing the ability to track the hacker's actions, you should
mount all of your partions in read only mode. Make carefull notes of everything you find, so you
can clean them out later.

- Find Suspicious Files/Directories: Look for directories that contain password files, hacking
tools, or anything that you didn't put on the system. These may not have been visible until you
booted the floopy kernel.

- Locate new setuserid programs: Any new setupuserid or setgroupid programs (especially
those owned by root) are extremely suspicious.

- Check timestamps: Though this is not reliable test, check for any files modified after the
suspected break-in to get an idea of what was being done.

- Read log file: Check all your log files for signs of the hacker's entry point. You may use your
log analyzing tools, but should probadly do a manual once-over of them all (especially durring
the time you belive the hacker gained access and thereafter) in case ypur tools miss important
log entries. If you have s second syslog server.

- Verify checksums: Verify the checksums of all your installed programs. It's a good idea to
compare against checksum databases from before and after the suspected break-in.

- Verify package installations: Verify the checksums of installed packages using the built-in
verify options as well. Verify that you're running the correct versions. A hacker may have
downgraded your software on your behalf, leaving you with insecure versions.

- Verify config files by hand: A quick glance at various configuration files may highlight in-
appopriate changes, such as a web server that is now configured to run as root, or additional
services in /etc/inetd.conf

- Back up yout files: Back up your files to tape or CD-ROM if you have one. If not, bring up just
enough networking to be able to copy them to another computer, making sure you don't have
any network accessible services running.

- Special Tools: More tools are becoming available to help you look at your system. One
recent intriguing suite is the Coroners Toolkits (http://www.fish.com/tcp) by Dan Farmer and
Wietse Venema. It can generate tons of (difficult to weed through) output about your system
via the "grave-robber" script, or help you look for deleted files by scanning the driver's
"unused" sections for inodes.

- Informing the Authorities: It is a good idea to let the authorities know that a breach occurred.
By being able to caculate the occurrences of successful hacks, they can warn the community
of problems on the rise.

The Linux Hacking Exposed
Reply With Quote
Forum Sponsor
  #2 (permalink)  
Old 10-01-2002
LivinFree's Avatar
Goober Extraordinaire
 

Join Date: Jul 2001
Location: Portland, OR, USA
Posts: 1,584
A lot of security-folk will tell you to clone the drive, and peek at that. For official evidence sake, let the proper authorities have the original disk that you have not tampered with.

Also, this stuf must be planned out way in advace... you shouldn't be reactive in a security policy. Everyone should be involved, as frustrating as that is bound to be: Lawyers, Managers, Technicians, Operators - everyone has something to offer.

I recommend subscribing to Bugtraq if you have the time to read it all - also, the other lists hosted by Security Focus are great. You'll get a chance to see how people are cleaning these incidents up, and see where mistakes have been made.
Reply With Quote
  #3 (permalink)  
Old 06-07-2008
Registered User
 

Join Date: Jun 2008
Posts: 4
question deleted, because answered

Last edited by kasa; 06-15-2008 at 08:17 AM. Reason: answered
Reply With Quote
  #4 (permalink)  
Old 06-10-2008
era era is offline
Herder of Useless Cats
 

Join Date: Mar 2008
Location: /there/is/only/bin/sh
Posts: 3,650
Judging from the contents of http://xe-xenical.com:80/poster/include9.txt they are using your domain to host their ads. Yes, you have been hacked.
Reply With Quote
  #5 (permalink)  
Old 06-11-2008
Registered User
 

Join Date: Jun 2008
Posts: 4
Thumbs up

question deleted, because answered

Last edited by kasa; 06-15-2008 at 08:16 AM. Reason: answered
Reply With Quote
  #6 (permalink)  
Old 06-11-2008
era era is offline
Herder of Useless Cats
 

Join Date: Mar 2008
Location: /there/is/only/bin/sh
Posts: 3,650
If at all feasible, the best thing would be if you could wipe and reinstall the servers. Stay informed on PHP security (now there's an oxymoron) and make sure you aren't running any known exploits in PHP itself or in the application you are using. If it was developed in-house, fire the developer, unless you have reason to believe that teaching her/him secure coding practices is less likely to fail than finding a qualified replacement (which is also almost certain to fail, I'm afraid).
Reply With Quote
  #7 (permalink)  
Old 4 Weeks Ago
Registered User
 

Join Date: Aug 2008
Posts: 7
Wow, this is one good reading.

Thanks,
Vaibhav
Reply With Quote
Google The UNIX and Linux Forums
Reply

Tags
linux, solaris

Thread Tools
Display Modes




All times are GMT -7. The time now is 01:08 PM.


Powered by: vBulletin, Copyright ©2000 - 2006, Jelsoft Enterprises Limited.
The UNIX and Linux Forums Content Copyright ©1993-2008. All Rights Reserved.Ad Management by RedTyger Visit The Global Fact Book

Content Relevant URLs by vBSEO 3.2.0