On Thu, 5 Feb 2009, David C. Rankin wrote:-

To have a little fun, I did an experiment. It seems that the hits I get are primarily looking for html2text.php or msgimport.php in the /roundcube/bin directory. So, I took an 8 Meg pdf filing from a court case (it's public record) and renamed it to html2text.php and then linked msgimport.php to it and put it in the /roundcube/bin directory on my server:

11:19 nirvana:/srv/www> l htdocs/roundcube/bin/ total 8132 drwxr-xr-x 2 root root 4096 2009-02-04 01:36 ./ drwxr-xr-x 3 root root 4096 2009-01-30 21:42 ../ -rw-r--r-- 1 root root 8306307 2009-01-30 13:46 html2text.php lrwxrwxrwx 1 root root 13 2009-02-04 01:36 msgimport.php -> html2text.php

The apache2/access_log is heartening...

You can save some space on the server by replacing html2text.php with this: <?php passthru('dd if=/dev/urandom bs=$[1+${RANDOM}] count=$[1+$[${RANDOM}%128]]'); ?> It gives a similar effect, but randomizes the size of the data to be sent. The %128 should make sure the maximum data to be transferred 4MB or lower. As an explanation, passthru() passes the results of the system command straight through without any modification of the output. In this case, the results are a random length stream of data from /dev/urandom . ${RANDOM} gives values between 0 and 32767, so 1 is added to make sure there's never a 0-byte block size. The ${RANDOM}%128 makes sure the count is less than 128, and 1 is added to make sure there's never a count of 0. If you'd prefer not to use /dev/urandom , you could change the command to if=/dev/zero instead and have the same effect. Regards, David Bolt -- Team Acorn: http://www.distributed.net/ OGR-NG @ ~100Mnodes RC5-72 @ ~1Mkeys/s | openSUSE 10.3 32b | openSUSE 11.0 32b | openSUSE 10.2 64b | openSUSE 10.3 64b | openSUSE 11.0 64b | openSUSE 11.1 64b TOS 4.02 | openSUSE 10.3 PPC | RISC OS 3.6 | RISC OS 3.11 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

On Thu, 5 Feb 2009, Carlos E. R. wrote:-

On Thursday, 2009-02-05 at 18:44 -0000, David Bolt wrote:

...

If you'd prefer not to use /dev/urandom , you could change the command to if=/dev/zero instead and have the same effect.

In my machine, it is slow and cpu intensive.

Hmm, using /dev/urandom on my machines, the test transfers were done so fast that I couldn't tell whether it was CPU intensive or not. However, re-testing using test blocks of 1MB and a count of 1000 does show it to be CPU intensive and fairly slow using /dev/urandom. Doing the same test using /dev/zero required a significantly larger count for any meaningful measurements. Keeping the 1MB block size and upping the count to 1024000, giving a total transfer of 1,073,741,824,000 bytes, showed that dd may also be fairly CPU intensive using /dev/zero as well. On one system, a 1.6GHz Sempron, dd used 90+% CPU for about 36 seconds and transferred at about 35.5GB/s. On another, a 2.6GHz X2, it took about 23 seconds and used about 50% on each core to transfer at about 46.5GB/s. Purely out of curiosity, I also tested it on my slowest system. That system is an old 300MHz P2 laptop, and it took 71 seconds with the processor at a little under 95%. Its transfer rate was a fraction under 14GB/s. So, end results of this very unscientific test is that using /dev/urandom may be slow and CPU intensive, while using /dev/zero possibly gives very short, and on my systems at least, immeasurable CPU usage spikes. Regards, David Bolt -- Team Acorn: http://www.distributed.net/ OGR-NG @ ~100Mnodes RC5-72 @ ~1Mkeys/s | openSUSE 10.3 32b | openSUSE 11.0 32b | openSUSE 10.2 64b | openSUSE 10.3 64b | openSUSE 11.0 64b | openSUSE 11.1 64b TOS 4.02 | openSUSE 10.3 PPC | RISC OS 3.6 | RISC OS 3.11 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thursday, 2009-02-05 at 14:36 -0800, Randall R Schulz wrote:

...

...

In my machine, it is slow and cpu intensive.

Hmm, using /dev/urandom on my machines, the test transfers were done so fast that I couldn't tell whether it was CPU intensive or not.

Depending on your hardware (might you have a hardware RNG?) this might be expected to be the case at least some of the time.

However, keep in mind that there are things for which entropy is required that are more important than giving script kiddies headaches, and pulling a lot of data out of /dev/urandom when there is no hardware RNG can deplete the available entropy and require some time for more to accumulate.

Mmm... interesting explanation, I like it. Yes, it is used in cryptography. This operation: time nice dd if=/dev/urandom of=/dev/sda4 run at 1.6..1.8 megs per second on my system (12.6 hours to fill an 80 GB partition). They say /dev/random is faster. - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkmLdlQACgkQtTMYHG2NR9WuFQCfTr3FUCUSmMeThfE8kenmmabD 5MMAnjW3EU56Ok9wc7pxtxqbq3nyoK/3 =HBQS -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thursday, 2009-02-05 at 16:13 -0800, Randall R Schulz wrote:

On Thursday February 5 2009, Carlos E. R. wrote:

...

... They say /dev/random is faster.

I didn't come across that, but I did find someone saying that by using /dev/random you can expose things about the source of entropy on your system in such a way to increase the vulnerability of hashes based upon that random data.

It's all far more than the limits of my knowledge of cryptography and the underlying mathematics allows me to say I understand.

Ah, I was wrong, I think it is the other way round, urandom is the faster one, because it doesn't wait for more entropy. There is more info on random(4). And it is thus /dev/urandom the one that could theoretically be attacked, they mention it on that man page. - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkmLjQYACgkQtTMYHG2NR9WC8QCfQQBF9XTD1aFpp6JDGlQAGUbY W3oAnj4uDXEGKEjItI5qyxV9iQL8kHfz =gw3P -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Friday, 2009-02-06 at 00:16 -0000, David Bolt wrote:

<Snip good reasons to not be using /dev/(u)random >

That all points towards /dev/zero being a good source then.

For having a laugh, the instructions for filling the tax returns or memoranda on the fine points of law are very good. /dev/zero can be compressed to much to be good for this >.-) - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkmLjhkACgkQtTMYHG2NR9WCTQCggnT2Fkt8tjuoH2nm7JTxoCS4 MREAni4ohJQRIVUF+L6J14q0CiPtaZUf =VaLQ -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Content-ID: <alpine.LSU.2.00.0902060407131.5741@nimrodel.valinor> On Friday, 2009-02-06 at 02:50 +0100, David Haller wrote:

You guys have it the wrong way around. You don't want to give 'em randomness as fast as you can, but you want to give it to them as _slow_ as you can!

Make that file e.g. 4MByte and deliver it at 1 Byte/s!

X'-) Good point. But then, we need a way to deliver slowly a file, which uses less cpu for us. Now, I read somewhere, maybe in the kernel documentation, a method to have a slow device via devmapper. Here: /usr/src/linux/Documentation/device-mapper/delay.txt: +++ dm-delay ======== Device-Mapper's "delay" target delays reads and/or writes and maps them to different devices. Parameters: <device> <offset> <delay> [<write_device> <write_offset> <write_delay>] With separate write parameters, the first set is only used for reads. Delays are specified in milliseconds. Example scripts =============== [[ #!/bin/sh # Create device delaying rw operation for 500ms echo "0 `blockdev --getsize $1` delay $1 0 500" | dmsetup create delayed ]] [[ #!/bin/sh # Create device delaying only write operation for 500ms and # splitting reads and writes to different devices $1 $2 echo "0 `blockdev --getsize $1` delay $1 0 0 $2 0 500" | dmsetup create delayed ]] ++- I don't know how exactly to use that for the current situation (or for any situation), but there it is. If anybody wants to explain the above in clear English, I'm all ears ;-) - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkmLq9UACgkQtTMYHG2NR9UDRACeN8eCREAeh8DnikzmYCEAy3Gn alsAoJhfbSxlR9+1sUFJrW5OesbDj/wB =dUrM -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

Per Jessen schreef:

David Haller wrote:

...

You guys have it the wrong way around. You don't want to give 'em randomness as fast as you can, but you want to give it to them as _slow_ as you can!

And it doesn't have to be random either. I've redirected dodgy requests to 'wait.php' for the last 6 years:

--- wait.php --- ignore_user_abort(0);

$filler=str_repeat(" ",16384);

for( $i=1800; $i; $i-- ) { if ( connection_status() ) exit(0); print $_SERVER['REMOTE_ADDR']." -- ".floor($i / 60)." minutes, " ($i % 60)." seconds and counting ...<br/>".$filler; sleep(1); flush(); } print "Done.<br/>".$filler; --- php end ---

Works great, and hardly any stress on my server. One detail: you forgot a point in the print line. It should be: print $_SERVER['REMOTE_ADDR']." -- ".floor($i / 60)." minutes, ". ($i % 60)." seconds and counting ...<br/>".$filler; -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thursday, 2009-02-05 at 11:19 -0600, David C. Rankin wrote:

To have a little fun, I did an experiment. It seems that the hits I get are primarily looking for html2text.php or msgimport.php in the /roundcube/bin directory. So, I took an 8 Meg pdf filing from a court case (it's public record) and renamed it to html2text.php and then linked msgimport.php to it and put it in the /roundcube/bin directory on my server:

X'-) - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkmLOvcACgkQtTMYHG2NR9WAOACcDNdOq5rTaPkD1mnSpE4+yd0E pPYAn1X+keeanhRLCzK6JPmEc0nmfbBP =EdSA -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

Amedee Van Gasse wrote:

On Wed, February 4, 2009 08:39, David C. Rankin wrote:

...

Listmates,

I get roundcube is a mail package, but I don't have it. So why are people looking for it on my web server. Is it a compromised app that people are looking to exploit? Anybody running it?

It's a webmail app like Squirrelmail, and I'm running it on my server. I don't know about any exploits but if there are, I'd like to know about it.

see: http://forums.vpslink.com/security/6571-roundcube-exploit-progress.html -- David C. Rankin, J.D.,P.E. Rankin Law Firm, PLLC 510 Ochiltree Street Nacogdoches, Texas 75961 Telephone: (936) 715-9333 Facsimile: (936) 715-9339 www.rankinlawfirm.com -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org