LINUX.ORG.RU

Mozilla and internal ip


0

0

Mozilla 1.7 и до 1.7.10 запущена от обычного пользователя и с включенным java-plugin. При заходе на сайт www.auditmypc.com при тестировании внешнего файервола определяется не только внешний IP-адрес роутера но и внутренний ( nated ) ip-адрес. При выключенном java-plugin этого не наблюдается. Как сделать так, чтобы internal ip нельзя было бы определить с внешней стороны.

anonymous

вы случаем прокси не используете? а то она (proxy) может отдавать X-Forwarded-For

mator ★★★★★
()

Proxy по-моему не при чем, т.к. "При выключенном java-plugin этого не наблюдается".
Зато можно попробовать отловить sniffer-ом HTTP-запросы, отсылаемые mozilla-й при включенном plugin-е. Если внутренний IP будет передаваться в каком-нибудь HTTP-заголовке, то в случае наличия proxy этот заголовок можно удалять из запросов.

spirit ★★★★★
()
Ответ на: комментарий от spirit

Нет прокси никакого нет. Вот что пишут на www.auditmypc.com после определения внутреннего ip-адреса : "This does not necessarily mean your firewall is malfunctioning or improperly configured. The method we used will sneak past most firewalls. Why? Because we use Java to grab the information and then pass it on to the server (Notice how everything ran without prompting you?) We used your internal IP for this demonstration because it's harmless (for the most part). Java passes this information to the server were it can be collected. Many claim this is not possible and that only you can see this information, so to prove the point, we included the last 20 internal IP addresses that this server has seen. To verify this information, simply tell a friend your Private IP and have them visit this page shortly after you do - they'll see your IP included in the list. The whole point of this demonstration is to make you aware that there is more to security than just a firewall. A malicious website owner could use a similar method to grab a lot more than your internal IP address, and you wouldn't even know it!

anonymous
()
Ответ на: комментарий от anonymous

Интересно, а что, кто-то держит и тем более пользует на сервере для просмотра сайтов Яву? Вот так машины и ломают. Хорошо что хоть решил проверить, теперь видно что у чему. А вообще, ОЧЕНЬ полезная тема в плане безопасности и урок хороший.

boatman
()
Ответ на: комментарий от boatman

2boatman Вы внимательно читали сообщение? На роутере никакой java-ы нет. Компьютер сидит за этим роутером.

anonymous
()
Ответ на: комментарий от anonymous

Таже фигня!
Причем, через squid (прозрачный прокси с авторедиректом на 3128) сижу за маскарадом.

=================== Тест
Что шлет Мозилла:
----------------------------------------------------
GET /freescan/securityscan.asp?S=T12051 HTTP/1.1
Host: www.auditmypc.com
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.10) Gecko/20050716
Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,
image/png,*/*;q=0.5
Accept-Language: en-us,en;q=0.7,ru;q=0.3
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Referer: http://www.auditmypc.com/freescan/scanoptions.asp?S=2051
Cookie: ASPSESSIONIDCCARBQQC=KPDFOOJDBKCOBIADJICDPBEN
----------------------------------------------------

Т.е., IP она не отдает!

Значит, что кто-то косячит в другом месте!

Notice!, your natted (or real) IP address is 10.1.1.11.   This information can be used to track your activities.   I should not be able to obtain this information if your security is properly configured!
Visit the Spyware Removal area for more information.

И они это признают:
Below is the Raw Data that you give away every time you visit a web site.
REMOTE_ADDR=XXX.XXX.XXX.XXX
REMOTE_HOST=XXX.XXX.XXX.XXX
REMOTE_USER=
HTTP_USER_AGENT=Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.10) Gecko/20050716
HTTP_X_FORWARDED_FOR=unknown
HTTP_REFERRER=
HTTP_REFERER=http://www.auditmypc.com/freescan/securityscan.asp?S=T12051

Воистину - бред какой-то!

ManJak ★★★★★
()
Ответ на: комментарий от ManJak

Вау, только заметил, что не все скопировалось

так правильно:
header_access Allow allow all
header_access Authorization allow all
header_access WWW-Authenticate allow all
header_access Cache-Control allow all
header_access Content-Encoding allow all
header_access Content-Length allow all
header_access Content-Type allow all
header_access Date allow all
header_access Expires allow all
header_access Host allow all
header_access If-Modified-Since allow all
header_access Last-Modified allow all
header_access Location allow all
header_access Pragma allow all
header_access Accept allow all
header_access Accept-Charset allow all
header_access Accept-Encoding allow all
header_access Accept-Language allow all
header_access Content-Language allow all
header_access Mime-Version allow all
header_access Retry-After allow all
header_access Title allow all
header_access Connection allow all
header_access Proxy-Connection allow all
header_access All deny all

ManJak ★★★★★
()
Ответ на: комментарий от ManJak

Исследовал, часа 4, чтоб понять!

Весь фикус, оказался в:
header_access Cookie deny all
Жутко неудобно!

А вопрос в том, насколько это РЕАЛЬНО опасно?
Они там вооще, чуть-ли не карой небеснойц пугают,
что небеса разверзнуться, если мой internal IP узнают!

ManJak ★★★★★
()
Ответ на: комментарий от ManJak

> Они там вооще, чуть-ли не карой небеснойц пугают, что небеса разверзнуться, если мой internal IP узнают!

усе равно за 254 попытки отгадать можно:)

dilmah ★★★★★
()
Ответ на: комментарий от dilmah

Дергаться, по любому не стоит, ибо врали(?) они по черному!
Тут длительный спор о безопастности (кому интересно):
http://forums.gentoo.org/viewtopic-p-2620408.html#2620408

Да, результат оглашу!

ИМХО!
был засунут кукис (с определенным, заранее, ИП адресом [ИМХО])!!!
Далее, все выирал ГСЧ!

Больше не видно:
#header_access  Cookie                  deny    all
header_access   Via                     deny    all
header_access   User-Agent              deny    all
header_access   X-Forwarded-For         deny    all
header_access   X-Cache                 deny    all
header_access   X-Cache-Lookup          deny    all
header_replace  User-Agent      007! Bond, James Bond! 

Ибо, без куков, иногда реальнгло не удобно!!!

Удачных всем исследований!
Будут дополнения/комментарии, пишите!

ManJak ★★★★★
()
Ответ на: комментарий от dilmah

>усе равно за 254 попытки отгадать можно:)

это в случае сети с маской 255.255.255.0. А если 255.255.0.0? или того хуже 255.0.0.0? пусть гадают ;)

v12aml ★★
()
Ответ на: комментарий от ManJak

> header_replace User-Agent 007! Bond, James Bond!
Очень не рекомендую так делать !!!
Сам когда-то напоролся на грабли: некоторые web-серверы могут ориентироваться на это при определении поддерживаемых клиентом кодировок.

spirit ★★★★★
()
Ответ на: комментарий от spirit

А нет риска, что если узнают клиента, то начнут его атаковать?
Я просто это скрыл, чтоб эксплореры не светить?

ЗЫ
если не в падлу, то можно конкретный пример?
Что-от в голову не приходит!

ManJak ★★★★★
()
Ответ на: комментарий от ManJak

Реальный пример: у меня стоит apache-1.3.x, когда я в squid-е сделал замену User-Agent на что-то типа вашего ("007! Bond, James Bond!"), т.е. на название browser-а, которое не существует в природе. apache стал криво отдавать некоторые страницы (они были в cp1251, стали отдаваться как koi8-r), т.к. посчитал, что такой browser не поддерживает cp1251.

А атаковать - интересно каким образом ? Вы думаете, если это захотят сделать, то не смогут попробовать целую пачку атак для разных типов browser-ов в надежде, что хоть одна сработает ?
Уже если заменять, то может на что-то существующее, например, говорить, что это Mozilla ?

spirit ★★★★★
()
Ответ на: комментарий от spirit

> Сам когда-то напоролся на грабли: некоторые web-серверы могут ориентироваться на это при определении поддерживаемых клиентом кодировок.

Если клиент не отдает Accept-Ecnoding, то он сам виноват.

ivlad ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.