I would like thanks to all contributors of this interesting debate, for their effort.
L. > As with Rob, this is my final say as well. > On Fri, Sep 11, 2015 at 1:38 PM, Petr L?z?ovsk? <lazna at volny.cz>wrote: >> 1. Security through obscurity is your first mistake. There is no such thing. > > Interesting.... It does not exist, but it have article on wikipedia. Sounds > like UFO or Yetti... > "Security through Obscurity" in layman terms is that you provide no > additional valid information to whomever is accessing your system. If you're > URL provides CGI in its path, it points (Doesn't necessarily MEAN) more at > that it is a Linux box than a Windows box. That doesn't mean it isn't, just > that it is more likely to. Looking at HTTP headers, you can find out what OS > your script is running on, what version of PHP, ASP, .NET, whatever. Black > Hats typically keep a very long list of found security holes on every single > version of whatever script processor you're using. Obscurity means you're > just muddying the waters, or hiding facts, or acting like an outright liar. > It doesn't mean your system becomes locked down and people aren't going to be > interested ESPECIALLY if you're found to be on a fat pipe to the net. > Because Security through Obscurity is becoming more mainstream, I'm sure > these Black Hats don't even look at that and have techniques to just get what > they need done. > > >> 2. Assuming that nobody is writing CGI scripts on Windows Servers is your >> next mistake. A lot of systems still do this, a lot of old systems still >> use this technique and some new ones, The attack vector is not necessarily >> through your CGI script itself but through the Windows Web server. Unless >> you have patched and patched and patched your web server, you will be >> attacked. > > Of course I keep my web server software up-to-date, why do you think I do > not did it? I am talking here about my scripts, not about the server SW. But > the server SW is relatively rare too... > "Scripts" and the underlying script processors are what do the processing. > OS updates are one thing, but the script processing engine is another, and so > are the scripts you write. If any one of those three links in the chain are > broken, then buh-bye security. The script processor talks to the OS to get > things done, such as allocate memory, set aside a portion of drive space, > execute other code, etc. If you don't sanitize your inputs 100% of the time > properly, you're subject to losing a LOT of information or having your > machine taken over, or as Rob mentions, resources sold (A thought I hadn't > even thought about). The 'execute other code' should scare the bejezus out > of you. If your system is allowed to run other code (Say, for example, [ ls > -ltr /etc ] to get a directory list), if you don't sanitize your code, > someone can (Not might, CAN if you don't sanitize) change that to [ ls -ltr > /etc ; rm -rf /etc ] and if Apache has access to write anything there, you > have a new install of an OS to do. > The company I work for sells software for the web that runs off both IIS and > Apache under Linux. Both are scrutinized for security even though the main > portion of the software is behind a paywall (Need credentials to get into the > heart and main functions of the system) and all communications are via HTTPS. > All HTTPS does is ensure that no one else knows what you're saying on the > socket, essentially. It doesn't mean that the system isn't hackable. If we > didn't ensure that the login field on the login page wasn't sanitized, then > we're pretty much bending over. > > >> 3. You assume that nobody is interested in your machine. Wrong. A lot of >> people are very interested as they can add your hacked server to their >> bonnet and sell your resources on. Your machine does not have to be >> publicised at all. As an example, I have a private server which I use. It >> has no DNS entry (a common way to search for machines), so is only >> accessible through an IP address which has never been published. It only >> has a single ssh port open and port 80 for a private web server running >> some software there rest of the machine is locked down as best I can. The >> lock down took me a day to do. It is not trivial. My last weekly report >> showed over 200,000 attempts to break into the machine via ssh, http, and >> various CGI exploits. Thats 200,000 robot attempts, the most prevalent was >> an ssh attempt from a single machine which accounted for 72,000 goes. A >> public web server I have has over 1M hacking attempts per week. This is for >> a low usage machine. > > Script kiddies starting codes writen to attack widely spreaded systems, > otherwise it will be not much fun. Some of this codes could be specialized to > intrude minor systems, but I have doubts there are number of working scripts > to successfuly intrude systems with rare occurance. > > Real hackers, those who are experienced in writing WORKING code targeted to > intrude one specific rare system, need a REAL reason to did such job. My > system does not offer such reason.... > > "Real hackers" is funny. I've never met a fake one. > People DO want your machine, and it isn't for fun, but for profit and money, > which is a hell of a lot more motivational than fun. Your mentality is still > pointing at the script kiddy level, not at a high end serious money making > strategies which INVOLVES your computer(s). They don't care what your > computer has on it, what it is running, what your software does, or anything > of the sort. They just want onto your machine to make it do their bidding, > and if you don't ONLY secure the box with updates, and validate that your > code can't be tricked into doing something it shouldn't be doing, then you > might as well just hand the keys over to the black hats. > >> I give your machine less than 24 hours once it is live on the internet if >> you put it on without taking security seriously. You need to get the OS >> patched up, the ports closed down, the web server patched up and correctly >> configured. Out of the box the security on a Windows server (depending on >> the version) is poor. You need to learn what you need to do (and there are >> loads of guides on the internet) otherwise your server will be owned by >> somebody else very quickly. > > As I already wrote, not using IIS. OS is protected by manualy configured > firewall. By concept Security through obscurity using this one > http://wipfw.sourceforge.net/ Intruding script perform OS detection first, > but do not expect BSD firewall on Windows... Simple as it. Did you > understand STO concept now? > A firewall isn't going to save your hide. A firewall is a bunch of holes to > let information flow through to different machines. It is a single point in > which one more more computers are exposed to the net. Firewalls have the > ability to sniff out what inbound traffic is doing and validate if what the > inbound communication is doing is not an attempt to break the TCP/UDP > packaging system, or not allow Torrent traffic, or decide the actions on > whatever different type of communication protocols are out there, but it > ABSOLUTELY WILL NOT protect you against unsanitized code. > What people expect versus what people are going to do are two completely > different things. They may not expect that you're running a BSD firewall on > windows, but then, why would they care? They already know you're running a > web server, so they'll run their suite of tools against it to find those > exploits. > You need to get it through your head that money is the driving force Black > Hats work for. If they have access to ONE of your computers, they may be > able to gain access to more. If they have access to more, they'll turn > whatever they have access to into a cluster. These guys DO-NOT-CARE what > you're running, just that the resources exist and that they want to exploit > it.
