Slashdot Mirror
Enhanced WiFi Security Patch For FreeBSD
Dan writes "Roland van Laar has a new, significant wi-fi patch for FreeBSD 5.1 and higher. The patch, available for download and testing, blocks clients with an empty or 'ANY' ssid and disables ssid broadcasting using the underlying firmware feature. SSID (Service Set ID) is used to identify wireless clients to a wireless / wired gateway. Wireless devices from the same manufacturer generally ship with the same default SSID. A beacon is a type of packet/frame that contains the SSID of a network. It is used to sync clocks on client devices and to make it easy for new network clients to see what networks are available. Preventing others from using your ssid is a means (although not foolproof!) of securing your wireless network."
I suppose it's good news that there are people who do care about Wifi security.
However, I'm wondering: how much security does SSID-based blocking add (could individuals forge SSIDs, or would they have to be organizations with cash and determination?)? Shouldn't all connections on a wireless network use a strong encoding (SSH or such)?
How do real people provide and use services that are normally insecure (NFS comes to mind) over Wifi?
This is a great addition nontheless. If you can hide your SID then some warfaring punk can't find you easy. But then again you probably are using WEP or WPA or whatever the encyrption of the week is, so that is a nonissue. Now, I would be impressed if more wireless cards were supported. I am getting sick and tired of using my windows machine to down load my FreeBSD software toys.
The views expressed are mine own and do not express the views of my employer.
I'll have to give this a try. While it does not make WiFi secure, it is a small step to making it a bit more secure. At least this way, if I'm not using my wireless network (which is most of the time), it's not broadcasting SSID's for people to sniff.
On a side note, it's a real shame that a useful article has garnered mostly trolls and flamebait as responses. Sigh...
Back in the day, around FreeBSD 2.2.8, it was a very nice operating system. However, when RELENG_5 was branched, a lot of wrong decisions were made, most of them by people with zero clue about how to implement proper SMP (e.g. John Baldwin). Matt Dillon tried to fix the situation, but all he got in response was a commit bit suspension, which later lead to his expulsion.
You can thank assholes like: Poul-Henning Kamp (POT, KETTLE, BLACK), Greg Lehey, Dag-Erling Smorgrav, Mark Murray and Bill Fumerola for kicking him out and making sure that, thanks to overengineering, RELENG_5 will never work.
Further proof, FreeBSD recently went 100% dynamic to allow the use of NSS switch system. John Dyson, who did most of the VM work back in the day, pointed out how wrong this decision was. Dillon also jumped in and offered a better solution. What he got as reward was Scott Long telling him to go away. Listen Scott, YOU ARE A FUCKING IDIOT. Not only you don't even know how to quote, but you also managed to fuck the 5.1-R isos twice. I wonder how can you be in re@, that sure has lead to the piss-poor quality of the last 2 or 3 releases.
FreeBSD 5.2 is currently in the RC phase, but it has a very important showstopper that needs to be ironed out before it's released. Activating softupdates during install is a sure way to kernel panic. RELENG_5 is doomed, and will never work. Install DragonFlyBSD while you can.
Joseph Mallett, an ex-committer.
17285Back in the day, around FreeBSD 2.2.8, it was a very nice operating system. However, when RELENG_5 was branched, a lot of wrong decisions were made, most of them by people with zero clue about how to implement proper SMP (e.g. John Baldwin). Matt Dillon tried to fix the situation, but all he got in response was a commit bit suspension, which later lead to his expulsion.
You can thank assholes like: Poul-Henning Kamp (POT, KETTLE, BLACK), Greg Lehey, Dag-Erling Smorgrav, Mark Murray and Bill Fumerola for kicking him out and making sure that, thanks to overengineering, RELENG_5 will never work.
Further proof, FreeBSD recently went 100% dynamic to allow the use of NSS switch system. John Dyson, who did most of the VM work back in the day, pointed out how wrong this decision was. Dillon also jumped in and offered a better solution. What he got as reward was Scott Long telling him to go away. Listen Scott, YOU ARE A FUCKING IDIOT. Not only you don't even know how to quote, but you also managed to fuck the 5.1-R isos twice. I wonder how can you be in re@, that sure has lead to the piss-poor quality of the last 2 or 3 releases.
FreeBSD 5.2 is currently in the RC phase, but it has a very important showstopper that needs to be ironed out before it's released. Activating softupdates during install is a sure way to kernel panic. RELENG_5 is doomed, and will never work. Install DragonFlyBSD while you can.
Joseph Mallett, an ex-committer.
9445Back in the day, around FreeBSD 2.2.8, it was a very nice operating system. However, when RELENG_5 was branched, a lot of wrong decisions were made, most of them by people with zero clue about how to implement proper SMP (e.g. John Baldwin). Matt Dillon tried to fix the situation, but all he got in response was a commit bit suspension, which later lead to his expulsion.
You can thank assholes like: Poul-Henning Kamp (POT, KETTLE, BLACK), Greg Lehey, Dag-Erling Smorgrav, Mark Murray and Bill Fumerola for kicking him out and making sure that, thanks to overengineering, RELENG_5 will never work.
Further proof, FreeBSD recently went 100% dynamic to allow the use of NSS switch system. John Dyson, who did most of the VM work back in the day, pointed out how wrong this decision was. Dillon also jumped in and offered a better solution. What he got as reward was Scott Long telling him to go away. Listen Scott, YOU ARE A FUCKING IDIOT. Not only you don't even know how to quote, but you also managed to fuck the 5.1-R isos twice. I wonder how can you be in re@, that sure has lead to the piss-poor quality of the last 2 or 3 releases.
FreeBSD 5.2 is currently in the RC phase, but it has a very important showstopper that needs to be ironed out before it's released. Activating softupdates during install is a sure way to kernel panic. RELENG_5 is doomed, and will never work. Install DragonFlyBSD while you can.
Joseph Mallett, an ex-committer.
7913I've been an avid follower of the developments in FreeBSD for around 5 years now, so my overview of the entire history of "glue that binds" FreeBSD together isn't complete. That said, I've come to be a bit disappointed at how events in the last 18 months or so seem to be pushing the project in a direction that has made things more difficult, instead of more successful, that has shown distain for experience and quality and made FreeBSD a platform for large ego's to push their personal projects down everyone's throat.
The statistics sample from 2001 over a year was a cheap attempt to minimize Matt's contribution to the project. The reason why he has been mostly silent is probably one of the most prominent signs of his superior maturity. The fact that the official defense (mostly fronted by Greg, atm) he wasn't such a substantial committer is crap, for the most part. If one wanted to go by the stats, Jeff Robertson (sorry if I munged the spelling) would be one of the key committers, and his UMA system isn't even entirely ripe yet, it's just been committed within the sample timeframe. That suddenly phk is at the top of the list, is simple a result of his newest attempt to add another large chunk of bit rot to the project that he can later claim not to have time to maintain "unless someone is willing to pay for my time" (like the atm bits, the half-finished devd monster, et.al.) One can hardly get him to look at his malloc bits, that put his name in lights at some point in the long past.
Matt didn't contribute because he was convinced that that the smp development direction that was chosen (my impression at least from the archives and my fading memory) was overly complex, too complex for the number and talent level of the contributers involved, and that it would delay a release from the -current branch significantly. So he was right. I'll almost bet that that was a constant sore for John, who still hasn't gotten his long-promised, but little delivered re-entrant work done, but he always had time enough to object to any other commits that might help along the way. Strangely Julian and Matt could work together. One might attribute certain commits to both Matt and Julian (if that would matter anyway, since -core is interested in proving the opposite statistically).
If the issue here had anything to do with IPFW, then you all better get out your C-coder hats and take a little more time to fix that rotting pile of muck that has been the standard broken packet filter interface for FreeBSD long past its possible usefulness. A packet filter with no central maintainer which is subject to once yearly random feature bloat through some wild university project from Luigi. The brokenness that Luigi introduced (and the repository bloat through backing out and recommitting, ad absurdum) was probably no less a threat to security than anything Matt did. If the security officer was to be blatantly honest with himself, ipfw would be marked broken for either a full audit or full removal (just port obsd's pf or something that someone actually actively _cares_ about).
You've alienated Jordan, Mike, Bill Paul (for all I can see), Greenman, you constantly rag on Terry, even though he's seen and done more with FreeBSD than most of you, O'Brien is on the verge of quitting (since he, like I, am not convinced that GEOM is anything more than an ego trip that will never be completely maintained or usefully documented). There are certainly others, too, that have attempted to make technically correct contributions, but didn't fit into the sort of paranoid "glee club" that core would like to have around them. You guys lack the talent to steer the positive from Matt into the project and let the crap fall by the wayside. I'm not saying Matt's rants are the most intelligent thing he's done, but he's sat by the wayside and watch the superstars beat up the code to a point where it's less stable, slower, and more bloated than it ever was. I, for one, can understand his frustration (as I can with Mike's, Jordan's, and a few o
I've been an avid follower of the developments in FreeBSD for around 5 years now, so my overview of the entire history of "glue that binds" FreeBSD together isn't complete. That said, I've come to be a bit disappointed at how events in the last 18 months or so seem to be pushing the project in a direction that has made things more difficult, instead of more successful, that has shown distain for experience and quality and made FreeBSD a platform for large ego's to push their personal projects down everyone's throat.
The statistics sample from 2001 over a year was a cheap attempt to minimize Matt's contribution to the project. The reason why he has been mostly silent is probably one of the most prominent signs of his superior maturity. The fact that the official defense (mostly fronted by Greg, atm) he wasn't such a substantial committer is crap, for the most part. If one wanted to go by the stats, Jeff Robertson (sorry if I munged the spelling) would be one of the key committers, and his UMA system isn't even entirely ripe yet, it's just been committed within the sample timeframe. That suddenly phk is at the top of the list, is simple a result of his newest attempt to add another large chunk of bit rot to the project that he can later claim not to have time to maintain "unless someone is willing to pay for my time" (like the atm bits, the half-finished devd monster, et.al.) One can hardly get him to look at his malloc bits, that put his name in lights at some point in the long past.
Matt didn't contribute because he was convinced that that the smp development direction that was chosen (my impression at least from the archives and my fading memory) was overly complex, too complex for the number and talent level of the contributers involved, and that it would delay a release from the -current branch significantly. So he was right. I'll almost bet that that was a constant sore for John, who still hasn't gotten his long-promised, but little delivered re-entrant work done, but he always had time enough to object to any other commits that might help along the way. Strangely Julian and Matt could work together. One might attribute certain commits to both Matt and Julian (if that would matter anyway, since -core is interested in proving the opposite statistically).
If the issue here had anything to do with IPFW, then you all better get out your C-coder hats and take a little more time to fix that rotting pile of muck that has been the standard broken packet filter interface for FreeBSD long past its possible usefulness. A packet filter with no central maintainer which is subject to once yearly random feature bloat through some wild university project from Luigi. The brokenness that Luigi introduced (and the repository bloat through backing out and recommitting, ad absurdum) was probably no less a threat to security than anything Matt did. If the security officer was to be blatantly honest with himself, ipfw would be marked broken for either a full audit or full removal (just port obsd's pf or something that someone actually actively _cares_ about).
You've alienated Jordan, Mike, Bill Paul (for all I can see), Greenman, you constantly rag on Terry, even though he's seen and done more with FreeBSD than most of you, O'Brien is on the verge of quitting (since he, like I, am not convinced that GEOM is anything more than an ego trip that will never be completely maintained or usefully documented). There are certainly others, too, that have attempted to make technically correct contributions, but didn't fit into the sort of paranoid "glee club" that core would like to have around them. You guys lack the talent to steer the positive from Matt into the project and let the crap fall by the wayside. I'm not saying Matt's rants are the most intelligent thing he's done, but he's sat by the wayside and watch the superstars beat up the code to a point where it's less stable, slower, and more bloated than it ever was. I, for one, can understand his frustration (as I can with Mike's, Jordan's, and a few o
I've been an avid follower of the developments in FreeBSD for around 5 years now, so my overview of the entire history of "glue that binds" FreeBSD together isn't complete. That said, I've come to be a bit disappointed at how events in the last 18 months or so seem to be pushing the project in a direction that has made things more difficult, instead of more successful, that has shown distain for experience and quality and made FreeBSD a platform for large ego's to push their personal projects down everyone's throat.
The statistics sample from 2001 over a year was a cheap attempt to minimize Matt's contribution to the project. The reason why he has been mostly silent is probably one of the most prominent signs of his superior maturity. The fact that the official defense (mostly fronted by Greg, atm) he wasn't such a substantial committer is crap, for the most part. If one wanted to go by the stats, Jeff Robertson (sorry if I munged the spelling) would be one of the key committers, and his UMA system isn't even entirely ripe yet, it's just been committed within the sample timeframe. That suddenly phk is at the top of the list, is simple a result of his newest attempt to add another large chunk of bit rot to the project that he can later claim not to have time to maintain "unless someone is willing to pay for my time" (like the atm bits, the half-finished devd monster, et.al.) One can hardly get him to look at his malloc bits, that put his name in lights at some point in the long past.
Matt didn't contribute because he was convinced that that the smp development direction that was chosen (my impression at least from the archives and my fading memory) was overly complex, too complex for the number and talent level of the contributers involved, and that it would delay a release from the -current branch significantly. So he was right. I'll almost bet that that was a constant sore for John, who still hasn't gotten his long-promised, but little delivered re-entrant work done, but he always had time enough to object to any other commits that might help along the way. Strangely Julian and Matt could work together. One might attribute certain commits to both Matt and Julian (if that would matter anyway, since -core is interested in proving the opposite statistically).
If the issue here had anything to do with IPFW, then you all better get out your C-coder hats and take a little more time to fix that rotting pile of muck that has been the standard broken packet filter interface for FreeBSD long past its possible usefulness. A packet filter with no central maintainer which is subject to once yearly random feature bloat through some wild university project from Luigi. The brokenness that Luigi introduced (and the repository bloat through backing out and recommitting, ad absurdum) was probably no less a threat to security than anything Matt did. If the security officer was to be blatantly honest with himself, ipfw would be marked broken for either a full audit or full removal (just port obsd's pf or something that someone actually actively _cares_ about).
You've alienated Jordan, Mike, Bill Paul (for all I can see), Greenman, you constantly rag on Terry, even though he's seen and done more with FreeBSD than most of you, O'Brien is on the verge of quitting (since he, like I, am not convinced that GEOM is anything more than an ego trip that will never be completely maintained or usefully documented). There are certainly others, too, that have attempted to make technically correct contributions, but didn't fit into the sort of paranoid "glee club" that core would like to have around them. You guys lack the talent to steer the positive from Matt into the project and let the crap fall by the wayside. I'm not saying Matt's rants are the most intelligent thing he's done, but he's sat by the wayside and watch the superstars beat up the code to a point where it's less stable, slower, and more bloated than it ever was. I, for one, can understand his frustration (as I can with Mike's, Jordan's, and a few o
Robust anonymous P2P across a mobile/fixed wireless mesh networks are the future of the net and the old net can connect or die. Intel has hyped this new trend as bigger than the net, they also claim the can put they will put an xbox in a PDA. Given a little bit of time the telcos and the RIAA will die the same obsolete death. At the end of Q2 next year every new PC will ship with WiMax on board and this will do it.
I remember reading the remarks of someone is dismay over discovering that search engines were being used for info searches and not to locate websites. Of course, the Internet was alive and well before all this extraneous marketing fluff. Its number one application is not business or how much money can be made, in fact a key application may be ridding the public of may organizations that were not in its interest. The next net is bigger and it will not involve telco sponsored back bones and all that stuff. The net belongs to the public- sort of an immenient domain arguement but it is defacto.
The day will come when people buy that mainframe node in a pda, and there won't be room along the way for greedy snooping relics.
The issue is that througout the city we have omni antenna's - where -anyone- can associate with - and directional antennas which provide the interlinks between nodes (although the network covers a medium sized city - we use no copper; all interlinks are wireless).
On these interlinks we only want node-to-node traffic.
As the network is totally open (no username, password or any thing) - we have no easy way to educate our users to use the right 'omni' antenna's, other than descriptive names. I.e. we do not catch them early enough.
So often people associate with the interlinks rather than the omni (if a beam passes over their house) - and then complain, or are surprized, that DHCP does not give them an address.
This problem is made worse by some windows userinterface tools which will automatically re-select networks based on some internal metric.
So what we wanted was to 'hide' the interlinks. So that clueless users are not accidentally ensnared. Rolands patch does exactly this.
Dw
I love FreeBSD, but I have a question. When on earth is anyone going to recognize the fact that there is a serious problem with the wi driver for dwl650 pcmcia cards? So many of us have them and yet the current driver for it, after a small amount of usage causes a full system lock up. Anyone have any info on that? I'd like to see the drivers for widely used software perfected before setting up default security for those who don't know how to on their access points.
The question beg's to be asked, shouldn't someone capable of installing and using FreeBSD be knowledgeable enough to secure their wifi ap?
./revolution
Access points broadcast beacon frames, which contain some information about the AP, including the name (SSID). If there are multiple APs in range, the SSID helps you identify and select the right one.
Now, what the patch does is hide the SSID in the beacon frames, and blocks clients with SSID "ANY". This prevents clients from automatically associating with the AP with best signal quality.
Hiding the SSID doesn't help a lot, because advanced wardriving tools like Kismet will still pick up the network. It keeps script kiddies out though, Netstumbler (Windows wardriver) won't see the AP.