2010-10-30 (#)
Met mijn aanval van BBS-nostalgie na het opduiken van de nodige text files van Koos z'n Doos ook maar eens voorzichtig de nederlandse wikipedia pagina's over NEABBS en Bulletin Board System bijgewerkt.
Update: en daarna in een vlaag van overmoed ook mijn 'overlegpagina' leeggehaald omdat daar al tijden stond dat ik welkom ben op wikipedia, wat ik nu wel weet. Blijkbaar was dat niet de bedoeling, gelijk moest iemand er op duiken om dat terug te draaien en een ander dat weer corrigeren.
2010-10-30 (#)
Interesting experience: trying to get a peek at a spamvertised website with lynx, and all of a sudden all the IPs of the site stop responding on port 80. Makes me think research with a bit of caution is unwanted. Maybe time to fake the user-agent to be a vulnerable Internet Explorer (although things like p0f will still detect linux, that's a bit harder to fake).The spam was a faked facebook notification:
Hi, You haven't been back to Facebook recently. You have received notifications while you were gone.Easy to spot as fake: I can't go back to facebook because I don't have an account there. "Facebook" makes Echelon look like a childish attempt at gathering information about people so I'll skip.All links in the mail were to http://yourrxpress.net/ which resolves to:
yourrxpress.net has address 88.255.78.101 yourrxpress.net has address 88.255.78.102 yourrxpress.net has address 86.55.211.121 yourrxpress.net has address 86.55.211.122 yourrxpress.net has address 86.55.211.123Interesting that *all* IPs started to firewall after I tried two times with lynx.
2010-10-29 (#)
I was in a bit BBS-nostalgic mood so I had a look at the old BBS tape and threw a number of files on-line at http://bbs.idefix.net/. The additions are in the Text files.
One of the additions is The canonical list of 'You Know When You've Been Hacking Too Long When' for which I was the maintainer for a while.
I lived both in the BBS world and the Internet world at the time (mostly Usenet!) so I brought good stuff from newsgroups like rec.humor to the BBS file archives.
The fail whale is gone! But, but, but ...
2010-10-27 (#)
I introduced a MediaWiki at work (science ict department) to use for internal documentation. One of the things I wanted to try is pages in the wiki created or maintained from other sources.I created a special namespace for pages with information from other sources, where normal users have no rights to edit pages. This is to make sure nobody tries to edit something which is maintained by a script from another source.
I started with something simple: the list of printers. The windows printserver is leading, so I want to fetch the list there and massage it to generate a list of printers and comments. The weapon of choice is perl and MediaWiki::Bot. The output of smbclient -N -L printserver takes one regexp to find printqueuenames and descriptions. For the overview of cups queues I can parse the output of lpstat -a. With a bit more digging into IPP it should also be possible to get a list of details of printers to link cups queues and their windows counterparts.I can run this script from crontab each day and the history tracking in MediaWiki will start to help document when something changed. Another thing which we can stop worrying about.
I have visions of the future of automatically linking zabbix (which has a json interface) and mediawiki and maybe a further future with a good database of stuff which is a source of entries in zabbix and the wiki. Double work is unneeded, computers are much better at working with one canonical source and importing that in a lot of places.
2010-10-26 (#)
And another asterisk SIP scan flood. It seems 213.77.26.82 also runs an old version svcrack, given the timing:9.001251 213.77.26.82 -> mm.nn.oo.pp SIP Request: REGISTER sip:mm.nn.oo.pp 9.006190 213.77.26.82 -> mm.nn.oo.pp SIP Request: REGISTER sip:mm.nn.oo.pp 9.011838 213.77.26.82 -> mm.nn.oo.pp SIP Request: REGISTER sip:mm.nn.oo.pp 9.016725 213.77.26.82 -> mm.nn.oo.pp SIP Request: REGISTER sip:mm.nn.oo.pp 9.021696 213.77.26.82 -> mm.nn.oo.pp SIP Request: REGISTER sip:mm.nn.oo.pp 9.027144 213.77.26.82 -> mm.nn.oo.pp SIP Request: REGISTER sip:mm.nn.oo.pp 9.032294 213.77.26.82 -> mm.nn.oo.pp SIP Request: REGISTER sip:mm.nn.oo.pp 9.037223 213.77.26.82 -> mm.nn.oo.pp SIP Request: REGISTER sip:mm.nn.oo.pp 9.042141 213.77.26.82 -> mm.nn.oo.pp SIP Request: REGISTER sip:mm.nn.oo.pp 9.047801 213.77.26.82 -> mm.nn.oo.pp SIP Request: REGISTER sip:mm.nn.oo.pp 9.052514 213.77.26.82 -> mm.nn.oo.pp SIP Request: REGISTER sip:mm.nn.oo.pp 9.057900 213.77.26.82 -> mm.nn.oo.pp SIP Request: REGISTER sip:mm.nn.oo.ppThe left column is in seconds, so that is 0.06 seconds worth of traffic.A bit of tcpdumping and an attempt with svcrash later it seems this is not the old version of the svcrack script as certain headers are updated (no more 1.1.1.1 IP address).. and the crash trick does not work. From the packet capture:
Session Initiation Protocol Request-Line: REGISTER sip:mm.nn.oo.pp SIP/2.0 Method: REGISTER [Resent Packet: False] Message Header Via: SIP/2.0/UDP 213.77.26.82:5131;branch=z9hG4bK-1864113917;rport Transport: UDP Sent-by Address: 213.77.26.82 Sent-by port: 5131 Branch: z9hG4bK-1864113917 RPort: rport Content-Length: 0 From: "3992603480" <sip:3992603480@mm.nn.oo.pp> SIP Display info: "3992603480" SIP from address: sip:3992603480@mm.nn.oo.pp Accept: application/sdp User-Agent: friendly-scanner To: "3992603480" >sip:3992603480@mm.nn.oo.pp> SIP Display info: "3992603480" SIP to address: sip:3992603480@mm.nn.oo.pp Contact: sip:123@213.77.26.82:5131 Contact Binding: sip:123@213.77.26.82:5131 URI: sip:123@213.77.26.82:5131\r SIP contact address: sip:123@213.77.26.82:5131\r CSeq: 1 REGISTER Sequence Number: 1 Method: REGISTER Call-ID: 3252836054 Max-Forwards: 70I notified the abuse address for tpnet.pl, let's see what that does.
Update: Well, the flood of SIP packets from 213.77.26.82 stopped. 7484510 attack packets stopped by fail2ban rule.
2010-10-25 (#)
Op een regenachtige zondagmiddag / avond de scanner aangezet. Bij het doorzoeken van de FM radio band (87.50 - 108.00 MHz) viel het me op dat ik in Utrecht op zondagmiddag geen enkele radiopiraat kon horen, terwijl zondagmiddag toch wel de ideale tijd is voor radio piraten. Magoed, agentschap telecom is daar tegenwoordig streng op. Verder was het grappig om op de 27 MHz kanalen iemand te horen die uitgebreid over z'n medische problemen aan het vertellen was.
2010-10-22 (#)
Google being actually slow over IPv6. Looks like IPv6 within googlenet is lossy:$ traceroute6 www.google.com traceroute to www.google.com (2a00:1450:8001::68) from 2001:980:14ca:2:21f:e1ff:fe45:2894, port 33434, from port 44229, 30 hops max, 60 byte packets 1 eth0-3.idefix.net (2001:980:14ca:2:21f:c6ff:fe59:76f6) 0.984 ms 1.138 ms 1.193 ms 2 lo1.dr4.1d12.xs4all.net (2001:888:0:4401::1) 20.699 ms 46.655 ms 19.687 ms 3 2001:888:0:4403::2 (2001:888:0:4403::2) 43.353 ms 15.605 ms 14.354 ms 4 0.ge-1-2-0.xr1.sara.xs4all.net (2001:888:2:2::1) 16.748 ms 25.312 ms 15.390 ms 5 pr61.ams04.net.google.com (2001:7f8:1::a501:5169:1) 16.627 ms 16.499 ms * 6 * 2001:4860::1:0:4b3 (2001:4860::1:0:4b3) 16.892 ms * 7 2001:4860::1:0:2a (2001:4860::1:0:2a) 21.734 ms 52.506 ms 44.668 ms 8 * * 2001:4860::34 (2001:4860::34) 74.322 ms 9 2001:4860:0:1::1b (2001:4860:0:1::1b) 47.581 ms 61.300 ms 90.075 ms 10 2a00:1450:8001::68 (2a00:1450:8001::68) 62.479 ms * *and a few minutes later it works again :)
2010-10-22 (#)
A very nice example of "why let facts get in the way of a good story": Google mapping team gets 'lost'.EVEN the boffins behind Google's revolutionary Street View can get LOST.With a photo credit(?) for Newsteam.co.uk.This employee was snapped reading a roadside MAP despite being on a mission to collect images for the world's most popular photographic database of towns and cities.
They were forced to pull over on the side of a remote stretch of road in Elsrijkdreef, near Amsterdam, where one of the team had to get out and consult a map as well as appearing to call for help.
The angle / view / granularity of the picture combined with the fact that the cars are not pulled over at all made me think it is a streetview photo itself and browsing around the Elsrijkdreef in Amsterdam shows this nicely: lots of images with three other streetview cars in the picture.
Image (C) google streetviewMy best guess is that there were four streetview cars, with the picture from the first one and they passed a bystander who was peering at the map. I can duplicate the situation with streetview but I can't (at the moment) get the correct deeplink. So a screengrab will have to do.
2010-10-22 (#)
If you want to look at your apache logfiles in Hollywood-style, try logstalgia which makes apache look like a sort of pong game. Needs a videocard with OpenGL. And access to the access_log of a busy server.
2010-10-21 (#)
The SIP scanner on 62.48.49.40 must be using an older version of SIPvicious: a number of hours after fail2ban automatically blocked the IP the traffic rose to about 50 kilobyte/second of SIP REGISTER requests. The rule set by fail2ban has until now dropped 3291335 tries.The older version also means svcrash.py works. So I had to give it a try, and that did wonders for the flood: it directly stopped. If the owner of the SIP scanner wants to discuss this attack on his systems by me, please do.
The traffic is back to a 'trickle' (about 10 seconds between requests). All mails to varous abuse addresses haven't worked yet.
2010-10-20 (#)
Another heavy hitter SIP scan attack:[2010-10-20 16:36:31] NOTICE[1516] chan_sip.c: Registration from '"2758977752"<sip:2758977752@mm.nn.oo.pp>' failed for '62.48.49.40' - No matching peer found [2010-10-20 16:36:31] NOTICE[1516] chan_sip.c: Registration from '"717551073"<sip:717551073@mm.nn.oo.pp>' failed for '62.48.49.40' - No matching peer found [2010-10-20 16:36:31] NOTICE[1516] chan_sip.c: Registration from '"100"<sip:100@mm.nn.oo.pp>' failed for '62.48.49.40' - No matching peer found [2010-10-20 16:36:31] NOTICE[1516] chan_sip.c: Registration from '"101"<sip:101@mm.nn.oo.pp>' failed for '62.48.49.40' - No matching peer found [2010-10-20 16:36:31] NOTICE[1516] chan_sip.c: Registration from '"102"<sip:102@mm.nn.oo.pp>' failed for '62.48.49.40' - No matching peer found .. [2010-10-20 19:33:56] NOTICE[1516] chan_sip.c: Registration from '"5616" <sip:5616@mm.nn.oo.pp>' failed for '62.48.49.40' - No matching peer found [2010-10-20 19:33:56] NOTICE[1516] chan_sip.c: Registration from '"5616" <sip:5616@mm.nn.oo.pp>' failed for '62.48.49.40' - No matching peer foundCausing (until now) 108704 log entries like these. The downside is that I have to stop these by hand (the 'rejected' SIP messages are filling the ADSL upstream). Somehow fail2ban fails to ban these. The test says nicely they are seen:# fail2ban-regex /var/log/asterisk/messages /etc/fail2ban/filter.d/asterisk.conf 62.48.49.40 (Wed Oct 20 19:33:55 2010) 62.48.49.40 (Wed Oct 20 19:33:55 2010) 62.48.49.40 (Wed Oct 20 19:33:56 2010) 62.48.49.40 (Wed Oct 20 19:33:56 2010)But somehow, the running fail2ban doesn't notice the messages or doesn't act on them. Since fail2ban is in python and multithreaded I can't debug it. All I see is a failure to regularly scan /var/log/asterisk/messages for new messages.
Update: Lots of debugging later: I made a typo in the ignoreip option in the general fail2ban config, and the code which parses this only runs as part of a python thread and the error gets ignored. Fixed that and now it works:[Fail2Ban] ASTERISK: banned 62.48.49.40
2010-10-19 (#)
De adsl lijn speelde de laatste dagen buienradar: na een fikse bui zakte de snelheid flink in en namen de hikken toe. Ik heb maar weer eens gebeld met de xs4all helpdesk, maar zolang de sessie niet volledig verbroken wordt door lijnkwaliteit problemen kan KPN er niet op afgestuurd worden. Als oplossing maar de lijn teruggezet naar een 10 megabit profiel, maar voorlopig blijft de stabiliteit matig. Ik denk toch dat er ergens een matige las ofzo in de draad zit die steeds meer ellende aan het opleveren is. Je zou bijna de pppd settings aanpassen om wat sneller de verbinding te verbreken. Da's alleen zo onhandig in huis.
2010-10-18 (#)
This is cool: Alcatel-Lucent Bell Labs has republished the archives of the Bell System Technical Journal, 1922-1983 from 1922 - 1983. Lots of information in there, including research behind what are now common theories in information science.
2010-10-14 (#)
Triggered by a question I was browsing around on the Defense Information Systems Agency website and noticed this little gem in avoiding information leaks: DISN data services has this nice image of a soldier at a console of a data center. The tags on the nearby servers have been made fuzzy so you can't (ab)use this picture ;)
Image probaby (c) Copyright US army.
2010-10-14 (#)
It seems a telephone DDoS attack on citibank London was tried. I see a lot of attempts to call +44-20-7500-5000 in the Asterisk logs, and this matches to this listing for citibank London with the incorrect display of the number (either use +44-20-7500-5000 or 020-7500-5000).[2010-10-13 07:10:08] NOTICE[1516] chan_sip.c: Call from '' to extension '#442075005000' rejected because extension not found. [2010-10-13 07:10:08] NOTICE[1516] chan_sip.c: Call from '' to extension '0#442075005000' rejected because extension not found. [2010-10-13 07:10:08] NOTICE[1516] chan_sip.c: Call from '' to extension '00442075005000' rejected because extension not found. [2010-10-13 07:10:08] NOTICE[1516] chan_sip.c: Call from '' to extension '00#442075005000' rejected because extension not found. [2010-10-13 07:10:09] NOTICE[1516] chan_sip.c: Call from '' to extension '000442075005000' rejected because extension not found. [2010-10-13 07:10:20] NOTICE[1516] chan_sip.c: Call from '' to extension '995442075005000' rejected because extension not found. [2010-10-13 07:10:20] NOTICE[1516] chan_sip.c: Call from '' to extension '99599442075005000' rejected because extension not found. [2010-10-13 07:10:20] NOTICE[1516] chan_sip.c: Call from '' to extension '998442075005000' rejected because extension not found. [2010-10-13 07:10:20] NOTICE[1516] chan_sip.c: Call from '' to extension '9999442075005000' rejected because extension not found. [2010-10-13 07:10:20] NOTICE[1516] chan_sip.c: Call from '' to extension '9442075005000' rejected because extension not found.Asterisk was kind enough to log the source:[2010-10-13 07:10:28] WARNING[1516] chan_sip.c: Maximum retries exceeded on transmission 355498004-01909399823-101602981@218.16.119.153 for seqno 102 (Critical Response) [2010-10-13 07:10:28] WARNING[1516] chan_sip.c: Maximum retries exceeded on transmission 1252672785-00018196951-458183090@218.16.119.153 for seqno 102 (Critical Response) [2010-10-13 07:10:28] WARNING[1516] chan_sip.c: Maximum retries exceeded on transmission 2001768799-01552085073-741882079@218.16.119.153 for seqno 102 (Critical Response)Which seems to be a known source for SIP attacks.
2010-10-12 (#)
Ik heb er niets over on-line kunnen vinden maar ik heb wel vertrouwen in Rudolf van der Berg die in een discussie via (o.a.) Twitter nog even opmerkte dat het hernieuwde overleg over het aanbieden van BBC kanalen via andere aanbieders dan die bij de Vecai in alle stilte mislukt is.internetthought Why does BBC allow Swisscom to broadcast it's channels, but not Dutch FTTH providers to do the same?khoos @internetthought those 'new talks' between BBC UK and ftth providers we heard about aren't delivering anything yet...internetthought @khoos just look at the swisscom broadband tV site. They even have Channel 4 and 5, Ceebeebies and ITV. And the talks have failed yes
2010-10-12 (#)
Fun with rechargeable batteries: two GP NiMh 2300 mAh batteries. One spent months in my MP3 player, sometimes playing stuff. The other was sitting in a drawer. When the battery in my MP3 player stopped I wanted to change to the other one, but that one was empty enough too that the MP3 player would not boot. So self-discharge takes more out of the batteries than my MP3 listening I guess.
2010-10-10 (#)
It seems there is an entire business model in having websites which show up in google searches for 'product type manual' and then either may have a manual but require you to jump through many hoops (giving them your e-mail address, entering captcha codes) or think a brochure pdf for a range of products is also a manual or plainly show somewhere hidden between the ads that more people are looking for that manual and it would be awesome if someone uploaded it to that site. Names like safemanuals.com, manualsonline.com and fixya.com are the first few who just annoyed me. In the end going to the attic and searching the box found the paper manuals which have the info I need.
2010-10-09 (#)
There is a large spam network behind this money mule recruitment spam doing the rounds:Building & Investment Company is pleased to offer you an excellent-paid part-time vacancy for the position of Administrative Assistant(Representative). You would work from the comfort of your home office or in our office, it would depend on your choice.I'm receiving it on several addresses from all over the world, which shows there is a serious spam network behind this. The fact that whoever mails this is in such a need of money mules in the Netherlands shows that there is a bigger criminal organisation behind it.Don't fall for it: you will be assisting in crime.
In het kort: dit is werk als 'money mule' en dat is een gegarandeerde manier om een veroordeling voor fraude op te lopen. Doe het niet.
2010-10-07 (#)
Large IPv6 implementations with ISPs are happening! According to Deutsche Telekom konkretisiert IPv6-Pläne - Heise online every T-DSL based connection in Germany will be dual stack before the end of 2011:Die Deutsche Telekom wird bis Ende 2011 bundesweit alle DSL-Anschlüsse auf den Dual-Stack-Betrieb mit IPv4 und IPv6 umstellen. Das erklärte Konzernsprecher Hans-Martin Lichtenthäler auf Anfrage von heise Netze.If I have my numbers correct, there are 11.5 million DSL lines with Deutsche Telekom. That is a LOT of end-users getting dual-stack connectivity.
2010-10-06 (#)
PinDr0p is a system for tracing call paths across multiple phone networks released by Georgia Tech. The first application they mention is detecting "vishing" (Voice phishing), the call center of your bank should not be routed via a satellite path and a voip exchange in Lagos.My first thought was: "will it detect the clicks, clangs and noises from old electromechanical switches". That might be even easier than the modern delays, jitter and packet loss.
Found via Voice-routing call fingerprint system fights 'vishing' - The Register. I love the 'Actually, I don't think my bank has a Lagos call centre' byline.
Update I asked the above question about electromechanical exchanges to the media contact for the research, who forwarded it to the researcher. The researcher found it an interesting question and thinks it is doable.
2010-10-05 (#)
Danny Burstein asks an interesting question in comp.risks:And once again we're treated to a malware warning, make that a near hysterical warning (especially the way it was covered by the mass media) which leaves out a key point, namely which computer operating systems and software packages are potentially affected.An interesting question. You don't hear mainstream news telling another microsoft windows virus is doing the rounds.When there's a safety concern with cars, there's no reluctance in publicizing the brand name. Even when the company is a major advertiser.
Why do we see so much hesitation in computer issues?AdB once had a very good idea, putting warnings on windows software boxes just like on cigarette boxes:
If only certain other packaging had to devote half the front panel to a huge black-and-white ``WINDOWS BOTNETS''. Sure, verbification weirds language, but given that the remaining space is being given over to M$'s marketing department, it should fit right in.
2010-10-04 (#)
Implementing a blacklist check in zabbix was a bit more complicated than I originally thought. Searching for it found Monitor DNS blacklist entries - zabbix forums which points at Monitor DNS blacklist entries with Zabbix - Penumbra where shell scripts are suggested. I decided to rewrite stuff in perl using Net::DNS because I wanted a bit more robustness.Well, as the docs for Net::DNS say:
BUGS "Net::DNS" is slow.checking 89 blacklists took about 25 seconds. Default external checks in zabbix need to be done in 3 seconds. As a crummy workaround I now run the checks from cron every 15 minutes which dump the result in a tempfile and the check is on the content of the tempfile, also every 15 minutes. Crude, but effective.
2010-10-04 (#)
Just had a look at backscatterer.org (one of the IPs I'm testing zabbix rbl checks on is listed). And found this gem:This IP is temporary listed. The listing will expire automatically and free of charge 4 weeks after the last abuse is seen from that IP.Lots of terms I can think of, but my first one which is nice enough to publish is 'extortion racket'.
Expedited manual expressdelisting is available as an option, in case you do not want to wait for the automatic and free expiration.
You will be charged 74 EUR
2010-10-04 (#)
Interesting SIP attack in the logs just now:[2010-10-04 13:56:40] NOTICE[24598] chan_sip.c: Registration from '"4282946309"<sip:4282946309@xx.xx.xx.xxx>' failed for '211.234.117.92' - No matching peer found [2010-10-04 13:56:41] NOTICE[24598] chan_sip.c: Registration from '"2466009100"<sip:2466009100@xx.xx.xx.xxx>' failed for '211.234.117.92' - No matching peer found [2010-10-04 13:56:48] NOTICE[24598] chan_sip.c: Registration from '"2466009100" <sip:2466009100@xx.xx.xx.xxx>' failed for '211.234.117.92' - No matching peer found [2010-10-04 13:56:49] NOTICE[24598] chan_sip.c: Registration from '"2466009100" <sip:2466009100@xx.xx.xx.xxx>' failed for '211.234.117.92' - No matching peer found.. 10815 entries skipped[2010-10-04 14:02:00] NOTICE[24598] chan_sip.c: Registration from '"2466009100" <sip:2466009100@xx.xx.xx.xxx>' failed for '211.234.117.92' - No matching peer foundI guess an entire dictionary flew by in somewhat over 5 minutes, causing some delay on the line.
2010-10-04 (#)
Er is nog genoeg te vinden op de scanner, je moet als scannerluisteraar alleen iets meer moeite steken in het zichtbaar maken van de signalen. Ook de politie blijkt nog bruikbare informatie te strooien door de lucht, blijkt uit onderzoek van Frequency Monitor Centre: Ernstig informatielek Politie Rotterdam-Rijnmond : middels het (verder technisch mooie) mobitex systeem van RAM mobile data wordt onversleuteld data uitgewisseld. De 'smoking gun' is natuurlijk dat de gegevens van de extra beveiliging van Balkenende gewoon te ontvangen zijn.
2010-10-03 (#)
Niet alleen de nigeriaanse oplichters hebben nu google translate ontdekt om krom Nederlands te schrijven, maar ook andere oplichters. Vandaag spam van webmenshirts.com met de prachtige zinsconstructie:Al onze ontwerpen zijn wasbaar in de machine 30° voor basis-onderhoud eenvoudig.