I'm about ready to pull my hair out.
This is the 2nd time I've had to deal with a rootkit infection, eating
up my precious time and resources away from being productive.
I've installed chkrootkit on the suspect server and found that a number
of the executables have been infected. I got suspicious
On 5/8/05, Benjamin Scott [EMAIL PROTECTED] wrote:
On May 4 at 11:33am, [EMAIL PROTECTED] wrote:
~!fs\ s\a\ ~\/ a\ll [EMAIL PROTECTED]@^~_ki~-^l~l~~-n~_x/ \~^u~_pa-~R-
^ notice the ~ escape at the beginning of that line. When piped through
/bin/mail ..., mail will interperet ~! as a
On Fri, 2005-05-06 at 07:47 -0400, David Ecklein wrote:
What do you know about this? How does it compare to Win4Lin (or other
hamburger helpers)? Any actual experience with such things? -Dave E.
I use Win4Lin routinely mainly to run Dreamweaver MX 2004, which
Crossover does not yet
Couple of things come to mind, not as resolutions, but as best practices...
1, NEVER allow root access via SSH. You should have to login as a user, and
then su - to root, or better yet setup a sudoers file.
2, ONLY allow ssh connections from trusted IPs, not the whole world.
Those 2 things
On 5/8/05, Benjamin Scott [EMAIL PROTECTED] wrote:
On May 8 at 6:39pm, Bruce Dawson wrote:
Does anyone know if Linux supports these?
stuff deleted
And a third: Fingerprint is used to cipher a key stored on the drive, and
that key is then used to cipher the data. This would really be the
I think you may be disappointed with some of my answer and that is that you'll
never know for sure how someone gets in. My experiences with this have been
that reinstalling is almost always the best fix in cases like this though,
and obviously, it takes away the opportunity for a deep
On Monday 09 May 2005 09:06 am, Brian wrote:
1, NEVER allow root access via SSH. You should have to login as a user,
and then su - to root, or better yet setup a sudoers file.
This is one of those best practices I've never really felt had merit. It
seems to me that when people break in
On 5/9/05, Brian [EMAIL PROTECTED] wrote:
Couple of things come to mind, not as resolutions, but as best practices...
1, NEVER allow root access via SSH. You should have to login as a user, and
then su - to root, or better yet setup a sudoers file.
If you have a user login to the system,
To me, it one of those laundry list things you do to tighten security on a
box. If you have a very random root password, then this is probably not as
useful as other things like applying security patches, setting up something
like tripwire and restricting access by IP. However it doesn't HURT
On Mon, 2005-05-09 at 09:06 -0400, Brian wrote:
Couple of things come to mind, not as resolutions, but as best practices...
1, NEVER allow root access via SSH. You should have to login as a user, and
then su - to root, or better yet setup a sudoers file.
2, ONLY allow ssh connections from
On Mon, 2005-05-09 at 09:23 -0400, Tom Buskey wrote:
3. Do not allow SSH v1 protocol. Only allow v2. v1 has known,
unfixable, vulnerabilities.
Yes, I have been turning off V1 on the boxes under attack. Though from
now on, V1 will *always* be disabled. Why it is still left enabled by
the
On Monday, May 9th 2005 at 09:38 -0400, quoth Fred:
=Well, this generated some good ideas, but I could use more. Thanks.
One more for aftermath cleanup if you're running an rpm-based setup:
rpm -Va will check every file in the installation for integrity.
Also, are you running ftp or telnet? Is
Neil Joseph Schelly [EMAIL PROTECTED] writes:
On Monday 09 May 2005 09:06 am, Brian wrote:
1, NEVER allow root access via SSH. You should have to login as a user,
and then su - to root, or better yet setup a sudoers file.
This is one of those best practices I've never really felt had
On May 9, 2005, at 09:38, Fred wrote:
Still, what I could probably do is implement a scheme where visiting a
particular webpage (and giving proper authentication) would enable that
IP address for ssh. Come to think of it, that's not such a bad idea
after all! That will also allow my users to ssh
On May 9, 2005, at 08:50, Fred wrote:
Sure enough, it's infected. And it's an FC3 system
to boot.
Just curious - were you using any of your own SELinux policies or just
the defaults (or did you turn it off because it's confounding)?
-Bill
-
Bill McGonigle, Owner Work: 603.448.4440
On Mon, May 09, 2005 at 10:55:02AM -0400, Bill McGonigle wrote:
On May 9, 2005, at 09:38, Fred wrote:
Still, what I could probably do is implement a scheme where visiting a
particular webpage (and giving proper authentication) would enable that
IP address for ssh. Come to think of it, that's
On 5/9/05, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
From: Tom Buskey [EMAIL PROTECTED]
Date: Mon, 9 May 2005 08:58:09 -0400
snip
You're not running Solaris.
$ which fs
/usr/openwin/bin/fs
$ fs
/usr/openwin/bin/xfs notice: Fatal Error. No Listening sockets
On 5/9/05, Bill McGonigle [EMAIL PROTECTED] wrote:
On May 9, 2005, at 09:38, Fred wrote:
The reason to disable root account ssh login is just an odds game -
every unix system is guaranteed to have a root user so it's a good one
for password guessers to start with. Any other account can be
On Mon, 2005-05-09 at 08:50, Fred wrote:
What I'd like to know is how my systems are being cracked. What is the
port of entry(!), how are my systems broken into. What's the latest news
on this.
If you're running AWStats on the server, make sure that it's up to date;
there is a vulnerability
On Mon, May 09, 2005 at 08:50:33AM -0400, Fred wrote:
I'm about ready to pull my hair out.
This is the 2nd time I've had to deal with a rootkit infection, eating
up my precious time and resources away from being productive.
From reading the whole thread, it's become clear that you have a
On Monday 09 May 2005 10:16 am, Kevin D. Clark wrote:
Neil Joseph Schelly [EMAIL PROTECTED] writes:
On Monday 09 May 2005 09:06 am, Brian wrote:
1, NEVER allow root access via SSH. You should have to login as a user,
and then su - to root, or better yet setup a sudoers file.
This is
On Mon, May 09, 2005 at 01:15:06PM -0400, Neil Joseph Schelly wrote:
That is an interesting perspective I hadn't considered. I can think
of more than a time or two that would have been helpful in
retrospect. So perhaps it's more of an administration best practice
than a security best
Neil Joseph Schelly [EMAIL PROTECTED] writes:
That is an interesting perspective I hadn't considered. I can think of more
than a time or two that would have been helpful in retrospect. So perhaps
it's more of an administration best practice than a security best practice?
I dunno. I
Kenny Donahue [EMAIL PROTECTED] writes:
Hi all,
I have a weird tcsh question ask.
in both Linux and Solaris if try and execute . I get either
/usr/sbin/. : permision deinied
or in Lunux /bin/. :Permission denied. What is happening?
Example:
Kenny on somemachine% .
/bin/.: Permission
/bin is way down in my $PATH. That was one of my first thoughts.
Like I said, this is no big deal. It was just a typo and I was wondering
why I got the results I did. Google (for once) was no help.
Please don't waste time on this. I thought someone might know off the top
of their head.
Thanks,
On Mon, 2005-05-09 at 13:15, Neil Joseph Schelly wrote:
On Monday 09 May 2005 10:16 am, Kevin D. Clark wrote:
You have a lot more information if you know that user logged in via
ssh and then su'd to root compared to just knowing that somebody
somewhere logged in as root.
That is an
For those of you who aren't following /., or U.S. politics, there is a
bill up for vote in the U.S. Senate tomorrow which has an attachment
that, should it pass, will implement the requirement for National ID
Cards.
Amazingly enough, this attachment has not been debated on the Senate
floor, nor
On 5/9/05, Paul Lussier [EMAIL PROTECTED] wrote:
Amazingly enough, this attachment has not been debated on the Senate
floor, nor has a single committee discussed it. Chances are, most of
the senators have not even read the bill. Because the main portion of
the bill includes things like
Steven W. Orr wrote:
On Monday, May 9th 2005 at 09:38 -0400, quoth Fred:
=Well, this generated some good ideas, but I could use more. Thanks.
One more for aftermath cleanup if you're running an rpm-based setup:
rpm -Va will check every file in the installation for integrity.
Also, are you running
puissante wrote:
If I ever find whomever is responsible for this -- not bloody likely,
but I can frolic in ideation, can't I? -- I won't be responsible for
my actions. Or actually, I will. The worst of the old medieval torture
practices will pale in comparasion to what I'll do to the
Thomas Charron [EMAIL PROTECTED] writes:
On 5/9/05, Paul Lussier [EMAIL PROTECTED] wrote:
Amazingly enough, this attachment has not been debated on the Senate
floor, nor has a single committee discussed it. Chances are, most of
the senators have not even read the bill. Because the main
On Mon, 2005-05-09 at 20:47 -0400, Paul Lussier wrote:
But the real problem is that the Dept. of Homeland Security is likely
going to be the one to drive the requirements, and they've already
stated several times that they want these to be RFID and remotely
readable! I don't know about you,
On Mon, 2005-05-09 at 20:21 -0400, Brian Chabot wrote:
...
It's really frustrating that the worst I can do usually is terminate the
offender's account(s) on our system, report some to SpamCop, and send
info to the useless addresses like [EMAIL PROTECTED] or whatever.
Sometimes you just
Tucker Hurton will be updating his Virtual Private Network talk. Last
time he covered this topic (Oct04) with a VPN that still worked great
but hadn't been maintained in a few years.
His recent Cross Platform VPN search ended with OpenVPN. Tonight he
will go over setup and usage on this new
34 matches
Mail list logo
