Как убедить моего Администратора, что Java НА СЕРВЕРЕ весьма безопасен по сути?
Приложение
У нас есть маленькое JAVA-приложение, которое использует некоторые маршруты Camel, чтобы поднять загруженные файлы с веб-сервера, обработать их и отослать некоторые электронные письма с результатами.
Сервер, на котором работало это приложение, был выведен из эксплуатации. На данный момент мы должны выполнить его на недостаточно мощных аппаратных средствах, потому что я не могу убедить администратора устанавливать JRE на веб-сервере (который является на самом деле многоцелевым сервером).
Страх
Я - Инженер JAVA-приложения сам, я пишу код JEE для жизни, обрабатывая транзакции B2B стоимостью в десятки тысяч €uros в неделю. Но у меня есть проблемы при нахождении достоверных источников, которые опровергают миф, что Java небезопасен по сути.
Два основных аргумента администратора против установки JRE:
- JAVA-приложения съедают всю мою RAM
- Java полон уязвимостей
Истина?
Когда дело доходит до JAVA-приложений, съедающих, врезаются. Хорошо... Я сказал бы, что мы должны установить собственные значения для Xmx.Готово.
Теперь существует много источников, говорящих о многих уязвимостях Java. Эти источники главным образом стремятся к конечным пользователям, выполняющим определенную операционную систему от компании в РЕДМОНДЕ/США. AFAIK это может быть верно для неисправленных версий Плагина Браузера Java, который настроен для выполнения всех апплетов автоматически, что существуют довольно большие возможности того, чтобы быть жертвой диска заражением. Так же, как существует риск ловли STD при наличии незащищенного секса с eveyone на поезде при добирании до работы.
Но я не мог найти никого на всемирном interwebz, кто говорит о серверных приложениях или выполнении JREs бездисплейного. Это - целая другая вещь.
Или я пропускаю что-то здесь?
[отредактируйте 28.08.2014] разъяснение: я только обеспокоен Java на серверах. Я не забочусь о проблемах с Java о Сменном и/или определенном программном обеспечении, разработанном в Java.
Дополнительная поверхность java безопасности, которую java вкладывает в ваше окружение, сложна, и важно не игнорировать ее и не пытаться упростить.
Во-первых, есть ужасная запись, которая есть в JRE за наличие ошибок в безопасности. Сложно указать на конкретную, и это страшная часть - ошибки - это в подавляющем большинстве случаев неопределённые уязвимости с неопределёнными векторами.
Когда я, как консультант по безопасности, читаю пункты типа "позволяет удалённому взломщику" без дополнительной квалификации их значения, я вижу, что это вполне может означать, что определённые параметры, попадающие в определённую функцию, могут вызывать уязвимое состояние, даже если вы запускаете только написанный вами код. И, поскольку они неуказаны, вы не узнаете, были ли вы затронуты.
Еще лучше, каноническое JRE, опубликованное Oracle, имеет заявленный ежеквартальный цикл обновления для критических обновлений, включая почти все обновления безопасности. За последние четыре года они в общей сложности 11 раз создавали исправления за счет циклов. Это означает, что существует вероятность того, что вы можете быть уязвимы к ошибке в безопасности до трех месяцев после сообщения об этом , прежде чем у вас появится возможность исправить ее.
Есть и другие проблемы с java, в которые я здесь не попаду, но на самом деле, кажется, что существует обоснованная озабоченность, особенно для многоцелевого сервера. Если вам нужно запустить такие вещи, то вы должны, по крайней мере, сделать для него VM одноцелевого назначения и изолировать его от других вещей.
В частности, если в JRE есть удаленный сервер, который позволяет злоумышленнику получить RCE, и еще один в PHP, который делает то же самое, и еще один в Ruby, который делает то же самое снова, вы должны исправить все три. Все три выглядят несколько правдоподобно, так как все это происходит, и злоумышленнику приходится выбирать, какой из них наиболее удобен, а затем владеть всем сервером. Вот почему мы должны использовать ВМ для разделения программного обеспечения, особенно такого багги программного обеспечения, как фреймворки управляемого языка, и особенно тех, которые устанавливают патчи безопасности только четыре раза в год и являются несвободными для поставщика, который утверждает перед лицом всех доказательств того, что они являются образцом безопасности.
Чтобы обновить, вот некоторые CVE, которые я выбрал из связанного с ChrisS поиска CVE, с помощью демонстрации.
- https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-5884
- https://cve.mitre.org/cgi-bin/cvename.cgi? name=CVE-2013-5910
- https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-5456
- https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-3007
- https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-2454
- https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-2447
- https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-1557
And my favourite, since I was there:
That's just a small sampling, by the way.
Java-приложения съедают всю мою оперативную память
Альтернативой использованию оперативной памяти является растрата оперативной памяти. Ее нельзя сохранить на потом.
Java полна уязвимостей
Это не имеет значения, так как вы не собираетесь выставлять JVM на обозрение. Я полагаю, что вы не собираетесь запускать враждебные программы, а если собираетесь, то Java безопаснее, чем большинство других языков. Важно то, есть ли у ваших приложений есть уязвимости.
Объясните, что все другие языки (или виртуальные машины) могут быть обезопашены кодом, который на них установлен, так же, как и Java. Если он думает, что другие платформы по своей природе безопасны (или более безопасны, чем Java) без правильного адреса безопасности, то он бредит.
Ваша компания, очевидно, вложила средства в наем разработчика Java, почему сисадмин отказывается поддерживать технологию, которую компания решила использовать?
Я бы перевернул вопрос и спросил его, какие альтернативы он предлагает и как они более безопасны, чем последние доступные серверы JRE, в очень специфических терминах. А пока поработайте над тем, чтобы показать, что вы понимаете вашу технологию, возможную поверхность атаки и что вы работали над ее минимизацией (например, ненужные фреймворки, сторонний код и т.д.). Проверьте свой код, поищите опубликованные уязвимости для фреймворков, на которые вы опирались в последние X лет, сравните его с другими языками/фреймворками (убедитесь, что в него также включен Markethare, неясные фреймворки без опубликованных уязвимостей ничего не значат).
Мы, возможно, не можем знать, как произошло полное преобразование между вами, но если бы это были два его аргумента, я полагаю, что вы имеете дело с младшим системным администратором. Есть ли у него опыт работы с серверами Java-приложений? Возможно, он недоволен этой технологией и боится поставить что-то в производство, не понимая этого досконально (тогда хороший сисадмин)
.Наймите компанию для выполнения статического анализа вашей программы. Veracode, например, это компания, которую я использовал в прошлом для аудита безопасности кода Java-программ, а именно.
Очевидно, что выставлять счет за код вашей команды администраторов.
.