This is why I use slackware - Slackware

This is a discussion on This is why I use slackware - Slackware ; On Mon, 6 Oct 2008, Mark Madsen wrote: >>>>> Is there any evidence to support that assertion? >>>> >>>> Scott Kitterman debian/ubuntu team. >> >> I'd take his word that the debian devs also do ubuntus over yours any >> ...

+ Reply to Thread
Page 2 of 3 FirstFirst 1 2 3 LastLast
Results 21 to 40 of 57

Thread: This is why I use slackware

  1. Re: This is why I use slackware

    On Mon, 6 Oct 2008, Mark Madsen wrote:

    >>>>> Is there any evidence to support that assertion?
    >>>>
    >>>> Scott Kitterman debian/ubuntu team.

    >>
    >> I'd take his word that the debian devs also do ubuntus over yours any
    >> day sport, why should I think you know more then him, you, a completely
    >> unknown troll, now kiddie, go try pull a fast one elsewhere where
    >> someone might give a **** and be dumb enough to listen to you.

    >
    > Cool. An ad hominem attack. That's an excellent way to demonstrate that
    > you don't actually have any evidence to support your wilder assertions.



    Already stated my proof, not my problem it doesnt fit in with your
    fantasy, I also note you cant state why I should accept your word
    over a debian team members, but I thought as much, troll. Now
    **** off back to whatever rock you climbed from out of troll boi.



    --
    Cheers
    Res

    "The hopes we had, were much to high, way out of reach, but we have to
    try, no need to hide, no need to run, cause all the answers come one by
    one" -Freiheit

  2. Re: This is why I use slackware

    On Mon, 06 Oct 2008 21:12:41 +1000, Res wrote:

    > On Mon, 6 Oct 2008, Mark Madsen wrote:
    >
    >>>>>> Is there any evidence to support that assertion?
    >>>>>
    >>>>> Scott Kitterman debian/ubuntu team.
    >>>
    >>> I'd take his word that the debian devs also do ubuntus over yours any
    >>> day sport, why should I think you know more then him, you, a
    >>> completely unknown troll, now kiddie, go try pull a fast one elsewhere
    >>> where someone might give a **** and be dumb enough to listen to you.

    >>
    >> Cool. An ad hominem attack. That's an excellent way to demonstrate
    >> that you don't actually have any evidence to support your wilder
    >> assertions.

    >
    > Already stated my proof, not my problem it doesnt fit in with your
    > fantasy, I also note you cant state why I should accept your word over a
    > debian team members, but I thought as much, troll. Now **** off back to
    > whatever rock you climbed from out of troll boi.


    Fascinating.

  3. Re: This is why I use slackware

    On Mon, 06 Oct 2008 16:48:55 +0200, Mark Madsen wrote:

    > Fascinating.


    This is alt.os.linux.slackware, it is always fascinating. If you hang
    around long enough you'll discover just how fascinating.

    --
    Two Ravens
    "...hit the squirrel..."

  4. Re: This is why I use slackware

    On Mon, 06 Oct 2008 16:44:13 +0000, Two Ravens wrote:

    > On Mon, 06 Oct 2008 16:48:55 +0200, Mark Madsen wrote:
    >
    >> Fascinating.

    >
    > This is alt.os.linux.slackware, it is always fascinating. If you hang
    > around long enough you'll discover just how fascinating.


    Thanks for the encouragement :-)

    I have been reading this group for ages. Even when there isn't much
    useful knowledge about Slackware, there is always new invective to
    appreciate.

  5. Re: This is why I use slackware

    Keith Keller wrote:

    > On 2008-10-04, notbob wrote:
    >>
    >> nb ...braindead slack user

    >
    > A perfect candidate for Ubuntu! ;-O
    >
    > --keith
    >


    BTW - not a dig, I was just finding a good natured part of this thread to
    add my bit. :-)

    Personally I avoid the advocacy arguments. If its not linux v Windows its
    Windows v Mac and Linux v Mac, and then once people start talking linux is
    Ubuntu v Slackware etc. Little of it is constructive, to the point that
    logic leaves the discussion and we are left with dogma and insults.

    Pete


    --
    http://www.petezilla.co.uk

  6. Re: This is why I use slackware

    notbob wrote:

    OK, for the purposes of my enlightenment. I'm not a firewall guru.

    >
    > Policy
    >
    > (Completed: Hardy)
    >
    > The default firewall policy will be:
    >
    > 1. ACCEPT all on loopback


    Seems reasonable

    > 2. ACCEPT all outgoing


    Seams reasonable. I know people will say this is stupid, but I am
    considering here a single PC that is not forwarding other computers to the
    internet. If nothing is getting in, is there a realistic chance of a
    trojan trying to send stuff out?

    > 3. default policy of ACCEPT for incoming (configurable)


    Confused here. Surely accept all on loopback as in 1. and maybe accept all
    on local network. But surely we want to REJECT all connections coming in
    from the internet side.

    > 4. LOG all dropped packets (perhaps use --limit 3/min
    > --limit-burst 10 or similar)


    Seems logical.

    > 5. Firewall is disabled on installation
    >


    Whilst I can see they want an easy life surely it should enabled? Perhaps
    some sort of wizard / config programme, given the target audience?

    Surely with 3. and 5. in place you have a firewall that does nothing? I
    would have thought, given the target audience, that on installation Ubuntu
    would ask the user to nominate which interface was the internet connection
    and block all incoming from there. In fact, though Slackware is not
    intended to nanny you along, it seems like a reasonable step in Slackware
    as it is likely, when installing Slack that you will be running services.
    I'd go further and say all linux or other OS installs. It would reduce the
    number of completely unfirewalled machines in the wild.

    Pete

    --
    http://www.petezilla.co.uk

  7. Re: This is why I use slackware

    Peter Chant wrote:

    > If nothing is getting in, is there a realistic chance of a trojan
    > trying to send stuff out?


    Yes there is. Even with no *services* responding on the local machine,
    if the user is using it as a client to services on other machines, there
    is a non-zero chance of unintended traffic leaving. However, the user
    needs to decide for him/herself whether a policy that would require
    explicit rules for all expected services is appropriate for a personal
    computer.

    > But surely we want to REJECT all connections coming in from the
    > internet side.


    A policy based on "default deny" would certainly be an improvement, but
    has the drawback that the user needs to learn how to configure the
    firewall to permit desired services. This is, of course, the same thing
    as an OS distribution that does not include any firewalling rules by
    default. I'm not about to defend the Ubuntu installation's approach, as
    I don't agree with it (my reaction, though, is simply that I have no
    intention to use it), but I suspect that the reasoning behind it is to
    provide a system that works by default as though there were no firewall
    in place, with the possibility of the user easily being able to add in
    some firewalling.

    >> 5. Firewall is disabled on installation

    >
    > Whilst I can see they want an easy life surely it should enabled?
    > Perhaps some sort of wizard / config programme, given the target
    > audience?


    See my speculation above. In most cases of a personal computer (with no
    services running on it anyway), a "firewall" adds no protection anyway.

    > ... it is likely, when installing Slack that you will be running
    > services.


    I don't think that necessarily follows. Slackware is just as likely to
    be installed on personal computers offering no services, as it is to be
    installed on organizational servers. Anyone running services on a
    system (regardless of OS distribution) needs to learn how to properly
    protect those services. That may or may not involve firewalling rules.

    > It would reduce the number of completely unfirewalled machines in the
    > wild.


    I manage several systems that have no firewalling rules applied to them.
    That's not to say that there is no access-control applied to the
    services running on them, but rather that there isn't any form of
    "firewall" (whether hardware or by iptables/ipchains) providing that
    access-control. The mistake people make is to turn too quickly to a
    "firewall" solution when more often than not (at least for the more
    common services), there exist access-control solutions that function at
    the application layer and therefore are more straightforward (and less
    potentially disruptive) to manage, but just as effective.

    The trick is to understand the available options, and to decide on a
    case-by-case basis which one(s) are more suitable for a given system.
    On some systems, I've done the exact opposite from what I describe
    above, and turned to IPTables for a host-side (default-deny) firewall,
    but that isn't my usual way of operating.

    --
    ----------------------------------------------------------------------
    Sylvain Robitaille syl@alcor.concordia.ca

    Network and Systems analyst Concordia University
    Instructional & Information Technology Montreal, Quebec, Canada
    ----------------------------------------------------------------------

  8. Re: This is why I use slackware

    On Mon, 06 Oct 2008 18:53:48 +0100, Peter Chant wrote:

    >notbob wrote:
    >
    >OK, for the purposes of my enlightenment. I'm not a firewall guru.
    >
    >>
    >> Policy
    >>
    >> (Completed: Hardy)
    >>
    >> The default firewall policy will be:
    >>
    >> 1. ACCEPT all on loopback

    >
    >Seems reasonable
    >
    >> 2. ACCEPT all outgoing

    >
    >Seams reasonable. I know people will say this is stupid, but I am
    >considering here a single PC that is not forwarding other computers to the
    >internet. If nothing is getting in, is there a realistic chance of a
    >trojan trying to send stuff out?


    Stuff getting out on a router firewall box goes via the FORWARD chain in any
    case, not the OUTPUT chain.
    >
    >> 3. default policy of ACCEPT for incoming (configurable)

    >
    >Confused here. Surely accept all on loopback as in 1. and maybe accept all
    >on local network. But surely we want to REJECT all connections coming in
    >from the internet side.


    Well DROP, is better here. REJECT advertises each port as being there but
    closed. DROP leaves the remote in the dark...
    >
    >> 4. LOG all dropped packets (perhaps use --limit 3/min
    >> --limit-burst 10 or similar)

    >
    >Seems logical.
    >
    >> 5. Firewall is disabled on installation


    This is the odd one, they claim firewall not needed because no services
    are offered. While true for a single machine right after an install, it's
    perhaps too easy to turn external access to a web (or other) server and
    not many steps for accidentally providing a transparent proxy or login
    service that can allow the machine to be r00ted or subverted into a botnet.

    Given that the target audience for *buntu are crying out for help on any
    forum out there, it would be expected that many will blindly follow bad
    scripts / install procedures as good ones, no?
    >>

    >
    >Whilst I can see they want an easy life surely it should enabled? Perhaps
    >some sort of wizard / config programme, given the target audience?


    Yes, or just the basic firewall a lowly modem / router has these days, in
    fact this is probably why firewalls are less important now -- to gain access
    to a service offered on the box one has to punch a hole through the DSL
    modem's firewall. In that sense the firewall on a linux box is less important
    than it used to be.

    How ever some users will run pppoe and/or firewall/router box with the modem
    in bridge mode, I do Even windoze offers pppoe -> bridged modem connection
    (not that I'd be mad enough to trust their firewall with one).
    >
    >Surely with 3. and 5. in place you have a firewall that does nothing? I
    >would have thought, given the target audience, that on installation Ubuntu
    >would ask the user to nominate which interface was the internet connection
    >and block all incoming from there. In fact, though Slackware is not
    >intended to nanny you along, it seems like a reasonable step in Slackware
    >as it is likely, when installing Slack that you will be running services.
    >I'd go further and say all linux or other OS installs. It would reduce the
    >number of completely unfirewalled machines in the wild.


    Yeah well, as I stated above -- the only saving is most access via an (A)DSL
    modem with firewall -- on the other hand there are many stories of people
    getting their bandwidth / quota stolen by war-drivers or neighbours... One
    I heard last week cost a company (windoze site) $600/month in excess fees,
    and for them, ISP charging $150/GB over the plan limit, only 4GB over. Yup,
    over $600 to download a DVD image in some circumstances? Dunno why people
    use those plans...

    So lack of decent firewall / security can lead to expensive side effects --
    and it is common for people to use a wireless modem / router -- ignoring
    security from the outset tends to setup the user for a fall, sort of like
    how one doesn't really pay attention to backups until some disaster strikes
    and either there's noting to restore, or one finds the last backup is
    suddenly months way to old to bother with.

    Encourage the right mindset? I tried slackware and stayed with it because
    slackware encourages one to learn, to discover )

    Grant.
    --
    http://bugsplatter.id.au/

  9. Re: This is why I use slackware

    Sylvain Robitaille wrote:


    >> If nothing is getting in, is there a realistic chance of a trojan
    >> trying to send stuff out?

    >
    > Yes there is. Even with no *services* responding on the local machine,
    > if the user is using it as a client to services on other machines, there
    > is a non-zero chance of unintended traffic leaving. However, the user
    > needs to decide for him/herself whether a policy that would require
    > explicit rules for all expected services is appropriate for a personal
    > computer.
    >


    I don't follow here. Any examples as I can't think of one. Surely any
    traffic leaving would have to be initialted by the user and therefore the
    user be aware?


    >> But surely we want to REJECT all connections coming in from the
    >> internet side.

    >
    > A policy based on "default deny" would certainly be an improvement, but
    > has the drawback that the user needs to learn how to configure the
    > firewall to permit desired services. This is, of course, the same thing
    > as an OS distribution that does not include any firewalling rules by
    > default. I'm not about to defend the Ubuntu installation's approach, as
    > I don't agree with it (my reaction, though, is simply that I have no
    > intention to use it), but I suspect that the reasoning behind it is to
    > provide a system that works by default as though there were no firewall
    > in place, with the possibility of the user easily being able to add in
    > some firewalling.
    >


    Surely though were the internet is conconcerned it is better to block access
    and then make holes only where needed. With a suitably commented file or
    tool that ought to be fairly easy.

    >>> 5. Firewall is disabled on installation

    >>
    >> Whilst I can see they want an easy life surely it should enabled?
    >> Perhaps some sort of wizard / config programme, given the target
    >> audience?

    >
    > See my speculation above. In most cases of a personal computer (with no
    > services running on it anyway), a "firewall" adds no protection anyway.
    >


    Just thinking that, for a nedwbie who installs apache locally for web
    development, or enables samba to share with windows having a deny incoming
    firewall by default would potentially save a lot of embarisment.

    --
    http://www.petezilla.co.uk

  10. Re: This is why I use slackware

    Peter Chant wrote:

    >> Yes there is. Even with no *services* responding on the local machine,
    >> if the user is using it as a client to services on other machines, there
    >> is a non-zero chance of unintended traffic leaving. ...

    >
    > I don't follow here. Any examples as I can't think of one. Surely any
    > traffic leaving would have to be initialted by the user and therefore the
    > user be aware?


    What things are possible with, for simple examples, flash, javascript, or
    more likely, java? Is it possible for a user to visit a website where a
    java applet is then run on the user's computer, and that applet creates
    connections back to the same (or different) remote site? I'm quite
    certain that it is. Or, it launches a local program that makes remote
    network access? I don't know if Javascript and flash have the same
    possibilities, but I'm raising them as potential examples. I'm not a
    web programmer, so I don't know the details of these possibilities.

    Consider also the (perhaps extreme, in the case of a Linux personal
    computer) example of a user clicking on an email attachment that results
    in a script running locally on the user's behalf. We know that users of
    other systems have encountered this, and we know the same possibility
    exists on Linux, despite it being a significantly smaller target,
    with a smaller potential impact. If we're examining the possibility,
    though, we need to take this into account.

    > Just thinking that, for a nedwbie who installs apache locally for web
    > development, or enables samba to share with windows having a deny
    > incoming firewall by default would potentially save a lot of
    > embarisment.


    I'm not disagreeing with you. I was simply proposing the sorts of
    explanations I've received for similar scenarios in the past. I don't
    claim to defend these arguments. Their validity, in my opinion, is
    site-specific. Most users unfortunately don't have enough knowledge
    (it seems) to make a suitably informed decision. :-(

    --
    ----------------------------------------------------------------------
    Sylvain Robitaille syl@alcor.concordia.ca

    Network and Systems analyst Concordia University
    Instructional & Information Technology Montreal, Quebec, Canada
    ----------------------------------------------------------------------

  11. Re: This is why I use slackware

    Grant wrote:

    > On Mon, 06 Oct 2008 18:53:48 +0100, Peter Chant
    > wrote:
    >
    >>notbob wrote:
    >>
    >>OK, for the purposes of my enlightenment. I'm not a firewall guru.
    >>
    >>>
    >>> Policy
    >>>
    >>> (Completed: Hardy)
    >>>
    >>> The default firewall policy will be:
    >>>
    >>> 1. ACCEPT all on loopback

    >>
    >>Seems reasonable
    >>
    >>> 2. ACCEPT all outgoing

    >>
    >>Seams reasonable. I know people will say this is stupid, but I am
    >>considering here a single PC that is not forwarding other computers to the
    >>internet. If nothing is getting in, is there a realistic chance of a
    >>trojan trying to send stuff out?

    >
    > Stuff getting out on a router firewall box goes via the FORWARD chain in
    > any case, not the OUTPUT chain.
    >>


    The example I used was a single PC connected directly to an ASDL / cable
    modem, not being used as a router. So OUTPUT is correct (even if you did
    make me think about that one...)


    >>> 3. default policy of ACCEPT for incoming (configurable)

    >>
    >>Confused here. Surely accept all on loopback as in 1. and maybe accept
    >>all
    >>on local network. But surely we want to REJECT all connections coming in
    >>from the internet side.

    >
    > Well DROP, is better here. REJECT advertises each port as being there but
    > closed. DROP leaves the remote in the dark...


    Fair cop!

    >>
    >>> 4. LOG all dropped packets (perhaps use --limit 3/min
    >>> --limit-burst 10 or similar)

    >>
    >>Seems logical.
    >>
    >>> 5. Firewall is disabled on installation

    >
    > This is the odd one, they claim firewall not needed because no services
    > are offered. While true for a single machine right after an install, it's
    > perhaps too easy to turn external access to a web (or other) server and
    > not many steps for accidentally providing a transparent proxy or login
    > service that can allow the machine to be r00ted or subverted into a
    > botnet.
    >
    > Given that the target audience for *buntu are crying out for help on any
    > forum out there, it would be expected that many will blindly follow bad
    > scripts / install procedures as good ones, no?


    Yes, I thought that was the plus point. I have installed stuff on Ubuntu to
    see what it was like as it was easier than slack. Mostly I just lost
    interested and went back the slack box - but automagick one click
    installation is Ubuntu's big plus. I espect a lot of people are running
    services that they clicked on in synaptic, had a quick look at, got bored
    and forgot.


    >>>

    >>
    >>Whilst I can see they want an easy life surely it should enabled? Perhaps
    >>some sort of wizard / config programme, given the target audience?

    >
    > Yes, or just the basic firewall a lowly modem / router has these days, in
    > fact this is probably why firewalls are less important now -- to gain
    > access to a service offered on the box one has to punch a hole through the
    > DSL
    > modem's firewall. In that sense the firewall on a linux box is less
    > important than it used to be.
    >
    > How ever some users will run pppoe and/or firewall/router box with the
    > modem
    > in bridge mode, I do Even windoze offers pppoe -> bridged modem
    > connection (not that I'd be mad enough to trust their firewall with one).


    Agree with the router thing. I've been running slack since 3.4 and always
    connected my windows machine to the internet via the slack machine using
    NAT. Once I went broadband I just popped the router in front the linux
    box. Rarely seen anything get as far as the linux box. I once, after
    about four years, of running NT behind the linux box with no antivirus ran
    a scan (with some online scanner). Nothing. Mind you, I read all my mail
    in linux and with windows softward that I have downloaded I only touch
    reputable stuff (Povray, Irfanview etc).

    My limited experience of Windows security software is that it causes as much
    trouble as it solves. I don't think its a windows thing, I suspect that if
    linux software was written along the same lines it would be just as much of
    a pain.

    >>
    >>Surely with 3. and 5. in place you have a firewall that does nothing? I
    >>would have thought, given the target audience, that on installation Ubuntu
    >>would ask the user to nominate which interface was the internet connection
    >>and block all incoming from there. In fact, though Slackware is not
    >>intended to nanny you along, it seems like a reasonable step in Slackware
    >>as it is likely, when installing Slack that you will be running services.
    >>I'd go further and say all linux or other OS installs. It would reduce
    >>the number of completely unfirewalled machines in the wild.

    >
    > Yeah well, as I stated above -- the only saving is most access via an
    > (A)DSL modem with firewall -- on the other hand there are many stories of
    > people
    > getting their bandwidth / quota stolen by war-drivers or neighbours...
    > One I heard last week cost a company (windoze site) $600/month in excess
    > fees,
    > and for them, ISP charging $150/GB over the plan limit, only 4GB over.
    > Yup,
    > over $600 to download a DVD image in some circumstances? Dunno why people
    > use those plans...
    >


    Just went wireless.4 Had WPA up and working almost immediately! (as least
    on the router end, eee end took a little bit more fiddling).

    > So lack of decent firewall / security can lead to expensive side effects
    > -- and it is common for people to use a wireless modem / router --
    > ignoring security from the outset tends to setup the user for a fall, sort
    > of like how one doesn't really pay attention to backups until some
    > disaster strikes and either there's noting to restore, or one finds the
    > last backup is suddenly months way to old to bother with.
    >


    Hmm, yes. Tried tape once and ran away. I now backup nightly to my slug
    and have another disk that I copy to every time I feel like it (probally
    monthly). Never say never, but I've rescued myself from a few disk
    failures without too much hastle.

    > Encourage the right mindset? I tried slackware and stayed with it because
    > slackware encourages one to learn, to discover )


    Why not go for linux from scratch... ;-)

    --
    http://www.petezilla.co.uk

  12. Re: This is why I use slackware

    Grant wrote:

    > Stuff getting out on a router firewall box goes via the FORWARD chain
    > in any case, not the OUTPUT chain.


    I believe the package in question is intended to be run on the end-user
    system, not a router/firewall system. Think "personal firewall" in the
    Windows-world.

    > Well DROP, is better here. REJECT advertises each port as being there
    > but closed. DROP leaves the remote in the dark...


    Which leads me to argue that REJECT is better: send them away believing
    there's nothing at that port, rather than letting them know the port is
    "filtered". DROP doesn't leave the scanner in the dark, it makes it
    quite clear that some firewall device is between them and the target
    system.

    > Given that the target audience for *buntu are crying out for help on any
    > forum out there, it would be expected that many will blindly follow bad
    > scripts / install procedures as good ones, no?


    Yes, of course. That's part of the problem ...

    --
    ----------------------------------------------------------------------
    Sylvain Robitaille syl@alcor.concordia.ca

    Network and Systems analyst Concordia University
    Instructional & Information Technology Montreal, Quebec, Canada
    ----------------------------------------------------------------------

  13. Re: This is why I use slackware

    On Mon, 06 Oct 2008 22:16:00 +0100, Peter Chant wrote:

    >Grant wrote:

    ....
    >> Stuff getting out on a router firewall box goes via the FORWARD chain in
    >> any case, not the OUTPUT chain.
    >>>

    >
    >The example I used was a single PC connected directly to an ASDL / cable
    >modem, not being used as a router. So OUTPUT is correct (even if you did
    >make me think about that one...)


    Oops, sorry
    ....
    >Hmm, yes. Tried tape once and ran away. I now backup nightly to my slug
    >and have another disk that I copy to every time I feel like it (probally
    >monthly). Never say never, but I've rescued myself from a few disk
    >failures without too much hastle.


    I run a 1/2 hour rsync/hardlink style backup on some development areas,
    so other day when I 'rm index.html' instead of 'rm index.html.gz' I just
    pulled the index.html file out of the /opt/backup area -- works for me

    What did piss me off was discovering last September that I'd broken the
    backup system the previous May -- months went by with the backup
    overwriting old stuff, until I needed to restore a file Funnier was
    when I setup and started sendmail couple weeks back there was ~10k messages
    queued from cron telling me about the backup problem )

    Other stuff I tarball to another box when I think of it.
    >
    >> Encourage the right mindset? I tried slackware and stayed with it because
    >> slackware encourages one to learn, to discover )

    >
    >Why not go for linux from scratch... ;-)


    Slackware is as close to that as I like I can maintain a two year
    old slack-11 quite nicely -- at the moment I'm starting to update
    packages in the slack-11.0 Internet facing machine to stay current.

    I've had to update netfilter iptables userspace (1.4.1.1) to match the
    latest kernels -- now there's a trap for young players -- old 'man
    iptables' no longer matched what the latest kernel accepted, leading
    to confusing errors.

    I had the latest dnsmasq in a few days before slack-11 issued the
    security update. Latest git, and a few other things as required.

    So what advantage going to linux from scratch from here? None as far
    as I can see.

    Grant.
    --
    http://bugsplatter.id.au/

  14. Re: This is why I use slackware

    On Mon, 6 Oct 2008 21:21:41 +0000 (UTC), Sylvain Robitaille wrote:

    >Grant wrote:
    >
    >> Stuff getting out on a router firewall box goes via the FORWARD chain
    >> in any case, not the OUTPUT chain.

    >
    >I believe the package in question is intended to be run on the end-user
    >system, not a router/firewall system. Think "personal firewall" in the
    >Windows-world.
    >
    >> Well DROP, is better here. REJECT advertises each port as being there
    >> but closed. DROP leaves the remote in the dark...

    >
    >Which leads me to argue that REJECT is better: send them away believing
    >there's nothing at that port, rather than letting them know the port is
    >"filtered". DROP doesn't leave the scanner in the dark, it makes it
    >quite clear that some firewall device is between them and the target
    >system.


    Now you confuse me -- at the moment my firewall cannot be OS profiled
    by nmap (a friend tried this recently) precisely because it does not
    do the default or expected response to port scans.

    On the other hand dropping traffic increases hits for TCP as the sender
    tries a couple more times in case the SYN packet was lost.
    >
    >> Given that the target audience for *buntu are crying out for help on any
    >> forum out there, it would be expected that many will blindly follow bad
    >> scripts / install procedures as good ones, no?

    >
    >Yes, of course. That's part of the problem ...


    Couple decades of windoze dumbing down the PC community led to it, and
    too many want to pop in an install CD/DVD for a free alternate windoze
    and *ubuntu has successfully targeted that audience.

    Grant.
    --
    http://bugsplatter.id.au/

  15. Re: This is why I use slackware

    On Mon, 06 Oct 2008 21:58:57 +0100, Peter Chant wrote:

    ....
    >Just thinking that, for a nedwbie who installs apache locally for web
    >development, or enables samba to share with windows having a deny incoming
    >firewall by default would potentially save a lot of embarisment.


    Yes, that's the type of thing I was thinking of too. I get lots
    of hits from windoze file sharing protocol, more 150 hits/day
    on ports 135, 139, 445 and 1433 -- mostly from my ISP's
    123.2.0.0/15 block that I'm on.

    Grant.
    --
    http://bugsplatter.id.au/

  16. Re: This is why I use slackware

    Sylvain Robitaille wrote:


    > What things are possible with, for simple examples, flash, javascript, or
    > more likely, java? Is it possible for a user to visit a website where a
    > java applet is then run on the user's computer, and that applet creates
    > connections back to the same (or different) remote site? I'm quite
    > certain that it is. Or, it launches a local program that makes remote
    > network access? I don't know if Javascript and flash have the same
    > possibilities, but I'm raising them as potential examples. I'm not a
    > web programmer, so I don't know the details of these possibilities.
    >


    Not too sure about the scripting languages you mention, most of the web
    development stuff I do is server end. However, I would suspect that anyone
    writing a malicious script would use a common port like 80 that has a good
    chance of passing outwards through a firewall. In this circumstance is
    there any point in blocking any other outgoing port if 80 is open?


    > Consider also the (perhaps extreme, in the case of a Linux personal
    > computer) example of a user clicking on an email attachment that results
    > in a script running locally on the user's behalf. We know that users of
    > other systems have encountered this, and we know the same possibility
    > exists on Linux, despite it being a significantly smaller target,
    > with a smaller potential impact. If we're examining the possibility,
    > though, we need to take this into account.
    >


    I don't think that would work with kmail, but I am not familiar with many
    other linux news clients.

    >> Just thinking that, for a nedwbie who installs apache locally for web
    >> development, or enables samba to share with windows having a deny
    >> incoming firewall by default would potentially save a lot of
    >> embarisment.

    >
    > I'm not disagreeing with you. I was simply proposing the sorts of
    > explanations I've received for similar scenarios in the past. I don't
    > claim to defend these arguments. Their validity, in my opinion, is
    > site-specific. Most users unfortunately don't have enough knowledge
    > (it seems) to make a suitably informed decision. :-(


    Sorry if my tone sounded combative. Trouble is, you & i can receive trojans
    and virii all day and not click on them, it's second nature.

    hmm - should I try opening one under wine to see what happens...
    (noting wine having access to $HOME perhaps not)


    --
    http://www.petezilla.co.uk

  17. Re: This is why I use slackware

    Grant wrote:


    > Yes, that's the type of thing I was thinking of too. I get lots
    > of hits from windoze file sharing protocol, more 150 hits/day
    > on ports 135, 139, 445 and 1433 -- mostly from my ISP's
    > 123.2.0.0/15 block that I'm on.


    Suspect they are from windows boxes looking for other machines on the same
    network rather than anything malicious, but I could be wrong!

    --
    http://www.petezilla.co.uk

  18. Re: This is why I use slackware

    On Tue, 07 Oct 2008 01:26:02 +0100, Peter Chant wrote:

    >Grant wrote:
    >
    >
    >> Yes, that's the type of thing I was thinking of too. I get lots
    >> of hits from windoze file sharing protocol, more 150 hits/day
    >> on ports 135, 139, 445 and 1433 -- mostly from my ISP's
    >> 123.2.0.0/15 block that I'm on.

    >
    >Suspect they are from windows boxes looking for other machines on the same
    >network rather than anything malicious, but I could be wrong!


    Well, not malicious, but the ISP could refuse to carry the stuff,
    but they account for two-way dataflow towards user quota so I suppose
    there's no incentive to reduce traffic.

    The other thing lately is an enormous increase in telnet hits, must
    some new kiddie-script out there? Who'd run a telnet server these days?

    Grant.
    --
    http://bugsplatter.id.au/

  19. Re: This is why I use slackware

    -----BEGIN PGP SIGNED MESSAGE-----
    Hash: SHA1

    On 2008-10-06, Sylvain Robitaille wrote:
    > Which leads me to argue that REJECT is better: send them away believing
    > there's nothing at that port, rather than letting them know the port is
    > "filtered". DROP doesn't leave the scanner in the dark, it makes it
    > quite clear that some firewall device is between them and the target
    > system.


    Unless of course you also DROP all other things that might let them
    know you exist and avoid sending any traffic they might intercept.
    This is plain bad practice though. Certain ICMP types need to be
    allowed through. And really, there is no practicle benefit to using
    DROP unless you find a particular port is constantly being hammered by
    illegitimate traffic. You could conceivably save some bandwith this
    way.

    >> Given that the target audience for *buntu are crying out for help on any
    >> forum out there, it would be expected that many will blindly follow bad
    >> scripts / install procedures as good ones, no?

    >
    > Yes, of course. That's part of the problem ...


    It's the same sort of problem you see in the Windows world. The answers
    generally boil down to "install this" or "run that" and "all your
    problems will go away". It's never that simple. The only real
    solutions to any computer problem are personal education, and/or hiring
    some one who knows more than you do to fix it.

    - --
    It is better to hear the rebuke of the wise,
    Than for a man to hear the song of fools.
    Ecclesiastes 7:5
    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.9 (GNU/Linux)

    iEYEARECAAYFAkjqvp8ACgkQkT+yo0QBUBubNwCeJDs895k6Ok +jLQu36c7aCdYs
    98AAn0IgNIeIWV0oLTYt5KXD5VX2yml5
    =ijEC
    -----END PGP SIGNATURE-----

  20. Re: This is why I use slackware

    On Tue, 07 Oct 2008 01:42:55 +0000, +Alan Hicks+ wrote:

    >On 2008-10-06, Sylvain Robitaille wrote:
    >> Which leads me to argue that REJECT is better: send them away believing
    >> there's nothing at that port, rather than letting them know the port is
    >> "filtered". DROP doesn't leave the scanner in the dark, it makes it
    >> quite clear that some firewall device is between them and the target
    >> system.

    >
    >Unless of course you also DROP all other things that might let them
    >know you exist and avoid sending any traffic they might intercept.
    >This is plain bad practice though. Certain ICMP types need to be
    >allowed through.


    Only one: ping request, is mandated. Other ICMPs that matter will be
    accepted via the ESTABLISHED,RELATED rule that must be part of accepting
    expected return traffic.

    > And really, there is no practicle benefit to using
    >DROP unless you find a particular port is constantly being hammered by
    >illegitimate traffic. You could conceivably save some bandwith this
    >way.


    Well, considering I'm on 512/128kbps ADSL somebody could hammer the box
    four times faster than the firewall can scream Ouch!

    Most abuse traffic I see here is more annoying than fending off attacks,
    like: my web site has one form, so some script kiddies in NL decide to
    hit the thing every few minutes for days on end -- until the usual ISP
    warning / whatever stops them -- but one persistent kiddie reappeared
    on a different IP from same ISP, apparently the same script going by
    the url-encoded response, by then I had them tagged and ignored. They
    didn't even notice the form now has validation timestamps in it -- so
    at least the server didn't have to waste effort generating a report
    the form produces.

    I do wonder whether being more 'correct', sending REJECT (port unreachable)
    for 'normal' TCP hits (useless responding to UDP spam, it's sent open loop --
    nobody's listening), then dropping offenders when they hit closed ports
    (the so-called adaptive firewall algorithm) too often is possibly better.

    I'm in the process of rewriting firewall rules at the moments and am
    watching the performance closely as I try different strategies. I've
    not it pays not to be too creative, doing anything too far from the
    like sending admin-prohibited can tweak a kiddies' curiosity and actually
    increase traffic. So reject, reset and drop are the options I fiddle
    with.

    I do like that default dropping results in nmap being unable to
    fingerprint the OS. And that's before playing with esoteric tricky
    stuff like chaostables.

    Grant.
    --
    http://bugsplatter.id.au/

+ Reply to Thread
Page 2 of 3 FirstFirst 1 2 3 LastLast