The plan is to use dynamic dns updates with dhcp3 and bind9. We keep lan & wlan seperate, so we can assign domain names based on the medium, if the host got not static-lease assigned based on his mac. Dynamic dhcp hosts get a dns entry like 192-168-5(2|3)-128.dyn.(wifi|wired).example.prv, based on the medium, static dhcp clients can either specify their entry themselves (usually the hostname), or you can set it as part of the config. We use the example.prv domain for our private network.
While the xmpp backend works really good, I've had no problems during the last months, there were very little sensors, basically just my own and - from time to time - some roamers.
As such service is pretty worthless without users, I thought about how to make it more attractive.
The best thing I could come up with, was allowing all sensors to receive files streamed to the xmpp channel, so your benefit from contributing to xmpp is getting something back. And, as this was the most convincing thing I could come up with, I already made it work.
So, if you hook you dionaea to the xmpp channel now, you'll get back all the files collected by other sensors *anonymously* and in realtime.
They end up in the same directory as the files dionaea collects, and basically get the same treatment, so you even receive the sandbox results for them. The only difference in treatment is, you do not stream files gatherd via xmpp to xmpp again.
So, if you want to benefit, update your dionaea, verify the config is up-to-date too, and …
Thats it.
I gave openssl 1.0 a shot, compared the “openssl speed” output to my ubuntu openssl 0.9.8g.
green indicates openssl 1.0 is faster. the numbers are in 1000 bytes per second.
click the image for large version
We need open ssh, as we use git-via-ssh (gitosis rocks too), but we wanted to avoid the nasty ssh bruteforce attempts in the logs.
This is the bruteforce activity for 2 days:
cat /var/log/auth.log | egrep -o 'rhost=([[:alnum:],[:digit:],[:punct:]]*)' | sort -n | uniq -c | sort -nr
9178 rhost=124.124.52.162
4623 rhost=u127.umbra.fastwebserver.de
4110 rhost=218.75.79.19
4053 rhost=mail.zenit-trade.ru
3660 rhost=84.243.246.109
2804 rhost=201.17.146.129
1857 rhost=59.40.182.186
978 rhost=222.46.121.106
861 rhost=59.37.54.41
296 rhost=121.14.129.135
216 rhost=cl-t020-180cl.privatedns.com
133 rhost=61.187.94.171
12 rhost=flh1adm107.kng.mesh.ad.jp
12 rhost=125.210.253.164
I had a look on denyhosts, and even though it would have done the job too, I prefered to disallow the attacker to connect to the attacked service, instead of dropping accepted connections via tcpwrappers host.deny.
fail2ban does a perfect job on this, it uses iptables to ban attackers from the service.
We're recovering, scm is semi-available yet.
Update #1
Some noteable changes:
Update #2
Update #3
We've had some odd things happening, we don't know how yet, but it was odd.
To make sure things don't get worse we disabled the svn repository.
If you have an idea how to verify an svn repositories integrity, comments are open …
I just committed xmpp backend code.
The backend code can:
Short update on xmpp, I setup prosody (again), and connected two clients:
it works, still hacked the reporting to be no xml, else psi does not render it
There is malware downloading files from rapidshare to install on your drive. Nothing new, I've had shellcode downloading files from rapidshare before
| first | last | hits | url |
|---|---|---|---|
| 2010-01-06 | 2010-01-07 | 2 | hxtp://rapidshare.com/files/331049304/hitman1 |
| 2010-01-08 | 2010-01-10 | 2 | hxtp://rapidshare.com/files/332058885/two |
| 2010-01-12 | 2010-01-12 | 1 | hxtp://rapidshare.com/files/333804484/roo |
| 2010-01-17 | 2010-01-17 | 1 | hxtp://rapidshare.com/files/335701706/uhit |
| 2010-01-20 | 2010-01-20 | 1 | hxtp://rapidshare.com/files/337582552/newtom |
| 2010-01-20 | 2010-01-20 | 1 | hxtp://rapidshare.com/files/337582552/newtom |
| 2010-01-21 | 2010-01-21 | 1 | hxtp://rapidshare.com/files/338398794/tomhas |
| 2010-01-21 | 2010-01-21 | 1 | hxtp://rapidshare.com/files/338403156/farhas |
| 2010-01-25 | 2010-01-25 | 1 | hxtp://rapidshare.com/files/340552045/tomd |
| 2010-01-27 | 2010-01-27 | 1 | hxtp://rapidshare.com/files/341701463/tsa |
| 2010-01-27 | 2010-01-27 | 1 | hxtp://rapidshare.com/files/341737994/xc |
| 2010-01-29 | 2010-01-30 | 2 | hxtp://rapidshare.com/files/342702954/dams |
but, the shellcode downloads the files directly.
create your own - the Bart Simpson generator
As distributed sensors are desireable, I had another look on xmpp over the weekend. XMPP is basically an xml stream for instant messaging, which can be used for other things too.
The good news first, it works:
screenshot from the reporting using psi, I had to change the rendering to escape < and >, else psi would not render it …
Beeing glad I'm not the only one who argues about the unportability of s6_add32, here is what the cups authors think about it.
/* * Oh, the wonderful world of IPv6 compatibility. Apparently some * implementations expose the (more logical) 32-bit address parts * to everyone, while others only expose it to kernel code... To * make supporting IPv6 even easier, each vendor chose different * core structure and union names, so the same defines or code * can't be used on all platforms. * * The following will likely need tweaking on new platforms that * support IPv6 - the "s6_addr32" define maps to the 32-bit integer * array in the in6_addr union, which is named differently on various * platforms. */ #if defined(AF_INET6) && !defined(s6_addr32) # if defined(__sun) # define s6_addr32 _S6_un._S6_u32 # elif defined(__FreeBSD__) || defined(__NetBSD__) || defined(__OpenBSD__) || defined(__APPLE__) # define s6_addr32 __u6_addr.__u6_addr32 # elif defined(__osf__) # define s6_addr32 s6_un.sa6_laddr # elif defined(WIN32) /* * Windows only defines byte and 16-bit word members of the union and * requires special casing of all raw address code... */ # define s6_addr32 error_need_win32_specific_code # endif /* __sun */ #endif /* AF_INET6 && !s6_addr32 */
source: cups
