error.log entry

Scanning for a HP exploit.

Wonderful idea, since IPs are so unique...

"File does not exist" should be pretty obvious, and of course you should know your scripts.

If the server was actually compromised, such suspicious entries would have already been wiped.

Anders,

Someone or something is attempting to exploit an SQL Injection Vulnerability on your apache webserver.

Has more info.

Bogwitch.

Anders wrote:

CHAR(49,50,55,46,48,46,48,46,49),null,1,null,null,161,500,CHAR(112,114,111,99),

null,1,300,0,CHAR(101,99,104,111,32,73,114,111,99,107,84,104,101,87,111,114,108,

100,32,62,32,46,47,114,114,97,47,97,112,111,46,108,111,103),null,null/**/FROM/**/host/*+11111

http://83.252.171.112/portal/cacti/cmd.php?1+1111)/**/UNION/**/SELECT/**/2,0,1,1,

CHAR(49,50,55,46,48,46,48,46,49),null,1,null,null,161,500,CHAR(112,114,111,99),null,1,

300,0,CHAR(101,99,104,111,32,73,114,111,99,107,84,104,101,87,111,114,108,100,32,62, 32,46,47,114,114,97,47,97,112,111,46,108,111,103),null,null/**/FROM/**/host/*+11111

Bogwitch skrev:

Thanks for the link. I did an search for SQL-inject and found a little on Wikipedia to.

/Anders

Mostly the IP's is unique

I use Rkhunter to check the system to see if there is any differences. It find nothing, and I have system chrooted so it is difficult to any one not familiar to the system to do anything on it.

/Anders

In a dialup network? Very unlikely. Most likely you're now just blocking some innocent users / potential customers.

Better use tripwire. It compares your system against a known trusted state, not different views of an untrusted state.

Ah... the first good sign that nothing happened. Apache utilizes chroot() properly, thus it's really pretty unlikely that anything could have happened.

Did you do a whois lookup to determine this? It is your server, and your access rules apply, but don't be overly (or under) reactive.

The O/P showed only one IP in the log - 213.215.135.124 which does not resolve. A whois query shows the address to be assigned to COLT Internet Italy, and sub-assigned to Centro Interregionale di Studi e Documentazione in Rome.

What-ever. Colt Telcom, whether from France, Germany, Italy, Sweden, or the UK has never responded to my abuse complaints. My users have not complained to me about the resulting blocks that were put in place. If that inconveniences some customer of Colt Telcom, they can discuss the problem with _their_ ISP.

Assuming even a halfway competent r00tkit - yes.

Your headers look like Fedora Core 5 that is being kept up to date. There are two windoze-wannabe "anti-malware" tools available (chkrootkit and rkhunter) as well as another not as easy to categorize (zeppoo). You need to actually _read_ the scripts of the first two to see what they are attempting to do. While extensive, both have a rather horrible coding style, and are easily fooled. This means both false positives (declaring something innocent to be a problem) AND false negatives (missing things that are important). In my opinion, neither is worth the CPU cycles or disk space they waste. If they do actually find a real root kit, you have been the victim of inept skript kiddiez.

which, if you read the documentation clearly means nothing.

There are three types of mal-ware detectors. The first, like chkrootkit and rkhunter, look for indications that have been seen in the past as evidence of a rooted system or the root kit itself. For example, both of those "tools" look for the "55808" worm - a port scanner trojan from

2003 - by looking for a file named /tmp/.../a or /tmp/.../r. If the file had been renamed /tmp/.../A or /tmp/.../R (or indeed any other name), neither tool would find it. Another variant of this test is to look for ASCII strings in certain binaries. Again, if the r00tkit author has changed anything, it won't be found.

A second type of detector is something that looks a what file are present, and compares these to some record. Usually, this is a hash made of the "known clean" snapshot of the file. Examples of this tool are 'tripwire' and 'aide'. To use these tools, you need to run them to _create_ the hashes before sneed to run them to _create_ the hashes before someone has "gotten to" your system. This normally means "when you installed your system". The huge advantage these tools have is that they are looking at what WAS on your system, rather than some generic. Also, these tools are not limited to the distribution supplied, or common files - meaning they can monitor your data and home directory files as easily as /sbin/init. The two most common Linux package managers (rpm and the Debian tools) can monitor most of the files that they have installed ('man rpm' and look at the VERIFICATION section) but are otherwise limited.

A third type of detector looks for indications of "hidden" processes, such as the modified 'ps' command that won't show the rootkit that is running. Both chkrootkit and rkhunter attempt to do this, as does the rather new 'zeppoo'. The first two have had significant numbers of false alarms. I don't have enough experience with 'zeppoo' to say one way or the other, and Usenet reports are fairly limited.

Malware detection really is more than running some script and hoping for the best. Malware prevention is another matter.

I will say only that chroot(1) is not fool-proof. Few things are. Know what your system is doing, and what it can do. See that it is kept up to date. Apply such access controls as you see fit. Unless someone can show a contract that each of you have signed granting access, no one has any _right_ to access your system(s). They may exercise the _privilege_ to access those parts of those systems that you have designated, but that privilege is totally under your control, and subject to ANY limitations you deem fit. If you wish to block hosts whose IP address contains the digit "6", or block hosts with names that contain the letter 'R' - it's your server, and your rules apply.

Old guy

Moe Trin skrev:

Yes, I did use Net-Tool to see who it was from.

----- inetnum: 213.215.135.120 - 213.215.135.127 netname: CINSEDO-NET-1 descr: CENTRO INTERREGIONALE DI STUDI E DOCUMENTAZIONE country: IT

-----

I looked up "Centro Interregionale di Studi e Documentazione" and founded that they seems to have locations in other country's as well.

I use Ubuntu 6.10 and on the server 6.06 LTS.

6.06 is a server install and it commited for 5 years of security supported updates.

This server version is quite simple, it only provide me with an patched kernel and apt-get, giving me free hands to do what ever I want with it. It is not 'easy-ubuntu' ;-).

Mostly I do not fear Kiddiez, but they who now how to get there way around on a posix system, can really hide them self so god that it is almost impossible to find them.

Only thing I can do is to check md5 and my log-files and hoping for the best.

I actually replaced ubuntu 5.10 server with this 6.06 a couple of days ago, making it quite simple to see if there was/is any differences on the server.

I did looked at Tripwire but a don't now what to think of a program that have not been updated for about 2 year.

Latest News * 2.4.0.1 Released 2005-12-01

'fuser -am' is a good start to se processes on the system, and looking in the /proc can give you a hint to.

I do not trust any detecting programs, but they are some sort of help figuring if something has been done outside of my control. If I would think that something i wrong I will flaten and rebiuld but first I would had a closer look to see if I can figure out what has been chanced and how it was done.

Chroot in it self is not enough have to lock down services as well. The sever is only accepting incoming connections on a few ports, and the router that stands in front of it is locked down as well to even a less number of open ports, not allowing any ftp, ssh or dns calls from wan.

/Anders

OK - 'man debsums'

;-)

It's not the skript kiddiez. but the skript _authors_ you have to worry about. The person running the script is going to be totally lost if the situations are not exactly as expected by the script. The better answer is to not let them in in the first place.

[compton ~]$ date +"%d %b %Y" --date="14 months ago" 01 Dec 2005 [compton ~]$

It's not quite that bad, but

Latest News

• Aide 0.13.1 released 2006-12-15 * Aide 0.13 released 2006-12-07 * Aide 0.11 released 2006-02-18

that is a suitable replacement. None the less, I really don't think that either tool has a shelf life problem. These are snapshot tools, to make comparisons, rather than looking for some generic indications of problem.

You're assuming that no one has "gotten to" the fuser binary, or the libraries, or the kernel.

All of our publicly accessible servers are run from read-only media, and don't use modular kernels.

Old guy

Moe Trin skrev:

Aide look like a better choice than Tripwire, I did find it in the repository, but I gonna take a look at it on the home site first.

Yes... I now, it is far from foolproof but it is a start.

I have only a static webb site, no guest-book and so on. And if something goes wrong (not necessary intruders) I have everything on CD's.

/Anders

or for something which the cracker cannot see to disable there's

Yeah, lots of people think of just their data. Crackers like that attitude. They need systems for their bot networks and for cracking into other systems. The would not think of messing with your data.

There are others as well. Integrit and Osiris may be worth looking at.

That reminds me of a take-off of the MasterCard slogan:

old dot matrix printer $15 continuous paper stock $5 look on script kiddie's face when they discover the logs are symlinked to /dev/lp0 priceless

or once you have an understanding of what these tools are doing, something that you create on your own.

For years, security professionals have been stressing that the only thing that should be on an exposed server is that which must be there for the server to do it's job. Thus, some things like X, gcc, make, development libraries or the skript-kiddiez favorite editor is undesirable. Except in unusual circumstances, there is no good reason to be able to upload _anything_ to the server. That makes it harder to install a r00tkit, trojan, or worm. Read-only media is also a step in the right direction. Administration is best done from separate channels - perhaps a separate NIC, certainly a physical console in a secure location.

Old guy

Moe Trin skrev:

;-)

BitTwister, thank you for the link it looks like another god program.

I will have a look on every one of them and testing them on my desktop before I make a decision.

Only remove and then reinstall will not be any solution, have to make an new install of the OS to and make sure there is new accounts to.

Router server | Ip-Cop > desktop

I treat the router as an DMZ it provide me with an first step of firewall blocking everything except webb services from it's WAN side. Ip-Cop is blocking all ports from it's WAN side. I make use of SSH for the connections to the server and only from the desktop.

Well, I do make use of nano on the server but no X, gcc, make and so on.

/Anders

Where you are using 'read-only media', a file integrity checker is not needed. Someone can't reach in to "this" system and change the data on the read-only media. What you have to worry about is someone changing the data that is in RAM.

File integrity on 'read-write media' is more important. This can be checked by statically compiled binaries comparing against data that is stored either elsewhere, or on separate read-only media. It is also a good idea to 'sanity check' the integrity checker, and this is most easily done by comparing a vulnerable application (such as /bin/ps) against a known bad checkfile (checksum, hash, image, what-ever) and seeing that the integrity checker does see that things are not correct. It can then check the same vulnerable file against a known good checkfile to see that the vulnerable file actually is OK.

The file integrity checker should (if possible) be stored on removable media along with the checkfiles. This removable media should normally be stored in a secure place, and installed ONLY during the checks.

That should be easy - but don't forget to keep the system up to date.

Not sure where the Internet lies - but whatever is blocking access has to be robust itself, and offering no connections to an untrusted source.

Good

I won't start an 'editor war' - but would recommend learning at least the fundamentals of '/bin/vi'. Some of the keystrokes you have already learned from using a pager like 'less'. Curiously, neither the LSB or FHS _require_ an editor other than 'sed' - which is a stream editor possibly used in boot scripts.

Old guy

Installed? Booting a Linux floppy doesn't require any installation.

Or use an editor like 'pice' or 'nano' where you don't need any strange key combinations.

Well, maybe because 'sed' is actually quite powerful if you know what you're doing? So is 'awk', 'm4' and 'perl'.

No, but you need to mount it. "/dev/fd0 /floppy/ext2 ext2 ro,root,noauto 0 0"

/Anders

Moe Trin skrev:

Would it be possible to create a MD5 on the entire /, like: md5sum / > /.md5 and then check it with: md5sum -c /.md5 to see if there is any differences on the disk?

The magic of 'apt' ;-)

The Internet is on the routers WAN-port.

For 'Vi' it is "only" a little bit more than 500 pages to read, I am using it on Ip-Cop but not as much as I should have to do, to really learn it well enough to get us of it on a daily bases.

/Anders

The floppy will of course mount itself.

Not necessary, if you use a line like the one above in fstab it will never mount by itself, and you have to be root to do it too.

/Anders

Now I'm pretty sue that you didn't get the point:

We want to boot a floppy with Linux which contains both our indexing utility (md5sum, sha1sum, ...) and the list of checksum (CSV with filename;SHA1;filesize).

And we should never boot into a potentially compromised system.