[Alcatel] PPP entry zomaar getrashed

[intoxicated]

Ik gebruik op dit moment een Alcatel ADSL 'Pro' modem met SIP Spoofing naar m'n Linux-servertje, dat d.m.v. IPTables de rest van m'n netwerk voorziet van een internetverbinding. Op de server draaien verschillende services, waarvan de meeste voor intern gebruik zijn, vanaf internet zijn alleen 21, 22 en 80 te zien. En zo hoort het ook. Verbindingen van buitenaf komen inderdaad gewoon op m'n Apache terecht, en zeker niet op de webbased config van het modem, die overigens ook nog eens beveiligd is met een password. Overigens staat de webbased-config en de telnet-port van een Alcatel modem ook in SIP Spoofing-mode sowieso niet open naar de buitenwereld, maar alleen op het interne LAN. Hetzelfde geldt voor de FTP-poort. Ook die komt netjes uit op de ProFTPD-server op m'n servertje, en niet op de TFTP van 't modem.

Hieronder even de nmap van mijn IP vanaf een willekeurige shell ergens op internet

code:

Port        State   Service Comment
21/tcp  open    ftp     ftp 21/tcp
22/tcp  open    ssh     SSH Remote Login Protocol
80/tcp  open    http        WorldWideWeb HTTP
111/tcp filtered    sunrpc  RPC 4.0 portmapper TCP
1024/tcp    filtered    kdm     
1025/tcp    filtered    listen  
3306/tcp    filtered    mysql   MySQL

En hier m'n IPTables rules

code:

iptables --flush
iptables -t nat -A POSTROUTING -o eth1 -j MASQUERADE
#MySQL...
iptables -A INPUT -i eth1 -p tcp --dport 3306 -j REJECT
iptables -A INPUT -i eth1 -p udp --dport 3306 -j REJECT
#En dat een paar keer voor de andere filtered-entries :)
echo 1 > /proc/sys/net/ipv4/ip_forward

Allemaal niks mis mee, en het werkte perfect tot vanmorgen. Toen kwam ik erachter dat m'n internetverbinding erg dood was. Daarom hing ik m'n modem even aan een workstation, om op 10.0.0.138 te kijken wat er aan de hand was. Het bleek dat m'n PPP entry (SIP_SPOOF) naar de eeuwige jachtvelden was verbannen, de tabel met Name t/m Action was namelijk volledig leeg. De Phonebook-entry SIP_SPOOF bestond nog wel, maar 'Usage' was geheel in de lijn der verwachtingen 'free'.

Daarom m'n vraag: Hoe kan dit?
Users in m'n interne netwerk hebben dit zeker niet op hun geweten, om de doodsimpele reden dat ze niet naar 10.0.0.138 kunnen connecten. Bovendien hebben ze geen useraccount op de server, dus daarheen SSH'en en via die server naar 10.0.0.138 over eth1 telnetten is ook niet denkbaar. Verder is er niets van terug te vinden in m'n serverlogs, dus een telnet via de server naar het modem acht ik sowieso onwaarschijnlijk.

Is het mogelijk dat men d.m.v. bouncing (III.B.2) verbinding heeft kunnen maken met 't modem om zodoende de configuratie overhoop te gooien? Zo ja, kan je zoiets voorkomen?

[paknaald]

Je wordt bedankt.
Las net je post, het artikel op sdsc.edu en ging, alhoewel ik er nauwelijks iets vanaf weet effe pielen. Een bug is pas een bug als hij repeteerbaar is, als ik dit kan herhalen is het nog ernstiger. Ik wist het password dus niet; probeerde een paar keer, en ineens was het password erased. Nu heb ik er al weer een nieuwe pass op staan, maar dit verbaast me zeer.

[Jelmer]

paknaald, zou je misschien kunnen vertellen hoe je dat dan precies hebt gedaan? (welke tools oa)

Volgens mij is het modem gewoon zn instellingen vergeten, gebeurde toen ik nog NAT gebruikt ook weleens met de NAT config..

[intoxicated]

't Gaat hier dus niet zozeer om de in de Alcatel ingebouwde backdoors, die zijn bekend. Maar het gaat erom, hoe iemand van buitenaf instaat is om een telnet-sessie op te bouwen met m'n modem, aangezien 't modem van buitenaf een volledig transparant device is.

[paknaald]

@jelmer Bij de gratie van intoxicated laat ik mijn eigen lijntje ook hierdoorheen lopen. Ik heb geen (!) tools gebruikt, slechts 4x proberen in te loggen waar bij de 4e maal het password was verdwenen! Aangezien een jongen uit enschede ons netwerkje had geinstalleerd was ik niet op de hoogte van het password maar ik garandeer dat ik de nieuwe nu wel ken.

@intoxicated De tekst waar je naar verwijst laat inderdaad de ruimte open voor wat je is overkomen. Als iemand pakketjes bounced via een computer in jou netwerk en naar 255.255.255.255 laat gaan luistert 'stomme' alcatel gezellig mee. (maar je kunt lezen neem ik aan ) Er staat wel dat je de optie om re-routed packages te gebruiken aan had moeten staan.