IptabLes a IptabLex

Možná se Vám v procesech objevili dva (třeba i v několika kopiích), které nadměrně zatěžují procesor a jmenují se jak je uvedeno v nadpisu. Možná máte i velký upload (TCP Retransmission) na převážně Čínské IP adresy. Pravděpodobně také máte spuštěný nějaký servletový kontejner.
Problém může nastat pokud na svém počítači hostujete aplikaci využívající Struts 2 verze 2.3.15 nebo starší.
Následující kroky se mi osvědčili při odstranění uvedeného malware:

1.  Undeploy aplikací využívající uvedenou verzi Struts 2.
2.  v /boot odstranit všechny soubory .IptabLe* a IpabLe*
3. v /etc/rc* odstrnit všechny soubory S55IptabLe*
4. Zkontrolujte jestli nemáte nevítaného hosta: cat /etc/passwd|grep '/bin/bash'
5. Rebuild a deploy aplikací s nejnovější verzí Struts 2

A takovéto requesty (u mě z adresy 60.190.218.252) onen problém způsobují:

POST /videos.action HTTP/1.1
User-Agent: Mozilla/5.0
Accept: */*
Content-Type: application/x-www-form-urlencoded
Expect: 100-continue
Connection: Keep-Alive
redirect:${%23res%3d%23context.get('com.opensymphony.xwork2.dispatcher.HttpServletResponse'),%23res.setCharacterEncoding(%22UTF-8%22),%23a%3d(new%20java.lang.ProcessBuilder(new%20java.lang.String[]{%22killall%22%2C%22%2Fboot%2F.IptabLes%22})).start(),%23b%3d%23a.getInputStream(),%23c%3dnew%20java.io.InputStreamReader(%23b),%23d%3dnew%20java.io.BufferedReader(%23c),%23e%3dnew%20char[20000],%23d.read(%23e),%23res.getWriter().println(%23e),%23res.getWriter().flush(),%23res.getWriter().close()}

SSL na více virtuálních serverech v rámci jednoho serveru glassfish

Poblém, který následující řádky řeší je přístup přes https na více domén (druhého řádu) v rámci jednoho glassfishe, kdy domény jsou definovány v rámci virtuálního serveru. Používat více serverových certifikátů na jednom glassfishi v rámci jedné domény možné není. Více o problému zde.

Uvedený problém je řešitelný vydáním certifikátu odpovídající standardu RFC-2818 (http://www.ietf.org/rfc/rfc2818.txt) následujícím způsobem:
V CN bude název jednoho z požadovaných názvů virtuálního serveru. Ostatní názvy virtuálních serverů budou v položce "Alternativní jména subjektu certifikátu" (SubjectAltName), kde je možné umístit jednu nebo více položek dNSName případně iPAddress nebo uniformResourceIdentifier. Tomuto podobných řešení existuje více (např. využití regulárního výrazu v CN), uvedené má ovšem nejlepší interoperabilitu (http://wiki.cacert.org/VhostTaskForce#Interoperability_Test).

Podle zmíněného standardu je možné v dNSName využívat i hvězdičkovou konvenci. Navíc definuje, že CN je použito jako identita až v případě, že není definováno rozšíření subjectAltName typu dNSName. Používání CN je zastaralé a RFC-2818 namísto toho certifikačním autoritám doporučuje používat dNSName.

SSL certifikát pro více subdomén spravovaných jedním serverem glassfish

Případ, kdy je více domén 3.řádu (k jedné doméně 2. řádu) obsluhováno jedním serverem je celkem častý. Pokud tyto domény využívají SSL je zde možnost využít  certifikát vystavený pro všechny domény třetího řádu (*.mojedomena.com)
Popíši teď postup pro případ, kdy si vytvořím certifikát podepsaný sám sebou. Budu předpokládat, že alias certifikátu nastavený v http listeneru serveru glassfish se jmenuje s1as. V Admin consoli je toto nastavení v Configuration - Network Config - Network Listeners - http-listener-nazev - záložka SSL - Certificate NickName. Všechni níže uváděné příkazy jsou prováděny v
1) Nejprve smažu dosud používaný privátní klíč:

 keytool -delete -alias s1as -keystore keystore.jks -storepass changeit  

2) Smažu certifikát:

 keytool -delete -alias s1as -keystore cacerts.jks -storepass changeit  

3) Vytvořím privátní klíč:

 keytool -genkey -alias s1as -keypass changeit -storepass changeit -keystore keystore.jks  

4) Předchozí příkaz je interaktivní. Je nutné na otázku "What is your first and last name?" napsat "*.mojedomena.com" další odpovědi již nejsou tolik významené.
5) Exportuji do souboru certifikát:

 keytool -export -alias s1as -storepass changeit -file cert.cer -keystore keystore.jks  

6) Importuji certifikát do cacerts:

 keytool -import -v -trustcacerts -alias s1as -file servercpost.cer -keystore cacerts.jks -keypass changeit -storepass changeit  

Hotovo, nyní by již měl glassfish po restartu na příchozí https požadavky využít nový "hvězdičkový" certifikát.

Import privátních klíčů PKCS12 do JKS keystoru glassfishe

Výchozí stav: mám soubor od certifikační autority s příponou p12, heslo k privátnímu klíči a potřebuji ho použít pro SSL v glassfishi jako náhradu za prošlý certifikát
Krok 1: nejprve je třeba z keystore.jks odstranit onen prošlý certifikát:

 keytool -delete -alias alias -keystore keystore.jks -storepass changeit -v  

Krok 2: import obsahu p12 do keystore.jks

 keytool -v -importkeystore -srckeystore cert_auth.p12 -srcstoretype PKCS12 -destkeystore keystore.jks -deststoretype JKS  

Krok 3: Dost možná nemá importovaný klíč stejný alias jaký bychom si představovali. My bychom např. chtěli aby se jmenoval ap1as1 a on se jmenuje authkey#1, to lze vyřešit následovně:

 keytool -changealias -alias authkey#1 -destalias ap1as1 -keystore keystore.jks  

Po zadání tohoto příkazu se keytool nejprve zeptá na heslo pro keystore a poté na heslo ke klíči, který jsme v předchozím kroku importovali.
Krok 4: V tomto stavu by po restartu glassfishe pravděpodobně nastala chyba java.security.UnrecoverableKeyException: Cannot recover key Důvodem je jiné heslo pro nově importovaný klíč a jiné heslo pro keystore. Hesla lze sjednotit následovně:

 keytool -keypasswd -alias ap1as1 -keypass oldKeyPassword -new changeit -keystore keystore.jks -storepass changeit -v  

Nyní by mělo stačit restartovat glassfish.