Karpion

sshd в принципе не может различать, пор какому доменному имени к нему обратились. Можно только по IP-адресу или по номеру TCP-порта.

Смотрим, как называется /dev/файл COM-порта. Читаем по нему man - там, скорее всего, есть список программ для работы с COM-портом.

Или можно начать с программы getty. Ну и хорошо бы помнить про ioctl - настройка параметров работы порта.

Вообще-то, проброс портов обычно настраивается в роутере через Web-интерфейс. Если роутер современный - д.б. без проблем.

Далее - "Виртуалкину сеть в режим bridge", nitro2005 правильно сказал.

Для начала надо дать команды mount и df. Ну и хорошо бы ls -l на папку, куда хотите сохранять.

Если компьютер не от Apple - то я советую Linux.

Что говорит ls -l /usr/lib64/libthread.so* ?
Если ничего не находит - то find /usr -name "libthread.so*"
(Все рекомендуемые незнакомцами команды надо давать осторожно. А то вдруг патч Бармина предложат. И копипастить - надо сначала в блокнот, потом прочитать ещё раз, потом копировать в терминал. А то есть способы скрытно всунуть гадость.)

Чтобы послать пакет наружу - его надо пробросить роутеру.
Если сеть построена на свичах - то надо запихнуть IP-пакет в Ethernet-кадр, где в качестве destignstion будет указан MAC-адрес шлюза_по_умолчанию (или иного шлюза, бывают разные конфигурации).
Если сеть построена на хабах или на коаксиале - то тоже нужно. Но мне лень объяснять, ибо неактуально. Кому интересно - достаточно знать, что промискуитет на сетевой карте включают только только по особой надобности.

Откуда наш компьютер может узнать MAC-адрес шлюза? Это можно узнать через протокол ARP; но для ARP-запроса надо знать IP-адрес запрашиваемого компьютера. Собственно, вот и ответ:
Мы прописываем адрес шлюза для того, чтобы наш компьютер мог ARP-запросом узнать MAC-адрес шлюза.

Кстати, есть альтернативный вариант настройки: компьютер знает свой IP-адрес, маска 0.0.0.0, а для всех внешних компьютеров прописывается ARP-соответствие. Такое решение годится для компьютера, который сам никогда не обращается наружу, а только получает обращения извне. И вообще, это извращение какое-то; хотя может работать.

Какой движок использовать для сайта - определяется функциональностью этого сайта. Где-то годится простой HTML, где-то надо больше.

Общие соображения по безопасности Вам уже сказали, я с ними согласен. Хотя про движок предыдущие авторы не сказали ничего осмысленного - ну так в первой фразе я обосновал, почему они и не могли ничего посоветовать: нет информации.

Хотя степень изоляции сайтов - тоже зависит от задачи.
В ряде случаев можно вообще не изолировать, а запустить вирт.серверы в рамках Apache - IP-based или DNS-based. По кр.мере, это нормально для статических сайтов на простом HTML (хотя JS, AdobeFlash и прочие программы, выполняющиеся на стороне клиента - тут ничего не меняют). Но у Вас MySQL - значит, работают server-side скрипты, а вот их надо изолировать. Но как именно изолировать - зависит от задачи.

Возможно, проблема в переменной окружения term (или TERM).

QEMU может как программно эмулировать процессор (в т.ч. не той архитектуры, где это делается), так и запускать программы на реальном процессоре. Остальные менеджеры вирт.машин типа WMWare и VirtualBox - только второй вариант.

Что понимает хостер под своими словами - знает только он сам.

Я не понял, что значит "пушит маршрут через себя". Какой маршрут?

По идее - при смене MAC-адреса и ряде иных операций, компьютер рассылает оповещения, т.е. ARP-ответы. Это нужно в первую очередь свичам, но и остальным тоже не помешает.

А в чём вопрос или проблема? Что Вам не нравится?

1) Вроде, даже при открытом коде - бэкдоры не обнаружены. Однако, это не исключает их наличия.

2) Смотря что считать свободой.

3) Да, поскольку Linux распространён очень широко. Кроме того, другие тоже достаточно популярные системы типа FreeBSD - имеют много общего с Linux. А часть интерфейсов - вообще POSIX-стандартные.

Запретить использование Linux - можно. Но это не значит, что остальной мир не положит нефритовый стержень на такой запрет.

Ну да - намеренно. И чем это Вас напрягает?
Как правило, запрет пинга и т.б. ICMP целиком - создаёт много проблем и никак не решает существующие проблемы.

Запретите на пакетном уровне весь трафик, кроме реально нужного.

Вот Вам пример для FTP-клиента:

ftp -i -n сервер <<END
user юзер пароль
cd директория
get файл
mget список_файлов
END

В этом варианте можно использовать внутри $переменная, ${переменная}, `команда`, $(команда). А используемые спец.символы, если их надо вводить как есть - надо бэкслешить; ну и сам бэкслеш тоже надо бэкслешить.

А если в первой строке написать ftp -i -n сервер <<\END - то все спец.символы перестают быть специальными, ничего бэкслешить не надо.

А есть более интеллектуальные системы, позволяющие интерактивно дискутировать с запущенной программой.

Ну, надо пробовать лёгкие дистрибутивы типа XUbuntu - из тех, у кого есть 32-битные версии.

С сайтами м.б. проблемы. Тогда лучше использовать этот компьютер как терминал к компьютеру нормальной мощности.

Поставьте задачу корректно. Что надо делать в псевдографике?
Можно не ставить Иксы. Или ставить, но не запускать. Но что тогда делать, если огромное количество программ работают в графических окнах? Разве что серверные задачи...

Если это Ваш сервер брутфорсил окружающий мир - то в первую очередь просите хостера закрыть Вашему серверу возможность исходящих соединений на TCP:22.
Вообще, странно, что хостер закрыл весь сервер, а не исходящие вызовы.

После этого смотрите, что у Вас там запущено. Похоже, кто-то подсадил резидентный процесс, постоянно висящий в памяти и долбящий соседей брутфорс-запросами. Ну так смотрите, какие процессы открывают TCP-соединения.
Теоретически - взломщик может не запускать дополнительный процесс, а дописать к нормальной программе, которая должна работать постоянно, свой кусок кода, который уже брутфорсит.

Далее подумайте над тем, какие исходящие TCP-порты Вам вообще нужны. Что-то мне кажется - практически никакие. Закройте ненужные порты - будет безопаснее; закрыть можно как силами хостера, так и силами Вашего сервера; правда, при взломе сервера - взломщик может отключить блокировку портов, сделанную силами Вашего сервера;, но это только если он получит root-привилегии.
В идеале - хостер должен предоставить Web-интерфейс, в котором клиент может сам открывать нужные ему порты и закрывать ненужные. По умолчанию - все типичные для хакеров порты д.б. закрыты.

Видимость компьютера в сетевом окружении - определяется регистрацией нужного доменного имени. Кто у вас там DNS-сервер? Что там с зоной local?