Become a fan of Slashdot on Facebook

 


Forgot your password?
Close
typodupeerror
×
Security

The Enemy Within: Firewalls and Backdoors 225

Posted by CowboyNeal from the securing-the-perimeter dept.
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.
This discussion has been archived. No new comments can be posted.

The Enemy Within: Firewalls and Backdoors More

The Enemy Within: Firewalls and Backdoors

Comments Filter:

  • Good info (Score:4, Insightful)

    by rekkanoryo ( 676146 ) <rekkanoryo AT rekkanoryo DOT org> on Friday June 13, 2003 @12:14AM (#6188181) Homepage
    I had a basic idea of a lot of stuff here an some knowledge of some things, too. This was a nice crash-course.

    Kinda makes me wonder, though, how often articles like this spawn ideas in the minds of the "wrong people," leading to attacks or attempts to attack. Anyone else ever wonder that?

  • The rule (Score:4, Insightful)

    by Faust7 ( 314817 ) on Friday June 13, 2003 @12:14AM (#6188183) Homepage
    Can your multiple-lines of defense truly protect your network from modern methods of intrusion?

    Only if "modern" meant "known." Everything else is fair game.

    • Re:The rule (Score:3, Interesting)

      by lavalyn ( 649886 )
      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.
      • Every ALLOW policy must be paired with an associated DENY policy...else your 'policy' is not one of coherent-level intent.

      • Re:The rule (Score:3, Insightful)

        by realdpk ( 116490 )
        I'm going to assume that you allow access to 1433/1434 from at least *some* hosts.

        So, you just have to hack those hosts, and then you're in.

        Fireawlls are not the answer, really.. they mask problems. Firewalls should be the very last step in your security initiative.

        Of course, I'll get replies to this about how this is just how it is done - well, too bad - it's not the best way to go and if you don't know it, you should. :)

        • Re:The rule (Score:5, Interesting)

          by Artifex ( 18308 ) on Friday June 13, 2003 @01:52AM (#6188504) Journal
          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.
          • If you really have time to follow up port scans, you should get a life. Even at our small /29 net, we receive roughly 4000 scan attempts on a quiet day. 1000 of them seems to be connected to immediate probing of known vulnerabilities. (I don't know exactly because we don't take the time to look on them closely.) Almost all of them come from dial-up IP numbers of large ISPs.

            I much prefer to find a balance between necessary security precautions (e.g., keeping automatically up to date with patches) and going

    • Not exactly. Pretty much every method of intrusion is "known". I mean pretty much every modern [and likely 99% of 'new' attacks in the next 2 years] attack is of a known type. A buffer overflow is a buffer overflow is a buffer overflow, just different buffers.

      If your multiple lines of defense are just string checking, yeah it's not going to be secure for new attacks. If the defense is against the type rather than the specific attack, you are much better off because the type is 'known' even if the attack is

  • layers (Score:4, Informative)

    by smettler ( 41331 ) on Friday June 13, 2003 @12:19AM (#6188194)
    I wonder which layer model (iso, dod, other?) they took. Looks like iso/osi to me and if that's the case

    >Packet filters [1]
    > * Operates at Layer 3
    > * Also known as Port-based firewalls
    > * Each packet is compared to against a list of rules (source/destination address, source/destination port, protocol)

    based on tcp/udp port numbers? that would be layer 4, right? Imho Layer 3 applies to ip-address only.

    >Application-level gateways [2]
    >
    > * Operates at Layer 5
    > * Application-specific
    > * Example: Web (http) proxy

    I thought the application layer is layer 7?

    someone?

    cheers
    Sascha

    • Re:layers (Score:3, Insightful)

      by rekkanoryo ( 676146 )
      You're right. OSI Layer 3 does not deal with port numbers. The Application Layer is the OSI model's Layer 7. Looks like someone forgot his/her coffee when writing the article, like I did reading it.
    • The application layer is layer 7 but application layer and an application-level gateway are two seperate things.

      Protocols such as HTTP and FTP usually start at the session layer (layer 5) which is what application-level gateways are working on. For you to manipulate sessions transparently you need to hijack the connection at the session layer otherwise you'd need special support for proxy servers.

      That said, many applications usually include support for proxy servers anyway since transparent proxies are no

  • Eep! (Score:2, Funny)

    by Faust7 ( 314817 )
    telnet some.insecure.host.org 1234

    Crap, how'd they find m--I mean, that poor sucker.

    • Re:Eep! (Score:2, Funny)

      by AndroidCat ( 229562 )
      You mean some.insecure.host.org at 216.74.108.110? I hope that it's like example.com, and meant to be used like this. (Hmm, FTP server running there. :^)

  • Stateful Packet Inspection recommended (Score:5, Interesting)

    by steveha ( 103154 ) on Friday June 13, 2003 @12:34AM (#6188246) Homepage
    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 [netgear.com] have stateful packet inspection features. Some of them are quite inexpensive (how about US$80 [buy.com] 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

    • Re:Stateful Packet Inspection recommended (Score:4, Informative)

      by brett42 ( 79648 ) on Friday June 13, 2003 @12:55AM (#6188332)
      I spent two years in a highschool cisco class, and in the 2 months before we started playing quake, I learned about network models. Basically, network operations can be divided into multiple layers, with each performing different functions. The layout of these devices seems to be based on one of these models, though I don't remember which. The stateful packet inspection you refer to would probably be part of the first device mentioned in the article, packet filters, which just operate on the network layer, not the other two.

      Of course, somewhat intellegent packet filtering at the router beats the hell out of those "home firewall" programs that make pop ups every time you run a new program.
      • I spent two years in a highschool cisco class, and in the 2 months before we started playing quake, I learned about network models. Basically, network operations can be divided into multiple layers, with each performing different functions. The layout of these devices seems to be based on one of these models, though I don't remember which. The stateful packet inspection you refer to would probably be part of the first device mentioned in the article, packet filters, which just operate on the network layer,

    • Re:Stateful Packet Inspection recommended (Score:5, Informative)

      by AlCoHoLiC ( 67938 ) on Friday June 13, 2003 @01:08AM (#6188374)
      Allowing ALL ougoing and RELATED incoming traffic is hardly secure setup. Every fscking worm/backdoor is allowed to call home, replicate itself or even participate in DDOS network. I also doubt that netgear cares about actual packet payload (layers 4-7). I guess that they're using dynamic packet filter.

      • "Every fscking worm/backdoor is allowed to call home"

        Simple. Don't use Windows.. That's a Windows problem.
        I quit using Windows in August of 2002 and have not had a single worm, virus, trojan, backdoor, hack, sneeze, fart, or burp since..
        • 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.)

          • Re:Stateful Packet Inspection recommended (Score:5, Insightful)

            by MeNeXT ( 200840 ) on Friday June 13, 2003 @09:44AM (#6190198)
            I have moderator points and I'm about to post go figure...


            This has nothing to do with thechnology but more to do with attitude, policy and productivity.



            You see in most trades/proffessions you need to learn how a tool works before you are eveluated on the tool. After that you need to apply the tool to the trade, which means you need to understand the workings of the trade. This takes years.


            Now, with computers, we have business that are trying to fit the trade to their tools. When that does not work and they encounter problems, they hire someone who knows one tool. They then try to force the tool into the business.


            This will never work! You cannot make a general tool to fit every need and at the same time make this tool easy to use. A good example that I can bring up is for MS Word users. Placing graphics in word does not make word a publishing software. All it has done is waste your time and the other person who is to open the document. Word is made for typing letters when we use it for other things it becomes complex. IT DOES A POOR JOB and it costs you more time and money than buiying the right tool or asking someone who is in the trade.



            Now before buying any software you need to identify what your needs are. Do you need to access files from home? Better yet why are you taking work home? How manyhours do you propose to work? If you wish to spend more time with your familly then mabye you should look at sleeping less because sitting in front of your computer is NOT familly time. In most cases this an ego issue (Look I can PISS farther than you!) an not a technologie issue.


            If Linux can only STOP trying to be Windows then the virus issue will stay with Windows. We have seen on the server side that Linux has not followed in the Windows steps.


            One last question why do you first start talking about the desktop and then give a server example?

        • hmm, that's FUD (Score:3, Insightful)

          by DrSkwid ( 118965 )
          1. how do you know?
          2. your computer != all non windows setups
          3. 10 Months is not a long time
          4. Robert Morris

          • I have 7 PC's here at home, all of them are Linux.
            I have ONE laptop from work that has Windows on it. I only fire it up when I *HAVE NO CHOICE*....

            I *USED* to be 100% Windows here, at home and work. I work on Windows computers for people, professionally. I'm IT..

            It's not FUD, it's FACT.. I know it from experiance.
            I've worked on computers for a living since 1981 and "played with them" since 1978. I didn't just fall off of the turnip truck...

            • big deal (Score:3, Insightful)

              by DrSkwid ( 118965 )
              because if you'd actually learned anything in the same 20 years that I've been working in IT it is that there is no "magic platform" that's invulnerable to sloppy coding be it windows, linux, AIX, plan9, OpenBSD or whatever.

              Go read Security Focus [securityfocus.com] and count the number of "Design Errors"

              Here's one from today's front page :

              Linux Kernel Privileged Process Hijacking Vulnerability **

              > I have 7 PC's here at home, all of them are Linux.

              Your cock waving has no effect I'm afraid.

              > It's not FUD, it's FACT.

      • This is a ridiculous argument. Any worm worth two cents is just going to communicate out using port 80, and if the author is really clever it will do it by opening http pages using Internet Explorer so the traffic doesn't look different, and not even local application level firewalls or authenticated proxies can stop it.

        Blocking outgoing traffic does nothing for security, and tons to block legitimate applications and the true power of the Internet (as opposed to the Web).
        • Blocking outgoing traffic helps prevent the "meat" layer from being a problem, where users do stuff that cause problems on the network or with their computers.

          For example, routing MS Gaming Zone to 127.0.0.1 via internal DNS did wonders for productivity around here. The same is true for any of the other 100% timewaster sites, Gator, porn, Yahoo, etc.

          Sure a few people will figure it out, but those are on my staff. :)
    • 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.

    • 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

      You're very confused. This behaviour is absolutely nothing to do with stateful packet inspection. *ALL* routers will behave like this if you enable routing of all outbound traffic - even really cheap and simple NAT firewalls (not really even a firewall). Allowing all outbound traffic means that any tr

      • You're very confused. This behaviour is absolutely nothing to do with stateful packet inspection. *ALL* routers will behave like this if you enable routing of all outbound traffic

        The last time I looked at a cheap firewall/router that did not have stateful packet inspection, I seem to recall that it had most ports closed. That if you wanted to run some wacky program on some wacky port (your new game, for instance) that you would have to fire up the web browser, go to the admin form, and open the port. A
        • OK, I probably didn't explain myself very well: A simple NAT firewall, such as that built into Windows XP and quite a few routers, will allow all outbound traffic by default. From the outside however, all ports that don't have an outbound connection will appear to be closed (as opposed to open, or non existant/stealth). "Closed" meaning that the computer actively sent back a packet saying that it doesn't accept connections on that port. Meanwhile, you can happily run games/P2P/ICQ etc without noticing that
    • I think that you're still talking about a simple port filter. A stateful multi-layer protection would provide that sort of protection, but it would also want to know about your game. It might even know the protocol well enough to recognize a Packet Of Death and know to not allow it through the firewall.

      It could also be configured to only allow game playing by certain characters, at certain times of the day (even if it does use port 80) and/or require you to provide extra authentication to go out.

      For S

  • I like (Score:5, Interesting)

    by pair-a-noyd ( 594371 ) on Friday June 13, 2003 @12:36AM (#6188258)
    Smoothwall GPL 2.0 Beta 4 (mallard)
    http://smoothwall.org/beta/ [smoothwall.org]

    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 [zelow.no]

    No worries here...

    • Re:I like (Score:3, Interesting)

      by Osty ( 16825 )

      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 s

      • Re:I like (Score:5, Informative)

        by pair-a-noyd ( 594371 ) on Friday June 13, 2003 @02:03AM (#6188532)
        Several of the games did not like the firewall. There was *some* connectivity but not total cooperation between the PS2 and the firewall.

        Several of the games want huge chunks of ports opened up. Uh uh. Not gonna do that. So I added the third nic as a DMZ (smoothwall calls it "Orange Zone") so that the PS2 has unhindered access to the web.

        There are three nics,
        red=nic to modem (dhcp)
        orange= nic to PS2 - 192.168.2.1
        green=nic to my lan - 192.168.1.1

        The red zone is the nic that goes to the cable modem, it gets it's IP from RR's DHCP.

        The orange zone nic is hard coded to 192.168.2.1 (by me) and the PS2 is 192.168.2.2 There are no port restrictions on it, it's raw and naked on the net, as it wants to be..
        Since it's a PS2 it doesn't matter.

        Smoothwall provides DHCP for the green zone so whatever I plug in to it works. Nice. People bring me PC's all the time to work on.

        Another nice thing smoothwall does is take care of dynamic DNS for me, I have a freebee domain from dyndns.org so I can FTP to a private box on my lan from remote sites (while working) and I have accounts setup for my friends so they can ftp in too.

        I hard coded one of my boxes to a specific IP then port forward from port XXXX to port 21 at my internal IP of 192.168.1.205. Only my friends and I know it's there and can access it. Very handy.

        Veyr often I get somewhere and remember that I forgot something important! Bada bing! I can connect up to the house and get it... Smoothwall is VERY handy for my needs. I have no complaints about it...

        • Several of the games want huge chunks of ports opened up. Uh uh. Not gonna do that. So I added the third nic as a DMZ (smoothwall calls it "Orange Zone") so that the PS2 has unhindered access to the web.

          There are three nics,
          red=nic to modem (dhcp)
          orange= nic to PS2 - 192.168.2.1
          green=nic to my lan - 192.168.1.1

          Okay, I'm still a little confused. (Read my suppositions about your reason here [slashdot.org], if you like)

          Can you not assign more than one block to a NIC? Assigning them as two discrete /24s instead of one /2

          • Two confessions are in order.
            1. I'm lazy. I have plenty of old nics laying around too. I'll get more elaborate with it another day.
            Besides, I don't feel overly compelled to put much effort into it, he's moving off to college this fall.
            This simple fix works. In two months he'll be moving out (Hooray!! Shhhh!! I didn't say that!!)

            2. My son just got his Linksys adapter and was bugging me. This was the most easy and the fastest way to shut him up..

            There! Now I feel better that the truth is out...

            • Re:I like (Score:3, Informative)

              by Artifex ( 18308 )

              There! Now I feel better that the truth is out...

              Well, I have a confession to make, then, also, just so you don't feel bad:

              Remember what I said about the PPPOE and ICS and a star config with one NIC on the gateway, and all that?

              I actually ran that for a while when I was living with my parents, before moving out. It was dog-slow when they'd be on their box though, sometimes, because ICS isn't exactly very efficient, and bouncing it in and out across the same segment didn't help. Plus, they couldn't tur

        • Re:I like (Score:3, Informative)

          by zcat_NZ ( 267672 )
          I hard coded one of my boxes to a specific IP then port forward from port XXXX to port 21 at my internal IP of 192.168.1.205. Only my friends and I know it's there and can access it. Very handy.

          Nice, but I strongly suggest you use SSH instead, particularly since you're on a cable connection.

          You can download a windows client called putty [greenend.org.uk]. It's a small, standalone .exe so you can easily grab it when you need it, and drop it in the trash when you're finished.

        • Re:I like (Score:2, Informative)

          by Osty ( 16825 )

          I've never used Smoothwall, instead doing all of that by hand (setting up a firewall, DHCP; haven't bothered with dyndns though, since I used to have static IPs and now that I don't I haven't found a need to connect to my home PCs yet). The way I would've setup your topology would have been to set a given IP to the PS2's mac rather than just getting a random IP, and then setup appropriate firewall rules for that IP. The rest of the internal network would have its own separate rules.

          Then again, I didn't

          • That's an interesting setup too. I may play with something like that myself.
            I also want to play with chained firewalls, that is one physical firewall going into
            another one then into my lan. Like the mega-paranoid version..
            Just for fun..
    • The idea of smoothwall is really cool. Is there software like that that I could install on a Redhat 9 machine? I have a system which I want to use as both a workstation and my firewall. I really like the remote administration functions of smoothwall, so I'd like to use that on the Redhat box. I'm currently using Monmotha's IPTables script [mplug.org].

    • I put three nics in a Pentium 90 that I found on a trash heap [to create a firewall]. ... It's really easy to use and so far I've had no problems. ... and all of them are using iptables ... so everything is really secure.

      I've done something similar. But did you RTFA? It's point was that backdoors are often not blocked by firewalls because firewall policies on outgoing connections are usually permissive. What matters, in the context of this article, is what your iptables restrict, not whether you have th

      • Did you RMFP? In case you didn't notice, and not to flame, but I mentioned that all my boxes are running Linux. No backdoor concerns here.

        Now if I had some Windows machines on the lan then I *would* have cause for concern.
        But of course I *don't* have any windows boxes so I sleep really well at night..
        Really well...

  • how come... (Score:3, Funny)

    by deadsaijinx* ( 637410 ) <animemeken@hotmail.com> on Friday June 13, 2003 @12:46AM (#6188301) Homepage
    articles about network security always remind me of a poorly written tech based porno?

  • SecurityFocus says no MacOS EVER exploited once! (Score:3, Interesting)

    by Anonymous Coward on Friday June 13, 2003 @12:46AM (#6188308)
    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

  • Routers (Score:5, Interesting)

    by Zarxos ( 648322 ) on Friday June 13, 2003 @01:14AM (#6188396)
    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.

    • Re:Routers (Score:4, Insightful)

      by thynk ( 653762 ) <slashdot AT thynk DOT us> on Friday June 13, 2003 @01:59AM (#6188520) Homepage Journal
      sonally I don't see any use for software firewalls for the majority of home users.

      Kind of funny that this comes up right as I'm thinking that my hardware/router based firewall isnt' enough and that I need to back it up with a linux software firewall.

      IIRC on the home routers, any program requesting a port to talk out of can recieve a request back on it. SO... your WORM opens up port n, sends the info, get's it's commands to try on your system, then sends off the next command it's done/how and waits for it's marching orders.

      • Re:Routers (Score:2, Insightful)

        by raga ( 12555 )
        SO... your WORM opens up port n, sends the info, get's it's commands to try on your system, then sends off the next command it's done/how and waits for it's marching orders.

        To do this, the worm would already have to be on your disk. If your system is already infected, then all bets are off....

        If Jane Q Public has a router that requires port-forwarding for external connections, and she takes other reasonable precautions to prevent an initial infection (re. downloads, email attachments etc.), she will be

      • http://www.nwc.com/1223/1223f45.html

        If you use IPTables on your linux box, you're not going to be doing much. IPTables is just a packet filter, and can't block access to individual applications.
    • That's fine, personally I don't see a need for any firewall on my properly configured home machine. I understand the fact that nearly every home user will not be able to lock down their machine, but seriously, shouldn't they be locked down in the first place?

  • SSH Tunnels (Score:5, Informative)

    by rf0 ( 159958 ) <rghf@fsck.me.uk> on Friday June 13, 2003 @01:37AM (#6188453) Homepage
    One thing which is handy for backdoor is SSH tunneling. A nice exaple can be found here [neu.edu] Just replace port 110 with anything else and off you go

    Rus

  • Most secure solution isnt simple, but its the best (Score:5, Informative)

    by Zeddicus_Z ( 214454 ) on Friday June 13, 2003 @02:17AM (#6188564) Homepage
    1) Use both inbound and OUTBOUND ACL lists on routers, firewalls and other access control devices. Go with the highest level of restriction you can get away with, and log everyhing to a central point.

    2) For services you must offer to internal users (www access etc), use good proxies and authenticate every connection.

    3) Ensure all services/software products are up to date with security patches. This INCLUDES user workstations.

    4) Keep track of security-related sites and lists, such as bugtraq, packetstorm etc.

    5) IDS' inside your perimeter to detect anything you're missing. After all, no-one (and by extention, no-one's ACLs) is perfect.

    6) Ensure you pay close attention to any remote-access you offer. Modem banks, VPN endpoints etc. Preferably these should also be access-controlled via ACL's of some sort.

    7) Ensure you configure your software properly. Seems stupid, I know. But a perfectly secure (from a bugs point of view) mail server is suddenly a problem if you've forgotten to disable mail relay.

    8) Ensure you have the right topology. There's no point in spending hundreds of man hours securing services, auditing router ACLs etc etc if theres fifteen different ingress/egress points to your network. The less, err, gresses you have, the more you can concentrate your efforts and thus use your time effectively.

    Caveats: I may have missed one or two points in the above summary of practice, but hey - it's a friday arvo and I want to get my work finished so im not here late.

    Also note that while the above list sounds relatively easy to implement, IT ISN'T. Be prepared for a lot of work if you want to do it right.
    • Of course, a network's weakest point is often the people who use it. Firewalls and security patches do not mean a lot if a user gives information out to anyone who calls their extension and acts like a manager from another department. Hardware is only part of the solution.
    • But at that point there's a serious question as to whether all that security is paying for itself.

      Call up a company, promise them anonymity, and ask them how much hackers cost them last year, and they'll throw out some exorbitant figure. The best indicator to their *real* losses, though, is how much they spend on computer security, which in the view of computer security experts is never "enough" - i.e. the computer security experts overestimate the problem.

  • Default deny (Score:3, Interesting)

    by MadFarmAnimalz ( 460972 ) on Friday June 13, 2003 @03:33AM (#6188832) Homepage
    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.
  • 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?
    • It will appear when the first spyware will be written for Linux. And will be used by people who install software that they can not trust.

      Right now even the worst spyware offenders have clean Unix/Linux versions/equivalents, so it's pointless.
    • 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 a
      • I think it sounds interesting. Of course, I am biased, but I think a good way to get developer attention would be to submit this to freshmeat (if you haven't already).

        Another interesting idea would be to expand this to work on a NAT gateway, dynamically adding iptables/pf/etc. rules for individual machines or entire subnets. Or maybe even go further and do traffic analysis at higher levels ("disallow all traffic of this type (Kazaa, etc.) from this subnet"). Of course, this is getting way ahead, and I a

  • The whole article describes: (Score:5, Insightful)

    by Alex Belits ( 437 ) on Friday June 13, 2003 @04:21AM (#6188947) Homepage
    1. What firewall software pretends to do (as opposed to what it actually accomplishes).

    2. How to become a perfect target of DoS attack through paranoia (imitation of any intrusion-like activity will make the supposed origin unable to access you).

    3. How to defend yourself when you have already lost, and are for all practical purposes as good as dead.
    • You say the article was about, "How to defend yourself when you have already lost, and are for all practical purposes as good as dead." I agree, the artilce is very defeatist. What really bothers me, though, is a missatribution of the cause of defeat.

      This piece of balance was less than objective:

      Chances are significantly higher that in most organizations a hacker will have a much easier time finding an un-patched Windows or *nix system to exploit than they will an un-patched and/or misconfigured piece

  • Everyone seems to be missing the point (Score:5, Insightful)

    by scottme ( 584888 ) on Friday June 13, 2003 @04:26AM (#6188962)
    I am not enough of a security geek to fault this article on any technical detail, but surely the main message is that no matter what technical measures you take, any dumb user can totally subvert all your efforts by inadvertantly, unwittingly, or even maliciously running code on a personal system inside the secured network that opens a tunnel to the outside. Hence the title of the article.

    The concluding sentences contain the main learning point, as I see it: you need a way to identify all connections down to the source (user).
    And you need to make sure that all those dumb users know you're watching them and that you will hold them accountable for breaches of security that they initiate.

    Or is all that so obvious that no-one has felt the need to point it out?

    • Actually, thats not exactly correct.

      Using restrictive ACL's on your outbound interfaces, you can kill connectivity for most types of malicious connections. For protocols you MUST run - say HTTP, outgoing SQL, outgoing SMTP and the like - you *proxy* every single connection, and ensure each connection is authenticated.

      The beauty of this solution is two-fold. First, it blocks off almost every type of malware connection you're going to see from exiting your network to $SKIDDIOT on the outside. Secondly,

      • Using restrictive ACL's on your outbound interfaces, you can kill connectivity for most types of malicious connections. For protocols you MUST run - say HTTP, outgoing SQL, outgoing SMTP and the like - you *proxy* every single connection, and ensure each connection is authenticated.

        This is, so far as I can tell, standard industry practice in certain places, and I'll tell you the result: everything gets tunnelled over HTTP.

        When people have some brand new protocol (say, when Microsoft was developing SOAP)

      • and these days with programs like http-tunnel you can use whatever program you want to use from a proxied HTTP connection sitting inside a 'secure' zone. i was just using Kazaa Lite just today in my office. wonder if my sysadmin knew.

  • Firewall Systems Considered Harmful (Score:3, Insightful)

    by Alioth ( 221270 ) <no@spam> on Friday June 13, 2003 @05:55AM (#6189208) Journal
    I would write a long rant about firewalls and people thinking, "Oh, it's OK, we have a firewall" and not dealing with internal security, but this article does it adequately:

    Firewall Systems Considered Harmful [clock.org]

  • Transparent firewalls (Score:3, Interesting)

    by nmg196 ( 184961 ) on Friday June 13, 2003 @06:42AM (#6189347)
    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...

    • Re:Transparent firewalls (Score:5, Informative)

      by Zeddicus_Z ( 214454 ) on Friday June 13, 2003 @07:17AM (#6189447) Homepage
      I suspect you haven't actually tried to implement a PIX yet. The Cisco PIX (at least, the low-end 506 we have) *does* support what you're talking about - although what you're talking about isn't really a transparent (also known as *bridged*) firewall.

      Setup the PIX. Use static maps for the IP addresses, so your webservers etc are behind the pix but using the public IP's. When an internal machine tries to connect to the IP address of your website (say 210.20.38.129), the request is forwarded to your default router (border router usually, unless you're on a larger network). The router gets the request, goes "hey, im responsible for that IP. It should go *HERE*" and fowards it back to the webserver *through* the PIX. At no point does the PIX attempt to map the IP address of 210.20.38.129 to the MAC addy of your webserver for the internal connection. Only after the connection has bounced off the border router does the PIX go "hey, incoming *external* request for 210.20.28.129. I've got a static route for that. I'll send it to $webserver". And your connection works.

      Now, if you use a domain name for the request (as most people do when using a web browser), your internal requests will first bounce off your internal DNS. And that's where the problem is. Your internal DNS is configured to point www.myinternalwebserver.com to 192.168.0.129 (or whatever the machine's internal interface is) instead of the public IP address. If it was pointed at the public address, your machine would get said address returned to it after doing the DNS lookup and follow the steps in the paragraph above. Namely, the req bounces off the border router.

      As a side note, transparent firewalls are synonyms for bridged firewalls. I.e. it's impossible to actually gain network connectivity to the firewall because for all intents and purposes, it's setup to act as an intercept on a peice of cat5, not as two interfaces seperating two network segments. Think of it as tapping a Cat5 cable and trying to ping the tap itself. Not going to happen, as neither the bridged firewall system (or the tap, per example) have interfaces with an IP address.

      There's a guide floating around the net on how to implement bridged/transparent firewalls using OpenBSD if you're interested. It can be found at http://ezine.daemonnews.org/200207/transpfobsd.htm l
      • You're right - I haven't actually tried, I was just repeating what I'd been told by our firewall supplier (who may or may not be particularly knowledgeable).

        The other criteria which I forgot to mention is that we also need VPN support. Can a bridging firewall support VPNs when, it doesn't actually have an external facing IP of it's own? Presumably it would have to create a virtual IP address and use that for the VPN?

        I don't really want to try building one myself using BSD, as then it would be my fault if
        • Bridged firewalls support VPNs, in that they'll pass VPN traffic. however, as they have no IP addresses, you can make them endpoints for the VPN tunnel. What you'd have to do is setup a 2nd host inside the bridged firewall, and use that. Keep in mind however that anyone who can authenticate to your VPN is treated as an internal user. So, if you have business parter type companies connecting, its best to keep a close eye on VPN traffic coming OUT of your VPN endpoint and into your internal network.
    • All firewalls I know of can behave "transparently" as you have described it - basically like a normal router, but also filtering undesired traffic.

      There is no requirement for a Checkpoint/1 or Cisco PIX firewall, for example, to use private addresses on the inside, and translate them into public addresses on the way out. It's just a question of how you configure the system.

      On the one hand, you could have your public addresses "on the inside of the firewall", with one address being the firewall's "insi

  • Bits go in. Bits go out. That's what networks do. (Score:4, Interesting)

    by aphor ( 99965 ) on Friday June 13, 2003 @11:04AM (#6190898) Journal

    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.

Slashdot Top Deals

If you have a procedure with 10 parameters, you probably missed some.

Close