error.log entry - Firewalls

This is a discussion on error.log entry - Firewalls ; 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 ...

+ Reply to Thread
Page 1 of 2 1 2 LastLast
Results 1 to 20 of 29

Thread: error.log entry

  1. 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?...ECT/**/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
    [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/c...ECT/**/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
    [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

  2. Re: error.log entry

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

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

  3. 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?...ECT/**/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
    >
    > [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/c...ECT/**/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
    >
    > [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


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

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

  6. Re: error.log entry

    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

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

    >
    > Mostly the IP's is unique


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

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


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

    > and I have system chrooted


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

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

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

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

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

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

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

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

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

  15. Re: error.log entry

    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.

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


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

    > Curiously, neither the LSB or FHS _require_ an editor other than 'sed' -
    > which is a stream editor possibly used in boot scripts.


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

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

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


  18. Re: error.log entry

    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.

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

  20. Re: error.log entry

    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:

    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.

+ Reply to Thread
Page 1 of 2 1 2 LastLast