2018-01-27 I caused an interesting problem with the VDSL pppoe session
Normally being active on certain HF bands causes one-time VDSL disconnects but what I have currently done seems to have triggered something else. After the connection dropped it refuses to come back at the moment. The entire session looks like:22:49:28.466922 PPPoE PADI [Service-Name] 22:49:28.490394 PPPoE PADO [AC-Name "dr12.d12"] [Service-Name] [AC-Cookie 0xA3FE109A222CE73945C23FCE85E03F83] [EOL] 22:49:28.490603 PPPoE PADR [Service-Name] [AC-Cookie 0xA3FE109A222CE73945C23FCE85E03F83] 22:49:28.517063 PPPoE PADS [ses 0x40c] [Service-Name] [AC-Name "dr12.d12"] [AC-Cookie 0xA3FE109A222CE73945C23FCE85E03F83] [EOL] 22:49:28.575266 PPPoE [ses 0x40c] LCP, Conf-Request (0x01), id 72, length 16 22:49:28.575776 PPPoE [ses 0x40c] LCP, Conf-Request (0x01), id 99, length 22 22:49:28.575798 PPPoE [ses 0x40c] LCP, Conf-Reject (0x04), id 72, length 10 22:49:28.589161 PPPoE [ses 0x40c] LCP, Conf-Ack (0x02), id 99, length 22 22:49:28.589164 PPPoE [ses 0x40c] LCP, Conf-Request (0x01), id 73, length 12 22:49:28.589666 PPPoE [ses 0x40c] LCP, Conf-Ack (0x02), id 73, length 12 22:49:28.589682 PPPoE [ses 0x40c] LCP, Echo-Request (0x09), id 0, length 10 22:49:28.589693 PPPoE [ses 0x40c] CCP, Conf-Request (0x01), id 89, length 17 22:49:28.589702 PPPoE [ses 0x40c] IPCP, Conf-Request (0x01), id 89, length 18 22:49:28.589711 PPPoE [ses 0x40c] IP6CP, Conf-Request (0x01), id 89, length 16 22:49:28.603265 PPPoE [ses 0x40c] LCP, Echo-Reply (0x0a), id 0, length 10 22:49:28.603267 PPPoE [ses 0x40c] LCP, Term-Request (0x05), id 74, length 6 22:49:28.604033 PPPoE [ses 0x40c] LCP, Term-Ack (0x06), id 74, length 6 22:49:31.623454 PPPoE PADT [ses 0x40c] [Generic-Error "RP-PPPoE: System call error: Input/output error"] [AC-Cookie 0xA3FE109A222CE73945C23FCE85E03F83]So in the end the router at my ISP decides to terminate the connection. On the connection failing I decided to change the configuration to use the kernel mode pppoe driver but after this started showing I reverted that change. Which made no difference, the connection is still not coming up. Update: I went looking at other changes I made to enable the pppoe server test and reverting the /etc/ppp/pap-secrets file to its original format fixed the problem. I guess I somehow started to authenticate the remote end. And changing from user-mode pppoe to kernel-mode pppoe does lower the MTU to 1492, so that test is also finished. Back to user-mode pppoe.
2018-01-25 Building a testing server for pppoe
The new homeserver will have to run the same pppoe client setup as the current server. But I want to get the whole setup tested before the migration to minimize disruption. Since I'm not going to get a free extra vdsl line and vdsl modem to test with and the complicated part is in the pppoe and ppp client part I decided to use a test vlan and set up a pppoe-server and ppp server on that vlan. The pppoe server part is started with# pppoe-server -I eth0.99 -C kzdoos -L 172.16.19.1 -R 172.16.21.19And it's indeed available from the client:# pppoe-discovery -I eth2 Access-Concentrator: kzdoos Got a cookie: 84 39 c6 51 13 fe 32 00 2c 06 2a b4 38 0e 30 87 46 7b 00 00 -------------------------------------------------- AC-Ethernet-Address: 00:1f:c6:59:76:f6So that part works. Next is to get an actual ppp session working over it. The server part was a bit of work as I want to get the whole configuration including password checks. Server configuration in /etc/ppp/pppoe-server-options on the server system:require-pap lcp-echo-interval 10 lcp-echo-failure 2 hide-password noipx ipv6 ,And the client configuration in /etc/ppp/peers/dray-vdsl:user testkees password topsecret +pap noauth noipdefault ipv6 , ipv6cp-use-persistent defaultroute persist maxfail 0 noproxyarp ipparam xs4all lcp-echo-interval 10 lcp-echo-failure 6 pty "pppoe -I eth2"Lots of options to make the setup exactly the same as the current. It took a lot of tries before password authentication was working. I could not get the client-side password in /etc/ppp/pap-secrets to work, but as show above the password in the ppp configuration did work. And the setup in /etc/network/interfaces on the client just the same as the known configuration:iface pppdray inet ppp provider dray-vdslAnd it works!# ifup pppdray Plugin rp-pppoe.so loaded. # ifconfig ppp0 ppp0: flags=4305<UP,POINTOPOINT,RUNNING,NOARP,MULTICAST> mtu 1492 inet 172.16.21.45 netmask 255.255.255.255 destination 172.16.19.1 inet6 fe80::5254:ff:fe3c:2014 prefixlen 10 scopeid 0x20<link> ppp txqueuelen 3 (Point-to-Point Protocol) RX packets 9 bytes 252 (252.0 B) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 9 bytes 202 (202.0 B) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 # ping -c 3 172.16.19.1 PING 172.16.19.1 (172.16.19.1) 56(84) bytes of data. 64 bytes from 172.16.19.1: icmp_seq=1 ttl=64 time=0.721 ms 64 bytes from 172.16.19.1: icmp_seq=2 ttl=64 time=0.436 ms 64 bytes from 172.16.19.1: icmp_seq=3 ttl=64 time=0.449 ms --- 172.16.19.1 ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2029ms rtt min/avg/max/mdev = 0.436/0.535/0.721/0.132 msThe mtu is not yet what I want, but the session is alive.
2018-01-23 Avoiding the linux statefull firewall for some traffic
I was setting up a linux based firewall on a busy ntp server and to make sure everything worked as designed I added the usual:iptables -A INPUT -j ACCEPT --protocol all -m state --state ESTABLISHED,RELATEDAnd after less than half an hour the system log started filling withnf_conntrack: table full, dropping packet nf_conntrack: table full, dropping packet nf_conntrack: table full, dropping packet nf_conntrack: table full, dropping packetIt is indeed a busy server. The solution is to exclude all the ntp traffic from the stateful firewall. Which means I have to allow all kinds of ntp traffic (outgoing and incoming) by itself. The specific ruleset:iptables -t raw -A PREROUTING --protocol udp --dport 123 -j NOTRACK iptables -t raw -A OUTPUT --protocol udp --sport 123 -j NOTRACK iptables -A INPUT -j ACCEPT --protocol udp --destination-port 123I also made sure the rules for the ntp traffic are the first rules. Traffic at this server is somewhat over 1000 ntp request per second. So the counters of the NOTRACK rules go fast.# iptables -t raw -L -v Chain PREROUTING (policy ACCEPT 1652K packets, 126M bytes) pkts bytes target prot opt in out source destination 9635K 732M CT udp -- any any anywhere anywhere udp dpt:ntp NOTRACK 1650K 125M CT udp -- any any anywhere anywhere udp dpt:ntp NOTRACK Chain OUTPUT (policy ACCEPT 1522K packets, 117M bytes) pkts bytes target prot opt in out source destination 9029K 686M CT udp -- any any anywhere anywhere udp spt:ntp NOTRACK 1520K 116M CT udp -- any any anywhere anywhere udp spt:ntp NOTRACKBut no packets are dropped, which is good as this server is supposed to be under a constant DDoS.
2018-01-23 (And they are back! New episodes showing up.)
Koos van den Hout : And they are back! New episodes showing up.
2018-01-19 Collecting ages of ntpd mode 7 probes
I noticed today one of the ntp servers I manage has been collecting ages of ntpd mode 7 probes without ever responding. But it makes a nice overview of probing IPv4 addresses:remote address port local address count m ver rstr avgint lstint =============================================================================== 184.105.139.82 1714 xxx.xxx.xxx.xxx 3 7 2 1 3413098 40058 184.105.139.72 14152 xxx.xxx.xxx.xxx 7 6 2 1 1107023 60553 185.165.29.145 33482 xxx.xxx.xxx.xxx 9 7 2 1 647886 73704 91.200.12.126 47493 xxx.xxx.xxx.xxx 2 7 2 1 12199 78678 185.94.111.1 33066 xxx.xxx.xxx.xxx 44 7 2 1 139771 83493 212.237.45.33 39353 xxx.xxx.xxx.xxx 1 7 2 1 0 84058 184.105.139.122 16124 xxx.xxx.xxx.xxx 4 7 2 1 1830407 127241 165.227.44.214 36749 xxx.xxx.xxx.xxx 1 7 2 1 0 138342 185.82.203.150 38141 xxx.xxx.xxx.xxx 12 7 2 1 147806 143793 185.2.81.90 33119 xxx.xxx.xxx.xxx 6 7 2 1 199742 180842 184.105.139.110 57630 xxx.xxx.xxx.xxx 6 7 2 1 968029 223794 77.87.79.97 34540 xxx.xxx.xxx.xxx 2 7 2 1 31910 251316 184.105.139.102 50130 xxx.xxx.xxx.xxx 3 7 2 1 2950157 308291 185.55.218.227 33716 xxx.xxx.xxx.xxx 2 7 2 1 853413 311971 104.243.41.54 30820 xxx.xxx.xxx.xxx 2 7 2 1 3258925 334017 123.249.27.176 35963 xxx.xxx.xxx.xxx 7 7 2 1 452131 339518 191.96.249.173 42895 xxx.xxx.xxx.xxx 10 7 2 1 692139 348753 71.194.80.50 51096 xxx.xxx.xxx.xxx 2 7 2 1 74579 392665 184.105.139.126 38393 xxx.xxx.xxx.xxx 2 7 2 1 3535530 394349 185.55.218.250 48871 xxx.xxx.xxx.xxx 2 7 2 1 537671 411921 184.105.139.86 34651 xxx.xxx.xxx.xxx 5 7 2 1 1361673 478157 123.249.24.175 37973 xxx.xxx.xxx.xxx 6 7 2 1 476469 502270 184.105.139.98 21269 xxx.xxx.xxx.xxx 10 7 2 1 718112 567076 184.105.139.70 38190 xxx.xxx.xxx.xxx 6 7 2 1 1107237 649625 66.55.135.62 54536 xxx.xxx.xxx.xxx 8 7 2 1 40836 721372 138.197.130.148 39857 xxx.xxx.xxx.xxx 2 7 2 1 415601 788308 191.96.249.113 36079 xxx.xxx.xxx.xxx 2 7 2 1 1501700 862267 184.105.139.78 37702 xxx.xxx.xxx.xxx 4 7 2 1 1637431 908028 159.89.47.224 47766 xxx.xxx.xxx.xxx 5 7 2 1 361160 913255 162.209.168.12 39122 xxx.xxx.xxx.xxx 2 7 2 1 109901 976174 123.249.26.159 34990 xxx.xxx.xxx.xxx 41 7 2 1 88999 1045070 184.105.139.74 38666 xxx.xxx.xxx.xxx 6 7 2 1 822261 1079624 185.55.218.242 54815 xxx.xxx.xxx.xxx 7 7 2 1 89032 1102095 191.96.249.12 48406 xxx.xxx.xxx.xxx 4 7 2 1 1133779 1198815 101.100.146.139 39660 xxx.xxx.xxx.xxx 3 7 2 1 1951322 1244586 209.250.238.186 39459 xxx.xxx.xxx.xxx 2 7 2 1 53072 1252190 119.1.109.85 51099 xxx.xxx.xxx.xxx 10 7 2 1 223881 1325320 184.105.139.118 34319 xxx.xxx.xxx.xxx 4 7 2 1 905995 1339133 184.105.139.106 15081 xxx.xxx.xxx.xxx 2 7 2 1 2932231 1430316 191.96.249.131 35972 xxx.xxx.xxx.xxx 2 7 2 1 1499287 1491171 185.55.218.237 43409 xxx.xxx.xxx.xxx 2 7 2 1 4255207 1497992 185.55.218.236 55927 xxx.xxx.xxx.xxx 3 7 2 1 1566148 1718947 138.68.247.41 41914 xxx.xxx.xxx.xxx 2 7 2 1 53524 1936953 184.105.139.94 41523 xxx.xxx.xxx.xxx 5 7 2 1 1112720 1948506 45.63.27.150 40862 xxx.xxx.xxx.xxx 2 7 2 1 1676933 1991259 185.188.207.13 45915 xxx.xxx.xxx.xxx 20 7 2 1 156321 2041538 185.44.107.183 45785 xxx.xxx.xxx.xxx 2 7 2 1 132706 2107890 184.105.139.90 35315 xxx.xxx.xxx.xxx 5 7 2 1 350936 2206670 191.96.249.61 30296 xxx.xxx.xxx.xxx 3 7 2 1 59063 2226284 195.22.127.173 40060 xxx.xxx.xxx.xxx 2 7 2 1 20615 2253429 184.105.139.114 56609 xxx.xxx.xxx.xxx 4 7 2 1 604491 2291452 104.243.41.52 123 xxx.xxx.xxx.xxx 2 7 2 1 85831 2381504 103.9.78.129 50367 xxx.xxx.xxx.xxx 2 7 2 1 868629 2449128 167.88.15.18 40815 xxx.xxx.xxx.xxx 2 7 2 1 182471 2525650 167.88.180.82 40640 xxx.xxx.xxx.xxx 2 7 2 1 66892 2715823 192.158.229.240 39284 xxx.xxx.xxx.xxx 4 7 2 1 163873 2759391 51.15.45.102 45371 xxx.xxx.xxx.xxx 2 7 2 1 92720 2768083 185.198.58.55 18637 xxx.xxx.xxx.xxx 2 7 0 1 802096 2787683 123.249.24.197 40362 xxx.xxx.xxx.xxx 37 7 2 1 85431 2983252 167.88.180.26 49125 xxx.xxx.xxx.xxx 4 7 2 1 60114 3023906 188.213.49.83 34969 xxx.xxx.xxx.xxx 2 7 2 1 254056 3095396 45.76.24.165 41025 xxx.xxx.xxx.xxx 2 7 2 1 107397 3103557 213.183.54.46 40409 xxx.xxx.xxx.xxx 5 7 2 1 206100 3224158 145.239.237.23 35814 xxx.xxx.xxx.xxx 2 7 2 1 571497 3264230 165.227.220.24 39557 xxx.xxx.xxx.xxx 2 7 2 1 52796 3292818 123.249.35.214 47756 xxx.xxx.xxx.xxx 2 7 2 1 242695 3296347 123.249.76.52 59698 xxx.xxx.xxx.xxx 8 7 2 1 246226 3446607 123.249.79.178 52301 xxx.xxx.xxx.xxx 2 7 2 1 839605 3455884 207.254.182.131 52337 xxx.xxx.xxx.xxx 4 7 2 1 1384 3648002 185.55.218.109 37602 xxx.xxx.xxx.xxx 2 7 2 1 752428 3652434 128.14.61.111 53586 xxx.xxx.xxx.xxx 3 7 2 1 103699 3796467 104.238.146.66 52224 xxx.xxx.xxx.xxx 2 7 2 1 138668 3837468 95.215.62.72 42111 xxx.xxx.xxx.xxx 4 7 2 1 608618 3932262 45.76.195.157 59987 xxx.xxx.xxx.xxx 2 7 2 1 143642 4096101 123.249.79.232 40165 xxx.xxx.xxx.xxx 4 7 2 1 146715 4317577 86.105.9.86 55857 xxx.xxx.xxx.xxx 4 7 2 1 115972 4329305 217.147.89.197 49717 xxx.xxx.xxx.xxx 4 7 2 1 314874 4463013 182.18.22.246 58611 xxx.xxx.xxx.xxx 3 7 2 1 359548 4485937 185.82.203.107 56661 xxx.xxx.xxx.xxx 7 7 2 1 176060 4516810 79.124.60.148 58043 xxx.xxx.xxx.xxx 2 7 2 1 687406 4684505 185.107.94.66 46254 xxx.xxx.xxx.xxx 2 7 2 1 1263073 4750583 191.96.249.84 49259 xxx.xxx.xxx.xxx 2 7 2 1 329846 5160890 111.121.193.201 6065 xxx.xxx.xxx.xxx 3 7 0 1 101832 5558503 185.188.207.15 33999 xxx.xxx.xxx.xxx 3 7 2 1 90416 5655119 185.117.74.118 52973 xxx.xxx.xxx.xxx 2 7 2 1 2174 5717159 185.82.203.58 59170 xxx.xxx.xxx.xxx 2 7 2 1 47838 5847404 185.162.128.66 39141 xxx.xxx.xxx.xxx 2 7 2 1 4837 5895126All IP addresses with only 1 packet removed.
2018-01-19 (Has anyone created a mediawiki template/plugin/... to use the first traffic light protocol in mediawiki...)
2018-01-17 Niet al het afval wordt opgehaald: plastic afval blijft achter
We hebben al een paar keer gehad dat er plastic afval achterbleef in de container daarvoor. Vandaag was het ophaaldag en zat de container vrij vol, maar ongeveer de onderste 1/3e bleef zitten. De niet zo milieuvriendelijke oplossing is om wat er overblijft in een vuilniszak te stoppen en die bij het restafval te doen. Ik heb toch maar een vriendelijke melding aan de gemeente gedaan of daar iets aan te verbeteren is. Ik ben benieuwd. Update: Reactie van de gemeente:Uw melding is opgenomen in de reguliere werkzaamheden. Het kan daardoor enige tijd duren voordat uw melding zichtbaar is opgelost.Klinkt een beetje als een standaardtekst voor afvalinzamelingsproblemen. Maar ik ga het een paar keer aankijken hoe het gaat. Update: Inderdaad geen problemen meer. Maar we zorgen nu zelf ook dat het plastic afval minder klem zit in de container.
2018-01-15 I participated in the UBA PSK63 prefix contest
Read the rest of I participated in the UBA PSK63 prefix contestAs planned I participated in the UBA PSK63 prefix contest in the weekend. Activity was Saturday evening and Sunday morning interrupted by some good sleep. Compared to my experiences in the ARRL RTTY roundup one weekend earlier the 40 meter band decided to act quite differently. On Saturday evening it was quite hard to make a contact. A lot of interference, no far away stations and it was hard to get heard by the other side. I stopped before 22:00 UTC (23:00 localtime) because I thought some sleep would be more effective than getting annoyed by the lack of contacts. Indeed, Sunday morning things got better although I heard only nearby signals on the 40 meter band, including some Belgian stations. No serious DX. Belgian stations are good for extra multipliers so it was good for the score. In the end I made 76 contacts. The last contact was started by a CQ I called at 11:59 UTC but it was only answered at 12:00, so it does count but I had to note it in the log as originating at 11:59 where the software normally logs the moment I see the callsign for the first time. Log submitted and de Veron afdelingscompetitie updated.
2018-01-14 Recovering firmware on the Draytek Vigor 130 VDSL2 modem with linux / macosx
I needed the recovery procedure again: there was a new firmware 3.8.12 with newer VDSL modem driver and the standard update via the webinterface failed. I just want to keep the notes from "OzCableguy" since his shop and blog have gone. I found the saved version via archive.org, Updating Draytek firmare using the MacOS X or UNIX command line and TFTP - OzCableguy.Read the rest of Recovering firmware on the Draytek Vigor 130 VDSL2 modem with linux / macosxDraytek modems have several methods available to update their firmware. You can use the Firmware Upgrade Utility under Windows, load it from the web interface via HTTP, FTP the file to the modem or use the TFTP (Trivial File Transfer Protocol) service built into the box. If your modem has been bricked you can’t use FTP or HTTP. If you don’t want to use Windows or go through the web interface, then this TFTP method is a viable alternative. Note that unlike a lot of other boxes using TFTP to load firmware, the Draytek is acting as a TFTP server, the UNIX/MacOS box as a client and you PUT the file onto the modem. It is normally the other way around, but that needs some extra setup steps that are conveniently avoided with this method. The firmware comes in two pieces. Use the .rst version of the file if you want to change the modem settings back to factory defaults, use the .all file to keep the current settings (.all may not be a good option if the modem is bricked). Secondly you need an ethernet interface on your Mac or UNIX box set to the subnet 192.168.1.0 (eg: with IP address 192.168.1.10) so that you can talk to the modem at its default IP address of 192.168.1.1. If the modem is up and running (and not bricked), you should now be able to ping it ..And this last bit is where the windows utility is better: it will tell you when the recovery is done and a success. With a commandline tool you'll just have to wait for the leds to blink right. After all the recovery and the waiting the modem works again and the line is stable. I chose the 'modem6' version again. I may try the 'modem5' and 'modem4' version too to see whether I can get lower latency without losing stability. Although the improvement may be in the single digit millisecond range so it would be a lot of work for very little improvement.$ ping 192.168.1.1 PING 192.168.1.1 (192.168.1.1): 56 data bytes 64 bytes from 192.168.1.1: icmp_seq=0 ttl=255 time=0.309 ms 64 bytes from 192.168.1.1: icmp_seq=1 ttl=255 time=0.421 ms 64 bytes from 192.168.1.1: icmp_seq=2 ttl=255 time=0.409 ms ^C —-192.168.1.1 PING Statistics—- 3 packets transmitted, 3 packets received, 0% packet loss round-trip min/avg/max/stddev = 0.309/0.380/0.421/0.050 ms$If your modem is really bricked then the ping will only work when the modem is actually in TFTP upload mode as below. You can ignore this step, it just demonstrates that the ethernet cable is working. Now we can upload the firmware. With the modem powered off, press and hold the factory reset button, then power up the modem. Continue to hold the button down until ’some’ of the lights flash together. On the Vigor2820Vn ’some’ is the left column of three. On the 2800 and 2910 the left two LEDs flash. Release the button and on your UNIX/MacOS box type the following commands (note that the modem only stays in TFTP mode for a short time, you can actually type right up to the end of the put command and just press return when the left-hand modem lights start flashing). The name of the firmware and the number of bytes transmitted depend on the product you are trying to recover.$ tftp 192.168.1.1 tftp> binary tftp> put v2820_v03301_211011_A.rst Sent 4973144 bytes in 13.1 seconds tftp> quit $There will be a pause after the ‘put’ command, but your modem ethernet port light should be flashing madly. The transfer is done when you get the “Sent” message. Quit the TFTP client and perhaps your Terminal session, there’s nothing more to see. What happens next isn’t really documented but we presume that the modem has to unpack the firmware and load it into flash. On our 2820Vn the column of 3 lights continued to flash, but gradually slowed down, speeded up, then slowed again. Eventually after a minute or two the modem rebooted in the normal fashion. Just be patient.
2018-01-12 I am planning to participate in the UBA PSK63 contest
As in previous years, I am planning to participate in the UBA PSK63 Prefix Contest in the upcoming weekend. I can't participate for 24 hours since other things have to be done too in the weekend including the all important 'sleep'. I just finished the preparations:Read the rest of I am planning to participate in the UBA PSK63 contestOn Saturday evening the 20 meter band will probably be closed by the time I am available for contesting. So I'll start on the 40 meter band. The choice for 40 meter band only or all band will have to be made on Sunday morning, depending on the amount of new contacts I can make in the 40 meter band.
- The endfed antenna for 10/20/40 is hanging outside
- The contest macros have been updated to call CQ UBA PFX TEST
2018-01-08 I participated in the ARRL RTTY Roundup 2018
Read the rest of I participated in the ARRL RTTY Roundup 2018For the past weekend I had the ARRL RTTY Roundup planned, meaning I had reserved time in the family calendar. Other things had to happen too but I reserved time for contesting and made sure I had the right macros available before the contest started. I hoped to find time to set up the endfed antenna before the contest but that did not happen so it was the first thing to do when we got home at the beginning of Saturday evening. In the contest I only operated on the 40 meter band. Most of the time I was able to participate were in the dark when I did not expect the 20 meter band to cooperate and I thought that operating in just one band would make me end higher in the rankings for that more specific category. Only after the contest I read the rules exactly and noticed that this specific contest does not differentiate between single and multi band operation. In the end I made 95 contacts. Local noise is high in my current setup so only the strongest stations came through the noise. I made only one contact in CQ mode, the rest was search and pounce. Propagation wasn't really good until late in the evenings when I managed to score some US contacts. I did see someone from Prince Edwards Island in Canada but that station did not hear me return. I noticed WP2B did not give me a US state but a serial number and found out that is a US Virgin Island callsign, so that was a new country for me. In the end a nice contest. For upcoming contests: check the rules / propagation predictions and plan my strategy.
For the past weekend I had the 2018-01-05 Mastercard securecode of een hele goeie phishing poging
Ik wilde vandaag iets betalen in een website en die kwam vervolgens met "Mastercard securecode". Alleen de manier waarop was dusdanig dat ik de betaling afgebroken heb omdat ik het niet vertrouwde. De afhandeling van Mastercard securecode was binnen een iframe van de website, in een compleet andere stijl dan de website. Vervolgens bleek bij het opvragen van details dat dat iframe komt van https://www.securesuite.co.uk/ing_retail/ wat geen EV certificaat heeft. Na het vragen om de creditcard gegevens kwam een vraag over de rekening die gekoppeld is aan de creditcard en een geboortedatum. Of dat gaat om mijn geboortedatum of die van de persoon van wie de creditcard is stond er niet bij. Dus een ernstige phishing poging of een slechte implementatie van het voorkomen van fraude. Ooit heb ik de mastercard secure code ingesteld, en daar werd ook niet naar gevraagd. Ik heb er voor gekozen de betaling af te breken. In 2010 schreef al iemand hierover: Verified by Visa and Mastercard SecureCode are broken and need to be fixed. Sindsdien is de enige verandering dat ik nu een EV certificaat op zo'n site zou verwachten. En dat heeft www.securesuite.co.uk niet.
2018-01-03 Fixing stuff in The Virtual Bookcase for PHP 7
After spending an evening fixing scripts on The Virtual Bookcase to make them run in PHP 7 and make them safer at the same time I came to the conclusion that I still don't like php. My conclusion is that if I want to maintain sites I'd rather redo them in perl. I noticed any serious maintenance on the scripts of The Virtual Bookcase was 9 years ago (!). That was also when I had the habit of writing maintenance scripts in perl and web code in php. The upside is that a part of the page-generating code is already available in perl. But a rewrite is a task for another day. For now the site works cleanly in PHP 7 (and 5) and I can go on to the next task for moving the homeserver.Read the rest of Fixing stuff in The Virtual Bookcase for PHP 7
2018-01-01 Making my own web stuff more robust
In building the new homeserver there is also time to test things and improve robustness a bit (although I should not overdo it). The one thing that forces me to look at some web-code again is that the new servers run PHP version 7. Some of my code is giving warnings, time to fix that. But I haven't written any serious PHP in ages, I just rewrote sites in mod_perl. So my PHP is rusty and needs work, especially with PHP 7. It's a good thing I use version management, which allows me to test the fixes on the development version(s) of the site and push them to the production version when I'm happy with the results. Some of the things I notice that could improve go on the todo list. One thing I did notice and fixed right away was that the CVS metadata inside the web directories could be requested too. Although I find no serious security information in there it is still an unwanted information leak.