what is means ?
Marcin Bednarz
Hi all.
In output of 'w' command I saw something like that:
--cut--
root 7073 0.0 0.0 1240 636 ? S 11:09 0:05 in.telnetd: some.host.in.my.domain
--cut--
Correct address I replaced with some.host.in.my.domain.
Is root is logging to this mashine by telnet ???
Regards,
Marcin B.
--
To UNSUBSCRIBE, email to debian-secu...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Sidnei da Silva
| Hi all.
|
| In output of 'w' command I saw something like that:
|
| --cut--
| root 7073 0.0 0.0 1240 636 ? S 11:09 0:05 in.telnetd:
| some.host.in.my.domain --cut--
|
| Correct address I replaced with some.host.in.my.domain.
| Is root is logging to this mashine by telnet ???
Clearly yes. In my opinion you should disable telnet and use ssh. Once i left
telnet open after installing a server, and the next day i found a rootkit
inside it. Telnet suckz badly.
--
Sidnei da Silva (dreamcatcher) <sid...@x3ng.com.br>
X3ng Web Technology <http://www.x3ng.com.br>
GNU/Linux user 257852
Debian GNU/Linux 3.0 (Sid) 2.4.19-pre6-ben0 ppc
It is easier to change the specification to fit the program than vice versa.
Jan Johansson
>Telnet suckz badly.
How do you know it was exploited via telnetd? I can think of a lot of services more readibly exploitable then telnet.
Marcin Bednarz
Hi al.
On Fri, 19 Apr 2002, Sidnei da Silva wrote:
> Clearly yes. In my opinion you should disable telnet and use ssh. Once i left
> telnet open after installing a server, and the next day i found a rootkit
> inside it. Telnet suckz badly.
How to protect against rootkis ? Is it some kind of trojan wich working
with root priviledges ?
Why some people says that eg. tripwire doesn't discover it ?
Regards,
Marcin B.
Jan Johansson
Keep your system up to date, do not run unrelaibale software, do not give accounts to people you do not trust.
> Is it some kind of trojan
> wich working
> with root priviledges ?
Basically, yes. It is typically a "kit" you drop on the system via a remote root exploit, which replaces binaries, and tries to mask itself.
> Why some people says that eg. tripwire doesn't discover it ?
Then they dont know what they are saying, i would say that Tripwire / AIDE / such will be 100% efficient in detecting kits _PROVIDING_ that your database is current, and is stored in a tamper-proof location... and ofcource you actually use and update teh IDS database.
Joe Moore
>
> --cut--
> root 7073 0.0 0.0 1240 636 ? S 11:09 0:05
> in.telnetd: some.host.in.my.domain --cut--
>
> Correct address I replaced with some.host.in.my.domain.
> Is root is logging to this mashine by telnet ???
Maybe, but probably not.
If you had done a "px axfl" (output trimmed below) and looked at process
7073 and its children, you probably would have seen something like this:
UID PID PPID PRI NI VSZ RSS TTY TIME COMMAND
0 322 1 0 0 2028 740 ? 0:02 /usr/sbin/inetd
0 9308 322 0 0 1492 712 ? 0:00 \_ in.telnetd
481 9309 9308 10 0 2248 1300 pts/6 0:00 \_ -bash
in.telnetd may be run with root privs, in order to set up the login
environment for the user. It does not mean that someone is telnetting in as
root. By default in testing, in.telnetd runs as user "telnetd" (uid 103)
rather than root.
--Joe
Patrick Maheral
> > Why some people says that eg. tripwire doesn't discover it ?
>
> Then they dont know what they are saying, i would say that Tripwire /
> AIDE / such will be 100% efficient in detecting kits _PROVIDING_ that
> your database is current, and is stored in a tamper-proof location...
> and ofcource you actually use and update teh IDS database.
I've heard of, but not confirmed the existence of, a root kit that is
not detected by Tripwire and other intrusion detection software. It
does this by keeping a backup of the original utility (eg. ls, ps, etc.)
and then provides either it's own utility or the original depending on
how it is opened (eg. if by ld.so, open trojan, else open original).
I think that as long as the source of the "open" system call can be
determined, a carefully crafted root-kit might be able remain undetected
as long as the system is running tainted code. I think the only way to
be sure that a utility such as tripwire works is to run it on an
untainted system (ie. boot from known good floppy/CD before running the
software).
Am I just being paranoid, or is this sort of compromise really possible?
Patrick
Jan Johansson
> not detected by Tripwire and other intrusion detection software. It
> does this by keeping a backup of the original utility (eg.
> ls, ps, etc.)
> and then provides either it's own utility or the original depending on
> how it is opened (eg. if by ld.so, open trojan, else open original).
> really possible?
There is a reason that tripwire and aide are normally compiled as statical binaries. And frankly, just copying the file will trigger teh IDS, since it can use inode/sector location as one of the fingerprints.
Personally i (pretty much) do the following:
Install system from a "known safe source", as well as applicable patches.
Then we install AIDE. And set up a decent log set.
Then we copy the AIDE binary aswell as the initial database to a media such as CD-ROM, which we then keep mounted in a CD unit.
Now, run AIDE check periodically (nightly) against that db. And all is well.
When i patch the system, just make sure the AIDE check is "clean" before the upgrade. Do the patches, do a new AIDE database and do an incremental burn of the CD. Then keep that routine up.
That, and keeping the kernel monolithical to prevent the "module type" exploits, and you have a pretty good setup.
Add to this logging of key elements to an old matrix printer.. Good luck in manipulating those logs remotely.
Frankly, i would actually like to see how to taint such a system...
Now, a fun thought would be to use a mirrored disk on either shared SCSI or fiber scsi for the system. Then break the mirror, mount one disk to a "secure" system and run the analyze from there, thereby bypassing ALL elements of the original object. (Okay, overkill).
Jan Johansson
> really possible?
And also: If the IDS "was there first" it would trigger on the modified kernel/module/library (or whatever) since it has to differ between the last check _before_ the infection and the first check _after_ infection.
Now, if the exploit was there first, the IDS is a moot point alltogether.
Giacomo Mulas
> I've heard of, but not confirmed the existence of, a root kit that is
> not detected by Tripwire and other intrusion detection software. It
> does this by keeping a backup of the original utility (eg. ls, ps, etc.)
> and then provides either it's own utility or the original depending on
> how it is opened (eg. if by ld.so, open trojan, else open original).
any root kit based upon kernel modules can do that. Search for "knark"
with Google...
> I think that as long as the source of the "open" system call can be
> determined, a carefully crafted root-kit might be able remain undetected
> as long as the system is running tainted code. I think the only way to
> be sure that a utility such as tripwire works is to run it on an
> untainted system (ie. boot from known good floppy/CD before running the
> software).
Yes, you are correct. To be safe, you need to keep the tripwire database
on a separate support which cannot be tampered with, and to check the
integrity of the system you should boot the system from secure media (e.g.
a boot CDROM you previously prepared), possibly in single user mode and
unconnected from the network.
> Am I just being paranoid, or is this sort of compromise really possible?
oh yes, it is possible.
Bye
Giacomo
--
_________________________________________________________________
Giacomo Mulas <gmu...@ca.astro.it, giacom...@tin.it>
_________________________________________________________________
OSSERVATORIO ASTRONOMICO DI CAGLIARI
Str. 54, Loc. Poggio dei Pini * 09012 Capoterra (CA)
Tel.: +39 070 71180 248 Fax : +39 070 71180 222
_________________________________________________________________
"When the storms are raging around you, stay right where you are"
(Freddy Mercury)
_________________________________________________________________
Sam Couter
> Now, run AIDE check periodically (nightly) against that db. And all is well.
Here's a weakness: The attacker can replace AIDE (or any libraries it
links to, if any exist, or even the kernel) with a fake that just says
"Everything's OK" without really checking.
> When i patch the system, just make sure the AIDE check is "clean" before the upgrade. Do the patches, do a new AIDE database and do an incremental burn of the CD. Then keep that routine up.
Another weakness: If your CD is in a burner in the attacked machine, the
attacker can update the database with false information. You haven't
made it clear where the burner is in relation to the mounted CD, so I
don't know if this applies.
> That, and keeping the kernel monolithical to prevent the "module type" exploits, and you have a pretty good setup.
Module support is not needed to modify the running kernel, it just makes
it easier.
> Add to this logging of key elements to an old matrix printer.. Good luck in manipulating those logs remotely.
Is that "old matrix printer" susceptible to fires if worked hard for a
while? ;)
> Frankly, i would actually like to see how to taint such a system...
The attacker can modify your running kernel. From that point, all bets
are off.
The attacker can also modify any software that's not on read-only media,
which can include your IDS software itself.
You need to boot from trusted media and run only trusted programs to
check untrusted media. You can't test the untrusted software using the
untrusted software.
> Now, a fun thought would be to use a mirrored disk on either shared SCSI or fiber scsi for the system. Then break the mirror, mount one disk to a "secure" system and run the analyze from there, thereby bypassing ALL elements of the original object. (Okay, overkill).
Whether or not it's overkill depends on your threat analysis, but the
system you've described here could actually be secure if done right, and
avoids the downtime of booting the machine from trusted media. Your
current system is vulnerable to (an unlikely) attack.
--
Sam "Eddie" Couter | mailto:sco...@bigpond.net.au
Debian Developer | mailto:ed...@debian.org
| jabber:s...@jabber.topic.com.au
OpenPGP fingerprint: A46B 9BB5 3148 7BEA 1F05 5BD5 8530 03AE DE89 C75C
Gustavo Felisberto
maintained by clients (we serve as web hosting company) and some are
internal.
The external accounts are loked out of the main fylesystem using proftpd
chroot feature and by having /dev/null as the shell.
My problem is that even that way users of the external group can use php's
fopen() to open other files. And in a php/mysql enviroment is not hard to
find files with database login/password. If i had lots of IP's i could run
several copies of apache each one on it's ip and one for each external
client, i would run it with the clients group and that way i could lock each
one out of the others account. The problem is that i dont have lots of ip's,
any ideas on how to solve this?
Gustavo Felisberto
hpknight
DocumentRoot for the domain, then they cannot open any files outside of
that directory. In php.ini:
safe_mode = on
Then in your <VirtualHost>:
php_admin_flag engine on
php_admin_value open_basedir "/var/www/vhosts/domain.com/htdocs:/tmp"
You may even want to leave off "/tmp" and make each user create a tmp
directory in their own directory, or move the restriction back to
/var/www/vhosts/domain.com so they can use anything inside of their domain
directory. If you do this for every VirtualHost, you shouldn't have to
worry about users reading/writing to each other's files .. if they attempt
to open a file outside of the open_basedir, their script will die out with
an error. There are some other safe_mode variables in the php.ini you
might want to check out too.
You will probably want to restrict cgi-script access, since this is
another way to get around chroot restrictions :)
-Henry
Arild Evensen
<Directory>
Addtypes for scripting and other file types.
Override settings for .htaccess.
Other php related settings.(includepath, sendmail from, upload tmp dir,..)
errdoc,...
Keep ftp root over www root, gives you a private space to have includefiles,
tmp directory, logfiles, maildir, files with password and other sensitive
settings outside www root
(ftp-root /var/www/virtual/customer1/
www-root /var/www/virtual/customer1/www )
Gives you a strong control over each virtualhost.
But it gives you some more administration.
Use one file for eache virtualhost and use include /fiele to run all
configurationsfile from that directory.
And in 2.X versions you can have user directive in each virtualhost, if i
recall correct.
>===== Original Message From hpknight <hpkn...@ao.net> =====
-
Arild Evensen
-
Marcel Hicking
> DocumentRoot for the domain, then they cannot open any files outside of
> that directory. In php.ini:
>
> safe_mode = on
>
> Then in your <VirtualHost>:
>
> php_admin_flag engine on
> php_admin_value open_basedir "/var/www/vhosts/domain.com/htdocs:/tmp"
I usually have the current directory "." in there, too.
Please note the difference between flags/values and admin_flag/values.
| "Admin" configuration settings can only be set from
| within the main Apache configuration files, and not
| from .htaccess files.
http://www.php.net/manual/en/configuration.php
Cheers, Marcel
Eric LeBlanc
On Fri, 19 Apr 2002, Jan Johansson wrote:
>
> Then they dont know what they are saying, i would say that Tripwire / AIDE / such will be 100% efficient in detecting kits _PROVIDING_ that your database is current, and is stored in a tamper-proof location... and ofcource you actually use and update teh IDS database.
>
In security, never said 100%, never. Nothing are good to fully trust. All
are good to be a paranoid, as told by AIDE.
And read the paper (do a search a relevant "The future is here"):
http://staff.washington.edu/dittrich/misc/faqs/rootkits.faq