Vilket program försöker skicka data på port 25?

2014-07-23 08:22

#1

Kalle W
Medlem ●
Bollnäs
2014-07-23 08:22

Bakgrund:

Min OSX Server agerar bland annat webb- och mejlserver åt ett dussin domäner. För några månader sedan fick jag ett intrång i en ouppdaterad wordpressinstallation på den vilket resulterade i att servern under ett par dagar agerade proxy för utskick av skräppost. Servern svartlistades i ett gäng RBL:er, men efter att jag säkrat upp den och städat bort skriptet så var allt frid och fröjd. Ett par veckor senare hände samma sak, men den här gången lyckades jag missa ett av skripten som installerades. Det i sin tur lade upp ett cronjob som skickade info om servern till en mejladress regelbundet. Som tur var hittade jag det utan att någon mejl gått iväg eftersom jag låst mejlkön tills allt var uppstädat.

Som en sista säkerhetsåtgärd för att verkligen försäkra mig om att ingen otillåten mejltrafik går ut har jag nu konfigurerat servern så att all mejl först körs genom ClamAV och Amavisd lokalt, sedan skickas till en sekundär mejlserver via en icke-standardport för mejltrafik (för att ingen ska kunna tunnla till den otillåtet) som även kräver SMTP auth via CRAM-MD5. På den sekundära servern körs mejlen ett varv till för koll av skräppost och virus innan den slutligen levereras ut till mottagaren.

För att allt verkligen ska ta den vägen så har jag också spärrat utgående trafik på port 25 i servern, ifall något program går förbi Postfix för utgående mejltrafik.

Problemet:

Nu har jag kört så här några veckor och det ser ut att ge det resultat jag önskar. I loggarna på sekundära servern ser det ut att endast vara tillåten trafik. Samma sak på den primära.

Men, nu ser jag att de senaste två dagarna har jag loggat spärrad trafik i brandväggen från en märklig lokal port som försöker skicka ut på port 25.

Jul 22 18:47:00 server ipfw[789]:  1010 Deny TCP 192.168.0.250:56975 209.86.93.229:25 out via en0
Jul 22 18:47:00 server ipfw[789]:  1010 Deny TCP 192.168.0.250:56976 209.86.93.226:25 out via en0
Jul 22 18:47:00 server ipfw[789]:  1010 Deny TCP 192.168.0.250:56977 173.194.71.26:25 out via en0
Jul 22 18:47:01 server ipfw[789]:  1010 Deny TCP 192.168.0.250:56978 173.194.64.26:25 out via en0
Jul 22 18:47:01 server ipfw[789]:  1010 Deny TCP 192.168.0.250:56979 152.163.0.100:25 out via en0
Jul 22 18:47:01 server ipfw[789]:  1010 Deny TCP 192.168.0.250:56980 64.12.88.163:25 out via en0
Jul 22 18:47:01 server ipfw[789]:  1010 Deny TCP 192.168.0.250:56981 64.12.88.164:25 out via en0
Jul 22 18:47:01 server ipfw[789]:  1010 Deny TCP 192.168.0.250:56982 64.12.91.195:25 out via en0
Jul 22 18:47:01 server ipfw[789]:  1010 Deny TCP 192.168.0.250:56983 74.125.142.27:25 out via en0
Jul 22 18:47:01 server ipfw[789]:  1010 Deny TCP 192.168.0.250:56984 74.125.137.27:25 out via en0

Fråga:

Hur kan jag hitta vilket program som står bakom ovan spärrade trafik?

Senast redigerat 2014-07-24 08:22

Anmäl Ändra Gilla Svara

2014-07-23 08:40

#2

hansfilipelo
Medlem ●
Linköping
2014-07-23 08:40

Ursprungligen av Kalle W:

Bakgrund:

Min OSX Server agerar bland annat webb- och mejlserver åt ett dussin domäner. För några månader sedan fick jag ett intrång i en ouppdaterad wordpressinstallation på den vilket resulterade i att servern under ett par dagar agerade proxy för utskick av skräppost. Servern svartlistades i ett gäng RBL:er, men efter att jag säkrat upp den och städat bort skriptet så var allt frid och fröjd. Ett par veckor senare hände samma sak, men den här gången lyckades jag missa ett av skripten som installerades. Det i sin tur lade upp ett cronjob som skickade info om servern till en mejladress regelbundet. Som tur var hittade jag det utan att någon mejl gått iväg eftersom jag låst mejlkön tills allt var uppstädat.

Som en sista säkerhetsåtgärd för att verkligen försäkra mig om att ingen otillåten mejltrafik går ut har jag nu konfigurerat servern så att all mejl först körs genom ClamAV och Amavisd lokalt, sedan skickas till en sekundär mejlserver via en icke-standardport för mejltrafik (för att ingen ska kunna tunnla till den otillåtet) som även kräver SMTP auth via CRAM-MD5. På den sekundära servern körs mejlen ett varv till för koll av skräppost och virus innan den slutligen levereras ut till mottagaren.

För att allt verkligen ska ta den vägen så har jag också spärrat utgående trafik på port 25 i servern, ifall något program går förbi Postfix för utgående mejltrafik.

Problemet:

Nu har jag kört så här några veckor och det ser ut att ge det resultat jag önskar. I loggarna på sekundära servern ser det ut att endast vara tillåten trafik. Samma sak på den primära.

Men, nu ser jag att de senaste två dagarna har jag loggat spärrad trafik i brandväggen från en märklig lokal port som försöker skicka ut på port 25.

Jul 22 18:47:00 server ipfw[789]: 1010 Deny TCP 192.168.0.250:56975 209.86.93.229:25 out via en0
Jul 22 18:47:00 server ipfw[789]: 1010 Deny TCP 192.168.0.250:56976 209.86.93.226:25 out via en0
Jul 22 18:47:00 server ipfw[789]: 1010 Deny TCP 192.168.0.250:56977 173.194.71.26:25 out via en0
Jul 22 18:47:01 server ipfw[789]: 1010 Deny TCP 192.168.0.250:56978 173.194.64.26:25 out via en0
Jul 22 18:47:01 server ipfw[789]: 1010 Deny TCP 192.168.0.250:56979 152.163.0.100:25 out via en0
Jul 22 18:47:01 server ipfw[789]: 1010 Deny TCP 192.168.0.250:56980 64.12.88.163:25 out via en0
Jul 22 18:47:01 server ipfw[789]: 1010 Deny TCP 192.168.0.250:56981 64.12.88.164:25 out via en0
Jul 22 18:47:01 server ipfw[789]: 1010 Deny TCP 192.168.0.250:56982 64.12.91.195:25 out via en0
Jul 22 18:47:01 server ipfw[789]: 1010 Deny TCP 192.168.0.250:56983 74.125.142.27:25 out via en0
Jul 22 18:47:01 server ipfw[789]: 1010 Deny TCP 192.168.0.250:56984 74.125.137.27:25 out via en0

Fråga:

Hur kan jag hitta vilket program som står bakom ovan spärrade trafik?

Gå till inlägget

Har mer erfarenhet av serveradministration på linux men där kan man, som root, köra "lsof -i :port" för att se vilka applikationer som öppnar trafik mot den porten.

lsof bör finnas även i OS X.

edit: Finns det någon anledning till att du kör OS X Server? Hela anledningen till intrånget är ju att du ej uppgraderat Wordpress. Med Debian eller Ubuntu har du pakethanterare som du kan använda för unattended-upgrades vilket gör att du slipper patcha manuellt så fort det släpps en säkerhetsfix eftersom den löser det åt dig.

Anmäl Ändra Gilla Svara

2014-07-23 09:29

#3

Kalle W
Medlem ●
Bollnäs
2014-07-23 09:29

Problemet med lsof är att det måste exekveras i den millisekund som trafiken sker.

Jag skulle vilja göra det den gör men logga det till en fil så fort något sker på porten. Är det möjligt utan att få en loop som äter upp all processor?

Ja, det finns en anledning till att jag kör OSX Server. WP-installationerna patchar jag nu via ett eget skript plus att jag kör Wordfence på dem som extra kontroll. Så allt är nog så säkert som det kan vara på just den fronten.

Anmäl Ändra Gilla Svara

2014-07-23 09:42

#4

hansfilipelo
Medlem ●
Linköping
2014-07-23 09:42

Ursprungligen av Kalle W:

Problemet med lsof är att det måste exekveras i den millisekund som trafiken sker.

Jag skulle vilja göra det den gör men logga det till en fil så fort något sker på porten. Är det möjligt utan att få en loop som äter upp all processor?

Ja, det finns en anledning till att jag kör OSX Server. WP-installationerna patchar jag nu via ett eget skript plus att jag kör Wordfence på dem som extra kontroll. Så allt är nog så säkert som det kan vara på just den fronten.

Gå till inlägget

Kan du inte trigga lsof över ssh när brandväggen blockerar enligt aktuell regel? Det enda jag kan komma på där om du inte ska köra lsof konstant.

Vad för anledning?

Anmäl Ändra Gilla Svara

2014-07-23 11:20

#5

suddgummi
Inte helt 100 ●
Irland
2014-07-23 11:20

nettop finns annars

Anmäl Ändra Gilla Svara

2014-07-23 11:46

#6

irrelogical
Medlem ●
Göteborg
2014-07-23 11:46

Whoa, att hålla Wordpress uppdaterat via operativsystemets pakethanterare är nog inte en så bra idé. Senaste versionen är 3.9.1, och t ex Ubuntu 14.04 skickar med 3.8.2. Det händer väldigt mycket på kort tid, och pakethanterare brukar inte lira bra ihop med flera installationer, speciella uppgraderingsrutiner pga plugins, etc.

Anmäl Ändra Gilla Svara

2014-07-23 16:08

#7

hansfilipelo
Medlem ●
Linköping
2014-07-23 16:08

Ursprungligen av irrelogical:

Whoa, att hålla Wordpress uppdaterat via operativsystemets pakethanterare är nog inte en så bra idé. Senaste versionen är 3.9.1, och t ex Ubuntu 14.04 skickar med 3.8.2. Det händer väldigt mycket på kort tid, och pakethanterare brukar inte lira bra ihop med flera installationer, speciella uppgraderingsrutiner pga plugins, etc.

Gå till inlägget

Versionen är 3.8.2 men den underhålls med säkerhetsuppdateringar. Det gäller alla paket i Debians och Ubuntus officiella repos.

Anmäl Ändra Gilla 1 Svara

2014-07-23 17:54

#8

Kalle W
Medlem ●
Bollnäs
2014-07-23 17:54

Både nettop och iftop (via Macports) är intressanta verktyg, men de agerar bara i realtid (vad jag kan förstå). Vilket innebär att jag måste sitta och titta på dem hela tiden och förhoppningsvis se när trafik kommer. Inte riktigt görbart i praktiken.

Hur kan man trigga lsof över ssh när brandväggen blockerar? (Har dålig erfarenhet här inser jag…)

Anmäl Ändra Gilla Svara

2014-07-23 21:35

#10

Borttaget
Oregistrerad ●
2014-07-23 21:35

Ursprungligen av hansfilipelo:

Versionen är 3.8.2 men den underhålls med säkerhetsuppdateringar. Det gäller alla paket i Debians och Ubuntus officiella repos.

Gå till inlägget

Det beror på vilken komponent paketet ligger under. I Debian ligger wordpress under main och får säkerhesuppdateringar. Ubuntu har däremot placerat det under universe som normalt inte underhålls alls. Ubuntu supportar bara en handfull paket jämfört med Debian och ingen av dem supportar alla paket som de har i sina arkiv.

Anmäl Ändra Gilla Svara

2014-07-24 07:36

#11

hansfilipelo
Medlem ●
Linköping
2014-07-24 07:36

Ursprungligen av Marcus K:

Det beror på vilken komponent paketet ligger under. I Debian ligger wordpress under main och får säkerhesuppdateringar. Ubuntu har däremot placerat det under universe som normalt inte underhålls alls. Ubuntu supportar bara en handfull paket jämfört med Debian och ingen av dem supportar alla paket som de har i sina arkiv.

Gå till inlägget

Visste inte att Wordpress låg i universe i Ubuntu. Kör själv Debian.

Nej de supportar inte alla paket - men de supportar alla paket i main. Mitt argument är alltså fortfarande hållbart. Varför patcha manuellt när man kan anmäla sig till en epostlista och:

Ta en kaffe och gör något annat.
Få ett mail som säger "lucka i det här programmet".
Ta en kaffe och gör något annat.
Få ett mail från servern med uppgraderingslogg.
Ta en kaffe och gör något annat.

Anmäl Ändra Gilla Svara

2014-07-24 07:38

#12

hansfilipelo
Medlem ●
Linköping
2014-07-24 07:38

Ursprungligen av Kalle W:

Både nettop och iftop (via Macports) är intressanta verktyg, men de agerar bara i realtid (vad jag kan förstå). Vilket innebär att jag måste sitta och titta på dem hela tiden och förhoppningsvis se när trafik kommer. Inte riktigt görbart i praktiken.

Hur kan man trigga lsof över ssh när brandväggen blockerar? (Har dålig erfarenhet här inser jag…)

Gå till inlägget

Vet inte vad du kör för brandvägg men om du kan trigga event på blockering kan du sedan från brandväggen köra:

touch filnamn.txt
ssh user@osxserver "lsof -i :25" >> filnamn.txt

Anmäl Ändra Gilla Svara

2014-07-24 08:22

#13

Kalle W
Medlem ●
Bollnäs
2014-07-24 08:22

Ursprungligen av hansfilipelo:

Vet inte vad du kör för brandvägg men om du kan trigga event på blockering kan du sedan från brandväggen köra:

Gå till inlägget

Jag kör ipfw på samma server. Hittar inget om att jag kan trigga något event från den, men jag har säkert missat något. Har du koll?

Anmäl Ändra Gilla Svara

2014-07-24 10:38

#15

irrelogical
Medlem ●
Göteborg
2014-07-24 10:38

Ursprungligen av hansfilipelo:

Varför patcha manuellt när man kan anmäla sig till en epostlista och...

Gå till inlägget

För att man vill köra senaste versionen, eller att man vill kunna köra flera wp-sajter på samma server (med olika versioner, för att dom har olika kompabilitetskrav med plugins etc) och uppgradering är ett klick bort i admin-panelen? Klart att det är smidigare att installera från pakethanteraren ur en systemadministrationsvinkel, men det finns ju fler perspektiv än så.