error.log entry

I have found this in my /var/log/apache2/error.log and I wonder a little
of what it is.
If there is some one who can explain it to me it would be appreciated.

I have make it sure that (what ever it is) all IP's (there was only 8 of
them) from this ISP now is blocked and I have checked my server and it
seems like it is free from root-kits and other malware's.

---------
[Mon Jan 29 15:10:36 2007] [error] [client 213.215.135.124] File does
not exist: /var/www/cacti, referer:
http://83.252.171.112/cacti/cmd.php?1+1111)/**/UNION/**/SELE CT/**/2,0,1,1,
CHAR(49,50,55,46,48,46,48,46,49),null,1,null,null,161,500,CH AR(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
[Mon Jan 29 15:10:36 2007] [error] [client 213.215.135.124] File does
not exist: /var/www/portal, referer:
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,CH AR(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
[Mon Jan 29 17:50:16 2007] [error] [client 213.215.135.124] File does
not exist: /var/www/cacti, referer: http://83.252.171.112/cacti/rra/apo.log
[Mon Jan 29 17:50:16 2007] [error] [client 213.215.135.124] File does
not exist: /var/www/portal, referer:
http://83.252.171.112/portal/cacti/rra/apo.log
---------

/Anders

Re: error.log entry

Post removed (X-No-Archive: yes)

Re: error.log entry

Anders,

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

http://www.us-cert.gov/cas/bulletins/SB07-001.html

Has more info.

Bogwitch.

Anders wrote:
> I have found this in my /var/log/apache2/error.log and I wonder a little
> of what it is.
> If there is some one who can explain it to me it would be appreciated.
>
> I have make it sure that (what ever it is) all IP's (there was only 8 of
> them) from this ISP now is blocked and I have checked my server and it
> seems like it is free from root-kits and other malware's.
>
> ---------
> [Mon Jan 29 15:10:36 2007] [error] [client 213.215.135.124] File does
> not exist: /var/www/cacti, referer:
> http://83.252.171.112/cacti/cmd.php?1+1111)/**/UNION/**/SELE CT/**/2,0,1,1,
> CHAR(49,50,55,46,48,46,48,46,49),null,1,null,null,161,500,CH AR(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
>
> [Mon Jan 29 15:10:36 2007] [error] [client 213.215.135.124] File does
> not exist: /var/www/portal, referer:
> 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,CH AR(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
>
> [Mon Jan 29 17:50:16 2007] [error] [client 213.215.135.124] File does
> not exist: /var/www/cacti, referer: http://83.252.171.112/cacti/rra/apo.log
> [Mon Jan 29 17:50:16 2007] [error] [client 213.215.135.124] File does
> not exist: /var/www/portal, referer:
> http://83.252.171.112/portal/cacti/rra/apo.log
> ---------
>
> /Anders

--
Posted via a free Usenet account from http://www.teranews.com

Re: error.log entry

Bogwitch skrev:
> Anders,
>
> Someone or something is attempting to exploit an SQL Injection
> Vulnerability on your apache webserver.
>
> http://www.us-cert.gov/cas/bulletins/SB07-001.html
>
> Has more info.
>
> Bogwitch.

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

/Anders

Re: error.log entry

Sebastian Gottschalk skrev:
> Anders wrote:
>
>> I have found this in my /var/log/apache2/error.log and I wonder a little
>> of what it is.
>
> Scanning for a HP exploit.
>
>> I have make it sure that (what ever it is) all IP's (there was only 8 of
>> them) from this ISP now is blocked
>
> Wonderful idea, since IPs are so unique...

Mostly the IP's is unique

>> and I have checked my server and it
>> seems like it is free from root-kits and other malware's.
>
> "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.

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

Re: error.log entry

Post removed (X-No-Archive: yes)

Re: error.log entry

On Tue, 30 Jan 2007, in the Usenet newsgroup comp.security.firewalls, in
article , Anders wrote:

>Sebastian Gottschalk skrev:

>> Anders wrote:

>>> I have make it sure that (what ever it is) all IP's (there was only 8 of
>>> them) from this ISP now is blocked

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.

>> Wonderful idea, since IPs are so unique...

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.

>Mostly the IP's is unique

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.

>>> and I have checked my server and it
>>> seems like it is free from root-kits and other malware's.
>>
>> "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.

Assuming even a halfway competent r00tkit - yes.

>I use Rkhunter to check the system to see if there is any differences.

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.

>It find nothing

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 have system chrooted so it is difficult to any one not familiar to
>the system to do anything on it.

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

Re: error.log entry

Moe Trin skrev:
> On Tue, 30 Jan 2007, in the Usenet newsgroup comp.security.firewalls, in
> article , Anders wrote:
>
>> Sebastian Gottschalk skrev:
>
>>> Anders wrote:
>
>>>> I have make it sure that (what ever it is) all IP's (there was only 8 of
>>>> them) from this ISP now is blocked
>
> 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.
>

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
-----

>>> Wonderful idea, since IPs are so unique...
>
> 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.
>
>> Mostly the IP's is unique
>
> 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.
>

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

>>>> and I have checked my server and it
>>>> seems like it is free from root-kits and other malware's.
>>> "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.
>
> Assuming even a halfway competent r00tkit - yes.
>
>> I use Rkhunter to check the system to see if there is any differences.
>
> Your headers look like Fedora Core 5 that is being kept up to date.

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' ;-).

> 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.
>

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.

>> It find nothing
>
> 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.

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

> 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.

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

> 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.

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.

> Malware detection really is more than running some script and hoping
> for the best. Malware prevention is another matter.
>
>> I have system chrooted so it is difficult to any one not familiar to
>> the system to do anything on it.
>
> 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

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

Re: error.log entry

On Wed, 31 Jan 2007, in the Usenet newsgroup comp.security.firewalls, in article
, Anders wrote:

>Moe Trin skrev:

>> Your headers look like Fedora Core 5 that is being kept up to date.
>
>I use Ubuntu 6.10 and on the server 6.06 LTS.
>6.06 is a server install

OK - 'man debsums'

>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.

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.

>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

[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.

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

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

>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.

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

Old guy

Re: error.log entry

Moe Trin skrev:
> On Wed, 31 Jan 2007, in the Usenet newsgroup comp.security.firewalls, in article
> , Anders wrote:
>
>
> [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.
>

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.

>> 'fuser -am' is a good start to se processes on the system,
>> and looking in the /proc can give you a hint to.
>
> You're assuming that no one has "gotten to" the fuser binary, or the
> libraries, or the kernel.
>

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

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

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

Re: error.log entry

On Thu, 01 Feb 2007 23:13:25 GMT, Anders wrote:
>
> 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.

or for something which the cracker cannot see to disable there's
http://la-samhna.de/samhain/s_documentation.html

> 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.

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.

Re: error.log entry

On Thu, 01 Feb 2007, in the Usenet newsgroup comp.security.firewalls, in article
, Bit Twister wrote:

>Anders wrote:
>>
>> 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.

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

>or for something which the cracker cannot see to disable

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

>there's http://la-samhna.de/samhain/s_documentation.html

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

>> 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.
>
>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.

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

Re: error.log entry

Moe Trin skrev:
> On Thu, 01 Feb 2007, in the Usenet newsgroup comp.security.firewalls, in article
> , Bit Twister wrote:
>
>> Anders wrote:
>>> 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.
>
> There are others as well. Integrit and Osiris may be worth looking at.
>
>> or for something which the cracker cannot see to disable
>
> 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

;-)

>> there's http://la-samhna.de/samhain/s_documentation.html

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

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

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

>>> 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.
>> 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.

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.

> 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.

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

Re: error.log entry

On Fri, 02 Feb 2007, in the Usenet newsgroup comp.security.firewalls, in article
, Anders wrote:

>Moe Trin skrev:

>> or once you have an understanding of what these tools are doing,
>> something that you create on your own.
>
>I will have a look on every one of them and testing them on my desktop
>before I make a decision.

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.

>>> They need systems for their bot networks and for cracking into other
>>> systems. The would not think of messing with your data.
>
>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.

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

>> Administration is best done from separate channels - perhaps a separate
>> NIC, certainly a physical console in a secure location.
>
>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.

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

>I make use of SSH for the connections to the server and only from the
>desktop.

Good

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

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

Re: error.log entry

Post removed (X-No-Archive: yes)

Re: error.log entry

Sebastian Gottschalk skrev:
> Moe Trin wrote:
>
>> 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.
>
> Installed? Booting a Linux floppy doesn't require any installation.

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

/Anders

Re: error.log entry

Moe Trin skrev:
> On Fri, 02 Feb 2007, in the Usenet newsgroup comp.security.firewalls, in article
> , Anders wrote:
>
>> Moe Trin skrev:
>
>>> or once you have an understanding of what these tools are doing,
>>> something that you create on your own.
>> I will have a look on every one of them and testing them on my desktop
>> before I make a decision.
>
> 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.

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 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.
>
>>>> They need systems for their bot networks and for cracking into other
>>>> systems. The would not think of messing with your data.
>> 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.
>
> That should be easy - but don't forget to keep the system up to date.

The magic of 'apt' ;-)

>>> Administration is best done from separate channels - perhaps a separate
>>> NIC, certainly a physical console in a secure location.
>> 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.
>
> Not sure where the Internet lies - but whatever is blocking access
> has to be robust itself, and offering no connections to an untrusted
> source.

The Internet is on the routers WAN-port.

>> I make use of SSH for the connections to the server and only from the
>> desktop.
>
> Good
>
>> Well, I do make use of nano on the server but no X, gcc, make and so on.
>
> 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.

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

Re: error.log entry

Post removed (X-No-Archive: yes)

Re: error.log entry

Sebastian Gottschalk skrev:
> Anders wrote:
>
>> Sebastian Gottschalk skrev:
>>> Moe Trin wrote:
>>>
>>>> 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.
>>> Installed? Booting a Linux floppy doesn't require any installation.
>> No, but you need to mount it.
>> "/dev/fd0 /floppy/ext2 ext2 ro,root,noauto 0 0"
>
> 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

Re: error.log entry

Post removed (X-No-Archive: yes)

Re: error.log entry

Sebastian Gottschalk skrev:
> Anders wrote:
>
>> Sebastian Gottschalk skrev:
>>> Anders wrote:
>>>
>>>> Sebastian Gottschalk skrev:
>>>>> Moe Trin wrote:
>>>>>
>>>>>> 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.
>>>>> Installed? Booting a Linux floppy doesn't require any installation.
>>>> No, but you need to mount it.
>>>> "/dev/fd0 /floppy/ext2 ext2 ro,root,noauto 0 0"
>>> 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.
>
> Now I'm pretty sue that you didn't get the point:

The point I get is to use a floppy containing the checking program,
and that I would be able to use even then the server is up and running.

> 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).

For that propose I use 'Insert' instead.
http://www.inside-security.de/insert_en.html

> And we should never boot into a potentially compromised system.

Even if I suspect that it has been compromised I will sure boot in to it,
after I disconnect it from the net.

/Anders

Re: error.log entry

Post removed (X-No-Archive: yes)

Re: error.log entry

On Sun, 04 Feb 2007, in the Usenet newsgroup comp.security.firewalls, in article
, Anders wrote:

>Sebastian Gottschalk skrev:
>> Moe Trin wrote:
>>
>>> 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.
>>
>> Installed? Booting a Linux floppy doesn't require any installation.

Sebastian, I realize that English isn't your primary language, but
you really do need more practice in reading it. Take your dictionary
and look up the word "removable". Then look at the word "install" and
see how they relate.

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

Actually, I meant what I wrote - the media should not even be in the
drive - on the off chance that someone trying to mount it on the off
chance that something interesting/useful might be there.

Old guy

Re: error.log entry

On Sun, 04 Feb 2007, in the Usenet newsgroup comp.security.firewalls, in article
, Anders wrote:

>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?

md5sum works on a "per file" basis. What you _could_ do is to make an
md5sum of the partition (remember, "everything is a file"), although
there could be rather interesting complications if the entire partition
is not mounted read-only.

>> but don't forget to keep the system up to date.
>
>The magic of 'apt' ;-)

We're a bit more paranoid, and anyway we're mainly rpm based. We have
two individuals tasked with monitoring the security groups and downloading
all errata as source packages. They then do an audit of the source before
locally building the binaries and putting those onto a local updates
server. For ordinary stuff, there is a nightly cron-job run on all systems
that looks in the errata server, and installs anything found there. It
also sends a mail with an "installed package list" to an inventory server
so we can keep track of things.

>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.

A neighbor teaches UNIX at a local junior college, and the "Introduction
to UNIX" class teaches basic concepts and some applications (vi, mail,
man, cat, wc, more, less, sort, tr, sed, grep, cut, awk, find, regular
expressions, pipes and redirections). The first two or three weeks of
class (3 hour class twice a week), the students are flailing away - way
over their head. By the ninth week, they are doing "one-liners" like

[compton ~]$ history | sed 's/^......//' | tr '|' '\n' | sed 's/^ *//' |
cut -d' ' -f1 | sort -u | wc -l
84
[compton ~]$

He has a hand-out for 'vi' that is five pages long. The textbook used
covers vi in one chapter of 48 pages. It also has 60 pages in a chapter
on 'ed' and 'ex', but he just skims over that. Looking at the O'Reilly
catalog (http://www.ora.com/), the "Learning the vi Editor, 6th Edition"
(ISBN 1-56592-426-6) is 344 pages, while the chapter covering vi in the
'Linux in a Nutshell' and 'UNIX in a Nutshell' is less than 15 pages.

You don't need to know everything about vi to use it effectively.
Depending on what packages your distribution supplied, you might have the
'vim' clone, and that comes with

[compton ~]$ whatis vim vimtutor
vim (1) - Vi IMproved, a programmers text editor
vim [ex] (1) - Vi IMproved, a programmers text editor
vim [gvim] (1) - Vi IMproved, a programmers text editor
vim [rvi] (1) - Vi IMproved, a programmers text editor
vim [rview] (1) - Vi IMproved, a programmers text editor
vim [vi] (1) - Vi IMproved, a programmers text editor
vim [view] (1) - Vi IMproved, a programmers text editor
vimtutor (1) - the Vim tutor
[compton ~]$ rpm -qd `rpm -qa | grep ^vim` | wc -l
311
[compton ~]$

The latter command is rpm specific, but queries the installed packages
that begin with the string 'vim' to count the number of files identified
as "documentation" (man pages, help pages, HOWTOs, FAQs, and general
information) that is installed from those packages.

Old guy

Re: error.log entry

On Sun, 04 Feb 2007, in the Usenet newsgroup comp.security.firewalls, in article
, Anders wrote:
>Sebastian Gottschalk skrev:
>> Anders wrote:
>>
>>> Sebastian Gottschalk skrev:
>>>> Anders wrote:
>>>>> "/dev/fd0 /floppy/ext2 ext2 ro,root,noauto 0 0"
>>>> The floppy will of course mount itself.

Gottschalk - READ THE GOD DAMN POST!!! Or stop posting because you don't
have a clue! Look at the freakin' man page and learn what "noauto" means.

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

Nope you are the one who doesn't know what you are talking about.

>The point I get is to use a floppy containing the checking program,
>and that I would be able to use even then the server is up and running.

Yes - just ignore this idiot, as his help is useless.

Old guy

Re: error.log entry

Post removed (X-No-Archive: yes)

Re: error.log entry

Post removed (X-No-Archive: yes)

Re: error.log entry

Moe Trin skrev:
> On Sun, 04 Feb 2007, in the Usenet newsgroup comp.security.firewalls, in article
> , Anders wrote:
>
>> 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?
>
> md5sum works on a "per file" basis. What you _could_ do is to make an
> md5sum of the partition (remember, "everything is a file"), although
> there could be rather interesting complications if the entire partition
> is not mounted read-only.

Maybe it is better to first use 'debsums -s', and go from that point to
see if
and there to create any md5's on separate files.

>>> but don't forget to keep the system up to date.
>> The magic of 'apt' ;-)
>
> We're a bit more paranoid, and anyway we're mainly rpm based. We have
> two individuals tasked with monitoring the security groups and downloading
> all errata as source packages. They then do an audit of the source before
> locally building the binaries and putting those onto a local updates
> server. For ordinary stuff, there is a nightly cron-job run on all systems
> that looks in the errata server, and installs anything found there. It
> also sends a mail with an "installed package list" to an inventory server
> so we can keep track of things.

I don't think I have to be that paranoid, it is no critical environment,
just the GPG key's and a restrictive sources.list wold be good enough
for me.

>> 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.
>
> A neighbor teaches UNIX at a local junior college, and the "Introduction
> to UNIX" class teaches basic concepts and some applications (vi, mail,
> man, cat, wc, more, less, sort, tr, sed, grep, cut, awk, find, regular
> expressions, pipes and redirections). The first two or three weeks of
> class (3 hour class twice a week), the students are flailing away - way
> over their head. By the ninth week, they are doing "one-liners" like
>
> [compton ~]$ history | sed 's/^......//' | tr '|' '\n' | sed 's/^ *//' |
> cut -d' ' -f1 | sort -u | wc -l
> 84
> [compton ~]$
>
> He has a hand-out for 'vi' that is five pages long. The textbook used
> covers vi in one chapter of 48 pages. It also has 60 pages in a chapter
> on 'ed' and 'ex', but he just skims over that. Looking at the O'Reilly
> catalog (http://www.ora.com/), the "Learning the vi Editor, 6th Edition"
> (ISBN 1-56592-426-6) is 344 pages, while the chapter covering vi in the
> 'Linux in a Nutshell' and 'UNIX in a Nutshell' is less than 15 pages.
>
> You don't need to know everything about vi to use it effectively.
> Depending on what packages your distribution supplied, you might have the
> 'vim' clone, and that comes with
>
> [compton ~]$ whatis vim vimtutor
> vim (1) - Vi IMproved, a programmers text editor
> vim [ex] (1) - Vi IMproved, a programmers text editor
> vim [gvim] (1) - Vi IMproved, a programmers text editor
> vim [rvi] (1) - Vi IMproved, a programmers text editor
> vim [rview] (1) - Vi IMproved, a programmers text editor
> vim [vi] (1) - Vi IMproved, a programmers text editor
> vim [view] (1) - Vi IMproved, a programmers text editor
> vimtutor (1) - the Vim tutor
> [compton ~]$ rpm -qd `rpm -qa | grep ^vim` | wc -l
> 311
> [compton ~]$
>
> The latter command is rpm specific, but queries the installed packages
> that begin with the string 'vim' to count the number of files identified
> as "documentation" (man pages, help pages, HOWTOs, FAQs, and general
> information) that is installed from those packages.

I have Vim installed as I erratically call 'Vi'.

It was this little bible I had in mind.
http://truth.sk/vim/vimbook-OPL.pdf
'VI Improved (VIM)' by 'Steve Oualline' made in 2002, and it is actually in
572 pages or (using 'wc -w') 142505 words.

VIM manuals and more on the sourceforge.
http://vimdoc.sourceforge.net/

/Anders

Re: error.log entry

On Mon, 05 Feb 2007, in the Usenet newsgroup comp.security.firewalls, in article
, Anders wrote:

>Moe Trin skrev:

>> md5sum works on a "per file" basis. What you _could_ do is to make an
>> md5sum of the partition (remember, "everything is a file"), although
>> there could be rather interesting complications if the entire partition
>> is not mounted read-only.
>
>Maybe it is better to first use 'debsums -s', and go from that point to
>see if and there to create any md5's on separate files.

The disadvantage of 'debsums' is that is that is only monitors the files
that belong to packages. Your home directory, data for your server and
so on is not checked - as the Debian package maintainers can't know what
those files/directories are going to look like. There is a 'debsums_gen'
tool, but that's probably not going to help either. A disadvantage of
these package tools is shown in the header of the man pages:

[van-allen ~]$ whatis debsums debsums_gen
debsums (1) - check the MD5 sums of installed Debian packages
debsums_gen (8) - Generate /var/lib/dpkg/info/*.md5sums for packages
lacking it
[van-allen ~]$

They only do MD5 sums. (rpm is similar, but also notes size, permissions
and ownerships). Compare that to a designated Integrity checker. In
fact, look at the bottom of the debsums(1) man page:

debsums is intended primarily as a way of determining what installed
files have been locally modified by the administrator or damaged by media
errors and is of limited use as a security tool.

If you are looking for an integrity checker that can run from safe media,
do integrity checks on checksum databases and can be easily configured to
run periodically to warn the admin of changes see other tools such as:
aide, integrit, samhain, or tripwire.

I'm aware of an application called 'fcheck(1)' which can be found on some
Debian installations. It was a Perl script. Two other possibilities are
'fam' and 'gamin' - although 'fam' has gotten a reputation as a resource
pig.

Old guy

Re: error.log entry

Moe Trin skrev:
> On Mon, 05 Feb 2007, in the Usenet newsgroup comp.security.firewalls, in article
> , Anders wrote:
>
>> Moe Trin skrev:

I just have to thank you for you're time taken.
And tell you that I am going to use Aide, I have been struggling with the
aide.conf a couple of hours, and now I believe that I have a functional
..conf
for my desktop (haven't had time to make it for the server), but there is no
way I gonna be able to use a floppy-disk the size is almost 2MB, so have to
keep it on an USB-stick instead.
The advantage is that I be able to have several installations on that
USB-stick (128MB),
the disadvantage is that I wan't to use the stick for other purposes to.

/Anders

Re: error.log entry

On Wed, 07 Feb 2007, in the Usenet newsgroup comp.security.firewalls, in article
<8Xoyh.31436$E02.12790@newsb.telia.net>, Anders wrote:

>I just have to thank you for you're time taken.

Glad to help

>And tell you that I am going to use Aide, I have been struggling with
>the aide.conf a couple of hours, and now I believe that I have a
>functional .conf for my desktop (haven't had time to make it for the
>server), but there is no way I gonna be able to use a floppy-disk the
>size is almost 2MB, so have to keep it on an USB-stick instead.

Well, there were 2.88 MB floppies long ago, and there were Zip drives
in various sizes, but a USB stick is a _LOT_ more convenient.

>The advantage is that I be able to have several installations on that
>USB-stick (128MB),
>the disadvantage is that I wan't to use the stick for other purposes to.

You'll just have to get another ;-)

Old guy