Steve Kemp's Blog

There are many online blacklists which are populated by volunteers. I'm looking for such a blacklist which contains records of hosts conducting portscans, ssh brute-forcing, or other similar "badness".

dshield looks good - but doesn't make the scanning IP availble - just shows the port data.

denyhosts allows you to upload/download a list of IPs trying to run ssh bruteforce attacks - but when I wrote my own RPC code to poll that list of IPs I found I couldnt' get the full list.

I'm aware that I could run denyhosts on a spare IP, then just copy the IPs it downloads but that feels icky...

I'm unaware of any existing service that I could use for my purposes.

So would there be any interest in a service listing only portscanning/ssh brute-force IPs? (Allowing DNS queries, XML-RPC, or rsync downloads of the submitted data.)

Obviously I have my own reason for wanting such a list of bad IPs... Those are probably obvious, but it does seem like it would be generally useful.

I'd be willing to host a server to process the submitted reports, and make the results available, but I guess thats the easy part. The hard part is persuading people to run my "submit IP" client. Which has to understand ssh logs, iptable logs, or something similar.. Ugh.

I guess between the machiens I work with and the machines I host myself I've got a fair number of IPs which I could collect scans from - I could populate the database myself. But this is a perfect job for distributed submission.

ObQuote: Batoru rowaiaru

I've setup several repositories for apt-get in the past, usually using reprepro as the backend. Each time I've come up with a different scheme to maintain them.

Time to make things consistent with a helper tool:

skx@gold:~/hg/rapt$ ls input/
spambayes-threaded_0.1-1_all.deb        spambayes-threaded_0.1-1.dsc
spambayes-threaded_0.1-1_amd64.build    spambayes-threaded_0.1-1.dsc.asc
spambayes-threaded_0.1-1_amd64.changes  spambayes-threaded_0.1-1.tar.gz

So we have an input directory containing just the package(s) we want to be in the repository.

We have an (empty) output directory:

skx@gold:~/hg/rapt$ ls output/
skx@gold:~/hg/rapt$

Now lets run the magic:

skx@gold:~/hg/rapt$ ./bin/rapt --input=./input/ --output=./output/
Data seems not to be signed trying to use directly...
Data seems not to be signed trying to use directly...
Exporting indices...

What do we have now?

skx@gold:~/hg/rapt$ tree output/
output/
|-- dists
|   `-- etch
|       |-- Release
|       |-- main
|           |-- binary-amd64
|           |   |-- Packages
|           |   |-- Packages.bz2
|           |   |-- Packages.gz
|           |   `-- Release
|           `-- source
|               |-- Release
|               |-- Sources
|               |-- Sources.bz2
|               `-- Sources.gz
|-- index.html
`-- pool
    `-- main
        `-- s
            `-- spambayes-threaded
                |-- spambayes-threaded_0.1-1.dsc
                |-- spambayes-threaded_0.1-1.tar.gz
                `-- spambayes-threaded_0.1-1_all.deb

neat.

Every time you run the rapt tool the output pool and dists directories are removed and then rebuilt to contain only the packages located in the incoming/ directory. (More correctly only *.changes are processed. Not *.deb.)

This mode of operation might strike some people as odd - but I guess it depends on whether you view "incoming" to mean "packages to be added to the exiting pool", or "packages to take as the incoming input to the pool generation process".

Anyway if it is useful to others feel free to clone it from the mercurial repository. There is no homepage yet, but it should be readable code and there is a minimum of supplied documentation in the script itself ..

ObQuote: Buffy. Again.