So, a certain MMO recently managed to turn off their wiki, upgrade their forums and in the process break almost all their links from anywhere. Even intra-forum links broke utterly. And the in-game big friendly Help button.
I'd really not want to responsible for that debacle. Breaking seven years worth of web forum google searches and intralinking is utter insanity from a professional standpoint.
But a ten-minute greasemonkey script can fix that for me personally.
DDO forum fixup
Well done irritating your subscribers, Turbine. Whatever will they think of next...
Saturday, 4 May 2013
Sunday, 7 October 2012
Netbooting NetBSD in KVM
So, I feel the need to netboot various OSes again. Because I can.
Output to serial is most convenient, my MIPS box is serial only, and besides I have no space for a bunch of extra monitors.
In the IA32 case, the (very very nice, though old) Diskless NetBSD howto directs me to use "pxeboot_ia32_com0.bin".
Problem #1: since NetBSD 4 or so, this isn't in base.tgz anymore.
David Laight points out that it can be created like so using the netbsd installboot(8) command. Though I have no NetBSD yet.
Ah well. I'll boot a more normal NetBSD on KVM and create that, then. Quick DHCPD setup:
hardware ethernet 22:22:22:22:00:00;
next-server 10.50.1.1; # TFTP / NFS host
filename "/netbsd-5/pxeboot_ia32.bin"; # Path on TFTP server
option root-path "/storage/nfs/ia32/netbsd-5.1.2/root"; # Path on NFS server
# FreeBSD pxe can use IP:path here, I believe, NetBSD just uses next-server.
}
... not so fast.
ISC DHCPD, current KVM's iPXE netboot firmware and NetBSD's pxeboot doesn't like each other.
* iPXE sends a DHCP request with dhcp_client_identifier (option 61) set to 01-ethernet mac address, loads pxeboot_ia32.bin from tftp and runs it.
* pxeboot_ia32.bin sends a simpler DHCP request without dhcp_client_identifier via PXE_UDP_WRITE. pxeboot_ia32.bin takes care to use the lease it knows about from the PXE environment as source IP, it just wants to ask for some more options.
* ISC DHCPD wants to assign a new address, since this apparently is another client (no dhcp_client_identifier), and assigns that as unicast destination.
* iPXE ignores the return unicast packet apparently sent to somebody else entirely.
* pxeboot_ia32.bin gets no response and gives up.
ISC DHCPD has a special case for BOOTP clients, and will give out an old lease if the hardware address matches even though they don't send any client-id. But we aren't BOOTP, we're just fragile followup-DHCP-in-PXE.
The least icky way out here seems to be patching DHCPD to ignore dhcp_client_identifier mismatches. (CMU DHCPD has a runtime option for it, btw) But oh, the tentacles, ISC source isn't known for its sanity...
So at this point I'm doing a traditional
pxe rom (iPXE 1.0 as shipped with modern qemu/kvm, or whatever PXE rom my old VIA Mini-ITX is running)
=> tftp loads pxeboot second stage
=> pxeboot loads kernel via simplified nfs
=> kernel boots a nfsroot system
The smart & modern way is of course to load the netbsd kernel directly from iPXE. But I'm betting that's too easy to be any fun.
Anyway, qemu-kvm in ubuntu precise has fun bugs that doesn't let the NetBSD kernel find any PCI devices. Like, for instance, the network card. So the boot stops with netboot interface not found.
Fixed in current debian and upstream qemu. A rebuild of QEMU seems to be in order.
apt-get source qemu-kvm
apt-get build-dep qemu-kvm
cd qemu-kvm-1.0+noroms/debian/patches
wget -O 'pci-fix-corrupted-pci-conf-index-register-by-unaligned-write.patch' "http://git.qemu.org/?p=qemu.git;a=commitdiff_plain;h=cdde6ffc27517bdf069734fbc5693ce2b14edc75"
echo pci-fix-corrupted-pci-conf-index-register-by-unaligned-write.patch >> series
cd ..
dch -i
cd ..
dpkg-buildpackage -b -uc
cd ..
dpkg -i qemu-kvm_1.0+noroms-0ubuntu14.2eib1_amd64.deb qemu-utils_1.0+noroms-0ubuntu14.2eib1_amd64.deb qemu-common_1.0+noroms-0ubuntu14.2eib1_all.deb
et voila!
Whee, I have a working NetBSD!
Current invocation: kvm -boot n -localtime -net nic,vlan=0,macaddr=22:22:22:22:00:00 -net tap,vlan=0,ifname=tap0,script=no,downscript=no
Now then, in netbsd (After changing root's shell to /bin/sh instead of the traditonal csh abomination)
cd /usr/mdec
cp ./pxeboot_ia32.bin ./pxeboot_ia32_com0.bin
installboot -e -oconsole=com0 -ospeed=0 ./pxeboot_ia32_com0.bin
So far, so good. Drop our new binary in, and boot kvm with no VGA and a serial console:
kvm -boot n -localtime -net nic,vlan=0,macaddr=22:22:22:22:00:00 -net tap,vlan=0,ifname=tap0,script=no,downscript=no -vga none -nographic
knan@sarevok:/storage/current/netboot$ ./kvm-ia32-netbsd.sh
>> NetBSD/x86 PXE Boot, Revision 5.1 (from NetBSD 5.1.2)
>> Memory: 623/391904 k
Press return to boot now, any other key for boot menu
Starting in 0 seconds.
PXE BIOS Version 2.1
Using PCI device at bus 0 device 2 function 0
Ethernet address 22:22:22:22:00:00
10090076+518916+618576 [521184+509293]=0xbb2988
Copyright (c) 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005,
2006, 2007, 2008, 2009, 2010, 2011, 2012
The NetBSD Foundation, Inc. All rights reserved.
Copyright (c) 1982, 1986, 1989, 1991, 1993
The Regents of the University of California. All rights reserved.
NetBSD 5.1.2 (GENERIC) #0: Thu Feb 2 17:22:10 UTC 2012
builds@b6.netbsd.org:/home/builds/ab/netbsd-5-1-2-RELEASE/i386/201202021012Z-obj/home/builds/ab/netbsd-5-1-2-RELEASE/src/sys/arch/i386/compile/GENERIC
[...]
Sun Oct 7 15:54:24 UTC 2012
NetBSD/i386 (netbsd5) (console)
login: root
Yay!
(Todo: train creaky old pxeboot_ia32.bin to retry DHCP via broadcast if unicast fails.)
Output to serial is most convenient, my MIPS box is serial only, and besides I have no space for a bunch of extra monitors.
In the IA32 case, the (very very nice, though old) Diskless NetBSD howto directs me to use "pxeboot_ia32_com0.bin".
Problem #1: since NetBSD 4 or so, this isn't in base.tgz anymore.
David Laight points out that it can be created like so using the netbsd installboot(8) command. Though I have no NetBSD yet.
Ah well. I'll boot a more normal NetBSD on KVM and create that, then. Quick DHCPD setup:
subnet 10.50.1.0 netmask 255.255.255.0 {
range 10.50.1.200 10.50.1.250;
}
host kvm-netbsd-ia32 {hardware ethernet 22:22:22:22:00:00;
next-server 10.50.1.1; # TFTP / NFS host
filename "/netbsd-5/pxeboot_ia32.bin"; # Path on TFTP server
option root-path "/storage/nfs/ia32/netbsd-5.1.2/root"; # Path on NFS server
# FreeBSD pxe can use IP:path here, I believe, NetBSD just uses next-server.
}
... not so fast.
ISC DHCPD, current KVM's iPXE netboot firmware and NetBSD's pxeboot doesn't like each other.
* iPXE sends a DHCP request with dhcp_client_identifier (option 61) set to 01-ethernet mac address, loads pxeboot_ia32.bin from tftp and runs it.
* pxeboot_ia32.bin sends a simpler DHCP request without dhcp_client_identifier via PXE_UDP_WRITE. pxeboot_ia32.bin takes care to use the lease it knows about from the PXE environment as source IP, it just wants to ask for some more options.
* ISC DHCPD wants to assign a new address, since this apparently is another client (no dhcp_client_identifier), and assigns that as unicast destination.
* iPXE ignores the return unicast packet apparently sent to somebody else entirely.
* pxeboot_ia32.bin gets no response and gives up.
ISC DHCPD has a special case for BOOTP clients, and will give out an old lease if the hardware address matches even though they don't send any client-id. But we aren't BOOTP, we're just fragile followup-DHCP-in-PXE.
The least icky way out here seems to be patching DHCPD to ignore dhcp_client_identifier mismatches. (CMU DHCPD has a runtime option for it, btw) But oh, the tentacles, ISC source isn't known for its sanity...
So at this point I'm doing a traditional
pxe rom (iPXE 1.0 as shipped with modern qemu/kvm, or whatever PXE rom my old VIA Mini-ITX is running)
=> tftp loads pxeboot second stage
=> pxeboot loads kernel via simplified nfs
=> kernel boots a nfsroot system
The smart & modern way is of course to load the netbsd kernel directly from iPXE. But I'm betting that's too easy to be any fun.
Anyway, qemu-kvm in ubuntu precise has fun bugs that doesn't let the NetBSD kernel find any PCI devices. Like, for instance, the network card. So the boot stops with netboot interface not found.
Fixed in current debian and upstream qemu. A rebuild of QEMU seems to be in order.
apt-get source qemu-kvm
apt-get build-dep qemu-kvm
cd qemu-kvm-1.0+noroms/debian/patches
wget -O 'pci-fix-corrupted-pci-conf-index-register-by-unaligned-write.patch' "http://git.qemu.org/?p=qemu.git;a=commitdiff_plain;h=cdde6ffc27517bdf069734fbc5693ce2b14edc75"
echo pci-fix-corrupted-pci-conf-index-register-by-unaligned-write.patch >> series
cd ..
dch -i
cd ..
dpkg-buildpackage -b -uc
cd ..
dpkg -i qemu-kvm_1.0+noroms-0ubuntu14.2eib1_amd64.deb qemu-utils_1.0+noroms-0ubuntu14.2eib1_amd64.deb qemu-common_1.0+noroms-0ubuntu14.2eib1_all.deb
et voila!
Whee, I have a working NetBSD!
Current invocation: kvm -boot n -localtime -net nic,vlan=0,macaddr=22:22:22:22:00:00 -net tap,vlan=0,ifname=tap0,script=no,downscript=no
Now then, in netbsd (After changing root's shell to /bin/sh instead of the traditonal csh abomination)
cd /usr/mdec
cp ./pxeboot_ia32.bin ./pxeboot_ia32_com0.bin
installboot -e -oconsole=com0 -ospeed=0 ./pxeboot_ia32_com0.bin
So far, so good. Drop our new binary in, and boot kvm with no VGA and a serial console:
kvm -boot n -localtime -net nic,vlan=0,macaddr=22:22:22:22:00:00 -net tap,vlan=0,ifname=tap0,script=no,downscript=no -vga none -nographic
knan@sarevok:/storage/current/netboot$ ./kvm-ia32-netbsd.sh
>> NetBSD/x86 PXE Boot, Revision 5.1 (from NetBSD 5.1.2)
>> Memory: 623/391904 k
Press return to boot now, any other key for boot menu
Starting in 0 seconds.
PXE BIOS Version 2.1
Using PCI device at bus 0 device 2 function 0
Ethernet address 22:22:22:22:00:00
10090076+518916+618576 [521184+509293]=0xbb2988
Copyright (c) 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005,
2006, 2007, 2008, 2009, 2010, 2011, 2012
The NetBSD Foundation, Inc. All rights reserved.
Copyright (c) 1982, 1986, 1989, 1991, 1993
The Regents of the University of California. All rights reserved.
NetBSD 5.1.2 (GENERIC) #0: Thu Feb 2 17:22:10 UTC 2012
builds@b6.netbsd.org:/home/builds/ab/netbsd-5-1-2-RELEASE/i386/201202021012Z-obj/home/builds/ab/netbsd-5-1-2-RELEASE/src/sys/arch/i386/compile/GENERIC
[...]
Sun Oct 7 15:54:24 UTC 2012
NetBSD/i386 (netbsd5) (console)
login: root
Yay!
(Todo: train creaky old pxeboot_ia32.bin to retry DHCP via broadcast if unicast fails.)
Thursday, 26 April 2012
FreeRADIUS and CRLs
Deploying FreeRADIUS, you may want to use a Certificate Revocation List (CRL) to revoke access to users that has been issued a valid certificate at some point.
How to actually do this isn't completely self-evident. Less so if you use multiple sub-CAs.
FreeRADIUS basically uses OpenSSL's routines and options for this. And OpenSSL doesn't currently refresh CRLs in a running process, so after updating a CRL you need to restart the freeradius daemon (easily scripted).
The important point in freeradius is in /etc/freeradius/eap.conf, specifically check_crl and CA_path in the tls section. Also, comment out CA_file, since CA_path and CA_file are intended for the same purposes, but CRLs only work with the CA_path method.
How to actually do this isn't completely self-evident. Less so if you use multiple sub-CAs.
FreeRADIUS basically uses OpenSSL's routines and options for this. And OpenSSL doesn't currently refresh CRLs in a running process, so after updating a CRL you need to restart the freeradius daemon (easily scripted).
The important point in freeradius is in /etc/freeradius/eap.conf, specifically check_crl and CA_path in the tls section. Also, comment out CA_file, since CA_path and CA_file are intended for the same purposes, but CRLs only work with the CA_path method.
# Check the Certificate Revocation List # # 1) Copy CA certificates and CRLs to same directory. # 2) Execute 'c_rehashBe sure not to concatenate certificates in your CA_path. One CA, one file. Then, after the c_rehash, your directory should look something like this:'. # 'c_rehash' is OpenSSL's command. # 3) uncomment the line below. # 5) Restart radiusd check_crl = yes CA_path = /etc/freeradius/certs/CA/
root@radius:~# ls -l /etc/freeradius/certs/CA/ lrwxrwxrwx 1 root freerad 9 2012-04-26 03:15 12345678.0 -> local-sub-ca-1.pem lrwxrwxrwx 1 root freerad 13 2012-04-26 03:15 12345678.r0 -> sub-ca-1-crl.pem lrwxrwxrwx 1 root freerad 11 2012-04-26 03:15 23456789.0 -> local-root-ca.pem lrwxrwxrwx 1 root freerad 8 2012-04-26 03:15 3456789a.0 -> local-sub-ca-2.pem lrwxrwxrwx 1 root freerad 12 2012-04-26 03:15 3456789a.r0 -> sub-ca-2-crl.pem -rw-r--r-- 1 root freerad 1360 2012-04-24 15:04 local-root-ca.pem -rw-r--r-- 1 root freerad 1360 2012-04-24 15:06 local-sub-ca-1.pem -rw-r--r-- 1 root freerad 1384 2012-04-24 14:58 local-sub-ca-2.pem -rw-r--r-- 1 root freerad 1251 2012-04-26 03:15 sub-ca-1-crl.pem -rw-r--r-- 1 root freerad 739 2012-04-26 03:15 sub-ca-2-crl.pemThanks to Yasuhiro ABE for pointing me in the right direction. ありがとうございました、あべさん！それはよかったよ！
Monday, 6 February 2012
dnstool - curses-based DNS zone administration
Out now! Get it while the bits are still hot!
https://github.com/Redpill-Linpro/dnstool
The Fine Manual is plain text and even has screenshots, perfect for the old-school lynx enthusiast ;)
If your dns server supports RFC2136 dynamic updates, you might want to look at this. BIND9 does.
Patches always welcome!
https://github.com/Redpill-Linpro/dnstool
The Fine Manual is plain text and even has screenshots, perfect for the old-school lynx enthusiast ;)
If your dns server supports RFC2136 dynamic updates, you might want to look at this. BIND9 does.
Patches always welcome!
Monday, 17 October 2011
Terra firma
Ok.
Jeg har i dag oppdatert firmware - på ei mus.
Når ble de lure nok til å trenge firmware? Antagelig sammen med led/optikk-variantene.
Og hva hindrer dem fra å gro et virtuelt keyboard om natta og bedrive bruteforcing av passordet mitt? Ingenting jeg vet om.
(Ok, feedback er et problem. Men det fins usb skjermkort... :p)
Jeg har i dag oppdatert firmware - på ei mus.
Når ble de lure nok til å trenge firmware? Antagelig sammen med led/optikk-variantene.
Og hva hindrer dem fra å gro et virtuelt keyboard om natta og bedrive bruteforcing av passordet mitt? Ingenting jeg vet om.
(Ok, feedback er et problem. Men det fins usb skjermkort... :p)
Wednesday, 17 August 2011
Verbbøyingsgalskap
Japansk er fleksibelt og komplisert. La oss ta et tilfeldig verb, taberu - å spise.
For det første er ikke ordbok-formen av verbet infinitiv på japansk. Ordbokformen av verbet er "uformell ikke-fortid" - kan hende det skjer omtrent nå, kan hende en bare har vage planer om det en gang i fremtiden, men det er iallfall ikke ferdig med å skje.
"Watashi wa niku ga taberu." - Jeg spiser kjøtt. Temmelig generell og uformell vending. Om du allerede snakker om deg selv og det du liker, vil du vanligvis sløyfe de to første ordene. "Niku ga taberu." - Spiser kjøtt.
Det er uformelt, dog. I høflig samtale med folk du ikke kjenner godt, vil du vanligvis bruke en normalt høflig form. "Niku ga tabemasu." (uttales "Niku ga tabemas".)
Men hvis du vanligvis ikke spiser kjøtt, vil du kanskje uttrykke det. "Niku ga tabemasen." - Spiser ikke kjøtt. Å bøye verb i positive og negative former er en typisk japansk ting. Fremdeles en veldig generell vending.
"Niku ga tabetai desu." - Har lyst til å spise kjøtt. Her er verbet gjort om til et adjektiv "lyst til å spise", mens "desu" = har.
"Niku ga tabete mimasu." - Kan prøve å spise kjøtt og se hvordan det går. Her er du usikker på om dette er noe for deg. "Mimasu" er høflig ikkefortid av "å se", her som hjelpeverb.
"Niku ga tabete mitai desu." - Har lyst til å prøve å spise kjøtt og se hvordan det går. Kombinasjon av de to over.
"Niku ga tabete imasu." - Spiser kjøtt akkurat nå. "-te imasu" er noe ala "am -ing"-form på engelsk.
"Niku ga tabete iru hito." - Personen som spiser kjøtt akkurat nå. "Iru" er den ikke-høflige kortformen av "imasu", når du bruker en hel frase som et adjektiv så brukes korte bøyinger.
"Niku ga tabemashou." - La oss spise kjøtt! Høflig men direkte.
"Niku ga tabemasen ka." - Skal vi ikke spise kjøtt? Indirekte invitt, høfligere.
"Niku ga taberaremasen." - Kan ikke spise kjøtt. Potensiell, høflig ikkefortid, negativ form.
"Niku ga tabemashita." - Har spist kjøtt.
"Niku wa tabeta koto ga arimasen." - Har aldri spist kjøtt. Uformell fortid pga. hjelpeordene etterpå. En mer klumpete og direkte oversettelse blir "Erfaringen å ha spist kjøtt, har jeg ikke."
"Niku wa tabenai tsumori desu." - Har ikke planer om å spise kjøtt. Negativ uformell ikkefortid + hjelpeord.
"Niku wa tabenakute wa ikemasen." - Må spise kjøtt. ("Kan da ikke la være å spise...")
"Niku ga tabeta hou ga ii desu." - Bør spise kjøtt. Formaning, "Det er bedre (for deg/meg) å..."
"Niku ga tabesugite wa ikemasen." - Ikke forspis deg på kjøtt. Her er taberu blitt til det sammensatte verbet tabesugiru, der -sugiru betyr "for mye".
... og jeg har fremdeles bare såvidt begynt på Genki II. Mange flere sammensetninger og former ligger på lur og venter. Og taberu er et enkelt, regulært verb i forhold til mange andre.
Det er da litt gøy. :)
また、ね！
For det første er ikke ordbok-formen av verbet infinitiv på japansk. Ordbokformen av verbet er "uformell ikke-fortid" - kan hende det skjer omtrent nå, kan hende en bare har vage planer om det en gang i fremtiden, men det er iallfall ikke ferdig med å skje.
"Watashi wa niku ga taberu." - Jeg spiser kjøtt. Temmelig generell og uformell vending. Om du allerede snakker om deg selv og det du liker, vil du vanligvis sløyfe de to første ordene. "Niku ga taberu." - Spiser kjøtt.
Det er uformelt, dog. I høflig samtale med folk du ikke kjenner godt, vil du vanligvis bruke en normalt høflig form. "Niku ga tabemasu." (uttales "Niku ga tabemas".)
Men hvis du vanligvis ikke spiser kjøtt, vil du kanskje uttrykke det. "Niku ga tabemasen." - Spiser ikke kjøtt. Å bøye verb i positive og negative former er en typisk japansk ting. Fremdeles en veldig generell vending.
"Niku ga tabetai desu." - Har lyst til å spise kjøtt. Her er verbet gjort om til et adjektiv "lyst til å spise", mens "desu" = har.
"Niku ga tabete mimasu." - Kan prøve å spise kjøtt og se hvordan det går. Her er du usikker på om dette er noe for deg. "Mimasu" er høflig ikkefortid av "å se", her som hjelpeverb.
"Niku ga tabete mitai desu." - Har lyst til å prøve å spise kjøtt og se hvordan det går. Kombinasjon av de to over.
"Niku ga tabete imasu." - Spiser kjøtt akkurat nå. "-te imasu" er noe ala "am -ing"-form på engelsk.
"Niku ga tabete iru hito." - Personen som spiser kjøtt akkurat nå. "Iru" er den ikke-høflige kortformen av "imasu", når du bruker en hel frase som et adjektiv så brukes korte bøyinger.
"Niku ga tabemashou." - La oss spise kjøtt! Høflig men direkte.
"Niku ga tabemasen ka." - Skal vi ikke spise kjøtt? Indirekte invitt, høfligere.
"Niku ga taberaremasen." - Kan ikke spise kjøtt. Potensiell, høflig ikkefortid, negativ form.
"Niku ga tabemashita." - Har spist kjøtt.
"Niku wa tabeta koto ga arimasen." - Har aldri spist kjøtt. Uformell fortid pga. hjelpeordene etterpå. En mer klumpete og direkte oversettelse blir "Erfaringen å ha spist kjøtt, har jeg ikke."
"Niku wa tabenai tsumori desu." - Har ikke planer om å spise kjøtt. Negativ uformell ikkefortid + hjelpeord.
"Niku wa tabenakute wa ikemasen." - Må spise kjøtt. ("Kan da ikke la være å spise...")
"Niku ga tabeta hou ga ii desu." - Bør spise kjøtt. Formaning, "Det er bedre (for deg/meg) å..."
"Niku ga tabesugite wa ikemasen." - Ikke forspis deg på kjøtt. Her er taberu blitt til det sammensatte verbet tabesugiru, der -sugiru betyr "for mye".
... og jeg har fremdeles bare såvidt begynt på Genki II. Mange flere sammensetninger og former ligger på lur og venter. Og taberu er et enkelt, regulært verb i forhold til mange andre.
Det er da litt gøy. :)
また、ね！
Tuesday, 21 December 2010
Transport layer protocols for stealth and evil
Ever tested some of the more exotic transport protocols?
SCTP is interesting ... multihoming means you can have several ips involved on each side of a connection (association in sctp speak) ... so when you move from wired to wireless your ssh session still is fine. If you find a proper SCTP ssh, of course.
Testing it on Ubuntu LTS, though, using socat for glue... a listening SCTP socket is invisible in netstat -ln. Fun. tcp, udp, raw sockets are visible ... but sctp isn't.
socat SCTP-LISTEN:8080,fork TCP-CONNECT:localhost:22
Nice, stealthy backdoor. Does not show in netstat(8) or ss(8). Combine with socat TCP-LISTEN:2223 SCTP-CONNECT:localhost:8080 on a remote host and we have a completely stealthy tunnel, if the firewall is mildly clue-challenged.
lsof reports a mysterious socket. But it also does that for udev and update-manager, so that's hardly conclusive.
knan@ip:~$ lsof | grep socat | grep sock
socat 24969 knan 3u sock 0,6 0t0 645716 can't identify protocol
The only place I've dug out useful info so far is from procfs.
Hardly easy to read. But it says LADDRS 0.0.0.0, LPORT 8080. Ok.
(BTW: SCTP not being in netstat is a Debian/Ubuntu-specific bug, SuSE/Red Hat have applied patches.)
sctp_darn(1) can do more fun sctp-specific stuff, like setting up multiple local and remote addresses for the association.
Cool enough. But there are other fun transport protocols we can try.
How about DCCP? It's connection-oriented and has congestion control but otherwise is UDP-like.
netsend dccp receive
The only place in /proc/net you find DCCP mentioned is in /proc/net/protocols. Which says nothing about ongoing connections or listening sockets.
knan@ip:~$ grep -ir DCCP /proc/net/
/proc/net/protocols:DCCP 1400 1 -1 NI 1196 yes dccp_ipv4 y y y y y y y y y y y y n n y y y y n
lsof still says little.
knan@ip:~$ lsof | grep netsend | grep sock
netsend 25376 knan 3u sock 0,6 0t0 658124 can't identify protocol
ss(8) to the rescue! But only when you specifically ask it about DCCP sockets with -d.
The final protocol I want to propose today is UDP-Lite. This is basically a UDP variant with partial checksums, for the case when garbled data is better than no data.
$ netsend udplite receive
As usual, netstat tells us nothing of this uncommon activity.
This time, though, lsof identifies it!
knan@ip:~$ lsof | grep netsend
netsend 25461 knan 3u IPv4 661633 0t0 UDPLITE *:6666
Which is good, since ss doesn't.
To summarize (for Ubuntu 10.04 LTS):
Hope this leaves you entertained by the possibilities. Black hats begone!
P.S.
launchpad:netstat+sctp
launchpad:lsof+sctp
launchpad:lsof+dccp
SCTP is interesting ... multihoming means you can have several ips involved on each side of a connection (association in sctp speak) ... so when you move from wired to wireless your ssh session still is fine. If you find a proper SCTP ssh, of course.
Testing it on Ubuntu LTS, though, using socat for glue... a listening SCTP socket is invisible in netstat -ln. Fun. tcp, udp, raw sockets are visible ... but sctp isn't.
socat SCTP-LISTEN:8080,fork TCP-CONNECT:localhost:22
Nice, stealthy backdoor. Does not show in netstat(8) or ss(8). Combine with socat TCP-LISTEN:2223 SCTP-CONNECT:localhost:8080 on a remote host and we have a completely stealthy tunnel, if the firewall is mildly clue-challenged.
knan@ip:~$ netstat -ln Active Internet connections (only servers) Proto Recv-Q Send-Q Local Address Foreign Address State tcp 0 0 0.0.0.0:4949 0.0.0.0:* LISTEN tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN tcp 0 0 127.0.0.1:631 0.0.0.0:* LISTEN tcp 0 0 127.0.0.1:25 0.0.0.0:* LISTEN udp 0 0 0.0.0.0:68 0.0.0.0:* udp 0 0 0.0.0.0:36558 0.0.0.0:* udp 0 0 0.0.0.0:5353 0.0.0.0:* udp 0 0 0.0.0.0:631 0.0.0.0:* udp 0 0 0.0.0.0:45561 0.0.0.0:* knan@ip:~$
lsof reports a mysterious socket. But it also does that for udev and update-manager, so that's hardly conclusive.
knan@ip:~$ lsof | grep socat | grep sock
socat 24969 knan 3u sock 0,6 0t0 645716 can't identify protocol
The only place I've dug out useful info so far is from procfs.
knan@ip:~$ cat /proc/net/sctp/eps ENDPT SOCK STY SST HBKT LPORT UID INODE LADDRS ffff8800722cb800 ffff8800342c8480 2 10 16 8080 1001 645716 0.0.0.0
Hardly easy to read. But it says LADDRS 0.0.0.0, LPORT 8080. Ok.
(BTW: SCTP not being in netstat is a Debian/Ubuntu-specific bug, SuSE/Red Hat have applied patches.)
sctp_darn(1) can do more fun sctp-specific stuff, like setting up multiple local and remote addresses for the association.
Cool enough. But there are other fun transport protocols we can try.
How about DCCP? It's connection-oriented and has congestion control but otherwise is UDP-like.
netsend dccp receive
knan@ip:~$ netstat -ln Active Internet connections (only servers) Proto Recv-Q Send-Q Local Address Foreign Address State tcp 0 0 0.0.0.0:4949 0.0.0.0:* LISTEN tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN tcp 0 0 127.0.0.1:631 0.0.0.0:* LISTEN tcp 0 0 127.0.0.1:25 0.0.0.0:* LISTEN tcp6 0 0 :::22 :::* LISTEN tcp6 0 0 ::1:631 :::* LISTEN udp 0 0 0.0.0.0:68 0.0.0.0:* udp 0 0 0.0.0.0:36558 0.0.0.0:* udp 0 0 0.0.0.0:5353 0.0.0.0:* udp 0 0 0.0.0.0:631 0.0.0.0:* udp 0 0 0.0.0.0:45561 0.0.0.0:*Netstat still says nothing.
The only place in /proc/net you find DCCP mentioned is in /proc/net/protocols. Which says nothing about ongoing connections or listening sockets.
knan@ip:~$ grep -ir DCCP /proc/net/
/proc/net/protocols:DCCP 1400 1 -1 NI 1196 yes dccp_ipv4 y y y y y y y y y y y y n n y y y y n
lsof still says little.
knan@ip:~$ lsof | grep netsend | grep sock
netsend 25376 knan 3u sock 0,6 0t0 658124 can't identify protocol
ss(8) to the rescue! But only when you specifically ask it about DCCP sockets with -d.
knan@ip:~$ ss -ldn Recv-Q Send-Q Local Address:Port Peer Address:Port 0 0 *:6666 *:*
The final protocol I want to propose today is UDP-Lite. This is basically a UDP variant with partial checksums, for the case when garbled data is better than no data.
$ netsend udplite receive
As usual, netstat tells us nothing of this uncommon activity.
knan@ip:~$ netstat -ln Active Internet connections (only servers) Proto Recv-Q Send-Q Local Address Foreign Address State tcp 0 0 0.0.0.0:4949 0.0.0.0:* LISTEN tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN tcp 0 0 127.0.0.1:631 0.0.0.0:* LISTEN tcp 0 0 127.0.0.1:25 0.0.0.0:* LISTEN tcp6 0 0 :::22 :::* LISTEN tcp6 0 0 ::1:631 :::* LISTEN udp 0 0 0.0.0.0:68 0.0.0.0:* udp 0 0 0.0.0.0:36558 0.0.0.0:* udp 0 0 0.0.0.0:5353 0.0.0.0:* udp 0 0 0.0.0.0:631 0.0.0.0:* udp 0 0 0.0.0.0:45561 0.0.0.0:*
This time, though, lsof identifies it!
knan@ip:~$ lsof | grep netsend
netsend 25461 knan 3u IPv4 661633 0t0 UDPLITE *:6666
Which is good, since ss doesn't.
To summarize (for Ubuntu 10.04 LTS):
| Protocol | netstat(8) | ss(8) | lsof(8) | /proc/net/* |
|---|---|---|---|---|
| SCTP | No | No | No | /proc/net/sctp/eps /proc/net/sctp6/eps |
| DCCP | No | Yes (-d) | No | No |
| UDP-Lite | No | No | Yes | /proc/net/udplite /proc/net/udplite6 |
Hope this leaves you entertained by the possibilities. Black hats begone!
P.S.
launchpad:netstat+sctp
launchpad:lsof+sctp
launchpad:lsof+dccp
Subscribe to:
Posts (Atom)