Slashdot Mirror


The Enemy Within: Firewalls and Backdoors

hrbrmstr writes "SecurityFocus is running an article on firewalls and backdoors on their InFocus site. They provide info on firewall types, backdoor classifications, some examples of real backdoors and tips on mitigating their use on your network." Some good topics explained for the beginner, and it's a nice refresher for the veteran admin as well.

19 of 225 comments (clear)

  1. Stateful Packet Inspection recommended by steveha · · Score: 5, Interesting
    The article is worth reading, but there was one comment that made me go "Huh?!?"

    Stateful, multi-layer inspection firewalls
    [...]
    High level of cost, security and complexity

    Pretty much all of Netgear's home routers have stateful packet inspection features. Some of them are quite inexpensive (how about US$80 for a model that even includes a print server!).

    The great thing about stateful packet inspection is that you don't have to configure it. If you want to play some new game that does multiplayer play on the Internet through some wacky port, it will just work, and meanwhile if some random guy blasts packets at that port or any other they will bounce off. If you didn't ask for a packet, it gets turned away.

    (If you ever serve as tech support for a friend or family member, be sure they buy a firewall/router with stateful packet inspection!)

    Of course, that cuts both ways: any back-doors in your network will just work, also. Don't figure that just having a cool firewall/router with stateful packet inspection is a guarantee that you are secure. But it's a nice start, and it's what I recommend to anyone who has an always-on Internet connection.

    steveha
    --
    lf(1): it's like ls(1) but sorts filenames by extension, tersely
    1. Re:Stateful Packet Inspection recommended by vrt3 · · Score: 2, Interesting
      I think you missed
      • Layer 3 filtering
      • Layer 4 validation
      • Layer 5 inspection
      I'm pretty sure the Netgear routers you talk about only handle layer 3, like linux' netfilter/iptables does. The expensive part is handling layers 4 and 5.
      --
      This sig under construction. Please check back later.
    2. Re:Stateful Packet Inspection recommended by baka_boy · · Score: 3, Interesting

      This is a Windows problem only as long as Windows rules to corporate and desktop market; if there were, say, 30% market share of Linux machines out there to worry about, there would be much closer to 30% of a share of virii, worms, backdoors, etc. for that market. So long as Linux, FreeBSD, et. al. are fairly unusual systems to find inside the firewall, they will be (somewhat) less commonly-targeted systems for network attacks.

      It's an unpleasant side-effect of the "security does not come through obscurity" argument: since truly strong security is more or less impossible for fully-networked commodity workstations, the more popular an operating system or protocol server implementation is, the more likely it is to be hacked, cracked, and just generally abused.

      I've seen this even within the microcosm of Linux servers; the one time I tried to put a relatively well-firewalled (but not, unfortunately, religiously-patched) Red Hat server out on the net, it was hit with a rootkit within a week. Once that was replaced with an OpenBSD system ru awanning the same services, (albiet with a somewhat more recent version of OpenSSH) I was free to check back no more than once every few days to make sure that everything was in order.

      (Note: before anyone flames me for my sloppy sysadmin practices, please be aware of two facts: one, at the time, I was already working 40+ hours a week as a lowly coder, and was solely responsible for the design, development, deployment, and maintenance of the dynamic product support website whose server got cracked, and two, I've more than learned my lesson, and now know how to firewall, audit, and harden a system well enough to be back to the point of worrying about application, rather than network or OS-level, security. And, I no longer put anything running Red Hat anywhere near an open port and public IP address, unless I'm ready to wipe and reinstall at a moment's notice.)

  2. I like by pair-a-noyd · · Score: 5, Interesting

    Smoothwall GPL 2.0 Beta 4 (mallard)
    http://smoothwall.org/beta/

    I put three nics in a Pentium 90 that I found on a trash heap. One nic goes to my RR cable modem, one nic goes to my switch and one nic is for my son's Playstation 2.
    I can control every aspect of the firewall from any pc on the green nic. The firewall pc doesn't even have a keyboard or monitor.

    I can VPN through it with ease and I have port forwarding from an oddball port number to port 21 for a private FTP so that RR won't find it.

    It's really easy to use and so far I've had no problems.
    Of course ALL the machine inside of it are Linux boxes and all of them are using iptables (w/shorewall) so everything is really secure..

    For a super easy, very cheap and very fast firewall try floppyfirewall at http://zelow.no/floppyfw

    No worries here...

    1. Re:I like by Osty · · Score: 3, Interesting

      I put three nics in a Pentium 90 that I found on a trash heap. One nic goes to my RR cable modem, one nic goes to my switch and one nic is for my son's Playstation 2.

      What was your reasoning behind adding a NIC specifically for the PS2? It should work fine just connecting to your switch, and assuming you have DHCP running for your internal network it won't even require any setup for the PS2. Plus, you can get an XBox as well and plug that into the switch, and have both running at the same time.


      I'm sure you had a reason for that layout, I just can't figure out what it could be. Enlighten me?

    2. Re:I like by pair-a-noyd · · Score: 2, Interesting

      "So I'm also really curious as to why he chose this arrangement... if it's not the third reason, I hope he shares his reason with us, because undoubtedly I could learn from it."

      The PS2 did not like being behind a firewall. The game people say to open up huge blocks of ports to allow unsolicited incoming traffic. I don't like that concept.

      If I open up 1000 ports (ports 6,000 to 7,000) plus a handful of other ports, and the PS2 is on the same zone as my other machines, well you get the picture.

      I *THINK* that what was happening was that the PS2 would send data out through certain ports and when the other players would respond on those same ports, all was well. But I think the PS2 was LISTENING on other ports for incoming but unsolicited traffic. That traffic came in and hit the firewall, IP tables saw it as unsolicited and stopped it.

      I could rewrite the IPtables if I were smart enough but I'm rather new to Linux, I've been a Linux user less than a year.
      The EASY thing to do was to add a third nic that is just naked. It's unfiltered so all traffic that it needs gets through. So far it's worked well.

      I *DID* try opening a few holes in the firewall at first when he was plugged into the switch with the rest of the house but I just did not like that option. I ran a seperate wire from his PS2 to the third nic.

      His block of 192.168.2.xxx can NOT communicate with my block of 192.168.1.xxx nor can mine see his unless I open a pinhole in the orange, which would be pointless...

      I decided to use DHCP on my side and the 192.168.1.xxx scheme since it is the most common one in use, making it extremely handy when other people bring other pc's and devices over for repair or fun.

      On my son's side, the 192.168.2.xxx side I hardcoded the IP's because there is no DHCP served to the orange zone.. (Smoothwall people call the DMZ the orange zone)

  3. Re:The rule by lavalyn · · Score: 2, Interesting

    Only if "modern" meant "known."

    Assuming you have a default ALLOW policy. I'd find it hard to attack an MSSQL server behind a firewall that autodrops all traffic to 1433/1434(udp). (Why I'd want an MSSQL server is another matter.)

    It still doesn't stop attacks against kernel-level packet handling but it'll take down most unknown service-level attacks.

    --
    Doing the Right Thing should not be preempted by making a buck.
  4. SecurityFocus says no MacOS EVER exploited once! by Anonymous Coward · · Score: 3, Interesting

    Firewalls have NEVER been required to prevent remote exploitation on a Mac.

    I find it both sad and amusing that people try to publish studies about this topic without first addressing the fact that there are more secure platforms for webserving.

    It is a concrete fact that that no MacOS based webserver has ever been hacked into in the history of the internet.

    The MacOS running WebStar and other webservers as has never been exploited or defaced, and are are unbreakable based on ample historical evidence.

    In fact in the entire SecurityFocus (BugTraq) database history there has never been a Mac exploited over the internet remotely. Scan it yourself.

    For years, except, for the last week, the army has always used MacOS and has never had a breakin on a Mac. Unlike their other MS defacements.

    http://uptime.netcraft.com/up/graph?site=www.arm y. mil

    That is why the US Army gave up on MS IIS and got a Mac for a web server.

    I am not talking about FreeBSD derived MacOS X (which already had a more than a 30 explo its and potential exploits in BugTraq) I am talking about current Mac OS 9.x and earlier which are highly sophisticated abstract-OS models.

    Why is is hack proof? These reasons :

    1> No command shell. No shell means no way to hook or intercept the flow of control with many various shell oriented tricks found in Unix or NT. Apple uses an object model for procces to process communication that is heavily typed and "pipe-less"

    2> No Root user. All mac developers know their code is always running at root. Not hing is higher (except undocumented microkernel stufff where you pass Gary Davidians birthday into certain registers and make a special call). By always being root there is no false sense of security, and programming is done carefully.

    3> Pascal strings. ANSI C Strings are the number one way people exploit Linux and Wintel boxes. The mac avoids C strings historically in most of all of its OS. In fact even its roms originally used Pascal strings. As you know pascal strings are faster than C (because they have the length delimiter in the front and do not have to endlessly hunt for NULL), but the side effect is less buffer exploits. Individual 3rd party products may use C stings and bind to ANSI libraries, but many do not. In case you are not aware of what a "pascal string" is, it usually has no null byte terminator.

    4> Macs running Webstar have ability to only run CGI placed in correct directory location and correctly file "typed" (not mere file name extension). File types on Macs are not easily settable by users, expecially remotely. Apache as you know has had many problems in earlier years preventing wayward execution.

    5> Macs never run code ever merely based on how a file is named. ".exe" suffixes mean nothing! For example the file type is 4 characters of user-invisible attributes, along with many other invisible attributes, but these 4 bytes cannot be set by most tool oriented utilities that work with data files. For example file copy utilities preserve launchable file-types, but JPEG MPEG HTML TXT etc oriented tools are physically incapable by designof creating an executable file. The file type is not set to executable for hte hackers needs. In fact its even more secure than that. A mac cannot run a program unless it has TWO files. The second file is an invisible file associated with the data fork file and is called a resource fork. EVERY mac program has a resource fork file containing launch information. It needs to be present. Typically JPEG, HTML, MPEG, TXT, ZIP, C, etc are merely data files and lack resource fork files, and even if the y had them they would lack launch information. but the best part is that mac web programs and server tools do not create files with resource forks usually. TOTAL security.

    4> Stack return address positioned in s afer location than some intel OSes. Buffer exploits take advantage of loser programmers lack of string leng

  5. Routers by Zarxos · · Score: 5, Interesting

    Personally I don't see any use for software firewalls for the majority of home users. I have a Linksys router and it completely shields both of my computers from outside access unless I use port forwarding. This is much easier to configure and use than a software firewall, and if there is ever a port you need to open for whatever reason, just use port forwarding and it's done in 30 seconds.

  6. Re:Good info by Anonymous Coward · · Score: 1, Interesting

    I agree, this kind of information will certainly make some people want to attack a particular security hole. However, as already stated, security through obscurity doesn't work, so who cares?

    On another note, that kind of "Hey, a security hole! Let me try attacking it!" was exactly the key to what is today my carreer (no, a network security engineer, not a black hat you insensitive clod! ;-) 16 years ago. I got so "in" to cracking stuff that I was no longer interested in actually doing (juvenile) damage to a BBS or war dialing. I ended up asking for permission to do stuff, and next thing I knew I had a pretty cool job. I was making money doing what I had always done. There was no incentive to do damage, but there sure was incentive to find and prevent problems.

    Ah, those were the good days. Now I'm a project manager, and although the pay is pretty good, there just isn't that satisfaction in doing my job anymore.

  7. Re:The rule by Artifex · · Score: 4, Interesting
    Fireawlls are not the answer, really.. they mask problems. Firewalls should be the very last step in your security initiative.


    Yes and no. If you rely solely on firewalls, yes, because firewalls just contain damage and prevent it spreading. You definitely still have to take care of the weak security on the affected machine(s). However, if you think of security as an ongoing effort (i.e. no "last step"), you'll see that monitoring your firewall may give you much quicker notification of abnormal activity.

    Personally, I much prefer to be warned by port scans, etc., than to rely solely on hardening for protection from attacks. It's like having a fence around your house, with a gate in front, and having a burglar standing outside, rattling the front gate, yelling "hey, I'm about to try to break into your house!" He might get over the fence or through the gate, but you'd be awfully stupid, if you knew some burglers did that, not to at least have the wall and the gate.

    Carrying the metaphor a little too far, of course, it's a heck of a lot easier to track the guy down and "remove the threat," if you know he's going to try something, and where he is, before he does tries it.
    --
    Get off my launchpad!
  8. What about the end-to-end argument by Anonymous Coward · · Score: 1, Interesting
    There can never be complete security unless its implemented at the end, for instance that firewall is only as secure as it breaks your internet connection.

    A firewall program running on the PC is still not at the end, its between the application and internet.

    Just install some anti-virus PCcillin and suddenly your LAN shares are disabled and no-one can connect to your ftp server. I spent an hour figuring out why the hell things didnt work on a friends PC, i was about to ask him call his ISP tech support and check if their ADSL modem do some NAT or acts as a firewall.

    Pushing NAT solutions on customers is the standard these days it seems, charging a monthly-fee for every IP you need is also part of their business plan. Which system is of course optimized when it goes to administrative expenses so they get as much as possible (99.9% profit for every extra IP a sucker "borrows."

    And no, if the ISP cant document their expenses, they have no right to take a monthly fee according to ripe 152

  9. Re:The rule by Anonymous Coward · · Score: 1, Interesting

    Personally, I much prefer to be warned by port scans, etc., than to rely solely on hardening for protection from attacks. It's like having a fence around your house, with a gate in front, and having a burglar standing outside, rattling the front gate, yelling "hey, I'm about to try to break into your house!" He might get over the fence or through the gate, but you'd be awfully stupid, if you knew some burglers did that, not to at least have the wall and the gate.

    People scan for ports constantly. Do you really want to know about each and every scan? I get *WAY* too many scans to even care. Most companies don't care either.

    Carrying the metaphor a little too far, of course, it's a heck of a lot easier to track the guy down and "remove the threat," if you know he's going to try something, and where he is, before he does tries it.

    and what do you do if someone is spoofing the IP address? What if the person who is scanning you is a helpless victim of some ubercracker using their machine to conduct attacks?

    Having a firewall is more like having the club on your car. Would-be car theives can walk by it all day long, look in the windows, kick the tires, etc., but it is enough of a deterrent that most theives would rather pick the car next to yours which is totally unguarded.

  10. Default deny by MadFarmAnimalz · · Score: 2, Interesting

    They avoid immediate detection by well-configured firewalls, network & host IDS.

    Hmm, well, not necessarily. I am thinking this is why there is such a thing as a default-deny firewall ruleset policy.

    For example, you have a dns server and http server up and running on the standard ports, and anything else gets binned.

    I'd say that's a fine example of 20-year-old technology (firewalls) catching a backdoor.

    --
    Blearf. Blearf, I say.
  11. Something like Zonealarm for linux? by jopet · · Score: 2, Interesting

    I wonder if there is some simple software for linux that alerts me every time a program tries to connect to the internet (outbound) and that allows me to allow or deny those connections. It should also detect new versions of the program using MD5 key or similar. Does such a program exist?

    1. Re:Something like Zonealarm for linux? by c0dd3r5 · · Score: 2, Interesting

      It just so happens... as of about three days ago, my associates and I have been working on just such a program. It basically hooks into net/socket.c and, on receiving a socket request, blocks the requesting application until a userland daemon authorises it. The daemon automatically grants / denies requests to applications in its control list, and denies requests from unknown applications. We're about to starting working on the client which, when running, will receive information about the unknown app. and ask the user if said app. ought to be allowed to use the internet.
      Obviously at the minute it's still heavily alpha. The kernel patch works, and applications can be made to block or allowed to run. I don't know if this has been done before, but work is continuing apace (cause it's still interesting and we haven't hit a brick wall yet). I hope to have gotten something resembling a client working by this evening, but since we're pretty much messing around at this stage it'll probably be a couple of weeks before any files are available for download.
      As for authentification, MD5 summing was one of our thoughts, but it would be a little heavy to sum the application every time it requested a socket, so at the moment we're just basing it on inode / dev_no which, although not impossible to fake, seems like a good starting point.
      I'd be interested to know what people thought about this; whether any such applications already exist and what features it ought to incorperate. If it turns out people are interested, I'll try making the patches and source files available, but I can't recommend installing it into a kernel which you're actually trying to use - suggest UML or similar virtual machine.

  12. Re:SSH Tunnels by Rob+Riggs · · Score: 3, Interesting
    A more generic solution for getting around egress filtering is an SSH-based VPN.

    For even more pertinacious network environments, one can use httptunnel or the more advanced desproxy

    --
    the growth in cynicism and rebellion has not been without cause
  13. Transparent firewalls by nmg196 · · Score: 2, Interesting

    While it's on topic, I've always wondered how many people use transparent firewalls. I work for a small web development company in the UK and as such we have about 30 IP which host a few public facing webservers as well as our mail and stuff. We decided to use a transparent firewall (ie, one that lets us keep our 30 real IP addresses on the machines which are public facing - rather than 192.x or 10.x addresses) so that if there were any problems with it, we could just remove it (physically) and everything would still work. No network reconfiguration required.

    But it seems that it's quite uncommon for firewalls to even support this feature and even less common for people to actually use it in this mode. Is there a reason that more firewalls don't support this functionality, or are there good reasons not to configure your network like this?

    A major problem we would have if we used something like a Cisco PIX is that we wouldn't be able to see the websites we are hosting. The domain would map to a normal internet facing address, yet we can't see those addresses from the LAN (they don't seem to apply the port mapping to connections that have come from the LAN - so we'd need to look at them on their internal IP or something).

    How many people actually use transparent firewalls? Or how do you get round the problems above if you're a web hosting company and you don't have a transparent firewall? Do any decent firewalls (apart from Sonicwalls) actually support this?

    Nick...

  14. Bits go in. Bits go out. That's what networks do. by aphor · · Score: 3, Interesting

    The real problem here is that these Security Focus people are still trying to design a harder eggshell. Any "barrier" must allow some traffic through, or it will break the network. You cannot install a barrier that understands how to distinguish between good and bad traffic. It is not a closed problem. It is an open-ended problem. It isn't about computers or technology. Its about people and subversion. The answer is too difficult for most people: trust is arbitrary and inherenly flawed, but it is absolutely necessary for human interaction. The technology just fools us into thinking we can control things like a vending machine. The problem seems to be transparent because we can see lots of stuff on the inside of technological subversion, but at the bottom is void: trust is arbitrary and error prone.

    The real answer is that we must do what we are already doing, willingly, instead of reluctantly as we do now: accept subversion as a part of the system. We must understand that we created the space-time in which the subversion is manifest. It must be percieved as the limits of our power. Once that is understood, it is also understood how to coexist with limited power. This is the fundamental social problem: being with others. Consider that the subverion is another feeling person expressing their limited power outside the scope of our limited power. Take compassion on that person if they do not know the suffering they cause will come back to them. Do what you can, each as individuals, to absorb the effects of those bad effects so that they do not become causes of other bad effects.

    Recurse your awareness; avoid recursing your (or others') mistakes. Security does not exist. Only fools really believe in it.

    --
    --- Nothing clever here: move along now...