Warning I am not known as security expert so do not follow this advice unless mods like it.
This is my first draft and I will improve it iff mods like.

good luck in any case.


DETECTING INTRUSION WITHOUT LOGS

PREAMBLE
This document may be modified to include your input. But I do not want any posts that people should use a logger please.....this is for newbies and kept (kind of) simple. If you follow anyone's advice on this thread you do so entirely at your own risk...but we care for you. This document is for local and external intrusion without resorting to logs. Logs are sometimes harder to translate.....My way still requires effort. I assume you have a home based computer and not a business. If you are business you can still follow these ideas but I suggest you consider professional advice which is tax deductible etc.

The steps below require you use a Knoppix cd...and you need to use the same cd for a year or more...and if you use a later one, you need to reset the base. More on that later. The important thing is knoppix has chkrootkit, md5sum, cfdisk, qtparted and partimage. It currently lacks clamav on cd version 3.7. As knoppix is easy to get I am not recommending alternatives.

Your system may already have these tools but you are NOT to use them because we agree you may have a compromised system....even if you don't, we use the knoppix cd tools as we can guarantee they have not changed.

That does not stop us from installing those tools, if fact, the existence of chkrootkit can lead some easy detective work, heh heh.

CREDITS
Here is where I give you credit for simple stuff...or for helping to make my stuff more simple.
Linux format magazine
LQ user Mara for her post
http://www.linuxquestions.org/questions/answers/299

LQ user unSpawn for the biggest collection to give you a bit to think about
http://www.linuxquestions.org/questi...threadid=45261

LQ user Capt_Caveman especially false positives here
http://www.linuxquestions.org/questi...hreadid=276980
http://www.linuxquestions.org/questi...hreadid=235270


Linux Troubleshooting Bible by C Negus and T Weeks
....for the idea of using RPM database checks....that I changed to md5sums for all distros.


STAGE 1
Lets assume you have intrusion right now. Go to a firewall site and see what ports are open and pay attention to any you KNOW you did not open. Some games need certain ports so check out their dox please before wasting time rebuilding your computer. Some file sharing needs open ports as well.

Have you been regular in checking your firewall in the past?

More on Firewalls below.

STAGE 2
Use the Knoppix chrootkit tool. Risk assess if you are to update its database, as Knoppix can use the internet. We want to know that you can confirm the intrusion for cracker exploits. (See www.chkrootkit.org)

LQ user Capt_Caveman and others report you may get FALSE POSITIVES....these look like intrusion but nothing to worry about it. So do a search at LQ for the kits detected/ports infected to see if it is a false positive. I don't like to say that something is a false positive.

STAGE 3
Download and install Clamav (or another anti-virus program) and update its database. We want to know that you can confirm the intrusion is a worm. (See www.clamav.net). Knoppix does not have it.

More on Clamav below.

STAGE 4
Now you either agree you have intrusion or a false positive. Since we are agreeing you have intrusion....shut down the internet and inform your friends via the phone your research.
Email may be vulnerable and less personal.

What if all is ok? I suggest you still rebuild your software with or without loggers so you have the skill and the resources when you are attacked. Broadband users can expect to be attacked more than dial-ups but you need a plan to act....not necessarily my plan....he cries.

STAGE 5
Now save any non-executable file that you know is safe and that you NEED. eg your text documents with a read only status and knoppix says has no immutable control bit.
Use command lsattr on your knoppix cd.

More on lsattr below.

STAGE 6
Now we start the rebuild...as we can not trust any file that does not conform to stage 5.

STAGE 7
Research how you are going, from now on, to backup your downloads or big files. If you are like me, do not download large files because I am still on dial up, you may be able to get away with just partimage and burning cds for other files.

STAGE 8
Research how your distro puts data in various folders and see what sizes to have for a new partition table in order to use a partition image tool off Knoppix.

Create the new table with at least one spare partition big enough to hold 50 per cent of all data you will install.
HINT I have one partition that I never image, files in this area are either temporary or get burnt to cdr.
This is where I put my partition images.

Use the knoppix partition tool cfdisk to create the new table......or you can use Knoppix graphical qtparted tool. NO matter which tool you used, keep a record of output of cfdisk on paper.

STAGE 9
Now install your operating system and do NOT connect to the net at any stage of the install.

STAGE 10
After install each partition is to be imaged, I use image 1a 2a 3a to refer to each partition.
I keep a log of what are the key changes on each image. I write a todo list for the future image.

This is my rough howto use partimage
http://www.linuxquestions.org/questi...hreadid=161771

STAGE 11
Now we create BASE files of md5sums of important local files that MAY become intruded in the future.

All folders on a fresh install from correctly downloaded cds or official cds are trusted so their md5sums are trusted....but we need to use the Knoppix tool md5sum so we can trust it for future use.

Always use the same cd of knoppix for doing your md5sums until your hardware or settings no longer work.

Keep your initial images and then on the future knoppix cd redo md5sums creating a new set of base files. Got the idea for later knoppix cd? Unless you have dramatic changes I guess your current cd should be good for a year or more.

The min folders to create base files are
/bin
/etc
/sbin.
Others more experienced may want to do /usr/bin and /usr/sbin but without good records of what you installed and knowing what files are changed....you may get frustrated.

For the folder /etc...these files are likely to change due to you making changes in configurations in some areas. But that area is important because it has passwords and group names and firewall settings.

We are going to run the md5sum command using knoppix and creating the file onto a floppy as total size of files about 150 Kb.

If you have no floppy run knoppix toram if you have 1G of ram and use k3b to burn this file from a ram directory area to cdr. Or create the files to your spare MOUNTED partition.
eg the ouput command will change to > /mnt/sda6/binbase (or sbinbase etc)
And then reboot to burn the cdr.

Experienced users know they can create the md5sums by doing all folders in the one command like this
/mountedpathway/md5sum /bin/* /etc/* /sbin/* > /mnt/floppy/base

But lets assume you prefer simple commands ....so we explain these commands instead
md5sum /mnt/sdaX/bin/* > /mnt/floppy/binbase
md5sum /mnt/sdaY/etc/* > /mnt/floppy/etcbase
md5sum /mnt/sdaZ/sbin/* > /mnt/floppy/sbinbase

[ Change sdaX to hdaX if you have IDE drive or hdbX etc depending on your fstab]

Lines 1 to line 3 use the same command to generate md5sums or algorithms for each file under that folder....you will get error outputs if you try it without su powers.
You will also get error output for files not summed as they were sub-folders. We can ignore the sub-folder errors as the real files that exist lower down still are summed.

The pathway for your files are likely to be different to mine and how to know what to use?
Knoppix to the rescue....left hand click on each partition icon and allow the file manager to appear. Now experienced users will know their /etc/fstab but trust me...do it to confirm please.
After clicking on each partition icon....some are likely to be not needed. For example my /boot is on its own partition....and I have a number of backup partitions.
so my command for the top line is
md5sum /mnt/sda3/bin/* > /mnt/floppy/binbase..... due to my live system having / mounted on /dev/sda3 but if I want /usr stuff I need to use a different partition. My etc and sbin are on the same partition mentioned.

But your knoppix will tell you. To confirm...use the file manager to navigate to /mnt and click on each partition showing. Bear in mind that you have already clicked on those icons to "mount" them.

What you are looking for is if "bin" is showing....drilling into to it gives you a list of files.
The / partition will have all the folder names but if you created /bin on its own partition drilling into /bin on the / partition with /mnt/sdax or /mnt/hdax will fail. Do you get the idea?
So when you can see which allows drilling down...note its pathway for the md5sum command.

The > means create a file if it did not exist or overwrite the file if it does exist.
Knoppix has an easy way of mounting a floppy. Insert a blank floppy and RIGHT click on the floppy icon and select the option MOUNT. Or just left hand click on the icon allow the file manager to load and exit from that if you are low on resources.

/mnt/floppy/filename are the respective pathways and filenames created. Feel free to be more exciting with your names. But remove floppy after unmounting it and write protect its tab.

Continue the process if you wish to do /usr/bin and /usr/sbin. Some distros also install software to /opt.....I personally think we will catch the intruder with only the 3 folders.

STAGE 12
Now start to write down what is on the next image and do it....and adjust your configurations etc.
Then repeat stage 10 for each changed partition...ie new image 1b 2b 5b etc

STAGE 13
Finally we are ready to do our first integrity or file change check.
Remember every change to a file in those 3 folders will generate a new md5sum.
Now we diverge...those who want to generate the new md5sums and instantly check the base files can do so by reading the man md5sum.

I prefer a slower step...into my mounted partition to use knoppix (sda6)....I insert my base files...remember do not have them there and rely them in case an intruder can play with them...then I generate my latest image md5sums but the output for me is that new directory
eg
md5sum /bin/* > /2/binimage2

STAGE 14
Now use the knoppix graphical comparison command....kompare.
Load your base file and the new md5sum for the respective folder.
With luck you will have no changes in /bin and /sbin.
If there are changes, did you keep a record of what security updates you downloaded for your distro? binutils is likely to be one.

However, expect numerous changes to your /etc files. Now the fun starts.
If you did not connect to the internet and used trusted cds...those changed files are purely due to your efforts. To be sure randomly go into each file and confirm that its your settings.
Once you are happy....that change becomes your NEW BASE file.

Sorry its messy. But I repeat it will be messy for /etc. We pursue /etc remember because it has init scripts and the passwd file and your firewall.....hint hint.

COMMENTS ONE
Its possible you may change things and install software and do 2 or 3 images before connecting to the internet. So you can jump to the latest of these to become your BASE files.

And then its likely you are going to update your security vulnerabilities (if any) and other software...all of which could lead to changed files.

Therefore, you are not to browse or wander around the net....until you disconnect...save the image check for changed files.....then browse the net...testing firewall etc.

When you decide you need to update software....you restore the last image and then and only then do you do the updates....that minimises you trying to remember what you did to cause a change to a certain file.

HINTS ONE
Now to make it easy to detect intrusion we could try the following

(a) Allow your file manager to always show hidden files....the intruder does not like that and may change it.

(b) In your default directory folder...likely to be /home/yourname install chkrootkit...intruders are likely to delete it and hope you don't spot it.

(c) KDE CONTROL CENTRE

Disable KDE wallet
Disable KDE abilitly to remember passwords
Disable autocompletion


FIREWALL TESTING
Any trojan or software that has enabled a open port in your firewall....who cares how it was done....can be detected by independent firewall testing sites. Use your web browser to go to these sites and check for one that suits your needs....I have put them in the order I like the best. There are more sites you may recommend.

www.auditmypc.com
www.pcflank.com
www.grc.com

Test your firewall before doing any significant financial transactions.

Test your firewall on a regular basis....once a month for dial ups as a guide. Daily for broadbandits.

Test your firewall before saving an image with partimage or backup software.

FIREWALL SHOWS OPEN PORTS (opinion needs some understanding)

Post your firewall script if you don't understand it but as LQ user MARA suggests, hide your IP address and any details of your ISP that may cause some further intruder getting free info.

see Mara's post in credits please.

It is preferred you understand how your firewall works but if you think you have intrusion it is better to have it confirmed than to ignore it.

Unless you have a server.....you should consider reducing open ports to the absolute min.

So, having a snapshot of what your old settings were is discussed in the CHANGED FILES section.


FIREWALL SHOWS pings WORK (opinion needs some understanding)
This is not proof of intrusion but unless your ISP needs to ping you, turn it off.

How?
Your distro may use a graphical tool to set up the firewall....but if you know where it is...you can edit the file for this line to be added or amended to:

sysctl -w net.ipv4.icmp_echo_ignore_all=1

Note...to turn ping on we can no longer ignore all so ping on needs the last bit ....all=0

You could have this command in your /etc/rc.d/rc.local file or another file that is run after your firewall is run....oops getting messy.

lsattr
man lsattr claims its for ext2 file system but it works on my reiserfs?

eg [name@localhost ]# lsattr /bin/* short list
----i-------- /bin/login
------------- /bin/awk
top line has an (eye) flag shows immutable set and likely to be intrusion
bottom line is normal

Immutable means that root can not change the file.

Hint...Therefore it is better you have none so you can spot any change and any change is bad.

CLAMAV
TODO a quick list of how to install and use.
one tip I might add here is do not run
clamscan -r / as that scans everything which means it scans the /proc folder which is virtual.
so you need to do this clamscan -r /bin (then /etc and so on)

If you run any servers I would leave ping up.

Its only real use is for users to be able to see if your system is alive or not, so if they are having issues with your services they can get your servers pulse.

a good thing is to allow very limited ping replies although I can take advise on how limited is good enough

Disabling ICMP at the host level does little to nothing to secure it, and plenty to break it... Don't block ICMP. TCP/IP needs it to work correctly.

I don't know who or what started this annoying little myth, but I wish people who don't understand IP would stop giving advice about it (and I'm not referring to the OP specifically, as I'm sure he/she is just repeating what he/she has heard elsewhere).

if you don't want your system to show it's up and running block ping and traceroute? what's wrong with that?

Nothing as long as you understand what you're doing and block select ICMP types that are unsolicited. Many who don't will completely block ICMP traffic which can cause several different connectivity issues that can be hard to diagnose (like MTU negotiation problems). If you're running a server with open ports, then it's about as effective as putting a lock on a screen door. If you're trying to completely 'stealth' a system then I can at least see the logic, I just don't particularly agree with it either.

thanks for the feedback.

ahh, should I edit this or not?

am I wasting your time or not?

cheerio

IMHO, this should be enough:

btw where can I see how IPT can set different ICMP msg types?

for now I have this:
net.ipv4.tcp_max_syn_backlog = 1280
net.ipv4.conf.all.accept_source_route = 0
net.ipv4.ip_forward = 1
net.ipv4.icmp_echo_ignore_broadcasts = 1

First off, I'd say anything of what you wrote is usefull cuz getting attention for and talking about this always is. I'd like to encourage you to keep it up to date as your knowledge (and wisdom, cuz knowledge ain't worth zilch w/o wisdom..) expands. I hope I can add a wee bit here. Before I dive in here's some things to keep in mind (which is a rerun of what I'll usually say, sorry):
- Stay calm. Panic leads to stress, stress leads to anger and, well, what anger leads to we all know :-]
- Think before you act. While easier said than done, some rash actions can lead to 'disturbing the crime scene' whatever that means from alerting the cracker to changing timestamps to overwriting data. Also some actions won't even get you anywhere like using /bin/ps when there's a process hider active. Common sense and all that.
- Be prepared. If you do something for the first time, chances for getting it wrong are optimal. So increase your mana by practicing. Get your toolkit together and keep it up to date. Practice, practice, practice.
( Minimally practice against a known clean box a few times. If you're confident you got it right, set up your own testbox (on your own LAN, right, not someone elses) with some rootkits (wouldn't hurt to actually try cracking that box). If that went well Google for Honeypot.org's SOM and replay those cases. )
- Warn others. Nothing worse than ppl continue using the suspected system. Warn ppl (from another box!) to keep and stay off. Don't save binary data to remote systems. If you have trust relations with remote systems and networks: warn those network or sysadms. If you find something 'good' consider warning CERT and posting on SF etc, etc.
- Know your priorities. There are no valid reasons to continue working on things, initiate backups or care for vanity issues like system uptime. Any reasons for putting off investigation and recovery are shortterm issues and without value, meaningless, illogical and only serve to show you're a bad admin and a bad netizen. They will also lessen the chance of success with respect to forensics. Focussing on system recovery is a longterm goal.
- Stay off the suspected system (as long as you can) during assessment. This really is THE trade-off: which 'evidence' to catch. On the one hand capturing live process data can tell a lot about the status of the box but needs you to perform commands usually as privileged root user. With the right tools you might be able to capture data but by logging in and running processes yourself you'll disturb the 'crime scene' beyond recovery. On the other hand by instantly powering off the box using the power button instead of a controlled shutdown (which admittedly doesn't work well for colo'ed boxen) and backing up disks with 'dd' to another box you lose the capabilities to capture live process data but gain a 'clean' crime scene no one can touch. Then you can mount the images (not on the suspected box!) read-only and start investigating. Since you're the only captain on the ship, the decision is yours and yours alone. Capturing live process data usually is considered 'easier' to perform and less time consuming compared to an 'autopsy' (as forensics ppl will call scraping data off a dead system).

...and most important of all:
- DONT TRUST ANYTHING Due to subversion any and all output can not be trusted. No shown irregularities does not mean they're not there!!!


STAGE 1
Lets assume you have intrusion right now.
No, let's assume you've got a box you *suspect* :-]

Go to a firewall site and see what ports are open and pay attention to any you KNOW you did not open.
Before you scan it would be good to know what the purpose of the box is so you kinda know what to expect. Next to that this step can't produce much 'evidence': if services are hidden (no open ports) or firewalled (on the box or along the route) it won't do much good.
Using remote Nmap / scan service. Don't access URI's from the suspected box, instead use another workstation. Scanning may alert ppl on the box, so if you're gonna do this, make your next moves as swift as possible. Luckily you have the steps printed out & at hand and practiced what you need to do numerous times, so, no sweat, eh? :-]


STAGE 2
Use the Knoppix chrootkit tool.
This means (having a box with a floppy drive or CDROM player in it and), logging in on the box and mounting stuff.
Before you continue it would be wise to copy all auth files login records and logs to a safe box and inspect them. This implies you did set up proper system and application logging beforehand. Nothing in the logs doesn't mean nothing ain't there. Next run kern_chk (see Samhain site). Caveat: kern_chk needs to be compiled for your running kernel. If you've got Aide, Samhain or a Linux package manager that allows for verifying checksums now would be a good time to run it :-]

Mounting stuff. Use mount '-n' to not write to /etc/mtab. Chkrootkit (CRT). Use option '-p' to change $PATH to where your binaries are at, '-d' and capture it to somewhere safe(r) like fd or shm using 'tee'. CRT uses deprecated 'ifpromisc'. Use my 'ip' patch for better detection capabilities if you like or run Rootkit Hunter as it uses 'ip' binary (but doesn't show which devices are in promiscuous mode unless you explicitly grep the log for it). Also note running CRT wil change MAC times for instance because of running 'strings'. Anyway, largest caveat for all tools like RKH and CRT: using fixed find paths, names and such (SIGINVISIBLE).


STAGE 11
Now we create BASE files of md5sums of important local files that MAY become intruded in the future.
If you've got a Linux package manager that allows for verifying checksums, copy the databases to ro media right after the install finishes.
Skip checksumming manually and use Aide, Samhain, Integrit, Osiris or even tripwire.


HINTS ONE
The usual: system hardening. Watch your vendors security alerts and act swift. Make sure you verbose logging, process logs (Logwatch etc,etc) and *read* the reports. Don't run services you don't need to run. Comb over *all* config files. Don't allow inbound connections to services if you don't have to. Run whatever you need to run with least privileges. Disable shells for users that don't need one. Use separate auth files for FTPd's and such. Update regularly from trusted sources. Harden your kernel with Grsecurity if you run2.4, learn to use SELinux if you run 2.6 or at least disable some capabilities using 'lcap'. Have a recovery strategy and actually *test* it. Regularly audit your system and services.


All for now.
Keep up the good work.

thats a wonderful reply I will need to study it b4 edit.

I would like to comment on some remarks regarding ping blocking and related matters

In my firewall section I mention
Unless you have a server.....you should consider reducing open ports to the absolute min and what I should have said in my preamble is that I am on dial up and have no server functions exept loopback for the printer via Cups.
I still recommend no ping.....for those like me as its one of the tests by pcflank.
And it was recommended as a tip in Linux format magazine in the Tips section.....not by a letter writer.

In some respects that means I have a narrower view than those who have local networks and your kind advice and commonsense I might add on warning others of a suspect machine......is more the big boys and girls. I will have to be more transparent in my preamble.

That would also clarify why I assume ppl may have a cdrom.......and its essential to my way to have such a device.....and its local not networked.

Anyhow I think its super the amount of quality feedback I have had on my idea......no matter how limited I made it by still being on dial up.......

I might add that local intrusion is stil a big issue for companies with disgruntled employees or curious family doing things that should not but you already knew that.....

sorry and thanks again