Re: ipsec setkey and 2.4.21 kernel
Mark Devin wrote: Mark Devin wrote: Mark Devin wrote: I have been running a custom compiled 2.4.21 kernel using the kernel source package from Adrian Bunk's site on Woody. I had an ipsec link setup and it was working well using the Kame implementation which debian has backported into the 2.4.21 kernel sources. I just recompiled my kernel today with the latest 2.4.21 kernel source deb (from Adrian Bunk's site). Now setkey refuses to load my policies which are unchanged from what was working before. Does anyone have any idea how to fix this? Here is the contents of the file I am passing to setkey: -- #!/usr/sbin/setkey -f flush; spdflush; spdadd 192.168.99.0/24[any] 192.168.99.0/24[any] any -P out ipsec esp/tunnel/192.168.1.1-192.168.1.74/require; spdadd 192.168.99.0/24[any] 192.168.99.0/24[any] any -P in ipsec esp/tunnel/192.168.1.74-192.168.1.1/require; -- And here is the errors setkey produces: -- # setkey -f /etc/ipsec.conf The result of line 6: Invalid argument. The result of line 9: Invalid argument. -- I have tried recompiling ipsec-tools from unstable sources. I also made sure the 2.4.21 kernel headers were being used during the compile process for the ipsec-tools package by ensuring the configure script was passed the appropriate --with-kernel-headers parameter in debian/rules. Any other ideas? Actually, it seems to only not work when trying to specify a policy to require tunnel mode. I can load transport policies OK with setkey. However, tunnel mode policies fail with setkey returning "Invalid argument". A couple of people have suggested that putting a '\' line continuation escape character at the end of the first line of each policy may correct the problem. Unfortunately this doesn't work and setkey just complains of a parse error with this. I am fairly certain that this is a bug in this 2.4.21 kernel source release since my previous 2.4.21 kernel compiled with the same config worked fine. I haven't changed the file I pass to setkey or my racoon.conf. Also, I note that setkey seems to work OK if policies for transport mode are used, but fails on tunnel mode policies. Just replying to myself again for the benefit of any list readers having similar problems. There is a bug in the 2.4.21 kernel causing this problem. The 2.4.22 kernel works fine. Also make sure that ipsec-tools package is compiled against the 2.4.22 kernel headers. This can be done by editing the debian/rules script and setting the --with-kernel-headers parameter correctly. Regards. Mark.
Re: ipsec setkey and 2.4.21 kernel
Mark Devin wrote: Mark Devin wrote: Mark Devin wrote: I have been running a custom compiled 2.4.21 kernel using the kernel source package from Adrian Bunk's site on Woody. I had an ipsec link setup and it was working well using the Kame implementation which debian has backported into the 2.4.21 kernel sources. I just recompiled my kernel today with the latest 2.4.21 kernel source deb (from Adrian Bunk's site). Now setkey refuses to load my policies which are unchanged from what was working before. Does anyone have any idea how to fix this? Here is the contents of the file I am passing to setkey: -- #!/usr/sbin/setkey -f flush; spdflush; spdadd 192.168.99.0/24[any] 192.168.99.0/24[any] any -P out ipsec esp/tunnel/192.168.1.1-192.168.1.74/require; spdadd 192.168.99.0/24[any] 192.168.99.0/24[any] any -P in ipsec esp/tunnel/192.168.1.74-192.168.1.1/require; -- And here is the errors setkey produces: -- # setkey -f /etc/ipsec.conf The result of line 6: Invalid argument. The result of line 9: Invalid argument. -- I have tried recompiling ipsec-tools from unstable sources. I also made sure the 2.4.21 kernel headers were being used during the compile process for the ipsec-tools package by ensuring the configure script was passed the appropriate --with-kernel-headers parameter in debian/rules. Any other ideas? Actually, it seems to only not work when trying to specify a policy to require tunnel mode. I can load transport policies OK with setkey. However, tunnel mode policies fail with setkey returning "Invalid argument". A couple of people have suggested that putting a '\' line continuation escape character at the end of the first line of each policy may correct the problem. Unfortunately this doesn't work and setkey just complains of a parse error with this. I am fairly certain that this is a bug in this 2.4.21 kernel source release since my previous 2.4.21 kernel compiled with the same config worked fine. I haven't changed the file I pass to setkey or my racoon.conf. Also, I note that setkey seems to work OK if policies for transport mode are used, but fails on tunnel mode policies. Just replying to myself again for the benefit of any list readers having similar problems. There is a bug in the 2.4.21 kernel causing this problem. The 2.4.22 kernel works fine. Also make sure that ipsec-tools package is compiled against the 2.4.22 kernel headers. This can be done by editing the debian/rules script and setting the --with-kernel-headers parameter correctly. Regards. Mark. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ipsec setkey and 2.4.21 kernel
Mark Devin wrote: Mark Devin wrote: I have been running a custom compiled 2.4.21 kernel using the kernel source package from Adrian Bunk's site on Woody. I had an ipsec link setup and it was working well using the Kame implementation which debian has backported into the 2.4.21 kernel sources. I just recompiled my kernel today with the latest 2.4.21 kernel source deb (from Adrian Bunk's site). Now setkey refuses to load my policies which are unchanged from what was working before. Does anyone have any idea how to fix this? Here is the contents of the file I am passing to setkey: -- #!/usr/sbin/setkey -f flush; spdflush; spdadd 192.168.99.0/24[any] 192.168.99.0/24[any] any -P out ipsec esp/tunnel/192.168.1.1-192.168.1.74/require; spdadd 192.168.99.0/24[any] 192.168.99.0/24[any] any -P in ipsec esp/tunnel/192.168.1.74-192.168.1.1/require; -- And here is the errors setkey produces: -- # setkey -f /etc/ipsec.conf The result of line 6: Invalid argument. The result of line 9: Invalid argument. -- I have tried recompiling ipsec-tools from unstable sources. I also made sure the 2.4.21 kernel headers were being used during the compile process for the ipsec-tools package by ensuring the configure script was passed the appropriate --with-kernel-headers parameter in debian/rules. Any other ideas? Actually, it seems to only not work when trying to specify a policy to require tunnel mode. I can load transport policies OK with setkey. However, tunnel mode policies fail with setkey returning "Invalid argument". A couple of people have suggested that putting a '\' line continuation escape character at the end of the first line of each policy may correct the problem. Unfortunately this doesn't work and setkey just complains of a parse error with this. I am fairly certain that this is a bug in this 2.4.21 kernel source release since my previous 2.4.21 kernel compiled with the same config worked fine. I haven't changed the file I pass to setkey or my racoon.conf. Also, I note that setkey seems to work OK if policies for transport mode are used, but fails on tunnel mode policies. Regards. Mark.
Re: ipsec setkey and 2.4.21 kernel
Mark Devin wrote: Mark Devin wrote: I have been running a custom compiled 2.4.21 kernel using the kernel source package from Adrian Bunk's site on Woody. I had an ipsec link setup and it was working well using the Kame implementation which debian has backported into the 2.4.21 kernel sources. I just recompiled my kernel today with the latest 2.4.21 kernel source deb (from Adrian Bunk's site). Now setkey refuses to load my policies which are unchanged from what was working before. Does anyone have any idea how to fix this? Here is the contents of the file I am passing to setkey: -- #!/usr/sbin/setkey -f flush; spdflush; spdadd 192.168.99.0/24[any] 192.168.99.0/24[any] any -P out ipsec esp/tunnel/192.168.1.1-192.168.1.74/require; spdadd 192.168.99.0/24[any] 192.168.99.0/24[any] any -P in ipsec esp/tunnel/192.168.1.74-192.168.1.1/require; -- And here is the errors setkey produces: -- # setkey -f /etc/ipsec.conf The result of line 6: Invalid argument. The result of line 9: Invalid argument. -- I have tried recompiling ipsec-tools from unstable sources. I also made sure the 2.4.21 kernel headers were being used during the compile process for the ipsec-tools package by ensuring the configure script was passed the appropriate --with-kernel-headers parameter in debian/rules. Any other ideas? Actually, it seems to only not work when trying to specify a policy to require tunnel mode. I can load transport policies OK with setkey. However, tunnel mode policies fail with setkey returning "Invalid argument". A couple of people have suggested that putting a '\' line continuation escape character at the end of the first line of each policy may correct the problem. Unfortunately this doesn't work and setkey just complains of a parse error with this. I am fairly certain that this is a bug in this 2.4.21 kernel source release since my previous 2.4.21 kernel compiled with the same config worked fine. I haven't changed the file I pass to setkey or my racoon.conf. Also, I note that setkey seems to work OK if policies for transport mode are used, but fails on tunnel mode policies. Regards. Mark. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ipsec setkey and 2.4.21 kernel
Mark Devin wrote: I have been running a custom compiled 2.4.21 kernel using the kernel source package from Adrian Bunk's site on Woody. I had an ipsec link setup and it was working well using the Kame implementation which debian has backported into the 2.4.21 kernel sources. I just recompiled my kernel today with the latest 2.4.21 kernel source deb (from Adrian Bunk's site). Now setkey refuses to load my policies which are unchanged from what was working before. Does anyone have any idea how to fix this? Here is the contents of the file I am passing to setkey: -- #!/usr/sbin/setkey -f flush; spdflush; spdadd 192.168.99.0/24[any] 192.168.99.0/24[any] any -P out ipsec esp/tunnel/192.168.1.1-192.168.1.74/require; spdadd 192.168.99.0/24[any] 192.168.99.0/24[any] any -P in ipsec esp/tunnel/192.168.1.74-192.168.1.1/require; -- And here is the errors setkey produces: -- # setkey -f /etc/ipsec.conf The result of line 6: Invalid argument. The result of line 9: Invalid argument. -- I have tried recompiling ipsec-tools from unstable sources. I also made sure the 2.4.21 kernel headers were being used during the compile process for the ipsec-tools package by ensuring the configure script was passed the appropriate --with-kernel-headers parameter in debian/rules. Any other ideas? Actually, it seems to only not work when trying to specify a policy to require tunnel mode. I can load transport policies OK with setkey. However, tunnel mode policies fail with setkey returning "Invalid argument". Regards. Mark.
ipsec setkey and 2.4.21 kernel
I have been running a custom compiled 2.4.21 kernel using the kernel source package from Adrian Bunk's site on Woody. I had an ipsec link setup and it was working well using the Kame implementation which debian has backported into the 2.4.21 kernel sources. I just recompiled my kernel today with the latest 2.4.21 kernel source deb (from Adrian Bunk's site). Now setkey refuses to load my policies which are unchanged from what was working before. Does anyone have any idea how to fix this? Here is the contents of the file I am passing to setkey: -- #!/usr/sbin/setkey -f flush; spdflush; spdadd 192.168.99.0/24[any] 192.168.99.0/24[any] any -P out ipsec esp/tunnel/192.168.1.1-192.168.1.74/require; spdadd 192.168.99.0/24[any] 192.168.99.0/24[any] any -P in ipsec esp/tunnel/192.168.1.74-192.168.1.1/require; -- And here is the errors setkey produces: -- # setkey -f /etc/ipsec.conf The result of line 6: Invalid argument. The result of line 9: Invalid argument. -- I have tried recompiling ipsec-tools from unstable sources. I also made sure the 2.4.21 kernel headers were being used during the compile process for the ipsec-tools package by ensuring the configure script was passed the appropriate --with-kernel-headers parameter in debian/rules. Any other ideas? Regards. Mark.
Re: ipsec setkey and 2.4.21 kernel
Mark Devin wrote: I have been running a custom compiled 2.4.21 kernel using the kernel source package from Adrian Bunk's site on Woody. I had an ipsec link setup and it was working well using the Kame implementation which debian has backported into the 2.4.21 kernel sources. I just recompiled my kernel today with the latest 2.4.21 kernel source deb (from Adrian Bunk's site). Now setkey refuses to load my policies which are unchanged from what was working before. Does anyone have any idea how to fix this? Here is the contents of the file I am passing to setkey: -- #!/usr/sbin/setkey -f flush; spdflush; spdadd 192.168.99.0/24[any] 192.168.99.0/24[any] any -P out ipsec esp/tunnel/192.168.1.1-192.168.1.74/require; spdadd 192.168.99.0/24[any] 192.168.99.0/24[any] any -P in ipsec esp/tunnel/192.168.1.74-192.168.1.1/require; -- And here is the errors setkey produces: -- # setkey -f /etc/ipsec.conf The result of line 6: Invalid argument. The result of line 9: Invalid argument. -- I have tried recompiling ipsec-tools from unstable sources. I also made sure the 2.4.21 kernel headers were being used during the compile process for the ipsec-tools package by ensuring the configure script was passed the appropriate --with-kernel-headers parameter in debian/rules. Any other ideas? Actually, it seems to only not work when trying to specify a policy to require tunnel mode. I can load transport policies OK with setkey. However, tunnel mode policies fail with setkey returning "Invalid argument". Regards. Mark. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
ipsec setkey and 2.4.21 kernel
I have been running a custom compiled 2.4.21 kernel using the kernel source package from Adrian Bunk's site on Woody. I had an ipsec link setup and it was working well using the Kame implementation which debian has backported into the 2.4.21 kernel sources. I just recompiled my kernel today with the latest 2.4.21 kernel source deb (from Adrian Bunk's site). Now setkey refuses to load my policies which are unchanged from what was working before. Does anyone have any idea how to fix this? Here is the contents of the file I am passing to setkey: -- #!/usr/sbin/setkey -f flush; spdflush; spdadd 192.168.99.0/24[any] 192.168.99.0/24[any] any -P out ipsec esp/tunnel/192.168.1.1-192.168.1.74/require; spdadd 192.168.99.0/24[any] 192.168.99.0/24[any] any -P in ipsec esp/tunnel/192.168.1.74-192.168.1.1/require; -- And here is the errors setkey produces: -- # setkey -f /etc/ipsec.conf The result of line 6: Invalid argument. The result of line 9: Invalid argument. -- I have tried recompiling ipsec-tools from unstable sources. I also made sure the 2.4.21 kernel headers were being used during the compile process for the ipsec-tools package by ensuring the configure script was passed the appropriate --with-kernel-headers parameter in debian/rules. Any other ideas? Regards. Mark. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Someone scanned my ssh daemon
On Mon, 2003-06-16 at 23:32, Tomasz Papszun wrote: > On Mon, 16 Jun 2003 at 14:26:33 +0200, Stefan Neufeind wrote: > > On 16 Jun 2003 at 7:00, Halil Demirezen wrote: > > > > > To be brief, I don't usually come accross that there is an exploit for > > > only effective to debian boxes. Plus, There are lots of ways to learn > > > what distribution you are running on your machine. telnet .com 80 > > > and do some returns and you get the info you are running apache with > > > php xxx support on debian box. > > > > > > This is not only ssh case. > > > > Well, but for e.g. php I don't see why this is necessary. Anybody > > wrote a doc on how to suppress unnecessary version-messages? I'd be > > really interested in such things ... > > > > In apache's config: > > ServerTokens ProductOnly > ServerSignature Off > I was going to say exactly this earlier in the thread. I put this in My Apache config quite some time ago when I realised I could. There should be something similar in the sshd_config in my opinion. Of the information spat out from my ssh daemon: SSH-2.0-OpenSSH_3.4p1 Debian 1:3.4p1-1 I believe that clients need only the "SSH-2.0" part. Even some security by obscurity makes me feel better if easy to implement and doesn't make anything more difficult to do. Regards. Mark. signature.asc Description: This is a digitally signed message part
Re: Someone scanned my ssh daemon
On Mon, 2003-06-16 at 23:32, Tomasz Papszun wrote: > On Mon, 16 Jun 2003 at 14:26:33 +0200, Stefan Neufeind wrote: > > On 16 Jun 2003 at 7:00, Halil Demirezen wrote: > > > > > To be brief, I don't usually come accross that there is an exploit for > > > only effective to debian boxes. Plus, There are lots of ways to learn > > > what distribution you are running on your machine. telnet .com 80 > > > and do some returns and you get the info you are running apache with > > > php xxx support on debian box. > > > > > > This is not only ssh case. > > > > Well, but for e.g. php I don't see why this is necessary. Anybody > > wrote a doc on how to suppress unnecessary version-messages? I'd be > > really interested in such things ... > > > > In apache's config: > > ServerTokens ProductOnly > ServerSignature Off > I was going to say exactly this earlier in the thread. I put this in My Apache config quite some time ago when I realised I could. There should be something similar in the sshd_config in my opinion. Of the information spat out from my ssh daemon: SSH-2.0-OpenSSH_3.4p1 Debian 1:3.4p1-1 I believe that clients need only the "SSH-2.0" part. Even some security by obscurity makes me feel better if easy to implement and doesn't make anything more difficult to do. Regards. Mark. signature.asc Description: This is a digitally signed message part
Re: Someone scanned my ssh daemon
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Mark Devin wrote: | It looks as though someone is trying to crack my box through ssh. OK, now I realise that it is an ssh scanner. See: http://www.monkey.org/~provos/scanssh/ Why is it that the Debian version of sshd gives out any information about its version number. Unless it is absolutely necessary for the clients to connect, I would like my ssh daemon to give out no version information to these scanners. Why doesn't debian do this by default? Here is what my machine shows when I run scanssh against it: SSH-2.0-OpenSSH_3.4p1 Debian 1:3.4p1-1 So they know that I am running debian and what version of ssh I use! I know that security through obscurity is no security, but I still don't want to help any attackers. Anyone else have thoughts on this? Regards. Mark. -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQE+7QqJL/zYpWVgapgRAlKNAJ9ttp2EXJTQOM0zbt4QxP9+9035FgCfecVc gIRXdU/bu7D5WN/1s1La4Is= =NZ2c -END PGP SIGNATURE-
Someone scanned my ssh daemon
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 It looks as though someone is trying to crack my box through ssh. This is what logcheck emailed me: - -- snip -- Jun 16 04:36:02 jack sshd[20026]: Connection from 212.202.204.149 port 2323 Jun 16 04:36:03 jack sshd[20027]: Connection from 212.202.204.149 port 2810 Jun 16 04:36:04 jack sshd[20027]: scanned from 212.202.204.149 with SSH-1.0-SSH_Version_Mapper. Don't panic. Jun 16 04:36:04 jack sshd[20026]: Did not receive identification string from 212.202.204.149 - -- end snip -- What is this? I have never seen that scanned message before. Is this a concern? I am running Woody and all packages are up-to-date with security fixes from the debian security site. Regards. Mark. -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQE+7PuvL/zYpWVgapgRAmGEAJ0aiDCMHiLRCJlYFlTArrlQNYNJJQCdE1iJ lL0KRowyskgzckMvgPTOPDQ= =Nol/ -END PGP SIGNATURE-
Re: Someone scanned my ssh daemon
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Mark Devin wrote: | It looks as though someone is trying to crack my box through ssh. OK, now I realise that it is an ssh scanner. See: http://www.monkey.org/~provos/scanssh/ Why is it that the Debian version of sshd gives out any information about its version number. Unless it is absolutely necessary for the clients to connect, I would like my ssh daemon to give out no version information to these scanners. Why doesn't debian do this by default? Here is what my machine shows when I run scanssh against it: SSH-2.0-OpenSSH_3.4p1 Debian 1:3.4p1-1 So they know that I am running debian and what version of ssh I use! I know that security through obscurity is no security, but I still don't want to help any attackers. Anyone else have thoughts on this? Regards. Mark. -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQE+7QqJL/zYpWVgapgRAlKNAJ9ttp2EXJTQOM0zbt4QxP9+9035FgCfecVc gIRXdU/bu7D5WN/1s1La4Is= =NZ2c -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Someone scanned my ssh daemon
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 It looks as though someone is trying to crack my box through ssh. This is what logcheck emailed me: - -- snip -- Jun 16 04:36:02 jack sshd[20026]: Connection from 212.202.204.149 port 2323 Jun 16 04:36:03 jack sshd[20027]: Connection from 212.202.204.149 port 2810 Jun 16 04:36:04 jack sshd[20027]: scanned from 212.202.204.149 with SSH-1.0-SSH_Version_Mapper. Don't panic. Jun 16 04:36:04 jack sshd[20026]: Did not receive identification string from 212.202.204.149 - -- end snip -- What is this? I have never seen that scanned message before. Is this a concern? I am running Woody and all packages are up-to-date with security fixes from the debian security site. Regards. Mark. -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQE+7PuvL/zYpWVgapgRAmGEAJ0aiDCMHiLRCJlYFlTArrlQNYNJJQCdE1iJ lL0KRowyskgzckMvgPTOPDQ= =Nol/ -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
grsecurity vs lsm vs lids
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 OK, I have been seeing lots of people on this list recommend using the grsecurity kernel patch. Now I want to give it a go, but I see that there is also a lsm patch and I also remember lids being recommended in the past by others. I would like to learn the interface to what is going to become the standard in future kernels. I read something while googling that suggested that lsm seems to be the way that the kernel is heading. What do people on this list recommend? Regards. Mark. -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQE+57clL/zYpWVgapgRAhvoAKCjWWfzCxbep+JNTjJHQaj8zhKL3ACffk8U n3GzkQ/8/xFevGntrlpfpFc= =D0BX -END PGP SIGNATURE-
grsecurity vs lsm vs lids
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 OK, I have been seeing lots of people on this list recommend using the grsecurity kernel patch. Now I want to give it a go, but I see that there is also a lsm patch and I also remember lids being recommended in the past by others. I would like to learn the interface to what is going to become the standard in future kernels. I read something while googling that suggested that lsm seems to be the way that the kernel is heading. What do people on this list recommend? Regards. Mark. -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQE+57clL/zYpWVgapgRAhvoAKCjWWfzCxbep+JNTjJHQaj8zhKL3ACffk8U n3GzkQ/8/xFevGntrlpfpFc= =D0BX -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: chkrootkit and LKM
On Mon, 2003-05-26 at 23:27, IC0N wrote: > > Checking `lkm'... You have 1 process hidden for readdir command > You have 1 process hidden for ps command > Warning: Possible LKM Trojan installed > > Sometimes I get 2 or 3 processes, sometimes NONE > If a process is created between the output of ps and the readdir then you will see this sort of output from chkrootkit. However, run chkrootkit several times and if the hidden process number is the same each time then you should be more suspicious. If you consistently get the same hidden process number then try changing into its directory in /proc. Eg. if process 26262 is hidden then try accessing the directory /proc/26262 If the directory exists then you may be dealing with a lkm trojan. Regards. Mark. signature.asc Description: This is a digitally signed message part
Re: chkrootkit and LKM
On Mon, 2003-05-26 at 23:27, IC0N wrote: > > Checking `lkm'... You have 1 process hidden for readdir command > You have 1 process hidden for ps command > Warning: Possible LKM Trojan installed > > Sometimes I get 2 or 3 processes, sometimes NONE > If a process is created between the output of ps and the readdir then you will see this sort of output from chkrootkit. However, run chkrootkit several times and if the hidden process number is the same each time then you should be more suspicious. If you consistently get the same hidden process number then try changing into its directory in /proc. Eg. if process 26262 is hidden then try accessing the directory /proc/26262 If the directory exists then you may be dealing with a lkm trojan. Regards. Mark. signature.asc Description: This is a digitally signed message part
Remotely monitoring security
I need to come up with some solutions for remotely monitoring the security of a server which is off-site. There is no direct connection from the main office to this box except using the internet backbone. I see two immediate issues: 1. I need to setup some method for receiving system logs from the server. I can setup syslog to send logs to one of our office computers. However, I am concerned that the logs should be encrypted. Maybe setting up ipsec?, or using stunnel? Although I thought stunnel was only for TCP connections and syslog uses UDP? 2. Also, I need to setup some intrusion detection system like AIDE or Tripwire. I don't have physical access to the machine so how can I be sure that the AIDE program has not itself been compromised and thus giving me a false sense of security. I can't for example, burn it to CDROM and run it from CD. Everything has to be done remotely. Should I look at LIDS instead? Can ipsec help me with this too? How can I run the AIDE executable from a trusted source and ensure its database remains trusted? Maybe an encrypted filesystem can be used to store the AIDE binary and database, but if so, does anyone have any pointers? Regards. Mark.
