Re: FTP Bounce scan
Oops... *shame on me* Just noticed that source.rfc822.org -> ftp2.de.debian.org (switched to that one because ftp.de.debian.org seemed down) It must have been apt-get update that tried to use active FTP which got blocked by the firewall and logged by snort... Excuse me for waisting everybodies precious time... Dries
FTP Bounce scan
Today, I saw in the snort logs the following: (removed ip & date to get it in 78-col format) 193.189.224.13:21 -> ip:58153 UNKNOWN *2*A**S* RESERVEDBITS 193.189.224.13:42940 -> ip:113 SYN 12S* RESERVEDBITS 193.189.224.13:42941 -> ip:58154 UNKNOWN *2*A**S* RESERVEDBITS 193.189.224.13:42942 -> ip:58155 UNKNOWN *2*A**S* RESERVEDBITS 193.189.224.13:42943 -> ip:58156 UNKNOWN *2*A**S* RESERVEDBITS 193.189.224.13:42944 -> ip:58157 UNKNOWN *2*A**S* RESERVEDBITS 193.189.224.13:42945 -> ip:58158 UNKNOWN *2*A**S* RESERVEDBITS 193.189.224.13:42946 -> ip:58159 UNKNOWN *2*A**S* RESERVEDBITS 193.189.224.13:42947 -> ip:58160 UNKNOWN *2*A**S* RESERVEDBITS 193.189.224.13:42948 -> ip:58161 UNKNOWN *2*A**S* RESERVEDBITS 193.189.224.13:42949 -> ip:58162 UNKNOWN *2*A**S* RESERVEDBITS 193.189.224.13:42950 -> ip:58163 UNKNOWN *2*A**S* RESERVEDBITS 193.189.224.13:42951 -> ip:58164 UNKNOWN *2*A**S* RESERVEDBITS 193.189.224.13:42952 -> ip:58165 UNKNOWN *2*A**S* RESERVEDBITS 193.189.224.13:42953 -> ip:58166 UNKNOWN *2*A**S* RESERVEDBITS 193.189.224.13:42954 -> ip:58167 UNKNOWN *2*A**S* RESERVEDBITS 193.189.224.13:42955 -> ip:58168 UNKNOWN *2*A**S* RESERVEDBITS 193.189.224.13:42956 -> ip:58169 UNKNOWN *2*A**S* RESERVEDBITS 193.189.224.13:42958 -> ip:58170 UNKNOWN *2*A**S* RESERVEDBITS 193.189.224.13:42959 -> ip:58171 UNKNOWN *2*A**S* RESERVEDBITS 193.189.224.13:42960 -> ip:58172 UNKNOWN *2*A**S* RESERVEDBITS 193.189.224.13:42962 -> ip:58173 UNKNOWN *2*A**S* RESERVEDBITS 193.189.224.13:42963 -> ip:58174 UNKNOWN *2*A**S* RESERVEDBITS 193.189.224.13:42965 -> ip:58175 UNKNOWN *2*A**S* RESERVEDBITS 193.189.224.13:42966 -> ip:58176 UNKNOWN *2*A**S* RESERVEDBITS 193.189.224.13:42967 -> ip:58177 UNKNOWN *2*A**S* RESERVEDBITS 193.189.224.13:21 -> ip:58180 UNKNOWN *2*A**S* RESERVEDBITS 193.189.224.13:43074 -> ip:113 SYN 12S* RESERVEDBITS 143.169.4.111:22 -> ip:22 SYNFIN **SF 143.169.4.111:4614 -> ip:22 SYN **S* Is this a so-called ftp-bounce scan? Because it starts every time with a connection from port 21, en next to a bunch of connections on higher ports. These came in bursts, each time for about one minute or so. The source is 'source.rfc822.org' (193.189.224.13). Does this mean their ftp server is misconfigured? Should I warn them about his? Nothing did get through my firewall (and ippl didn't show anything either), so I shouldn't worry about this? Am I right in saying that using ipt_conntrack_ftp doesn't make me more vulnerable to this, as it only opens up for connections going *out* from my machine? Thanks for the info, Dries
Re: FTP Bounce scan
Oops... *shame on me* Just noticed that source.rfc822.org -> ftp2.de.debian.org (switched to that one because ftp.de.debian.org seemed down) It must have been apt-get update that tried to use active FTP which got blocked by the firewall and logged by snort... Excuse me for waisting everybodies precious time... Dries -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
FTP Bounce scan
Today, I saw in the snort logs the following: (removed ip & date to get it in 78-col format) 193.189.224.13:21 -> ip:58153 UNKNOWN *2*A**S* RESERVEDBITS 193.189.224.13:42940 -> ip:113 SYN 12S* RESERVEDBITS 193.189.224.13:42941 -> ip:58154 UNKNOWN *2*A**S* RESERVEDBITS 193.189.224.13:42942 -> ip:58155 UNKNOWN *2*A**S* RESERVEDBITS 193.189.224.13:42943 -> ip:58156 UNKNOWN *2*A**S* RESERVEDBITS 193.189.224.13:42944 -> ip:58157 UNKNOWN *2*A**S* RESERVEDBITS 193.189.224.13:42945 -> ip:58158 UNKNOWN *2*A**S* RESERVEDBITS 193.189.224.13:42946 -> ip:58159 UNKNOWN *2*A**S* RESERVEDBITS 193.189.224.13:42947 -> ip:58160 UNKNOWN *2*A**S* RESERVEDBITS 193.189.224.13:42948 -> ip:58161 UNKNOWN *2*A**S* RESERVEDBITS 193.189.224.13:42949 -> ip:58162 UNKNOWN *2*A**S* RESERVEDBITS 193.189.224.13:42950 -> ip:58163 UNKNOWN *2*A**S* RESERVEDBITS 193.189.224.13:42951 -> ip:58164 UNKNOWN *2*A**S* RESERVEDBITS 193.189.224.13:42952 -> ip:58165 UNKNOWN *2*A**S* RESERVEDBITS 193.189.224.13:42953 -> ip:58166 UNKNOWN *2*A**S* RESERVEDBITS 193.189.224.13:42954 -> ip:58167 UNKNOWN *2*A**S* RESERVEDBITS 193.189.224.13:42955 -> ip:58168 UNKNOWN *2*A**S* RESERVEDBITS 193.189.224.13:42956 -> ip:58169 UNKNOWN *2*A**S* RESERVEDBITS 193.189.224.13:42958 -> ip:58170 UNKNOWN *2*A**S* RESERVEDBITS 193.189.224.13:42959 -> ip:58171 UNKNOWN *2*A**S* RESERVEDBITS 193.189.224.13:42960 -> ip:58172 UNKNOWN *2*A**S* RESERVEDBITS 193.189.224.13:42962 -> ip:58173 UNKNOWN *2*A**S* RESERVEDBITS 193.189.224.13:42963 -> ip:58174 UNKNOWN *2*A**S* RESERVEDBITS 193.189.224.13:42965 -> ip:58175 UNKNOWN *2*A**S* RESERVEDBITS 193.189.224.13:42966 -> ip:58176 UNKNOWN *2*A**S* RESERVEDBITS 193.189.224.13:42967 -> ip:58177 UNKNOWN *2*A**S* RESERVEDBITS 193.189.224.13:21 -> ip:58180 UNKNOWN *2*A**S* RESERVEDBITS 193.189.224.13:43074 -> ip:113 SYN 12S* RESERVEDBITS 143.169.4.111:22 -> ip:22 SYNFIN **SF 143.169.4.111:4614 -> ip:22 SYN **S* Is this a so-called ftp-bounce scan? Because it starts every time with a connection from port 21, en next to a bunch of connections on higher ports. These came in bursts, each time for about one minute or so. The source is 'source.rfc822.org' (193.189.224.13). Does this mean their ftp server is misconfigured? Should I warn them about his? Nothing did get through my firewall (and ippl didn't show anything either), so I shouldn't worry about this? Am I right in saying that using ipt_conntrack_ftp doesn't make me more vulnerable to this, as it only opens up for connections going *out* from my machine? Thanks for the info, Dries -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Portsentry & iptables
After noticing some more portscans (fast, even in order - nice snort logs though) I remembered portsentry. Thanks to debian's apt-get I didn't take long to install & check it out of course. I noticed in standard-mode, it binds to some ports and just waits until somebody connects to them. The documentation also suggests NOT to use the host-blocking feature upon detection of a portscan. Wel, my questions are: 1) I noticed it was non-free: is there any free equivalent? 2) When one also runs a firewall (fully closed tcp range except the few needed services ofcourse) people scanning the box (if they use connect-scan that is) never even hit portsentry because of the firewall. In this case, could it be justified to use the blocking feature? (In the event somebody bypasses the firewall and touches the wrong port they still would be blocked out) 3) Has anybody some experience with this tool? (like using the syn-mode, number of false blockings/alerts, advanced mode, ...) Dries
Portsentry & iptables
After noticing some more portscans (fast, even in order - nice snort logs though) I remembered portsentry. Thanks to debian's apt-get I didn't take long to install & check it out of course. I noticed in standard-mode, it binds to some ports and just waits until somebody connects to them. The documentation also suggests NOT to use the host-blocking feature upon detection of a portscan. Wel, my questions are: 1) I noticed it was non-free: is there any free equivalent? 2) When one also runs a firewall (fully closed tcp range except the few needed services ofcourse) people scanning the box (if they use connect-scan that is) never even hit portsentry because of the firewall. In this case, could it be justified to use the blocking feature? (In the event somebody bypasses the firewall and touches the wrong port they still would be blocked out) 3) Has anybody some experience with this tool? (like using the syn-mode, number of false blockings/alerts, advanced mode, ...) Dries -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: I've been hacked by DevilSoul
On 13 Jan 2002, Florian Weimer wrote: > Henrique de Moraes Holschuh <[EMAIL PROTECTED]> writes: > > > On Fri, 11 Jan 2002, Ricardo B wrote: > > > Isn't there a way to turn module loading off (a way that can't be chagend > > > back - without rebooting) ? > > > > None that cannot be undone if you're root in a non-ACL kernel. It gets hard > > if the kernel has no module support at all, but not impossible. > Hmm, am I right in assuming that all (current) non-LKM rootkits use write access on /dev/kmem (/dev/mem)? In anycase, patching the kernel that there's no write access would be a good idea. Anybody knows of programs that need to write to dev kmem? There are some (mostly video drivers) that write there I think, but most should only be reading (like videoboard grabbers). Another solution could be to randomize (or at least pick a non-standard) GFP_KERNEL, as (in the article) there is no algorithm (yet) to find that value. I'd rather have the box kernel-panic. (Well, not *every* day of course ;-) Dries
Re: I've been hacked by DevilSoul
On 13 Jan 2002, Florian Weimer wrote: > Henrique de Moraes Holschuh <[EMAIL PROTECTED]> writes: > > > On Fri, 11 Jan 2002, Ricardo B wrote: > > > Isn't there a way to turn module loading off (a way that can't be chagend > > > back - without rebooting) ? > > > > None that cannot be undone if you're root in a non-ACL kernel. It gets hard > > if the kernel has no module support at all, but not impossible. > Hmm, am I right in assuming that all (current) non-LKM rootkits use write access on /dev/kmem (/dev/mem)? In anycase, patching the kernel that there's no write access would be a good idea. Anybody knows of programs that need to write to dev kmem? There are some (mostly video drivers) that write there I think, but most should only be reading (like videoboard grabbers). Another solution could be to randomize (or at least pick a non-standard) GFP_KERNEL, as (in the article) there is no algorithm (yet) to find that value. I'd rather have the box kernel-panic. (Well, not *every* day of course ;-) Dries -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: I've been hacked by DevilSoul
On Sat, 12 Jan 2002, Richard wrote: > > On Fri, Jan 11, 2002 at 10:25:03PM +0100, martin f krafft wrote: > > > > > > i doubt that a kernel module can override the linux kernel filesystem > > > abstraction layer. but i guess it could be possible. > > > > > > > Oh, it certainly can! knark is a perfect example of a kernel module to > > do just this. (knark is Swedish for "drugged".) It allows files, > > processes, network connections, and network interface promiscuity to be > > *completely* hidden. It allows the cracker to override what actual > > binary file gets run when a user tries to run some other (possibly > > hidden) executable. > > Here kstat might be of intrest, it's getting it's information directly > from the kernel structures. (reading /dev/kmen, and using a dummy module) > Looking at all the nice things one can do with a modern (and surprisingly easy to make) rootkit, I'm really thinking about just avoiding modular kernels at any cost. I once had a redhat box hacked (old lpr exploit [from within the 'trusted' network]). Think it was adore I found (along with some sniffers) I already avoid modules on most places (gateway, webservers, ...). Usually the pro's from modules outweight the con's, but nowadays, with memory that cheap i don't think it's worth the trouble anylonger. Still, knark is nice work ;-) Solves the whole AIDE-problem a hacker has on most systems these days... As the document states, one of the only possibilities in detecting knark is using the utils and try to get root yourself, or unhide/hide files. Adore already had a solution for that: those things mostly work by sending a signal to the process, and adore used an offset, so the 'standard' detection tools couldn't detect it anymore. Without the correct offset, nobody but those who installed the rootkit could use it (easily). The problem is that with code like that lying around (don't get me wrong, I think it's *good* that people create things like that - without challenge, there's no need for improvement, and it stimulates creativity - but what worries me is that it lowers the treshold. You don't have to know that much about linux kernel internals to adapt the knark code to use different signals/ports. As soon as people start to do that, most rootkit-detection software fails... And as said in this thread before, one can hide for a very long time in a (standard) linux system... Dries
Re: I've been hacked by DevilSoul
On Sat, 12 Jan 2002, Richard wrote: > > On Fri, Jan 11, 2002 at 10:25:03PM +0100, martin f krafft wrote: > > > > > > i doubt that a kernel module can override the linux kernel filesystem > > > abstraction layer. but i guess it could be possible. > > > > > > > Oh, it certainly can! knark is a perfect example of a kernel module to > > do just this. (knark is Swedish for "drugged".) It allows files, > > processes, network connections, and network interface promiscuity to be > > *completely* hidden. It allows the cracker to override what actual > > binary file gets run when a user tries to run some other (possibly > > hidden) executable. > > Here kstat might be of intrest, it's getting it's information directly > from the kernel structures. (reading /dev/kmen, and using a dummy module) > Looking at all the nice things one can do with a modern (and surprisingly easy to make) rootkit, I'm really thinking about just avoiding modular kernels at any cost. I once had a redhat box hacked (old lpr exploit [from within the 'trusted' network]). Think it was adore I found (along with some sniffers) I already avoid modules on most places (gateway, webservers, ...). Usually the pro's from modules outweight the con's, but nowadays, with memory that cheap i don't think it's worth the trouble anylonger. Still, knark is nice work ;-) Solves the whole AIDE-problem a hacker has on most systems these days... As the document states, one of the only possibilities in detecting knark is using the utils and try to get root yourself, or unhide/hide files. Adore already had a solution for that: those things mostly work by sending a signal to the process, and adore used an offset, so the 'standard' detection tools couldn't detect it anymore. Without the correct offset, nobody but those who installed the rootkit could use it (easily). The problem is that with code like that lying around (don't get me wrong, I think it's *good* that people create things like that - without challenge, there's no need for improvement, and it stimulates creativity - but what worries me is that it lowers the treshold. You don't have to know that much about linux kernel internals to adapt the knark code to use different signals/ports. As soon as people start to do that, most rootkit-detection software fails... And as said in this thread before, one can hide for a very long time in a (standard) linux system... Dries -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Deducing key from encrypted & original data
Hi, this is something I've been wondering for some time now: Is it possible (or at least much easier) to extract the encryption key if you both have the encrypted and original data? Dries PS. I know it isn't debian-related, but it's a good question anyway...
Deducing key from encrypted & original data
Hi, this is something I've been wondering for some time now: Is it possible (or at least much easier) to extract the encryption key if you both have the encrypted and original data? Dries PS. I know it isn't debian-related, but it's a good question anyway... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
