Linux - SecurityThis forum is for all security related questions.
Questions, tips, system compromises, firewalls, etc. are all included here.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Distribution: CentOS, RHEL, Solaris 10, AIX, HP-UX
Posts: 731
Rep:
Hi,
same as your post about the "possible security issue in no script". You are telling us vague information without any background trying to begin a discussion on a useless base.
You better do not create such posts if you are not able or willing to provide detailled information on your subject.
The OP should add a link to the Google story mentioned. Network devices have MAC addresses. The ethernet protocol (level 2, e.g. switches) wouldn't work without it. The MAC address isn't included in IP (level 3, routers) traffic, the IP address is used instead.
The Google WiFi packet sniffing story has been covered by all the major news organizations. None of the "major news organizations" have mentioned the January patent application, but see the EFF website.
It would be helpful to provide links. This can be conveniently be done using the link button (globe with link of chain in front).
You don't appear to understand the nature of networks. Your mention of telnet and http access makes no sense as neither of them is encrypted, and all that means is that someone could intercept the username and password as you submit them. Most routers can be configured to only allow local network access, so no one outside in the wider internet can access them. Of courser you should change the default password, but the MAC address is essentially public information. And the google story basically relates to people who have left their wifi connections unsecured and unencrypted. How is that googles fault ? They are not being investigated for intercepting this communication, they are being investigated for storing the data that was collected. There are laws relating to data collection and storage to ensure the proper safe storage of private information. If your router doesn't allow you to encrypt your connection and change your access method (which I find hard to believe) then get a different one, or don't use WiFi !
You didn't mention street view or wireless in your original post. Juxtaposed with DSL routers, I assumed you were referring to wired DSL access.
One should never allow internet access to router management. Any wireless router worth it's salt will allow you to restrict the management interface to a wired connection on the switch ports. They will also allow restricting access to https. If your router doesn't, look at getting a new one.
An attack on the LAN side management interface of routers depends on allowing scripts to run in the web browser, and failure to change the default password. No script also has features protecting the router.
This makes no sense, you seem to be stringing a few independent things together (Google data collection during StreetView, DSL, and security).
As already mentioned HTTP and Telnet don't encrypt, so from a security standpoint they are pretty much equal, the only major difference being one is a GUI and the other a CLI. Most modern routers/modems will support HTTPS, and come setup with access from the internet facing side disabled. Now if there is a particular ISP decides to disable and change these setting by default that is a different matter.
The widespread Google issue has nothing to do with MAC addresses, it revolves around Google getting and storing information from unencrypted networks while doing mapping. This is most likely all older routers which shipped with any wireless encryption disabled, or had wireless encryption disabled manually by the user. Anybody who has any concern of security could easily encrypt wireless as even the cheapest OEM wireless router would support WEP. None of this is breaking news and hardly worth mentioning at this point with most every wireless router coming with some sort of secure by default settings.
How MAC addresses have anything to do with this is beyond me. As already mentioned they are basically public knowledge. A MAC address is just a unique identifier (half of which is just an identification of manufacturer) which can easily be found.
Care to backup your claim by posting a router model and/or ISP? All of your recent posts here are just making vague claims of potential security issues and a refusal to post any specifics/evidence in order to "protect" some party.
If we do choose to believe the claim of this ISP (who can't be named, and is the only ISP available) forcing you to use a router (which again can't be named) what is stopping you from putting something you feel provides acceptable security behind it? There is nothing stopping you from buying the most advanced firewall available and connecting it to your ISP router, and your network behind the better firewall. Then if someone wanted to attack/snoop/hack the ISP router they would get nothing.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.