Freesco, NND, CDN, EOS
http://forum.freesco.pl/

lynx a strona konfiguracyjna access pointa
http://forum.freesco.pl/viewtopic.php?f=24&t=10145
Strona 1 z 1

Autor:  JOSH [ poniedziałek, 5 grudnia 2005, 07:51 ]
Tytuł:  lynx a strona konfiguracyjna access pointa

Chciałbym aby sieć byla bezpieczna i staram się jak najmniej usług wystawiać na świat. Pytanie jest takie , jak wejść z konsoli linuksoskiej w panel administracyjny apeka?

na windowsie wpisuję w explorerze tylko np 192.168.0.2 , podaje login hasło i jadę dalej, a jak to zrobic na lynxie ? gdy wpisuje adres nic się nie dzieje. Help !

Autor:  Maciek [ poniedziałek, 5 grudnia 2005, 16:23 ]
Tytuł: 

Zwykle te panele www mają elementy javascriptu, więc lynx odpada. Spróbuj links. Ewentualnie sprawdź, czy twój AP ma wejście telnetowe.
Wg mnie skoro możesz wejść z sieci lokalnej prezez IE, to po co katować się tekstowo.

Autor:  ccrash [ poniedziałek, 5 grudnia 2005, 17:19 ]
Tytuł: 

wzgeldnie mozesz sobie zrobic prezkierowanie portow i mozesz logowac sie na apka z zewnatrz sieci

Autor:  rychmar [ niedziela, 11 grudnia 2005, 23:14 ]
Tytuł: 

A jak to zrobić?? Bo przekierowalem sobie porty np 1111 na AP-eka z danym IP i wpisuje tak w przegladarke http://82.xx.xx.98:1111
i nic,nie moge sie dostać. Chyba że robie coś źle.

Autor:  Jacq [ niedziela, 11 grudnia 2005, 23:28 ]
Tytuł: 

ustawiłeś w AP ten port zeby przez niego się logowac za pomocą www?

Autor:  rychmar [ wtorek, 13 grudnia 2005, 02:49 ]
Tytuł: 

No własnie nie przestawiłem.Mam Ovislink 1120 ,na pokładzie linux.Musze poszukac gdzie to sie zmienia.

Autor:  pablo2k5 [ wtorek, 13 grudnia 2005, 09:33 ]
Tytuł: 

A nie lepiej było by użyć tunelowania SSH. Masz z tego dwie korzyści.
1. Otwierasz tylko jeden port na zewnątrz dla usługi SSH (najlepiej zmienić na inny niż standardowy 22). Za pomocą jednego portu otwartego na zewnątrz łączysz się z wieloma urządzeniami zdefiniowanymi w tunelach wewnątrz sieci. Nie musisz także zmieniać portu w AP.
2. Transmitowane dane są szyfrowane w przeciwieństwie do większości urządzeń zarządzanych po protokole http.
Sam tego używam, wszak niewygodne jest odpalanie na klienckej stacji roboczej PuTTy, ale to już błachostka.

Autor:  rychmar [ sobota, 24 grudnia 2005, 02:23 ]
Tytuł: 

A mógłbyś opisać szerzej jak to robisz?? Googlowałem ale za wiele to sie nie dowiedziałem.Jakimi programami??
Mam taka sytuacje ,mam 2 sieci w różnych miastach,obydwa serwery to NND i łącze DSL. No i musze czasami z jednej sieci połączyć się z drugą i np wejść na AP-eka aby coś pozmieniać. Robie to przez putty na serwer a potem lynx ale to nie jest za wygodne.
Szukam lepszego rozwiazania.

Autor:  pablo2k5 [ sobota, 24 grudnia 2005, 21:15 ]
Tytuł: 

rychmar pisze:
Robie to przez putty na serwer a potem lynx ale to nie jest za wygodne.

No jeśli masz putty za pomocą którego łączysz się ze zdalnym serwerem NND to już masz prawie wszystko co Ci potrzeba. Teraz w putty w lewym menu wybierasz SSH >> Tunnels.
Następnie w polu "source port" wpisujesz jakiś wymyślony przez siebie port np: 2000. W polu "destination" wpisujesz adres np wewnątrz sieci AP i port na którym nasłuchuje jego serwer http do konfiguracji czyli: IP_AccessPoint:80
Niższe opcje w przyciskach radiowy ustawiasz na Local i IPv4. Na koniec klikasz przycisk ADD i już masz utworzony tunel. Zapisujesz sesję, a następnie podłączasz putty do zdalnego serwera. No i teraz najlepsze. Włączas sobie na kompie na którym uruchomiłeś putty przeglądarkę internetową i wpisujesz adresik http://localhost:2000/ i łączysz się ze swoim AP w bezpiecznym połączeniu SSH mimo że wykorzystujesz protokół http :) jak nie wierzysz to uruchom sobie sniffer i sam sprawdź. To jest najprostrza konfiguracja jaka może być dla tuneli ssh, oczywiście dla jednej sesji możesz dodać więcej tuneli, jednak każdy musi działać na innym porcie np: 2000,2001,2002 itd
Pozdrawiam

Autor:  rychmar [ poniedziałek, 26 grudnia 2005, 16:39 ]
Tytuł: 

Nie no poprostu rewelka,dzieki serdeczne za pomoc.

Autor:  muray [ poniedziałek, 26 grudnia 2005, 19:11 ]
Tytuł: 

ja robie to inaczej

łącze sie z serwerem przez putty po czym włączam elinks'a na serwie z nr ip danego apeka z tym ze nie próbowalem zapisywac nic bo wszystko mam juz poustawiane wiec nei wiem jak bedza działać przyciski.

mysle ze ta opcja jest troche bezpieczniejsza bo nie wystawiasz apeka na zagożenie ze swiata.

Autor:  pablo2k5 [ wtorek, 27 grudnia 2005, 09:15 ]
Tytuł: 

muray pisze:
mysle ze ta opcja jest troche bezpieczniejsza bo nie wystawiasz apeka na zagożenie ze swiata.

Trochę bym nad tym polenizował gdyż informacje które widzisz w Putty są i tak wyprowadzane na świat kanałem ssh, więc wydaje mi się że zagrożenie jest na tym samym poziomie.

Autor:  muray [ wtorek, 27 grudnia 2005, 10:45 ]
Tytuł: 

możemy polemizować. informacje owszem idą kanałem ssh ale w części AP NIE MA możliwości zmiany nazwy użytkownika (np. nowy ovislink 5460 z oryginalnym softem) i domyślnie jest to admin wiec jedynie dobre hasło ratuje cie przed włamaniem

a jesli dostęp do AP jest poprzez tunelowane porty, to dla kogoś kto to juz odkryje nie bedzie problemem odpalić programik do łamania haseł bo użytkownika juz bedzie znał.

generalnie dostęp do AP gdzie nie mam możliwości zmiany loginu wg mnie powinien być możliwy tylko z wewnętrznej sieci (a jesli komputery są w tej samej klasie adresow co AP - to tak jest) lub właśnie z serwera.

włamanie na AP możliwe jest wtedy tylko poprzez włamanie sie do sieci wewnętrznej - czyli w przypadku zabezpieczonej wep-em -złapanie wepa z powietrza + wysnifowanie MACów kart w przypadku zabezpieczenia ARP-em -- z tego co mi wiadomo ok 20h roboty przy duzym natężeniu ruchu wokół AP, potem dopiero próba włamania się na AP.

takie jest moje zdanie, ale chętnie przyjme inne propozycje.

Autor:  pablo2k5 [ wtorek, 27 grudnia 2005, 11:35 ]
Tytuł: 

Samego AP moim zdaniem jest bardziej narażony na zagrożenia z wnętrza sieci niż na zewnątrz. Po pierwsze wewnątrz sieci z AP łączysz się "czystym" protokołem http w którym przesyłasz loginy i hasła w postaci jawnego tekstu. Jesli jednak łączysz się z zewnątrz to komunikacja zarówno w tulenu jak i bezpośrednim połączeniu SSH jest jednakowo szysfrowana. Nie ma znaczenia czy na serwerze odpalisz linksa czy na zdalnym komputerze. Zarówno w jednym jak i drugim przypadku musisz przesłać informacje potrzebne do zalogowania się do AP (login i hasło). No chyba że potrafisz to zrobić telepatycznie ;). Zwykłą komunikację którą ty nawiązujesz przez ssh jest taka sama jak w tunelu (jeśli użyjesz tego samego sposobu szyfrowania w SSH). Tunele mają za zadanie "kapsułkować" w sobie protokoły niezabezpieczone np. jakim jest HTTP, POP3, SMTP i inne w bezpiecznym protokole SSH. Sam protokół SSH nie jest do końca bezpieczny gdyż coraz częściej słyszy się o np. przejęciach sesji itd. ale większość włamów dokonanych przez SSH wynika z przyczyny błędów popełnianych przez administratorów.
Pozdrawiam.

Autor:  muray [ wtorek, 27 grudnia 2005, 11:38 ]
Tytuł: 

skoro tak twierdzisz :)

w takim razie bede robil to twoim sposobem :) a jak ktos mi sie wlamnie to bede mowil a bo taki jeden z forum nnd mi tak powiedzial (nie zeby to byla moja wina :) )

Autor:  pablo2k5 [ wtorek, 27 grudnia 2005, 15:45 ]
Tytuł: 

No jeśli zostawisz ssh na 22 porcie i będziesz akceptował każdą zmianę klucza prywatnego na serwerze to ja umywam od takiego włamania ręce ;)
A tak na marginesie to już ponad rok używam tej metody komunikacji i narazie cisza, głośno zaczyna się robić jak SSH pracuje na standardowym porcie. Do tego jeśli masz na kompie z którego się łączysz do serwera stałe publiczne IP to dopuszczasz tylko jego na zaporze sieciowej, no i na koniec to jeszcze można pokombinować z opcjami hosts.allow i hosts.deny. No i jeszcze kwestia silnego szyfrowania. Nie warto używać protokołu SSHv1 tylko SSHv2, bo tamten już dawno złamany i niestety już mało skuteczny.
Pozdrawiam :)

Autor:  JOSH [ piątek, 17 lutego 2006, 00:51 ]
Tytuł: 

Pablo2k5 , dzięki serdeczne, już dałem punkcik :P
Ta metoda jest dosłownie zajebista.
Wszystko chodzi jak należy.

Strona 1 z 1 Strefa czasowa UTC+2godz.
Powered by phpBB® Forum Software © phpBB Group
https://www.phpbb.com/