Hello,
Couple thoughts:
1) You should add semi-colons onto the end of the category lines within
the logging stanza.
2) I take it that you restarted bind after making changes in the
configuration file?
Also note that /etc/bind/namec.conf.options is the preferred place for
the logging stanza,
On Tue, May 13, 2008 at 06:35:25PM -0300, dererk wrote:
> On Tue, May 13, 2008 at 10:53:25PM +0200, Jan Luehr wrote:
> > rm /etc/ssh/ssh_host_*
> > ssh-keygen -t dsa -f /etc/ssh/ssh_host_dsa_key -N ''
> > ssh-keygen -t rsa -f /etc/ssh/ssh_host_rsa_key -N ''
> > /etc/init.d/ssh restart
> >
> > -> j
This looks normal to me. I believe 'ps' cuts off the USER column after
a certain number of characters. To test, I just added a user
'stevesuehring' to a local Debian etch box and then logged in as that
user. The ps output shows 1002 in the USER column rather than the name.
Steve
On Wed, Ja
I would likely restrict access to ssh from external, if at all possible.
I realize that this isn't always possible but it should be possible to
at least narrow down access to certain IP ranges.
For this particular problem I'm assuming there are two NICs in the
computer, one with an IP in private
I've had good luck with nullmailer for just this situation. It's simple
and lightweight, works well in chroot.
Steve
===
= Home Page: http://www.braingia.org/=
=
Could it be this?
http://lists.sans.org/pipermail/intrusions/2004-August/008357.html
You didn't specify which usernames were being used, so it's tough to
tell if that's the same.
A couple of simple and quick things that I might do if this was a
concern:
-Setup an iptables firewall on the boxe
If I'm not mistaken the vulnerabilities existed in two files found in
apache-common. Since apache-common is a prerequisite for apache-ssl,
updating apache-common should correct the vulnerability. I could be
wrong and I'm sure someone will correct me if I am. :)
Steve
On Wed, Nov 17, 2004, Ada
*All* services in /etc/init.d? Do you mean /etc/inetd.conf services?
Could you narrow down the services that you'd like to chroot? Some
services are fairly trivial to chroot while others are more involved and
require some thought before dumping into a chroot.
You might have a look at makejai
On Mon, May 03, 2004 at 07:14:31PM +0200, LeVA wrote:
> Hi!
>
> Is there a way to figure out what program is using a port. For example I
> want to know which process is using port 80. How can I do this?
lsof -i
> ps.: and another tiny question: Is it possible to see if a symlink is
> pointing
On Mon, May 03, 2004 at 07:14:31PM +0200, LeVA wrote:
> Hi!
>
> Is there a way to figure out what program is using a port. For example I
> want to know which process is using port 80. How can I do this?
lsof -i
> ps.: and another tiny question: Is it possible to see if a symlink is
> pointing
SSL won't be of any help if there's another exploit against IIS servers. If
someone can get to the IIS server and there's an exploit, SSL won't do
anything except encrypt their exploit traffic.
SSL helps to encrypt the data but won't help to make the IIS server any more
secure. SSL helps unde
SSL won't be of any help if there's another exploit against IIS servers. If
someone can get to the IIS server and there's an exploit, SSL won't do
anything except encrypt their exploit traffic.
SSL helps to encrypt the data but won't help to make the IIS server any more
secure. SSL helps unde
On Tue, Sep 16, 2003 at 04:49:19PM +0100, Thomas Horsten wrote:
> Thanks, apt-get upgrade worked for me. I guess we'll find out soon enough
> if it was the correct patch...
>
> Good work on getting it integrated so quickly!
Heh. I can't take any credit for this. That's the work of the debian
s
On Tue, Sep 16, 2003 at 11:26:52AM -0400, Michael Stone wrote:
> On Tue, Sep 16, 2003 at 04:00:30PM +0100, Thomas Horsten wrote:
> >Is there an emergency patch/workaround for this, if disabling ssh is not
> >an option?
>
> No.
>
Actually, there is a patch for buffer.c:
http://www.freebsd.org/cg
On Tue, Sep 16, 2003 at 04:49:19PM +0100, Thomas Horsten wrote:
> Thanks, apt-get upgrade worked for me. I guess we'll find out soon enough
> if it was the correct patch...
>
> Good work on getting it integrated so quickly!
Heh. I can't take any credit for this. That's the work of the debian
s
On Tue, Sep 16, 2003 at 11:26:52AM -0400, Michael Stone wrote:
> On Tue, Sep 16, 2003 at 04:00:30PM +0100, Thomas Horsten wrote:
> >Is there an emergency patch/workaround for this, if disabling ssh is not
> >an option?
>
> No.
>
Actually, there is a patch for buffer.c:
http://www.freebsd.org/cg
On Sat, Aug 23, 2003 at 10:14:24AM +0100, Dale Amon wrote:
> Does anyone know when a grsec patch set will be available for 2.6.0t3
> or know of one updated to work with 2.4.22rc2?
>
> Yeah, I know, they are still experimental...
This would be a great question posed to the GrSecurity forum,
http:
On Sat, Aug 23, 2003 at 10:14:24AM +0100, Dale Amon wrote:
> Does anyone know when a grsec patch set will be available for 2.6.0t3
> or know of one updated to work with 2.4.22rc2?
>
> Yeah, I know, they are still experimental...
This would be a great question posed to the GrSecurity forum,
http:
There should be some logging taking place, hopefully from snort itself.
One thing to try, which will all but rule out a permissions issue would be
to try to connect using the MySQL CLI as the user you setup. So,
something like this:
mysql -u snortuser -p snort
Probably wouldn't hurt to show
There should be some logging taking place, hopefully from snort itself.
One thing to try, which will all but rule out a permissions issue would be
to try to connect using the MySQL CLI as the user you setup. So,
something like this:
mysql -u snortuser -p snort
Probably wouldn't hurt to show
You are correct insofar as it triggers at compile time for libpcap, the
configure script to be exact. I grabbed a copy of the trojan'ed libpcap
and compiled it in a sandbox machine. You can do a strings of
the compiled libpcap.a and grep for 1963. Doing so yields these results:
debian:~/lib
You are correct insofar as it triggers at compile time for libpcap, the
configure script to be exact. I grabbed a copy of the trojan'ed libpcap
and compiled it in a sandbox machine. You can do a strings of
the compiled libpcap.a and grep for 1963. Doing so yields these results:
debian:~/lib
22 matches
Mail list logo
