[CentOS 4] Rare verbindingen in netstat

[Luppie]

Sinds 3 dagen staan er op mijn Linux webserver continu 3 verbindingen open.



Nu heb ik met netstat de verbindingen opgevraagd en krijg ik het volgende :

Proto Recv-Q Send-Q Local Address Foreign Address State
tcp 0 0 xxxxx.xxxxxx.xxx:20201 air207.startdedicated:38596 ESTABLISHED
tcp 0 0 xxxxx.xxxxxx.xxx:http ns2.transip.net:49917 TIME_WAIT
tcp 0 0 xxxxx.xxxxxx.xxx:http 62.140.137.30:17166 FIN_WAIT2
tcp 0 0 xxxxx.xxxxxx.xxx:20201 melky-ganteng-a.biz:1934 ESTABLISHED
tcp 0 0 xxxxx.xxxxxx.xxx:http 62.140.137.30:16818 FIN_WAIT2
tcp 0 0 xxxxx.xxxxxx.xxx:http relay0.transip.nl:49969 TIME_WAIT
tcp 0 0 xxxxx.xxxxxx.xxx:20201 i.dont.like.you.coz.y:42280 ESTABLISHED
tcp 0 0 xxxxx.xxxxxx.xxx:http relay1.transip.nl:49385 TIME_WAIT
tcp 0 0 xxxxx.xxxxxx.xxx:http a82-92-67-55.adsl.xs4:63129 ESTABLISHED
tcp 0 1264 xxxxx.xxxxxx.xxx:ssh ::ffff:62.140.137.30:15051 ESTABLISHED

De adressen die ik niet vertrouw heb ik bold weergegeven. Hoe kan ik van deze adressen de verbinding verbreken ? Het lijken niet bestaande adressen, ik ken geen .y domein of een .startdedicated domein.

xxxxx.xxxxxx.xxx = mijn server
Poort 20201 heb ik op google gezocht, maar kon niks vinden.

[ Voor 5% gewijzigd door Luppie op 12-04-2006 10:45 ]

[Lancer]

Volgens mij is er geen commando om een specifieke tcp/ip verbinding te terminaten
Wat je zou kunnen doen is tijdelijk een iptables entry toevoegen die verkeer over deze poort blocked. Uiteindelijk komt er een timeout op de verbindingen en worden deze gesloten.

Ik vindt het wel opvallend dat het iedere keer dezelfde poort is. Als je geen eMule oid hebt lopen zou ik eens goed je systeem nakijken

Je zou ook met tcpdump/ethereal kunnen kijken wat er precies over de lijn gaat.

[ Voor 10% gewijzigd door Lancer op 12-04-2006 10:49 ]

[Luppie]

Ik heb nu het volgende gedaan :

code:

iptables -A INPUT -j DROP -p tcp --dport 20201
iptables -A INPUT -j DROP -p udp --dport 20201

service network restart

En nog steeds staan de 3 genoemde verbindingen op Established.

[ Voor 72% gewijzigd door Luppie op 12-04-2006 11:43 ]

[Verwijderd]

Kijk eens met lsof welk programma die poorten openzet?
"lsof | grep 21201" is genoeg daarvoor.
Het kan zijn dat je lsof moet installeren.

Als je netstat vertrouwt kan je ook gewoon netstat -eeap gebruiken als root.
Dan staat het PID van het betreffende proces erachter en kan je dat opzoeken in ps aux.
Als je machine serieus gehacked is zou ik netstat en ps niet meer vertrouwen though.

[ Voor 8% gewijzigd door Verwijderd op 12-04-2006 12:22 ]

[Luppie]

Dit is de output van lsof.

code:

bnc       21165  apache    3u     IPv4  2063094004                 TCP *:20201 (LISTEN)
bnc       21165  apache    4u     IPv4 -2145770357                 TCP lupsrv01.luppie.net:20201->air207.startdedicated.com:38596 (ESTABLISHED)
bnc       21165  apache    5u     IPv4 -2145770134                 TCP lupsrv01.luppie.net:20201->i.dont.like.you.coz.you.are.a.baldgirl.net:42280 (ESTABLISHED)
bnc       21165  apache    6u     IPv4 -2145766201                 TCP lupsrv01.luppie.net:20201->melky-ganteng-a.biz:1934 (ESTABLISHED)

Wat kan ik hier precies aan zien ?

[blaataaps]

Dat je je machine moet herinstalleren en na de herinstallatie wel je security-updates bijhouden omdat er (waarschijnlijk irc-) bouncers draaien als apache-user, wat me niet de bedoeling lijkt wel?

[ Voor 18% gewijzigd door blaataaps op 12-04-2006 13:22 ]

[Luppie]

bnc is inderdaad een irc bouncer (had ik net gevonden)
Heb een automatische updatejob lopen om mijn machine iedere dag te auto-updaten.

Ga nog wel verder zoeken hoe en wat er precies gebeurd is om het in de toekomst te voorkomen.

[Luppie]

Heb het e.e.a. gevonden.

Op mijn server in de /tmp staan 2 programma's geïnstalleerd :

BNC (Is ook geconfigureerd en ik kan connecten met mijn server over IRC op bovenstaande poort)
orbit-root (Hierover kan ik heel weinig vinden)

chkrootkit ziet verder geen problemen, alleen is dat natuurlijk niet echt betrouwbaar.

Hoe kunnen deze apps in mijn tmp komen en hoe voorkom ik dat. Ik draai iedere nacht YUM Update en IP's van brute force attacks worden na 4 pogingen d.m.v. denyhost geblokkeerd.

[blaataaps]

Het is via apache gegaan, je zult wel iets draaien als een lek forum (phpbb ofzo) of een ander notoir stuk software (awstats ofzo), of een stuk eigengeschreven software is/was lek.

[Netraam]

Waarschijnlijk heb je een php script of iets dergelijks draaien op je webserver dat niet helemaal goed alle input afvangt en die kan dan processen als apache starten.

Dit heb ik wel eens gezien met onder andere mambo cms.

[_JGC_]

blaataaps schreef op woensdag 12 april 2006 @ 13:21:
Dat je je machine moet herinstalleren en na de herinstallatie wel je security-updates bijhouden omdat er (waarschijnlijk irc-) bouncers draaien als apache-user, wat me niet de bedoeling lijkt wel?

Een IRC bouncer op je systeem is geen reden om je hele systeem van de grond af op te bouwen, in dit geval is het gewoon een kwestie van het lekke PHP script dichtzetten en onderzoeken of er noodzaak is voor een reinstall.

[daft_dutch]

_JGC_ schreef op woensdag 12 april 2006 @ 14:32:
[...]
Een IRC bouncer op je systeem is geen reden om je hele systeem van de grond af op te bouwen, in dit geval is het gewoon een kwestie van het lekke PHP script dichtzetten en onderzoeken of er noodzaak is voor een reinstall.

Helemaal mee eens. De bouncers maken gebruik van de apache user. Als ik jou was zou ik eerst een Rootkit scanner draaien. je kan er vast wel een met yum starten.

kijk ook eens wanneer die bnc gekopieerd is naar je server.
en dan vergelijken in je apache logs of er een overeenkomstige tijd is waneer een php script werd aangeproken,
mischien kan je het lek vinden

[Luppie]

Dat wordt dus even zoeken, draaien +/- 20 sites met een variatie van Mambo, Joombla, PHP Nuke, Drupal en ook wat gastenboek systemen.

Waarschijnlijk is diegene die het gedaan heeft lid van de "malanghackerlink"
Dit kom ik i.i.g. tegen in de bnc dir. Deze groep is verantwoordelijk voor een aantal defacements van php gebouwde sites/gastenboeken.

The search continues

Ik had al chkrootkit gedraaid en die kon niks vinden als rootkit, het moet enkel bij een exploit van de apache user gebleven zijn.

[ Voor 17% gewijzigd door Luppie op 12-04-2006 15:05 ]

[_JGC_]

Nog een reden om over te stappen naar FastCGI met suexec: meteen zien welke klant lekt

Hoe vaak ik wel niet vage bouncers of spamruns heb gezien op een webserver met 350 VHosts, een ps aux verraadt meteen welke klant het is

[Luppie]

code:

 ps aux |grep bnc

apache   25930  0.0  0.1  3776  516 ?        Ss   20:28   0:00 ./bnc bnc.conf

Hoe kan ik nu zien welke user het is ? Er staat een relatief pad en hij draaid onder apache. Met locate is bnc ook niet te vinden.

[Verwijderd]

Cobra_Lup schreef op woensdag 12 april 2006 @ 22:12:

code:

 ps aux |grep bnc

apache   25930  0.0  0.1  3776  516 ?        Ss   20:28   0:00 ./bnc bnc.conf

Hoe kan ik nu zien welke user het is ? Er staat een relatief pad en hij draaid onder apache. Met locate is bnc ook niet te vinden.

Je kan niet zien welke user het is.
Al je webbased dingen worden onder de apache user gedraait, dat is ook de reden dat je suphp/exec moet gebruiken. Daarmee voer je de scripts uit onder de naam van de eigenaar en niet als apache user.

Je kan bnc niet in locate vinden omdat de file niet in de locate database staat.
Een mogelijkheid zou find zijn.
Maar lsof -p 25930 werkt sneller en geeft meer info over het betreffende PID.

Je kan ook handmatig in /proc/25930 kijken.
Bijvoorbeeld ls -l /proc/25930/exe.
Dat is als het goed is een symlink naar de executable van dat PID.

En kill die processen eens.
Je bent nu een free for all IRC proxy.
Of nog erger, een spam proxy.

[ Voor 23% gewijzigd door Verwijderd op 13-04-2006 00:44 ]

[Luppie]

De processen had ik gisteren al gekilled, ik kan jouw tips dus niet even uitproberen.
Bleek ook nog een proces r0nin actief te zijn, die waarschijnlijk iedere keer opnieuw bnc opstarte.

Alle vreemde processen zijn nu gestopt en ik ga maar snel mijn php patchen, hier ligt de grootste oorzaak. Probleem is alleen dat mijn server DirectAdmin gebruikt met custom gecompileerde php en apache en ik nog niet een hele grote held ben op Linux gebied.

[Luppie]

Ik heb de oorzaak gevonden. Er is een php site (SQuery) waarvoor een exploit gevonden is.

http://secunia.com/advisories/19482/

[Verwijderd]

Cobra_Lup schreef op zondag 16 april 2006 @ 14:12:
Ik heb de oorzaak gevonden. Er is een php site (SQuery) waarvoor een exploit gevonden is.

http://secunia.com/advisories/19482/

Weet je dit zeker of doe je gewoon een gokje omdat je dit toevallig hebt lopen?
Heb je al logfiles gevonden waarin de exploit plaatsvond?

[Luppie]

Ik heb de logfiles gevonden Anders was ik nooit gericht gaan zoeken naar deze mogelijkheid.
Had SQuery al meer dan een jaar draaien dus had er nooit aangedacht dat ie lek zou kunnen zijn.

Heb ook aan de hand van de logfiles zelf ook een attack uitgevoerd op mijn eigen server en het is best "eng" om te zien wat een hacker dan kan met je server.

Wel ga ik verder uitzoeken hoe ik in de toekomst dit nog beter kan voorkomen/opsporen.

Ben nu aan het kijken naar snort en tripwire.

[Verwijderd]

Cobra_Lup schreef op zondag 16 april 2006 @ 15:21:
Ik heb de logfiles gevonden Anders was ik nooit gericht gaan zoeken naar deze mogelijkheid.
Had SQuery al meer dan een jaar draaien dus had er nooit aangedacht dat ie lek zou kunnen zijn.

Heb ook aan de hand van de logfiles zelf ook een attack uitgevoerd op mijn eigen server en het is best "eng" om te zien wat een hacker dan kan met je server.

Wel ga ik verder uitzoeken hoe ik in de toekomst dit nog beter kan voorkomen/opsporen.

Ben nu aan het kijken naar snort en tripwire.

Je moet niet naar snort en tripwire kijken, je moet subscriben op security lists en je software gewoon up to date houden waar noodzakelijk.
En je moet dingen als suexec en suphp draaien, het liefst in een chroot of jail.

Je moet geen muur om een onveilig systeem bouwen, je moet het systeem gewoon veilig maken.