Problems with simple Samba file share
Sasquatch
reverting back to old settings about 1/2 hour after I change them. Can
someone please help? Here are the details...
I've set up a simple Samba file share on my MandrakeLinux Special
Edition 2005 server. Samba was already installed and running because
of the choices I made when I installed my linux distro. So all I had
to do (I think) is edit the smb.conf file, which I did. The only
change I made to smb.conf was to change the workgroup name to match the
workgroup on my home LAN, and I added the following section to the very
bottom of the smb.conf file:
# This one is useful for people to share files
[share]
comment = Shared files
path = /home/share
read only = no
writable = yes
browseable = yes
public = yes
Then I ran the Konquerer file manager with root privileges (kdesu
konqueror) and changed the permissions on the /home/share folder and
all of its contents so that the one and only user on my Linux system
has both read and write privileges, as does the group and all "others."
Once I made these changes, the new Samba share started showing up on my
Windows computers just as I suspected. Immediately I was able to
transfer files to the share from my Windows computers, rename files,
delete files, copy files, etc. Everything worked perfectly. ...but
only for about 1/2 hour. When it stopped working, I examined the
permissions, and they had changed back to "forbidden" for both "group"
and "others." I changed the permissions back to read and write, closed
Konqueror, and reopened Konqueror to check the privileges, and the
privilege changes were indeed sticking. But 1/2 hour later they
changed back AGAIN.
Why are these privileges reverting like this? I should also point out
that, a day before, prior to learning about the smb.conf file, I tried
setting up some kind of sharing of the same folder using some kind of
KDE utility, and I can't even remember which utility it was now. Ever
since, in Konqueror, the icon for the shared folder has had a slightly
different folder icon, as if it has a tiny picture of a power plug,
cable, or link, or something on it. This was before I even configured
Samba. Could this other sharing be conflicting with my Samba settings?
What are all the different utilities I can check to make sure this
share is set up properly and that there are no other sharing settings
that are conflicting?
Please help. Any assistance is greatly appreciated.
Thanks,
John
Chris F.A. Johnson
The permissions are probably being reset by msec, Mandrake's
security system. You can change the settings in
/usr/share/msec/perm.N, where N is your security level.
--
Chris F.A. Johnson <http://cfaj.freeshell.org>
==================================================================
Shell Scripting Recipes: A Problem-Solution Approach, 2005, Apress
<http://www.torfree.net/~chris/books/ssr.html>
Sasquatch
to this security service/system? Is there any documentation? I've
never heard of it before.
Again, thanks for the help.
- John
Chris F.A. Johnson
"If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson
On Sun, 08 May 2005 at 00:29 GMT, Sasquatch wrote:
> How do I know what my security level is? Isn't there a GUI interface
> to this security service/system? Is there any documentation? I've
> never heard of it before.
Mandrake Control Centre -> Security
Sasquatch
select that, the Mandrake Control Center starts. In the Mandrake
Control Center, there is a section called "Security." Under
"Security," there is only one choice: "Set up a firewall." I have not
set up a firewall because my home LAN is protected by a hardware
firewall. I do not see a choice for configuring security levels.
I recall that, while installing my distro, the firewall and the
security level were two different configurations. For firewall, I
elected to leave it turned off. For security level, I chose the second
highest level. The instructions said that the second highest level was
the lowest level that was adequate for running a server. In hindsight,
I probably should have chosen the lowest level. After all, I'm behind
a firewall, and this is not a mission critical server--it's for home
use. Unfortunately, now that I've finished intalling the distro, I
don't see an option to change the security level.
Do you have any advice on how I can lower my security level? I know
where the config files for the different levels are, but how do I
change the level itself. Please advise.
Also, I really think I configured some kind of share somewhere else
because the folder icon for /home/share has a different icon. What are
the various places where sharing can be configured so I can check?
- Sasquatch
Chris F.A. Johnson
>
> Chris F.A. Johnson wrote:
>> "If you want to post a followup via groups.google.com, don't use
>> the broken "Reply" link at the bottom of the article. Click
> on
>> "show options" at the top of the article, then click on the
>> "Reply" at the bottom of the article headers." - Keith
> Thompson
>>
>> On Sun, 08 May 2005 at 00:29 GMT, Sasquatch wrote:
>> > How do I know what my security level is? Isn't there a GUI
> interface
>> > to this security service/system? Is there any documentation? I've
>> > never heard of it before.
>>
>> Mandrake Control Centre -> Security
[please don't top post]
> Okay, in my KDE menu, I have System > Configure Your Computer. When I
> select that, the Mandrake Control Center starts. In the Mandrake
> Control Center, there is a section called "Security." Under
> "Security," there is only one choice: "Set up a firewall." I have not
> set up a firewall because my home LAN is protected by a hardware
> firewall. I do not see a choice for configuring security levels.
Then use the Mandrake Control Centre. I don't know where it is in
the KDE menu maze, but from a shell the command is mcc.
One of the selections is Security.
> I recall that, while installing my distro, the firewall and the
> security level were two different configurations. For firewall, I
> elected to leave it turned off. For security level, I chose the second
> highest level. The instructions said that the second highest level was
> the lowest level that was adequate for running a server. In hindsight,
> I probably should have chosen the lowest level. After all, I'm behind
> a firewall, and this is not a mission critical server--it's for home
> use. Unfortunately, now that I've finished intalling the distro, I
> don't see an option to change the security level.
>
> Do you have any advice on how I can lower my security level? I know
> where the config files for the different levels are, but how do I
> change the level itself. Please advise.
mcc
> Also, I really think I configured some kind of share somewhere else
> because the folder icon for /home/share has a different icon. What are
> the various places where sharing can be configured so I can check?
Tony Lawrence
> Okay, in my KDE menu, I have System > Configure Your Computer. When I
> select that, the Mandrake Control Center starts. In the Mandrake
> Control Center, there is a section called "Security." Under
> "Security," there is only one choice: "Set up a firewall." I have not
> set up a firewall because my home LAN is protected by a hardware
> firewall.
Just curious about other folks opinions: I always use a hardware
firewall but I always setup software iptables or whatever also, and
explicitly disable services I don't want. I then completely remove
anything that I don't intend to use at all. On top of that I add pam
controls for various things, and will do redundancy like only allowing
public key authentication for ssh but also using pam to limit failed
login attempts.
Maybe right now the firewall only allows ssh from a specific set of ip's
but that might have to be changed, so I have key authentication only, no
logins. On top of that, I'll only have certain users allowed for ssh,
and so on.
When I suddenly have to open up part of that for whatever reason, I
already have the other protections in place. Yeah, sometimes it's
annoying because I have to tear down several barriers to get what I
need, but it's comforting to think that someone deliberately trying to
breach me would be hampered in the same ways - so if they managed to
break through the hardware firewall, the machine's iptables still should
stop them, etc.
I know there are other folks just as compulsive and maybe even more so,
but is that more prevalent than " I have not set up a firewall because
my home LAN is protected by a hardware firewall" ?
--
Tony Lawrence
Unix/Linux/Mac OS X resources: http://aplawrence.com
Peter T. Breuer
> I know there are other folks just as compulsive and maybe even more so,
> but is that more prevalent than " I have not set up a firewall because
> my home LAN is protected by a hardware firewall" ?
I have never set up any protective firewall. I have been on a T1
backbone for nigh on twenty years. I run slackware 3.0 (vintage 1996, I
think). A quick nmap shows at least the following ports open:
PORT STATE SERVICE
7/tcp open echo
9/tcp open discard
11/tcp open systat
13/tcp open daytime
15/tcp open netstat
19/tcp open chargen
21/tcp open ftp
22/tcp open ssh
23/tcp open telnet
25/tcp open smtp
37/tcp open time
53/tcp open domain
79/tcp open finger
80/tcp open http
110/tcp open pop3
111/tcp open rpcbind
113/tcp open auth
139/tcp open netbios-ssn
143/tcp open imap
513/tcp open login
514/tcp open shell
587/tcp open submission
640/tcp open unknown
643/tcp open unknown
727/tcp open unknown
739/tcp open unknown
782/tcp open hp-managed-node
873/tcp open rsync
992/tcp open telnets
993/tcp open imaps
995/tcp open pop3s
1110/tcp open nfsd-status
1337/tcp open waste
2049/tcp open nfs
2401/tcp open cvspserver
6001/tcp open X11:1
6002/tcp open X11:2
7100/tcp open font-service
10000/tcp open snet-sensor-mgmt
and a few more that I would be forced to kill you if I told you about.
Peter
Tony Lawrence
OK :-)
So your point must be what? The software you run can't be compromised?
Are you pulling my leg? You must be..
Michael Heiming
> Tony Lawrence <f...@pcunix.com> wrote:
>> I know there are other folks just as compulsive and maybe even more so,
>> but is that more prevalent than " I have not set up a firewall because
>> my home LAN is protected by a hardware firewall" ?
> I have never set up any protective firewall. I have been on a T1
> backbone for nigh on twenty years. I run slackware 3.0 (vintage 1996, I
> think). A quick nmap shows at least the following ports open:
[ bunch of open ports ]
> and a few more that I would be forced to kill you if I told you about.
Man, my box, which is my firewall is drilled down it doesn't even
allow me to run nmap:
sendto in send_ip_packet: sendto(3, packet, 40, 0,
xxx.xxx.xxx.xxx, 16) => Operation not permitted
OK, could fire up another box, which would work.
Anyway, you seem to have somewhere else a firewall up, most ports
can't (luckily) be reached from the outside.
Personally don't trust any "hardware" firewall, use iptables and
don't allow anything despite ssh from a few systems.
Have limited logging to a small amount, so logs don't tell
anything, looks like the usual crap:
First incident: May 8 04:10:01 - Last one: May 8 12:39:17
Denied by fw in this time (count): 54
Top 10 IP
22 SRC=80.131.89.65
7 SRC=127.0.0.1
2 SRC=80.131.62.146
2 SRC=80.131.127.12
2 SRC=38.113.214.15
1 SRC=83.42.37.55
1 SRC=80.131.96.154
1 SRC=80.131.89.25
1 SRC=80.131.85.129
1 SRC=80.131.77.168
port incidents
20 DPT=24441
13 DPT=135
7 DPT=445
2 DPT=49142
2 DPT=49141
2 DPT=4672
1 DPT=636
1 DPT=49156
1 DPT=49150
1 DPT=23
1 DPT=22
1 DPT=1433
1 DPT=119
1 DPT=1026
Have to take a look what app on my own system tried "microsoft-ds".
--
Michael Heiming (X-PGP-Sig > GPG-Key ID: EDD27B94)
mail: echo zvp...@urvzvat.qr | perl -pe 'y/a-z/n-za-m/'
#bofh excuse 50: Change in Earth's rotational speed
Sasquatch
hardware-firewall-only approach is advisable. It's just that, for me,
it's all I need. This is my home network. There is nothing to
compromise. I have some important files, but they're on a different
machine, and I'm confident that they cannot be accessed from outside my
network, so that's all I care about. I'm not a masochistic "armchair
network administrator" who is going to spend days securing a system
when there is no need, and I don't even have a desire to learn. Now if
I was setting this machine up for an employer, I would certainly be as
careful as possible.
If you're wondering how many people are careful like you are... I
would say that people with a network security background are going to
tend to set up their machines like you do just because (1) they know
how and (2) they tend to take security more seriously, even when there
isn't a real need. But, amongst people like myself who are not Linux
experts nor network security gurus, I think we're going to tend to just
set up basic security and be satisfied with that.
- Sasquatch
Peter T. Breuer
> how and (2) they tend to take security more seriously, even when there
> isn't a real need. But, amongst people like myself who are not Linux
> experts nor network security gurus, I think we're going to tend to just
> set up basic security and be satisfied with that.
But what do you think a firewall protects you from? (if the answer is
"I don't know", then you want to ask yourself some deeper questions).
Peter
Peter T. Breuer
> In comp.os.linux.misc Peter T. Breuer <p...@lab.it.uc3m.es>:
> [ bunch of open ports ]
> > and a few more that I would be forced to kill you if I told you about.
> Man, my box, which is my firewall is drilled down it doesn't even
> allow me to run nmap:
It has you handcuffed to the wall!
> sendto in send_ip_packet: sendto(3, packet, 40, 0,
> xxx.xxx.xxx.xxx, 16) => Operation not permitted
How come you don't have capability to send packets? Or is
that just the outgoing rules on your firewall blocking it?
> Anyway, you seem to have somewhere else a firewall up, most ports
> can't (luckily) be reached from the outside.
From outside I see only the following as blocked.
7/tcp closed echo
9/tcp closed discard
11/tcp closed systat
13/tcp closed daytime
15/tcp closed netstat
19/tcp closed chargen
25/tcp closed smtp
37/tcp closed time
53/tcp closed domain
79/tcp closed finger
111/tcp closed rpcbind
113/tcp closed auth
139/tcp closed netbios-ssn
513/tcp closed login
514/tcp closed shell
587/tcp closed submission
640/tcp closed unknown
643/tcp closed unknown
727/tcp closed unknown
739/tcp closed unknown
782/tcp closed hp-managed-node
992/tcp closed telnets
...
The rest seem to be reachable, including telnet, ftp, http, and so on.
But I don't know who's rejecting echo and discard and systat and daytime
and netstat, etc! Not me. That's annoying. It must be the uni. I
wish they wouldn't do that.
> Personally don't trust any "hardware" firewall, use iptables and
> don't allow anything despite ssh from a few systems.
I don't use any. I don't mind people trying to guess my password, at
six seconds the try.
> Have limited logging to a small amount, so logs don't tell
> anything, looks like the usual crap:
> First incident: May 8 04:10:01 - Last one: May 8 12:39:17
> Denied by fw in this time (count): 54
> Top 10 IP
> 22 SRC=80.131.89.65
> 7 SRC=127.0.0.1
Very few.
> Have to take a look what app on my own system tried "microsoft-ds".
Probably "the admin", while scanning.
Peter
Tony Lawrence
> I think it's good that you're so careful. I do not claim that my
> hardware-firewall-only approach is advisable. It's just that, for me,
> it's all I need. This is my home network. There is nothing to
> compromise. I have some important files, but they're on a different
> machine, and I'm confident that they cannot be accessed from outside my
> network, so that's all I care about. I'm not a masochistic "armchair
> network administrator" who is going to spend days securing a system
> when there is no need, and I don't even have a desire to learn. Now if
> I was setting this machine up for an employer, I would certainly be as
> careful as possible.
If any machine on your network can be accessed from the internet, then
potentially any other machine can be accessed.
If the files really are important, you might think about running a
software firewall on that machine anyway. Most systems (Windows or
Linux) have easy methods to set that up, at least for a basic
configuration, which is certainly better than nothing.
>
> If you're wondering how many people are careful like you are... I
> would say that people with a network security background are going to
> tend to set up their machines like you do just because (1) they know
> how and (2) they tend to take security more seriously, even when there
> isn't a real need. But, amongst people like myself who are not Linux
> experts nor network security gurus, I think we're going to tend to just
> set up basic security and be satisfied with that.
>
> - Sasquatch
>
I'm not a security professional and certainly not a guru in any sense.
I'm just paranoid and would rather be safe than sorry.
Tony Lawrence
I think a far more interesting question is why you seem to imply that no
firewall is needed at all.. if indeed that is what your posts in this
part of the thread mean to express.
Peter T. Breuer
> If any machine on your network can be accessed from the internet, then
> potentially any other machine can be accessed.
Oooh ... scary! But meaningless. The word "potentially" gives it away.
I think you are really saying "he has a internet connection in which all
incoming packets are not blocked, ?therefore? (maybe) he can be contacted".
So ^&((^ WHAT?
This isn't windows you know! (i.e. the fact that you can be talked to
doesn't mean that you are in danger of being infected with horrible
electronic diseases).
And incoming packets can't really be blocked if you want to talk out,
because communication is 2-way.
And you can only be contacted from outside if you have some server running
on a given port. Now why are you running it if you don't ant it to be
contacted? And if you want it to be contacted, but not from utide your
own network, then why haven't yu configured it like that?
A firewall merely prevents certain specified froms of accss (either
way). It doesn't stop physical access. It doesn't stop trojans. It
doesn't stop you doibg something silly on a web page (java stops that).
It doesn't stop you running something you received in the mail.
In short, it's only use is on a multimachine network where the admin
can't be boothered to or does not have authority to go round all the
machines on the local network turning off or reconfiguring services
which are not intended.
But you, of course, have no such problem! Unless you are running a
windows machine. And then the windows machine is the problem.
Peter
Peter T. Breuer
> I think a far more interesting question is why you seem to imply that no
> firewall is needed at all..
Of course it isn't needed. What on earth for?
Peter
jeff
I'm really happy to see that the world has still not accepted the
"wisdom" of your firewall-is-unnecessary nonsense. Extra protection
against unanticipated configuration blunders, malicious activity, etc.
is always a good thing.
Give it up Peter. And please proof-read your posts. It's hard to have
any faith at all in a message so loaded with errors.
Jeff
Alexander Skwar
> I think a far more interesting question is why you seem to imply that no
> firewall is needed at all.. if indeed that is what your posts in this
> part of the thread mean to express.
Dunno about him, but he's right. Packet filters are normally not
needed. Just disable the services ("daemons") that are not needed
and that's it. No need for useless stacks of complexity.
Alexander Skwar
--
You will pass away very quickly.
Tony Lawrence
> Tony Lawrence <f...@pcunix.com> wrote:
>
>>If any machine on your network can be accessed from the internet, then
>>potentially any other machine can be accessed.
>
>
> Oooh ... scary! But meaningless. The word "potentially" gives it away.
> I think you are really saying "he has a internet connection in which all
> incoming packets are not blocked, ?therefore? (maybe) he can be contacted".
No. I'm saying he's put all of his protection on one device. That's
something that might have its own weakness: it's hardly unheard of for a
firewall device to be compromised. If so, that's a foot in the door,
and I'd rather have that simply be the first lock encountered, not the only.
>
> So ^&((^ WHAT?
>
> This isn't windows you know! (i.e. the fact that you can be talked to
> doesn't mean that you are in danger of being infected with horrible
> electronic diseases).
First, you and I do not know that the "other machines" are not, in fact,
Windows. It's quite common, you know: here in my office I have several
Linux boxes, a Mac, and a Windows XP machine, plus a few test boxes that
might be running almost anything at any given moment.
>
> And incoming packets can't really be blocked if you want to talk out,
> because communication is 2-way.
Yes, though firewalls keep track of packets that belong to conversations
that originated from within and treat those differently. That can be
fooled, of course, but that isn't as easy as having an open invitatation
to walk in the door, is it?
>
> And you can only be contacted from outside if you have some server running
> on a given port. Now why are you running it if you don't ant it to be
> contacted? And if you want it to be contacted, but not from utide your
> own network, then why haven't yu configured it like that?
True. But software does have problems now and then, both in design and
in configuration. I may (and do) wish to allow various services within
my network. Each is configured that way as you suggest. But why should
I trust to only that? I don't: even though the service specifically
isn't listening for outside connections, and even though its
configuration may tell it to reject any that somehow arrive, I think it
only makes sense to also have iptables block it, and to do the same at
my hardware firewall.
>
> A firewall merely prevents certain specified froms of accss (either
> way). It doesn't stop physical access. It doesn't stop trojans. It
> doesn't stop you doibg something silly on a web page (java stops that).
> It doesn't stop you running something you received in the mail.
Actually some types of firewalls do full packet inspection and can block
trojans and other unpleasantries.
>
> In short, it's only use is on a multimachine network where the admin
> can't be boothered to or does not have authority to go round all the
> machines on the local network turning off or reconfiguring services
> which are not intended.
I don't agree. A software firewall is also of value on an internal
machine with only one network connection. Agreed, you absolutely should
turn off services also. But services can be accidentally (or otherwise)
turned on or misconfigured due to ignorance or design flaw. Many,
many times I have seen people allow more access than they intended -
especially with web servers.
>
> But you, of course, have no such problem! Unless you are running a
> windows machine. And then the windows machine is the problem.
>
> Peter
Windows machines are an unfortunate necessity in many networks, both
business and home. That's just reality. I'd prefer a different world,
but I have to deal with what is, not with what I'd like.
Tony Lawrence
OK, Peter. I see were going to descend into foolishness, aren't we?
A firewall gives extra protection. Banks have interior vaults, but
they still lock their exterior doors when they are closed, don't they?
Often those vaults are on time locks that cannot be opened even if you
have the combination. And they monitor the tightly locked up assets
with security camera too.. What on earth for?
Michael Heiming
> Michael Heiming <michael...@www.heiming.de> wrote:
>> In comp.os.linux.misc Peter T. Breuer <p...@lab.it.uc3m.es>:
>> [ bunch of open ports ]
>> > and a few more that I would be forced to kill you if I told you about.
>> Man, my box, which is my firewall is drilled down it doesn't even
>> allow me to run nmap:
> It has you handcuffed to the wall!
Yep, works as designed.;-) Only things explicit allowed will pass
if the source is the firewall itself.
>> sendto in send_ip_packet: sendto(3, packet, 40, 0,
>> xxx.xxx.xxx.xxx, 16) => Operation not permitted
> How come you don't have capability to send packets? Or is
> that just the outgoing rules on your firewall blocking it?
My own firewall.
>> Anyway, you seem to have somewhere else a firewall up, most ports
>> can't (luckily) be reached from the outside.
> From outside I see only the following as blocked.
[ more ports]
> 727/tcp closed unknown
> 992/tcp closed telnets
> ...
> The rest seem to be reachable, including telnet, ftp, http, and so on.
Not from outside your network, at least telnet, or you don't run
anything on the port?
> But I don't know who's rejecting echo and discard and systat and daytime
> and netstat, etc! Not me. That's annoying. It must be the uni. I
> wish they wouldn't do that.
Probably they are only concerned about your security, fear you
can't do much unless you control the outside fw(s).
>> Personally don't trust any "hardware" firewall, use iptables and
>> don't allow anything despite ssh from a few systems.
> I don't use any. I don't mind people trying to guess my password, at
> six seconds the try.
Of course you don't really need one, if you know what you are
doing. Anyway if you need to NAT, you have to use iptables and an
additional fw doesn't let you come clean if there's some local
misconfiguration or/and vulnerability. Safer to turn it on if
your system is 24/7 connected to the internet. IMHO security is
like an onion, the more layer the better.
In reality, I'm much more concerned about spam and spammer
actually forging my domain to send out their crap, hopefully it
wont be RBL registered one day, thx to the idiots, who can't be
punished hard enough:
http://www.userfriendly.org/cartoons/archives/05apr/uf007810.gif
>> Have limited logging to a small amount, so logs don't tell
>> anything, looks like the usual crap:
>> First incident: May 8 04:10:01 - Last one: May 8 12:39:17
>> Denied by fw in this time (count): 54
>> Top 10 IP
>> 22 SRC=80.131.89.65
>> 7 SRC=127.0.0.1
> Very few.
Yup "-m limit" is heavily used, don't care about the bloat in the
logs which might lead to DOS if file space gets used and I
wouldn't like to wait login until one of my cron jobs kicks in
and clears up the mess.
Using tcpdump one can see all those p2p and alike dudes smashing
a couple of times per second against the box 24/7.
>> Have to take a look what app on my own system tried "microsoft-ds".
> Probably "the admin", while scanning.
Sounds most reasonable.;)
--
Michael Heiming (X-PGP-Sig > GPG-Key ID: EDD27B94)
mail: echo zvp...@urvzvat.qr | perl -pe 'y/a-z/n-za-m/'
#bofh excuse 431: Borg implants are failing
Tony Lawrence
OK, at least two people who think this way. I sure don't.. and I don't
see it as "useless stacks of complexity" but rather as additional
protection.
Peter T. Breuer
> Peter T. Breuer wrote:
> > Tony Lawrence <f...@pcunix.com> wrote:
> >
> >>I think a far more interesting question is why you seem to imply that no
> >>firewall is needed at all..
> >
> >
> > Of course it isn't needed. What on earth for?
> OK, Peter. I see were going to descend into foolishness, aren't we?
> A firewall gives extra protection.
Against what?
(I am trying to get you to name a scenario against which it protects,
instead of mouthing vague generalities that may or may not be true!).
Peter
Peter T. Breuer
> > The rest seem to be reachable, including telnet, ftp, http, and so on.
> Not from outside your network, at least telnet, or you don't run
> anything on the port?
I am at home. I can reach all the ports on my server at work (which
are open) apart from the ones I listed. Including telnet:
pebbles:/usr/oboe/ptb% telnet oboe
Connected to oboe
Escape character is '^]'.
...
(it's protected by tcpwrapper, so it won't speak long, but that's
orthogonal).
> > But I don't know who's rejecting echo and discard and systat and daytime
> > and netstat, etc! Not me. That's annoying. It must be the uni. I
> > wish they wouldn't do that.
> Probably they are only concerned about your security, fear you
> can't do much unless you control the outside fw(s).
I would really get tired echoing all those ascii packets. Or discarding
them.
> > I don't use any. I don't mind people trying to guess my password, at
> > six seconds the try.
> Of course you don't really need one, if you know what you are
> doing. Anyway if you need to NAT, you have to use iptables and an
> additional fw doesn't let you come clean if there's some local
> misconfiguration or/and vulnerability. Safer to turn it on if
> your system is 24/7 connected to the internet. IMHO security is
> like an onion, the more layer the better.
Oh, it's safer, but the protection is against your own failings (when
you are in charge of the machines on your local net)!
> In reality, I'm much more concerned about spam and spammer
> actually forging my domain to send out their crap, hopefully it
> wont be RBL registered one day, thx to the idiots, who can't be
> punished hard enough:
That DCC thing in the newest SA really seems to have got the last of
the spam that crept through before. On my slack 3.0 machine!
> http://www.userfriendly.org/cartoons/archives/05apr/uf007810.gif
I didn't know you also read them! They're currently going through an
australian experience ...
Peter
Peter T. Breuer
> I'm really happy to see that the world has still not accepted the
> "wisdom" of your firewall-is-unnecessary nonsense. Extra protection
> against unanticipated configuration blunders, malicious activity, etc.
You can't make any such "blunder".
(please _try_ the thought exercise!)
> is always a good thing.
> Give it up Peter. And please proof-read your posts. It's hard to have
> any faith at all in a message so loaded with errors.
I write, not read. My keyboard is too dusty to record accurately what I
type. While I'm sorry about that, I don't have time to reread and
correct it.
Peter
Tony Lawrence
I have given examples, and so have other people. It hasn't been vague
generalities at all. A firewall protects against software deficiency and
accidental misconfiguration. It can also act to limit the extent of
other security breaches. As someone else noted, some of us prefer to
have layers of security.
I have a server that accepts ssh connections, but only from a specific
set of IP's. Additionally, ssh is configured only to accept specific
users, and additionally only allows public key authentication. Beyond
that, it's configured to lock out after two incorrect passwords - which
of course can't be given because it doesn't accept passwords. That
server is also protected by a hardware firewall and iptables. Most of
this is completely redundant, but that's the point: redundancy protects
against error, either on my part or in the ssh daemon iteslf. If an
exploit comes out for ssh that can bypass my configuration rules, the
firewall rules that limit it to specific ip's may protect me. The
iptables (which you consider pointless) is enforcing the same rules that
the hardware firewall is - so if I accidentally scew up one or the
other, or an exploit is discovered that can breach either one, I may
still be protected by the other.
Gee, Peter, you haven't become abusive yet.. I wonder how much longer
that will last. Are we actually going to have a thread that doesn't
include you impugning my intelligence?
Tony Lawrence
> jeff <ne...@invalid.spam> wrote:
>
>>I'm really happy to see that the world has still not accepted the
>>"wisdom" of your firewall-is-unnecessary nonsense. Extra protection
>>against unanticipated configuration blunders, malicious activity, etc.
>
>
> You can't make any such "blunder".
>
> (please _try_ the thought exercise!)
Perhaps YOU can't make mistakes, and your system software is somehow
defect free, but I think the rest of us live in a rather different world.
jeff
I might need to enable a service for a given set of users (say a local
subnet) but may need to disable the service to the wider audience. In
this case, I can't disable the service. I can certainly apply
host_access or whatever other protections are available, but I could
also misconfigure any such protection. A firewall simply offers an
additional layer of centralized protection against these types of
potential problems.
Jeff
Peter T. Breuer
> Peter T. Breuer wrote:
> > Tony Lawrence <f...@pcunix.com> wrote:
> >>If any machine on your network can be accessed from the internet, then
> >>potentially any other machine can be accessed.
> >
> > Oooh ... scary! But meaningless. The word "potentially" gives it away.
> > I think you are really saying "he has a internet connection in which all
> > incoming packets are not blocked, ?therefore? (maybe) he can be contacted".
> No. I'm saying he's put all of his protection on one device.
So you want him to have two firewalls, in series?
> That's
> something that might have its own weakness: it's hardly unheard of for a
> firewall device to be compromised.
It's harder if it's a hardware device, but not impossible. Having an IP
address for configuration plus a well-known default password is
normally the give-away. But the firewall will only respond to local
accesses :-). You would first have to compromise the next router along.
Easier with a wireless router, of course.
Anyway, it's moot - nobody in their right minds bothers to try and
crack in the hard way. Your password would be stolen somewhere else, and
a legitimate login method used.
> If so, that's a foot in the door,
Try and stay away from generalities. Name the specific attack scenario,
and the defense, that you have in mind.
> and I'd rather have that simply be the first lock encountered, not the only.
The same thing that compromised your first defense would compromise the
second, if your imagined attack is what I think it is.
And anyway ...
> > So ^&((^ WHAT?
So what?
> > This isn't windows you know! (i.e. the fact that you can be talked to
> > doesn't mean that you are in danger of being infected with horrible
> > electronic diseases).
> First, you and I do not know that the "other machines" are not, in fact,
> Windows.
Oh yes "we" do. I do. Look ... no windows machines here!
> It's quite common, you know: here in my office I have several
> Linux boxes, a Mac, and a Windows XP machine,
Good for you, but that is the only situation in which a firewall gives
you protection - when you are not the master of the machines on your
local net. Having a windows machine means that you are not.
However, on a net composed of linux machines on which you are root,
you are the master.
How about if you are worried about what your users can do?
I'm sorry, they can do whatever they like within the confines of their
non-root privileges. If you are worried about what they do, the only
useful thing I can think a firewall might do is prohibit incoming
to ports above 1024 (mind you, that will kill your legitimate
services also too often).
> plus a few test boxes that
> might be running almost anything at any given moment.
Good. Prime candidates for use of a firewall - lack of control.
> > And incoming packets can't really be blocked if you want to talk out,
> > because communication is 2-way.
> Yes, though firewalls keep track of packets that belong to conversations
> that originated from within and treat those differently. That can be
> fooled, of course, but that isn't as easy as having an open invitatation
> to walk in the door, is it?
Please do not use analogies. A packet is a packet. Nothing else.
> > And you can only be contacted from outside if you have some server running
> > on a given port. Now why are you running it if you don't want it to be
> > contacted? And if you want it to be contacted, but not from outside your
> > own network, then why haven't you configured it like that?
> True. But software does have problems now and then, both in design and
> in configuration.
You have the distro's updates. That's what they're for.
> I may (and do) wish to allow various services within
> my network. Each is configured that way as you suggest.
Good control.
> But why should
> I trust to only that?
Because you have control. Are you trying to protect yourself against
your own failings? Fix yourself, then. And anyway, so what if somebody
outside can reach one of your precious "internal" services? They can
get in to your net a legitimate way (stolen password, http redirect, ftp
proxy, etc.) first and reach the service from inside if they really
want to.
> I don't: even though the service specifically
> isn't listening for outside connections, and even though its
> configuration may tell it to reject any that somehow arrive, I think it
> only makes sense to also have iptables block it, and to do the same at
> my hardware firewall.
You are making life hard for yourself when you want to change things
(that's OK!).
> > A firewall merely prevents certain specified froms of accss (either
> > way). It doesn't stop physical access. It doesn't stop trojans. It
> > doesn't stop you doibg something silly on a web page (java stops that).
> > It doesn't stop you running something you received in the mail.
> Actually some types of firewalls do full packet inspection and can block
> trojans and other unpleasantries.
No they can't - they have no way of telling that the source code you
just downloaded to compile and install contains a trick in its Makefile
that sets up an open root listener at 12pm to 12.05 pm on a port number
derived from your IP address.
> > In short, it's only use is on a multimachine network where the admin
> > can't be boothered to or does not have authority to go round all the
> > machines on the local network turning off or reconfiguring services
> > which are not intended.
> I don't agree. A software firewall is also of value on an internal
> machine with only one network connection.
That's when it is NOT useful.
> Agreed, you absolutely should
> turn off services also. But services can be accidentally (or otherwise)
> turned on or misconfigured due to ignorance or design flaw.
It doesn't matter - the services only do what they are supposed to do.
If they have a vulnerability, it would already have been fixed by your
ditro before you get exploited by it.
> Many,
> many times I have seen people allow more access than they intended -
> especially with web servers.
Web servers are supposed to allow universal access. Or are you talking
about cgi and .htaccess? You can't seriously intend to configure the
firewall to allow access to http dirs by source address! Whatever
happened to authentication ...
> > But you, of course, have no such problem! Unless you are running a
> > windows machine. And then the windows machine is the problem.
> Windows machines are an unfortunate necessity in many networks, both
> business and home. That's just reality. I'd prefer a different world,
> but I have to deal with what is, not with what I'd like.
A firewall is useful on a network where you do not control all the
machines. A windows machine on your net means that that criterion is
satisfied.
Peter
Peter T. Breuer
> Peter T. Breuer wrote:
> > (I am trying to get you to name a scenario against which it protects,
> > instead of mouthing vague generalities that may or may not be true!).
> I have given examples, and so have other people. It hasn't been vague
Please quote. I have seen only fuzzy generalities.
> I have a server that accepts ssh connections, but only from a specific
> set of IP's.
Ah good! An example!
Why restrict ssh? There's no point in restricting ssh. Nobody can log
in through it without your password and/or digital key, no matter where
they try from. And the whole idea is to give you access wherever you
are calling from, securely.
> Additionally, ssh is configured only to accept specific
> users,
Nobody unauthorised can log in. If you don't want somebody in
particular to log in through ssh, why have you given him a password on
your machine?
> and additionally only allows public key authentication.
Why do you think that he has kept his private key secure? Or do you
mean that the client must present a certificate? (normally we do not
care WHERE we are logging in from! The point of ssh is to allow you to
log in from unexpected places, or expected places, securely, with
authetication).
> Beyond
> that, it's configured to lock out after two incorrect passwords - which
No point - there's a 6 second delay anyway, and I type badly. And it
helps somebody steal the password by using a fake ssh frontend that
aborts the connect after stealing the password.
> of course can't be given because it doesn't accept passwords. That
> server is also protected by a hardware firewall and iptables. Most of
> this is completely redundant,
It worse - it does nothing. You don't want to restrict ssh entries,
because the point of ssh is to allow _secure_ entries from anywhere. You
try logging in from your laptop on an internet cafe otherwise!
(I knew this would be the case - any example of a server that needs
restriction is likely to be an example of a server that is prevented
from doing what it is supposed to be doing; and it would do that
safely, if left to itself; because that's what it is supposed to do).
Peter
Peter T. Breuer
> Perhaps YOU can't make mistakes, and your system software is somehow
Just try the exercise. I won't trade vague FUD.
Peter
Michael Heiming
>> > The rest seem to be reachable, including telnet, ftp, http, and so on.
>> Not from outside your network, at least telnet, or you don't run
>> anything on the port?
> I am at home. I can reach all the ports on my server at work (which
> are open) apart from the ones I listed. Including telnet:
> pebbles:/usr/oboe/ptb% telnet oboe
> Connected to oboe
> Escape character is '^]'.
> ...
> (it's protected by tcpwrapper, so it won't speak long, but that's
> orthogonal).
$ telnet xxx.xxx.xxx.xxx
Trying xxx.xxx.xxx.xxx...
telnet: Unable to connect to remote host: Connection refused
Exactly, doesn't really feels like a fw.;) Personally I'm using
tcpwrapper for critical services in addition, just in case should
there be a problem with the fw. ;-)
[..]
>> > I don't use any. I don't mind people trying to guess my password, at
>> > six seconds the try.
>> Of course you don't really need one, if you know what you are
>> doing. Anyway if you need to NAT, you have to use iptables and an
>> additional fw doesn't let you come clean if there's some local
>> misconfiguration or/and vulnerability. Safer to turn it on if
>> your system is 24/7 connected to the internet. IMHO security is
>> like an onion, the more layer the better.
> Oh, it's safer, but the protection is against your own failings (when
> you are in charge of the machines on your local net)!
Or/and new vulnerabilities or whatever. People asking questions
here don't have decades of *nix experience under their belt like
you. Quite often we can be be lucky if they manage to find some
xterm or/and get the idea of applying patches on a regular base.
Some basic fw as setup by many modern distro provide with easy
tools is a good thing[tm] for them.
Bear in mind the ever growing amount of people sick of doze,
trying out Linux. They don't know anything about TCP/IP and
alike, how should they? Just clicking on some colorful buttons
until the next reboot.
Now many of them aren't going to take the time to learn about
Linux, they just want the same colorful environment without all
the problems doze systems face.
>> In reality, I'm much more concerned about spam and spammer
>> actually forging my domain to send out their crap, hopefully it
>> wont be RBL registered one day, thx to the idiots, who can't be
>> punished hard enough:
> That DCC thing in the newest SA really seems to have got the last of
> the spam that crept through before. On my slack 3.0 machine!
After updating SA to 3.0.3, things have improved dramatically
again, missed updating for a week or so, should setup some cron
job warning me daily just in case a new SA version is available.
>> http://www.userfriendly.org/cartoons/archives/05apr/uf007810.gif
> I didn't know you also read them! They're currently going through an
> australian experience ...
Reading is to much, from time to time pick up an URL somewhere.;)
Perhaps I'll take a closer look.
--
Michael Heiming (X-PGP-Sig > GPG-Key ID: EDD27B94)
mail: echo zvp...@urvzvat.qr | perl -pe 'y/a-z/n-za-m/'
#bofh excuse 334: 50% of the manual is in .pdf readme files
Tony Lawrence
> Tony Lawrence <f...@pcunix.com> wrote:
>
>>Peter T. Breuer wrote:
>>
>>>Tony Lawrence <f...@pcunix.com> wrote:
>>>
>>>>If any machine on your network can be accessed from the internet, then
>>>>potentially any other machine can be accessed.
>>>
>>>Oooh ... scary! But meaningless. The word "potentially" gives it away.
>>>I think you are really saying "he has a internet connection in which all
>>>incoming packets are not blocked, ?therefore? (maybe) he can be contacted".
>
>
>>No. I'm saying he's put all of his protection on one device.
>
>
> So you want him to have two firewalls, in series?
I don't care what HE does. But two firewalls is indeed what I do.
>
>
>>That's
>>something that might have its own weakness: it's hardly unheard of for a
>>firewall device to be compromised.
>
>
> It's harder if it's a hardware device, but not impossible. Having an IP
> address for configuration plus a well-known default password is
> normally the give-away. But the firewall will only respond to local
> accesses :-). You would first have to compromise the next router along.
> Easier with a wireless router, of course.
Firewalls often are configured to allow remote configuration. I'm not
saying they SHOULD be left this way, but they often are. That's not the
only possible breach, though. Many firewalls have some sort of shell
that in theory could be accessed by some unknown exploit.
>
> Anyway, it's moot - nobody in their right minds bothers to try and
> crack in the hard way. Your password would be stolen somewhere else, and
> a legitimate login method used.
Well, gosh then: must be a lot of people not in their right minds
because my logs are full of people trying both easy and hard ways..
>
>
>
>>If so, that's a foot in the door,
>
>
> Try and stay away from generalities. Name the specific attack scenario,
> and the defense, that you have in mind.
That's the whole point, Peter: new exploits come along almost daily.
Security isn't just about protecting from specific scenarios. Multiple
layers are more likely to thwart unexpected attack vectors.
>
>
>>and I'd rather have that simply be the first lock encountered, not the only.
>
>
> The same thing that compromised your first defense would compromise the
> second, if your imagined attack is what I think it is.
It would? So an error in iptables automatically causes the same error
in the software of my hardware firewall?
>>Yes, though firewalls keep track of packets that belong to conversations
>>that originated from within and treat those differently. That can be
>>fooled, of course, but that isn't as easy as having an open invitatation
>>to walk in the door, is it?
>
>
> Please do not use analogies. A packet is a packet. Nothing else.
Nonsense. Packet inspection at an external firewall can identify
specific attacks. You might want to read "Intrusion Prevention and
Active Response" which I reviewed at
http://aplawrence.com/Books/intrusionpreventionsystems.html
>
>
>
>>>And you can only be contacted from outside if you have some server running
>>>on a given port. Now why are you running it if you don't want it to be
>>>contacted? And if you want it to be contacted, but not from outside your
>>>own network, then why haven't you configured it like that?
>
>
>>True. But software does have problems now and then, both in design and
>>in configuration.
>
>
> You have the distro's updates. That's what they're for.
Huh? So the moment an exploit is discovered, updates are instantly
available (fully debugged, of course) and can be instantly deployed on
your machines. You must live in a very different world than I do :-)
>
>
>
>>I may (and do) wish to allow various services within
>>my network. Each is configured that way as you suggest.
>
>
> Good control.
>
>
>>But why should
>>I trust to only that?
>
>
> Because you have control. Are you trying to protect yourself against
> your own failings? Fix yourself, then. And anyway, so what if somebody
> outside can reach one of your precious "internal" services? They can
> get in to your net a legitimate way (stolen password, http redirect, ftp
> proxy, etc.) first and reach the service from inside if they really
> want to.
My failings, my errors, and of course any exploits as discussed above.
It is generally true that if someone badly wants to get in, sooner or
later they probably will - assuming they have the patience and resources
to do so. The same is true for someone who wants to steal my car -
except that's even easier. So why don't I just leave it unlocked with
the keys in it and the alarm disabled? Why bother to even try to
protect anything?
>
>
>>I don't: even though the service specifically
>>isn't listening for outside connections, and even though its
>>configuration may tell it to reject any that somehow arrive, I think it
>>only makes sense to also have iptables block it, and to do the same at
>>my hardware firewall.
>
>
> You are making life hard for yourself when you want to change things
> (that's OK!).
Yes, it is harder to change things. Absolutely true.
>
>
>
>
>>>A firewall merely prevents certain specified froms of accss (either
>>>way). It doesn't stop physical access. It doesn't stop trojans. It
>>>doesn't stop you doibg something silly on a web page (java stops that).
>>>It doesn't stop you running something you received in the mail.
>
>
>>Actually some types of firewalls do full packet inspection and can block
>>trojans and other unpleasantries.
>
>
> No they can't - they have no way of telling that the source code you
> just downloaded to compile and install contains a trick in its Makefile
> that sets up an open root listener at 12pm to 12.05 pm on a port number
> derived from your IP address.
I'm sorry, but you are incorrect. Firewalls can do full packet
inspection and can look for known patterns. See the book I referred you
to above.
>
>>Agreed, you absolutely should
>>turn off services also. But services can be accidentally (or otherwise)
>> turned on or misconfigured due to ignorance or design flaw.
>
>
> It doesn't matter - the services only do what they are supposed to do.
> If they have a vulnerability, it would already have been fixed by your
> ditro before you get exploited by it.
Really? So all services are now 100% secure and are guaranteed against
any and all future exploits? Are you REALLY asserting that?
That cannot be what you mean to say. But it sure looks like it. You
say "the services only do what they are supposed to do" as though there
never has been an exploit of any service in the past decade.. and you
also seem to be saying that if some vulnerability did turn up it would
be instantly fixed.. if that's really your position, all I can say is
"Wow!".
Wow.
>
>
>
>>Many,
>>many times I have seen people allow more access than they intended -
>>especially with web servers.
>
>
> Web servers are supposed to allow universal access. Or are you talking
> about cgi and .htaccess? You can't seriously intend to configure the
> firewall to allow access to http dirs by source address! Whatever
> happened to authentication ...
You can allow and disallow specific directories by ip address and in
this case I was thinking of web servers that are NOT supposed to be
universally available - intranet servers. In that case, I would have
the Apache config set for only the allowed use and do the same thing
with both firewalls.
Tony Lawrence
> Tony Lawrence <f...@pcunix.com> wrote:
>
>>Peter T. Breuer wrote:
>>
>>>(I am trying to get you to name a scenario against which it protects,
>>>instead of mouthing vague generalities that may or may not be true!).
>
>
>>I have given examples, and so have other people. It hasn't been vague
>
>
> Please quote. I have seen only fuzzy generalities.
>
>
>>I have a server that accepts ssh connections, but only from a specific
>>set of IP's.
>
>
> Ah good! An example!
>
> Why restrict ssh? There's no point in restricting ssh. Nobody can log
> in through it without your password and/or digital key, no matter where
> they try from. And the whole idea is to give you access wherever you
> are calling from, securely.
You are presuming a use for ssh that does not exist in this situation.
The point of ssh is not just to give access from wherever I am. As I
said, this server only allows access from specific ip's. Why do you
presume to tell me what purpose I have?
>
>
>
>>Additionally, ssh is configured only to accept specific
>>users,
>
>
> Nobody unauthorised can log in. If you don't want somebody in
> particular to log in through ssh, why have you given him a password on
> your machine?
Local users have local access through telnet and are allowed to log in.
Only a few users have a need and therefor the ability to log in remotely.
>
>>and additionally only allows public key authentication.
>
>
> Why do you think that he has kept his private key secure? Or do you
> mean that the client must present a certificate? (normally we do not
> care WHERE we are logging in from! The point of ssh is to allow you to
> log in from unexpected places, or expected places, securely, with
> authetication).
Again, you presume to tell me what the point of MY connections are.
No, in this case I don't go the extra extent of a certificate. So yes,
if the private keys are stolen, ssh would accept the connection -
except, as already noted, both the iptables and the hardware firewall
are also restricting this to specific ip's.
>
>>Beyond
>>that, it's configured to lock out after two incorrect passwords - which
>
>
> No point - there's a 6 second delay anyway, and I type badly. And it
> helps somebody steal the password by using a fake ssh frontend that
> aborts the connect after stealing the password.
There is a point. If it becomes necessary to momentarily allow password
logins, the lockout protection from pam is already in place. It also
helps protect against some unknown exploit that manages to get to a
shell and now wants to become root.
>
>
>>of course can't be given because it doesn't accept passwords. That
>>server is also protected by a hardware firewall and iptables. Most of
>>this is completely redundant,
>
>
> It worse - it does nothing. You don't want to restrict ssh entries,
> because the point of ssh is to allow _secure_ entries from anywhere. You
> try logging in from your laptop on an internet cafe otherwise!
The presumption on your part is that I want to allow logins to this
server from an internet cafe. I don't. I allow logins from specific,
known ip's only.
>
> (I knew this would be the case - any example of a server that needs
> restriction is likely to be an example of a server that is prevented
> from doing what it is supposed to be doing; and it would do that
> safely, if left to itself; because that's what it is supposed to do).
>
Who are you to say what my server is supposed to be doing????
Peter T. Breuer
> > Oh, it's safer, but the protection is against your own failings (when
> > you are in charge of the machines on your local net)!
> Or/and new vulnerabilities or whatever. People asking questions
Those will be taken care of by their distros standard updates page.
But anyway the f/w makes no difference because of the logic that
a server is meant to serve - if they firewall it off, it can't do its
intended job.
If there's something wrong with doing its intended job, i.e. serving,
then newbies shouldn't generally be using it (there are good exceptions,
but newbies won't be into those).
> here don't have decades of *nix experience under their belt like
> you. Quite often we can be be lucky if they manage to find some
> xterm or/and get the idea of applying patches on a regular base.
Yep, but there is nothing wrong with those people turning on as many
services as they like - the default setup is safe, or the distro is not
doing its job for them.
> Some basic fw as setup by many modern distro provide with easy
> tools is a good thing[tm] for them.
> Bear in mind the ever growing amount of people sick of doze,
> trying out Linux. They don't know anything about TCP/IP and
> alike, how should they? Just clicking on some colorful buttons
> until the next reboot.
But a firewall is a solution to a windows problem - namely that you
can't know what is going on in your own machine. There is no such problem
on linux, where you can see precisely everything, and what runs is
precisely what you want to run, and by default it will be configured to
allow accesss only from localhost (or less). The linux solution to not
knowing what goes on on your box is to look and see! And change it if
you don't want it that way. And if you don't use a fireall, so what?
Nothing on linux will be dangerous to you by default!
Peter
Tony Lawrence
> Michael Heiming <michael...@www.heiming.de> wrote:
>
>>>Oh, it's safer, but the protection is against your own failings (when
>>>you are in charge of the machines on your local net)!
>
>
>>Or/and new vulnerabilities or whatever. People asking questions
>
>
> Those will be taken care of by their distros standard updates page.
Again you seem to assume that there is no window of vulnerability, but
of course there is - and a firewall can help protect you during that window.
>
> But anyway the f/w makes no difference because of the logic that
> a server is meant to serve - if they firewall it off, it can't do its
> intended job.
You seem to assume you know what people's intentions are. As I
explained in another thread, I have many situations where ssh is allowed
for specific IP's only - consider a store with branch offices or
telecommuters.
>
> If there's something wrong with doing its intended job, i.e. serving,
> then newbies shouldn't generally be using it (there are good exceptions,
> but newbies won't be into those).
You don't always want to serve everyone. Some clubs are private.
>
>
>>here don't have decades of *nix experience under their belt like
>>you. Quite often we can be be lucky if they manage to find some
>>xterm or/and get the idea of applying patches on a regular base.
>
>
> Yep, but there is nothing wrong with those people turning on as many
> services as they like - the default setup is safe, or the distro is not
> doing its job for them.
Again, you say that depending upon software only makes you safe.
History shows over and over again that is not true. There are very few
applications that have never had security updates.
And if you don't use a fireall, so what?
> Nothing on linux will be dangerous to you by default!
That's an incredible assertion, and plainly incorrect. I think that
once again you've painted yourself in a a corner and are just too
stubborn to admit that you are wrong.
John Hasler
> saying they SHOULD be left this way, but they often are. That's not the
> only possible breach, though. Many firewalls have some sort of shell
> that in theory could be accessed by some unknown exploit.
I presume that you mean proprietary firewalls similar to the one built in
to my Netopia modem (I've got it configured as a bridge: the firewall falls
over when I poke it with Nmap). My firewall is an old Aptiva running
a stripped-down Debian Woody.
--
John Hasler
jo...@dhh.gt.org
Dancing Horse Hill
Elmwood, WI USA
Michael Heiming
>> Why do you think that he has kept his private key secure? Or do you
>> mean that the client must present a certificate? (normally we do not
>> care WHERE we are logging in from! The point of ssh is to allow you to
>> log in from unexpected places, or expected places, securely, with
>> authetication).
> Again, you presume to tell me what the point of MY connections are.
> No, in this case I don't go the extra extent of a certificate. So yes,
> if the private keys are stolen, ssh would accept the connection -
It doesn't, if you setup things probably, using a pass-phrase on
your private key, you should replace the stolen private key asap.
But it's still impossible to login without the passprahse. For
convenience you want to use ssh-agent, which enables thx to agent
forwarding single sign-on through multiple hosts.
If you are serious about ssh, there's a new version of O'Reilly's
"Ssh the definite guide" available.
[..]
--
Michael Heiming (X-PGP-Sig > GPG-Key ID: EDD27B94)
mail: echo zvp...@urvzvat.qr | perl -pe 'y/a-z/n-za-m/'
#bofh excuse 396: Mail server hit by UniSpammer.
Peter T. Breuer
> The point of ssh is not just to give access from wherever I am. As I
Yes it is. That is precisely the use of it. Man ssh ...
ssh (Secure Shell) is a program for logging into a remote machine
and for executing commands on a remote machine.
[It] provide[s] secure encrypted communications between two
untrusted hosts over an insecure network.
> said, this server only allows access from specific ip's. Why do you
> presume to tell me what purpose I have?
Because you don't seem to understand what ssh is for, given the
evidence (I know you do understand at some level, but you don't seem to
appreciate the design quite fully enough).
> > Nobody unauthorised can log in. If you don't want somebody in
> > particular to log in through ssh, why have you given him a password on
> > your machine?
> Local users have local access through telnet and are allowed to log in.
> Only a few users have a need and therefor the ability to log in remotely.
Why do you presume to tell your users what needs or abilities they have?
The aim of ssh is to allow secure logins. As soon as you read the
"between .. untrusted hosts" in the description, you see that it
doesn't matter from where!
Now let me tell you what scenario you try and avoid by your ruse:
somebody having obtained one of your users passwords (and/or secret
key), but not having access to your users machine, so that they try and
log in from a disallowed machine with the right password and/or key.
Spot the problem? They had access to the users machine because they got
the secret key already! So they can log in from the users machine (and
they can log in to the users machine, as they have the password and
secret key ...).
If it's any comfort to you, I often have to do this sort of
stepping-stone procedure when breaking into a secure network. First one
steals a password on a local machine, then one leverages that into
more and more accesses and keys. nfs locally is also helpful in that
regard. And the more silly restrictions like "admin group only" you put
in to sshd_conf, the longer is the route round it. Once in I don't want
to change your setup as you'd look there, so I might chose to add
myself to the admin group, or simply leave a trojan to steal all the
admin passwords (and wipe itself as it gets them). I might even start
my own ssh server on a specified port at a specified hour every day,
and leave it running for 10mins only. Or I might randomise the hour and
let it serve a dummy on a prearranged port for the ten minutes previous.
That's enough for random tests to allow entry. Tcp logging might reveal
it, however. Enough random and it won't.
> > Why do you think that he has kept his private key secure? Or do you
> > mean that the client must present a certificate? (normally we do not
> > care WHERE we are logging in from! The point of ssh is to allow you to
> > log in from unexpected places, or expected places, securely, with
> > authetication).
> Again, you presume to tell me what the point of MY connections are.
No, I am telling yu what you ought to knw, what the design
objective of SSH is. That you think
a) that it is something else, designed only for your needs and deficient
otherwise,
b) that your restriction closes a hole
reveals faults in thinking. There is no hole because ssh is _already_
proof against the worst case.
> No, in this case I don't go the extra extent of a certificate. So yes,
> if the private keys are stolen, ssh would accept the connection -
> except, as already noted, both the iptables and the hardware firewall
> are also restricting this to specific ip's.
There's no point. How did they GET those keys? That's right .. by
logging in to one of those specific authorised IPs. They're the only
places with them in the first instance.
> >>Beyond
> >>that, it's configured to lock out after two incorrect passwords - which
> >
> > No point - there's a 6 second delay anyway, and I type badly. And it
> > helps somebody steal the password by using a fake ssh frontend that
> > aborts the connect after stealing the password.
> There is a point. If it becomes necessary to momentarily allow password
> logins, the lockout protection from pam is already in place. It also
> helps protect against some unknown exploit that manages to get to a
> shell and now wants to become root.
Vaguenesses again. A local exploit only works because somebody has
already managed to log in (and hence become local). They can only do
that with the password (or secret key, in your case). So you are
defending a situation that cannot be countered by your defense!
> > It worse - it does nothing. You don't want to restrict ssh entries,
> > because the point of ssh is to allow _secure_ entries from anywhere. You
> > try logging in from your laptop on an internet cafe otherwise!
> The presumption on your part is that I want to allow logins to this
> server from an internet cafe. I don't.
You have no say in the matter. You don't know where I am sitting. I can
log in to an IP you do allow - in fact I must have done that in order
to get the password/key in the first place.
> I allow logins from specific, known ip's only.
> > (I knew this would be the case - any example of a server that needs
> > restriction is likely to be an example of a server that is prevented
> > from doing what it is supposed to be doing; and it would do that
> > safely, if left to itself; because that's what it is supposed to do).
> Who are you to say what my server is supposed to be doing????
The person with access to the design documents for the service.
Peter
Tony Lawrence
>>Firewalls often are configured to allow remote configuration. I'm not
>>saying they SHOULD be left this way, but they often are. That's not the
>>only possible breach, though. Many firewalls have some sort of shell
>>that in theory could be accessed by some unknown exploit.
>
>
> I presume that you mean proprietary firewalls similar to the one built in
> to my Netopia modem (I've got it configured as a bridge: the firewall falls
> over when I poke it with Nmap). My firewall is an old Aptiva running
> a stripped-down Debian Woody.
Yes, I'm referring to what we've been calling hardware firewalls, which
of course really are just dedicated purpose computers and might even be
running Linux themselves in some cases.. but at the consumer/small
business level usually something like Cisco PIX, Linksys, Multitech,
etc. - and most do at least allow remote configuration, contrary to
Peter's apparent assertion that they can only be accessed locally.
But Peter seems to be saying a lot of strange things today - like "a
packet is just a packet" and can't be inspected for malicious payload,
or that distro updates are all you need in the event of some security
exploit in ssh or whatever - those updates must magically get to his
machine just before the exploit is discovered. He also seems to know
how people want to use their machines, and has told us that the purpose
of ssh is to allow access from anywhere in the world - apparently using
it locked down to specific IP's is some sort of blasphemy.. and web
servers are always for public access only, never for private use..
As I said, Peter has said a lot of strange stuff today.. or I'm just
completely misunderstanding him. Some of it seems so incredible I
think I have to be..
Tony Lawrence
> In comp.os.linux.misc Tony Lawrence <f...@pcunix.com>:
>
>>Peter T. Breuer wrote:
>>
>>>Tony Lawrence <f...@pcunix.com> wrote:
>>>
>>>
>>>>Peter T. Breuer wrote:
>
> [..]
>
>
>>>Why do you think that he has kept his private key secure? Or do you
>>>mean that the client must present a certificate? (normally we do not
>>>care WHERE we are logging in from! The point of ssh is to allow you to
>>>log in from unexpected places, or expected places, securely, with
>>>authetication).
>
>
>>Again, you presume to tell me what the point of MY connections are.
>
>
>>No, in this case I don't go the extra extent of a certificate. So yes,
>>if the private keys are stolen, ssh would accept the connection -
>
>
> It doesn't, if you setup things probably, using a pass-phrase on
> your private key, you should replace the stolen private key asap.
>
> But it's still impossible to login without the passprahse. For
> convenience you want to use ssh-agent, which enables thx to agent
> forwarding single sign-on through multiple hosts.
>
> If you are serious about ssh, there's a new version of O'Reilly's
> "Ssh the definite guide" available.
>
> [..]
>
Well, I have a non-blank passphrase on my keys. But I believe Peter was
referring to the situation where we've gotten a public key from some
user we preumably trust. We can't be sure they haven't but a blank or
trivial passphrase on their key, so as Peter correctly asserts, if their
private key were stolen, there'd be some element of risk. But again,
that's where the other controls come into play, like the firewall
allowing only certain ip's.
Peter T. Breuer
> Again you seem to assume that there is no window of vulnerability, but
There isn't. Precisely none, to a value of none as close to zero as
makes no difference at all. Closer than I could mark with a pencil.
And your f/w will make no differnce, because it will be allowing access
to that service - that's why you have the service running, no?
> > But anyway the f/w makes no difference because of the logic that
> > a server is meant to serve - if they firewall it off, it can't do its
> > intended job.
> You seem to assume you know what people's intentions are.
I know what the server is intended to do. What you intend is your
business.
> > If there's something wrong with doing its intended job, i.e. serving,
> > then newbies shouldn't generally be using it (there are good exceptions,
> > but newbies won't be into those).
> You don't always want to serve everyone. Some clubs are private.
If you had a service that you wanted to give to only a special
group of people, you would configure it that way. And you wouldn't be a
newbie.
Let's get specific. You want to let some people use mysql, so you
run the server, open it to every IP, and give your users a login.
You don't know that there is a default mysql user with a login "mysql",
so the world can use it to search around with.
Wrong. If mysql came configured that way, it would be a security hole,
so it isn't.
Anyway, you were the one who deliberately went and spcified the netmask
as 0! You get it in the arse. Your job.
So you won't do that, will you?
Personal responsibility is so nice, when the server comes configured
safe by default!
> > Yep, but there is nothing wrong with those people turning on as many
> > services as they like - the default setup is safe, or the distro is not
> > doing its job for them.
> Again, you say that depending upon software only makes you safe.
It does - the distro's job is to make it so.
> History shows over and over again that is not true.
History shows that it IS true - name one vulnerability that has not
been corrected within hours of first exploitation (or way before!) by
any distro.
> There are very few
> applications that have never had security updates.
There you are.
See?
Peter
Michael Heiming
>> > Oh, it's safer, but the protection is against your own failings (when
>> > you are in charge of the machines on your local net)!
>> Or/and new vulnerabilities or whatever. People asking questions
> Those will be taken care of by their distros standard updates page.
Despite the gap between a vulnerability is announced, the patch
ready and someone really applying it.
How often do we read questions from people running an EOL distro
without a single patch applied? Guess every second day, even if
you don't read anything.
> But anyway the f/w makes no difference because of the logic that
> a server is meant to serve - if they firewall it off, it can't do its
> intended job.
Distro provided easy fw setup tools usually take care to only
deliver services to the local LAN not to the rest of the world.
> If there's something wrong with doing its intended job, i.e. serving,
> then newbies shouldn't generally be using it (there are good exceptions,
> but newbies won't be into those).
>> here don't have decades of *nix experience under their belt like
>> you. Quite often we can be be lucky if they manage to find some
>> xterm or/and get the idea of applying patches on a regular base.
> Yep, but there is nothing wrong with those people turning on as many
> services as they like - the default setup is safe, or the distro is not
> doing its job for them.
Perhaps, with luck, as it came out, but eight weeks later? My
point remains, many people have no clue how to apply patches
or/and fear it would break things and will not apply them. Even
if not a really preferred solution, the firewall helps them to
keep unwanted stuff out.
>> Some basic fw as setup by many modern distro provide with easy
>> tools is a good thing[tm] for them.
>> Bear in mind the ever growing amount of people sick of doze,
>> trying out Linux. They don't know anything about TCP/IP and
>> alike, how should they? Just clicking on some colorful buttons
>> until the next reboot.
> But a firewall is a solution to a windows problem - namely that you
> can't know what is going on in your own machine. There is no such problem
> on linux, where you can see precisely everything, and what runs is
> precisely what you want to run, and by default it will be configured to
> allow accesss only from localhost (or less). The linux solution to not
> knowing what goes on on your box is to look and see! And change it if
More and more people coming to Linux don't care, they want to
surf the web, send a few mails, manage their digi-cams, mp3
collections and what else. Anything of course completely driven
from a GUI. It's likely they won't eve find they way to this or
another Linux ng, most have never heard about usenet or will
ever. They couldn't handle their doze without help of friends,
like they won't with Linux, so it doesn't really mater what they
run, they don't know what's going on anyway.
Sure you can change things like you want, but we aren't the
new + future Linux users, those will do fine with a few basic
distro setup iptables rules.
> you don't want it that way. And if you don't use a fireall, so what?
> Nothing on linux will be dangerous to you by default!
Except for all those guys without a single patch applied and
remember it's not uncommon people use their Linux box to NAT doze
systems to the internet.
Anyway, no one knows which vulnerabilities will be seen next week.
--
Michael Heiming (X-PGP-Sig > GPG-Key ID: EDD27B94)
mail: echo zvp...@urvzvat.qr | perl -pe 'y/a-z/n-za-m/'
#bofh excuse 45: virus attack, luser responsible
Tony Lawrence
> Tony Lawrence <f...@pcunix.com> wrote:
>
>>The point of ssh is not just to give access from wherever I am. As I
>
>
> Yes it is. That is precisely the use of it. Man ssh ...
>
> ssh (Secure Shell) is a program for logging into a remote machine
> and for executing commands on a remote machine.
> [It] provide[s] secure encrypted communications between two
> untrusted hosts over an insecure network.
>
>
>>said, this server only allows access from specific ip's. Why do you
>>presume to tell me what purpose I have?
>
>
> Because you don't seem to understand what ssh is for, given the
> evidence (I know you do understand at some level, but you don't seem to
> appreciate the design quite fully enough).
So because ssh allows access from ANYWHERE, I can't restrict it to
specific ip's? Why is that, Peter? Because you say so? :-)
Does ssh lose any functionality when I restrict it so? Does it not
still offer me the advantages of encrypted communication and file
transfer?
How is that not appreciating the design? That's a favorite tactic of
yours, btw: pretending the other person doesn't understand something.
By the way, is the goal here to use ssh as you want me to use it or help
restrict access to machines as I desire? I think the latter.. ssh is
only part of the picture, you know.
>
>>Local users have local access through telnet and are allowed to log in.
>>Only a few users have a need and therefor the ability to log in remotely.
>
>
> Why do you presume to tell your users what needs or abilities they have?
Sigh.. because if a user isn't supposed to have access from anywhere
but their desk, then I presume to prevent any such access. In some
unusual situations, we even provide specific ip's to specific Mac
addresses, enforce that the ip is only connected to a certain switch
port, and put further restrictions on the user presumed to be using that
IP.
Not everyone is allowed to work from home. Simple as that.
>
> The aim of ssh is to allow secure logins. As soon as you read the
> "between .. untrusted hosts" in the description, you see that it
> doesn't matter from where!
>
> Now let me tell you what scenario you try and avoid by your ruse:
> somebody having obtained one of your users passwords (and/or secret
> key), but not having access to your users machine, so that they try and
> log in from a disallowed machine with the right password and/or key.
>
> Spot the problem? They had access to the users machine because they got
> the secret key already! So they can log in from the users machine (and
> they can log in to the users machine, as they have the password and
> secret key ...).
If someone has physical access to a remote machine and has the
passphrase or the passphrase is blank or easily guessed, of course the
firewall does nothing.
But that's a strawman and you know it. The firewall does help protect
against someone stealing the keys and using them at another location.
It also protects against an unknown ssh exploit from unauthorized locations.
>
> If it's any comfort to you, I often have to do this sort of
> stepping-stone procedure when breaking into a secure network. First one
> steals a password on a local machine, then one leverages that into
> more and more accesses and keys.
Of course.
> nfs locally is also helpful in that
> regard. And the more silly restrictions like "admin group only" you put
> in to sshd_conf, the longer is the route round it.
You are just proving my point. The more layers you have to fight
through, the harder it is. Again, why don't I just leave my car
unlocked with the keys in it and the alarm off? We both know you CAN
steal my car if you have enough patience and skill.
> Once in I don't want
> to change your setup as you'd look there, so I might chose to add
> myself to the admin group, or simply leave a trojan to steal all the
> admin passwords (and wipe itself as it gets them). I might even start
> my own ssh server on a specified port at a specified hour every day,
> and leave it running for 10mins only. Or I might randomise the hour and
> let it serve a dummy on a prearranged port for the ten minutes previous.
> That's enough for random tests to allow entry. Tcp logging might reveal
> it, however. Enough random and it won't.
And a firewall you have no access to might make that more difficult for
you.
>
>
> No, I am telling yu what you ought to knw, what the design
> objective of SSH is. That you think
>
> a) that it is something else, designed only for your needs and deficient
> otherwise,
> b) that your restriction closes a hole
Strawman. I never said ssh was deficient or that I'm closing a hole.
I merely state that addition of firewalls can add extra layers of
security and can help prevent against newly discovered exploits - *help*
prevent, please note, no guarantees of that of course.
On the other hand, you apparently hold the ridiculous position that a
firewall can offer no additional protection against undesired use.
>
> reveals faults in thinking. There is no hole because ssh is _already_
> proof against the worst case.
Typical Peter argument: setting up something that was never said and
beating the hell out of it. Toss that straw around, Peter.
>
>
>>No, in this case I don't go the extra extent of a certificate. So yes,
>>if the private keys are stolen, ssh would accept the connection -
>>except, as already noted, both the iptables and the hardware firewall
>>are also restricting this to specific ip's.
>
>
> There's no point. How did they GET those keys? That's right .. by
> logging in to one of those specific authorised IPs. They're the only
> places with them in the first instance.
Really? I know people who carry their keys on a cd or a usb stick.
Wrong again, Peter. A firewall limiting them to known ip addresses
prevents them or anyone else from making use of those keys at unexpected
locations.
Keys can also be on backup tapes and are often transmitted by email..
logging into that IP is certainly not the only way to get keys.
>
> Vaguenesses again. A local exploit only works because somebody has
> already managed to log in (and hence become local). They can only do
> that with the password (or secret key, in your case). So you are
> defending a situation that cannot be countered by your defense!
Wrong. The pam will also lockout after unsuccessful su attempts. You
are also forgetting that we may have a network here - the initial breach
may have been elsewhere. The pam lockout isn't directly related,
correct, but it does add more security.
>
>
>
>>>It worse - it does nothing. You don't want to restrict ssh entries,
>>>because the point of ssh is to allow _secure_ entries from anywhere. You
>>>try logging in from your laptop on an internet cafe otherwise!
>
>
>>The presumption on your part is that I want to allow logins to this
>>server from an internet cafe. I don't.
>
>
> You have no say in the matter. You don't know where I am sitting. I can
> log in to an IP you do allow - in fact I must have done that in order
> to get the password/key in the first place.
Sigh.. again, that's plainly not the case. You could have stolen a
backup tape. You could have stolen a usb stick. The public key might
have been transmitted by email or other insecure methods and you might
have obtained a copy of it. The external site may have carelessly left
an nfs or smb share that you can get at without credentials. And so on.
You are just plain wrong, Peter, and too stubborn to admit it. Having
had experience with you more than once in the past, I can pretty well
guess what comes next: more attempts at obfuscation, more strawmen and
red herrings, and ultimately insults and silence. You are so
predictable.. :-)
Tony Lawrence
> Tony Lawrence <f...@pcunix.com> wrote:
>
>>Peter T. Breuer wrote:
>>
>>>[vulnerabilities] will be taken care of by their distros standard updates page.
>
>
>>Again you seem to assume that there is no window of vulnerability, but
>
>
> There isn't. Precisely none, to a value of none as close to zero as
> makes no difference at all. Closer than I could mark with a pencil.
That's idiotic, sorry. *Some* exploits are discovered by white hats,
reported privately, and yes, in that case the problem can be fixed
before anyone else knows about it. That is not always the case, has not
always been the case, and even where it has been, you have no assurance
that the exploit hasn't been independently discovered by someone else
either before or concurrent with the white hat reporting.
>
> And your f/w will make no differnce, because it will be allowing access
> to that service - that's why you have the service running, no?
You aren't paying attention, are you? The firewall is allowing some
access, but not all access. Therefor it can help protect in this situation.
>
>
>
>>>But anyway the f/w makes no difference because of the logic that
>>>a server is meant to serve - if they firewall it off, it can't do its
>>>intended job.
>
>
>>You seem to assume you know what people's intentions are.
>
>
> I know what the server is intended to do. What you intend is your
> business.
Huh? A server is intended to do what its owner intends it to do.
>
>
>
>>>If there's something wrong with doing its intended job, i.e. serving,
>>>then newbies shouldn't generally be using it (there are good exceptions,
>>>but newbies won't be into those).
>
>
>>You don't always want to serve everyone. Some clubs are private.
>
>
> If you had a service that you wanted to give to only a special
> group of people, you would configure it that way. And you wouldn't be a
> newbie.
That's exactly what we've been talking about here, in addition to
accidental misconfiguration - which can happen to anyone, newbie or not.
>
> Personal responsibility is so nice, when the server comes configured
> safe by default!
Sigh.. again - it may not be safe by default. Round and round we go..
> History shows that it IS true - name one vulnerability that has not
> been corrected within hours of first exploitation (or way before!) by
> any distro.
How do you know who was aware of the vulnerability or how long they were
aware of it? Take the case of Ken's infamous root login hack.. unknown
to anyone until he divulged it - or was it?
>
>
>>There are very few
>>applications that have never had security updates.
>
>
> There you are.
>
> See?
Yes, there I am. That proves my points, not yours!
Peter T. Breuer
> In comp.os.linux.misc Peter T. Breuer <p...@lab.it.uc3m.es>:
> > Michael Heiming <michael...@www.heiming.de> wrote:
> >> > Oh, it's safer, but the protection is against your own failings (when
> >> > you are in charge of the machines on your local net)!
> >> Or/and new vulnerabilities or whatever. People asking questions
> > Those will be taken care of by their distros standard updates page.
> Despite the gap between a vulnerability is announced, the patch
> ready and someone really applying it.
The vulnerability will not be announced until the patch is ready. But
anyway, I said _exploited_. My point was that if a vulnerability is not
being exploited then you have effectively no chance of getting hit by it
- when it is exploited (in the sense that you begin to develop a chance
of being hit by it), then a fix is generated in a big hurry! Hours.
The number of exploit events required to trigger a response is in the
order of one or two or three. If it ever hit ten or a hundred or a
thousand the response would be massive.
What worms have we had in the past? I recall some combo attack via ftp
and lp on rh. Rh fixed that in hours, but no firewall would have helped
meanwhile - the services were legitimate and hence would have been open
via the f/w.
> How often do we read questions from people running an EOL distro
> without a single patch applied? Guess every second day, even if
> you don't read anything.
The same argument applies - they have to update their servers, not have
a firewall; the firewall would have holes in it to allow
access to their compromisable servers! An ftp server or whatever.
> > But anyway the f/w makes no difference because of the logic that
> > a server is meant to serve - if they firewall it off, it can't do its
> > intended job.
> Distro provided easy fw setup tools usually take care to only
> deliver services to the local LAN not to the rest of the world.
The distro provided servers are also configured that way anyway. If
they wanted to make their servers more generally available they would
have to configure the server to allow it, and then open the firewall.
So the firewall would be no protection when an exploit appears. Only
updating the server helps.
> > Yep, but there is nothing wrong with those people turning on as many
> > services as they like - the default setup is safe, or the distro is not
> > doing its job for them.
> Perhaps, with luck, as it came out, but eight weeks later? My
8 weeks later it has had the distro updates applied. And if it hasn't,
the firewall makes no difference, because it has holes in to allow
access to those services if those services have been made available
externally. Think ftp - you'd have to let tcpwrappers let it out, then
open the firewall for it. If you haven't made the service available
generally, then the firewall has not been opened either, but it makes
no difference because the service has not been reconfigged t allow
anyone but localhost.
Your argument is probably that they intended to allow access for
everyone, but entry only for a few. Then a vulnerability appears that
escalates access into entry.
Tough - they have to type "apt-get update".
> point remains, many people have no clue how to apply patches
They use apt-get update.
> or/and fear it would break things and will not apply them. Even
That's fine - let them fear.
> if not a really preferred solution, the firewall helps them to
> keep unwanted stuff out.
It permits access to services. That's the aim of services - to serve,
so firewalls are open to them. No net attack is based on an uncommon
service not running anywahere except locally! There's no point! Worms
only target generic, open, services. The next wuftpd vulnerability
please stand up! (aren't we overdue?).
> > But a firewall is a solution to a windows problem - namely that you
> > can't know what is going on in your own machine. There is no such problem
> > on linux, where you can see precisely everything, and what runs is
> > precisely what you want to run, and by default it will be configured to
> > allow accesss only from localhost (or less). The linux solution to not
> > knowing what goes on on your box is to look and see! And change it if
> More and more people coming to Linux don't care, they want to
> surf the web, send a few mails, manage their digi-cams, mp3
Then they won't be starting services, so they don't need a firewall to
disallow access to these nonexisting servers.
> collections and what else. Anything of course completely driven
> from a GUI. It's likely they won't eve find they way to this or
> another Linux ng, most have never heard about usenet or will
> ever. They couldn't handle their doze without help of friends,
> like they won't with Linux, so it doesn't really mater what they
> run, they don't know what's going on anyway.
> Sure you can change things like you want, but we aren't the
> new + future Linux users, those will do fine with a few basic
> distro setup iptables rules.
> > you don't want it that way. And if you don't use a fireall, so what?
> > Nothing on linux will be dangerous to you by default!
> Except for all those guys without a single patch applied and
They type apt-get update. They always do, because how else can they keep
their gam3s up to date? I bet they do it ten times a day.
Peter
Peter T. Breuer
> Peter T. Breuer wrote:
> > Tony Lawrence <f...@pcunix.com> wrote:
> >
> >>Peter T. Breuer wrote:
> >>
> >>>[vulnerabilities] will be taken care of by their distros standard updates page.
> >
> >
> >>Again you seem to assume that there is no window of vulnerability, but
> >
> >
> > There isn't. Precisely none, to a value of none as close to zero as
> > makes no difference at all. Closer than I could mark with a pencil.
> That's idiotic, sorry.
Sorry, but it's true.
> *Some* exploits are discovered by white hats,
Really? I suppose so. So what?
> always been the case, and even where it has been, you have no assurance
> that the exploit hasn't been independently discovered by someone else
> either before or concurrent with the white hat reporting.
Of course I have! It hasn't been exploited!
Look - if a tree falls in the forest with nobody to observe it, has it
really fallen?
If an exploit is not exploited, there is nothing to worry about. You
have zero chance of being hit. When it is exploited, te vulnerability
will be closed in a matter of hours That is a matter of history, and is
perfectly predictable! So your chance of being hit is proportional to
that window of a few hours, which is "as close to zero as I care to think
about". Or "about my chances of getting Ebola". Exploits satisfy
epedemial statistics. The fast response of open source keeps the stats
on my side by thousands to one.
> > And your f/w will make no differnce, because it will be allowing access
> > to that service - that's why you have the service running, no?
> You aren't paying attention, are you? The firewall is allowing some
> access, but not all access. Therefor it can help protect in this situation.
It allows ALL access - an exploit which does not attack a universal
service does not spread.
Peter
John Hasler
> Yes, I'm referring to what we've been calling hardware firewalls, which
> of course really are just dedicated purpose computers and might even be
> running Linux themselves in some cases.. but at the consumer/small
> business level usually something like Cisco PIX, Linksys, Multitech,
> etc. - and most do at least allow remote configuration, contrary to
> Peter's apparent assertion that they can only be accessed locally.
I assume that by "locally" he means "only from the LAN side".
Unfortunately, some have been found to have deliberate WAN-side backdoors
with default passwords.
And then there is the imbecilic practice of shipping security products with
the same default password on all units...
In any case, I need a router to handle PPPoE and NAT since I can't trust
the piece-of-crap Netopia box that CenturyTel supplied. I don't need to
offer any services to the Internet. Why, while I am configuring that
router, should I not configure iptables?
Alexander Skwar
> OK, at least two people who think this way. I sure don't.. and I don't
> see it as "useless stacks of complexity" but rather as additional
> protection.
What "additional protection"? A port is only open, if it gets opened
by some sort of server daemon. The surest way to close a port is thus
to not run that server daemon.
Sure, if you wish to run a daemon and have it only be accessible
by certain parts of the net, a packet filter will often be a good
configuration choice.
Alexander Skwar
--
The trouble is, there is an endless supply of White Men, but there has
always been a limited number of Human Beings.
-- Little Big Man
Alexander Skwar
> Alexander Skwar wrote:
>> · Tony Lawrence <f...@pcunix.com>:
>>
>>
>>>I think a far more interesting question is why you seem to imply that no
>>>firewall is needed at all.. if indeed that is what your posts in this
>>>part of the thread mean to express.
>>
>>
>> Dunno about him, but he's right. Packet filters are normally not
>> needed. Just disable the services ("daemons") that are not needed
>> and that's it. No need for useless stacks of complexity.
>>
>> Alexander Skwar
>
> I might need to enable a service for a given set of users (say a local
> subnet) but may need to disable the service to the wider audience. In
> this case, I can't disable the service.
Well, tcp wrappers might exist. But, yes, for such a scenario a packet
filter will be the tool of choice.
> I can certainly apply
> host_access or whatever other protections are available, but I could
> also misconfigure any such protection.
Yep. You could also misconfigure the packet filter.
> A firewall simply offers an
> additional layer of centralized protection against these types of
> potential problems.
Which, in the best case, is just useless.
Alexander Skwar
--
All heiresses are beautiful.
-- John Dryden
Tony Lawrence
> Tony Lawrence <f...@pcunix.com> wrote:
>
>>always been the case, and even where it has been, you have no assurance
>>that the exploit hasn't been independently discovered by someone else
>>either before or concurrent with the white hat reporting.
>
>
> Of course I have! It hasn't been exploited!
Nonsense. You don't know that.. you can't know it because you don't
even know that the possibility exists yet! But it does exist, and
someone can know it and use that knowledge against you.
>
> Look - if a tree falls in the forest with nobody to observe it, has it
> really fallen?
If I steal a dollar from your wallet and you don't know it, do I still
have your dollar?
>
> If an exploit is not exploited, there is nothing to worry about. You
> have zero chance of being hit. When it is exploited, te vulnerability
> will be closed in a matter of hours That is a matter of history, and is
> perfectly predictable!
There's a buffer overflow bug in the foobah daemon. Nobody has ever
noticed it because it is buried in an unusual condition. Hacker xyz
discovers it and begins using it to get into servers using foobah. He
leaves no tracks, just steals what he wants and is gone. It may be
years before anyone ever notices this problem.
> So your chance of being hit is proportional to
> that window of a few hours, which is "as close to zero as I care to think
> about". Or "about my chances of getting Ebola". Exploits satisfy
> epedemial statistics. The fast response of open source keeps the stats
> on my side by thousands to one.
So what? Whatever the odds are, I want to increase them in my favor!
The odds of my accidentally turning on a service I don't want are even
lower than that, but I'm still going to block the port at both
firewalls. My car is locked, but I don't leave a spare key in the ignition!
>
>
>
>>>And your f/w will make no differnce, because it will be allowing access
>>>to that service - that's why you have the service running, no?
>
>
>>You aren't paying attention, are you? The firewall is allowing some
>>access, but not all access. Therefor it can help protect in this situation.
>
>
>
> It allows ALL access - an exploit which does not attack a universal
> service does not spread.
What??? What on earth are you saying?
Alexander Skwar
> Why restrict ssh? There's no point in restricting ssh. Nobody can log
> in through it without your password and/or digital key, no matter where
> they try from. And the whole idea is to give you access wherever you
> are calling from, securely.
Well. You're certainly right. But, if it is *KNOWN* (eg. by defintion)
that valid connections can only come from a certain subnet/host, it
IS a good idea to setup the system, so that connections can only be
made from that subnet/host. One way would be tcp wrappers. Another
would be a packet filter.
Alexander Skwar
--
It is so very hard to be an
on-your-own-take-care-of-yourself-because-there-is-no-one-else-to-do-it-for-you
grown-up.
Tony Lawrence
> Tony Lawrence writes:
>
>>Yes, I'm referring to what we've been calling hardware firewalls, which
>>of course really are just dedicated purpose computers and might even be
>>running Linux themselves in some cases.. but at the consumer/small
>>business level usually something like Cisco PIX, Linksys, Multitech,
>>etc. - and most do at least allow remote configuration, contrary to
>>Peter's apparent assertion that they can only be accessed locally.
>
>
> I assume that by "locally" he means "only from the LAN side".
> Unfortunately, some have been found to have deliberate WAN-side backdoors
> with default passwords.
Yes. Which is why I also deploy a software firewall. It's just extra
protection.
>
> And then there is the imbecilic practice of shipping security products with
> the same default password on all units...
>
> In any case, I need a router to handle PPPoE and NAT since I can't trust
> the piece-of-crap Netopia box that CenturyTel supplied. I don't need to
> offer any services to the Internet. Why, while I am configuring that
> router, should I not configure iptables?
Right.
Alexander Skwar
> Tony Lawrence <f...@pcunix.com> wrote:
>> The point of ssh is not just to give access from wherever I am. As I
>
> Yes it is. That is precisely the use of it.
Not "the use", it is *a* *possible* use.
For example, I'm "pretty" certain, that I will only ever connect
to my servers from "german" IPs. Or rather, I'll never make a connection
from a "chinese" IP. Why should I allow connections from China? I'm
not running an SSH server that's supposed to be used by everybody
on the planet. I'm running an SSH server just for me.
> b) that your restriction closes a hole
>
> reveals faults in thinking. There is no hole because ssh is _already_
> proof against the worst case.
Well, no. There's *always* the possibility of remotly explotable
bugs. It's possible that they might not yet be fixed. Because
of that, it makes sense to make a certain server only accessible
to those, that are supposed to use it.
>> The presumption on your part is that I want to allow logins to this
>> server from an internet cafe. I don't.
>
> You have no say in the matter.
Of course he has. It's his server. *ONLY* he has a say in the
matter of the use of *HIS* server.
> You don't know where I am sitting. I can
> log in to an IP you do allow
Not necessiarily.
Alexander Skwar
--
You humans are all alike.
Alexander Skwar
> Some basic fw as setup by many modern distro provide with easy
> tools is a good thing[tm] for them.
No, it's not. It's a rather *BAD* thing. It would be *MUCH*
better, if the distribution would configure the system in
such a way, that only the needed services are externally
connectable - that might be none.
Further, it would be good, if the distribution would offer
easy ways to dis-/enable needed services.
Alexander Skwar
--
Don't tell me what you dreamed last night for I've been reading Freud.
Alexander Skwar
> How is that not appreciating the design?
Yep. Also, how comes that the OpenSSH sshd man page lists
/etc/hosts.allow as possible configuartion options? Is
the OpenSSH sshd man page against the design of sshd?
Alexander Skwar
--
The difference between a lawyer and a rooster is that
the rooster gets up in the morning and clucks defiance.
Alexander Skwar
> Tony Lawrence <f...@pcunix.com> wrote:
>> Peter T. Breuer wrote:
>> > [vulnerabilities] will be taken care of by their distros standard updates page.
>
>> Again you seem to assume that there is no window of vulnerability, but
>
> There isn't. Precisely none, to a value of none as close to zero as
> makes no difference at all. Closer than I could mark with a pencil.
You know pretty well, that this is bull. There are 0 day exploits.
There will ALWAYS be a time lapse between the discovery of a hole
and the time it is fixed by the people who make the software and
also the time the distributor provides a fix.
> I know what the server is intended to do.
Yep. Provide service to allowed clients. It's not always the
case, that *everybody* is supposed to be an allowed client.
>> > If there's something wrong with doing its intended job, i.e. serving,
>> > then newbies shouldn't generally be using it (there are good exceptions,
>> > but newbies won't be into those).
>
>> You don't always want to serve everyone. Some clubs are private.
>
> If you had a service that you wanted to give to only a special
> group of people, you would configure it that way.
Yep. A packet filter or tcp wrappers might be a way to do that.
But since not every service supports tcp wrappers, a packet
filter might be the only available choice.
> And you wouldn't be a
> newbie.
Yep.
> Let's get specific. You want to let some people use mysql, so you
> run the server, open it to every IP, and give your users a login.
No. If possible, you would open it only to a certain subset of
IPs, to limit the source of possible breakins at that layer
already.
Alexander Skwar
--
Usage: fortune -P [-f] -a [xsz] Q: file [rKe9] -v6[+] file1 ...
jeff
>>
>>> You aren't paying attention, are you? The firewall is allowing some
>>> access, but not all access. Therefor it can help protect in this
>>> situation.
>>
>>
>>
>>
>> It allows ALL access - an exploit which does not attack a universal
>> service does not spread.
>
>
>
> What??? What on earth are you saying?
PTB has been trying to stomp out firewalls for years. He's obviously so
invested in this nonsense that he could not possibly change his story
now, so debating the issue is probably futile. One wonders, though, why
he doesn't just let the whole debate fade away.
Jeff
Alexander Skwar
> Michael Heiming <michael...@www.heiming.de> wrote:
>> In comp.os.linux.misc Peter T. Breuer <p...@lab.it.uc3m.es>:
>> > Michael Heiming <michael...@www.heiming.de> wrote:
>> >> > Oh, it's safer, but the protection is against your own failings (when
>> >> > you are in charge of the machines on your local net)!
>
>> >> Or/and new vulnerabilities or whatever. People asking questions
>
>> > Those will be taken care of by their distros standard updates page.
>
>> Despite the gap between a vulnerability is announced, the patch
>> ready and someone really applying it.
>
> The vulnerability will not be announced until the patch is ready.
Bull.
If I'd discover a hole, I could *RIGHT* *AWAY* announce it
on full disclosure or another list. That might be the first
time the make of hte software with the hole get's a notice
of the existence of the hole.
> But
> anyway, I said _exploited_. My point was that if a vulnerability is not
> being exploited then you have effectively no chance of getting hit by it
The point is, that it is not possible to know if there's an
exploit. It might be, that a bad guy knows of a hole and starts
attacking your servers with the exploit he wrote.
> - when it is exploited (in the sense that you begin to develop a chance
> of being hit by it), then a fix is generated in a big hurry!
Not always.
> The same argument applies - they have to update their servers, not have
> a firewall; the firewall would have holes in it to allow
> access to their compromisable servers! An ftp server or whatever.
Again: If it is an "all or nothing" decision, then you are completely
right and the proper solution is to run a service - or don't.
But there are cases, when a service is only supposed to be used
by certain clients. One configuration choice would be a packet
filter in this "advanced" configuration setup.
Alexander Skwar
--
If I had a Q-TIP, I could prevent th' collapse of NEGOTIATIONS!!
Tony Lawrence
> · Tony Lawrence <f...@pcunix.com>:
>
>>Peter T. Breuer wrote:
>>
>>>Tony Lawrence <f...@pcunix.com> wrote:
>
>
>>How is that not appreciating the design?
>
>
> Yep. Also, how comes that the OpenSSH sshd man page lists
> /etc/hosts.allow as possible configuartion options? Is
> the OpenSSH sshd man page against the design of sshd?
>
> Alexander Skwar
I guess they'll have to change it. Peter says it has to be open to
everyone - so that must be a mistake.
Peter does have a point in narrow situations, but he ignores reality.
For example, I probably never want inbound telnet. It's solidly shut
off, so technically Peter is right: adding the two fw's adds nothing to
that. However, I may want local telnet. I'm going to set it only to
accept the local lan, but I can make a mistake. Even if I don't make a
mistake now, something I do later may accidentally open up telnet or
some other currently local only service. Peter may never make mistakes,
but I sure do, especially when I'm rushing..
From another viewpoint, the firewalls are just obvious security policy:
deny everything by default. That's what you are doing by not turning on
services, but the firewalls just extend that to an extra level.
And as we both agree, if you know where your intended users are coming
from, there's no point in allowing anyone else. You could extend that
to geographic locations, and we've done that at some places: if there no
users from Japan or Korea, why allow those ip blocks? If it's your
personal access, why allow any blocks that you won't be traveling to?
That could still let you travel to the internet cafe that Peter
mentioned, but it improves security. Any improvement is of value, in my
opinion.
jeff
In the "best" case (i.e. everyone behaves and no one makes mistakes) ALL
security is useless. In the real world, though, it's prudent to try to
anticipate, and cover, the "worst" case. Tcp wrappers are good. Tcp
wrappers and packet filtering are better, since you'd need to make TWO
configuration errors rather than just ONE, to create a vulnerability.
Jeff
Tony Lawrence
Let me guess: in some distant thread, he painted himself into a corner
and just couldn't admit he was wrong? So familiar..
My experience with Peter is that he never lets anything fade. He will
reach a point where he'll claim that it's pointless to go on because the
people on the other side don't understand x, y or z. He's pulled that
on me more than once.
I do respect the guy. He's knowledgeable, and when he isn't up on a
horse, he can be very helpful. But when he goes off course like this,
well.. it can be a wild ride..
But because he is helpful, and he does provide a lot of good posts, I
can't just let him get away with this nonsense. Newbies respect his
opinions, and rightfully so in most cases but in this case they should
pay no attention to him.
Tony Lawrence
Add a hardware fw and now you need three problems.. :-)
Peter T. Breuer
> Peter T. Breuer wrote:
> > Tony Lawrence <f...@pcunix.com> wrote:
> >
> >>always been the case, and even where it has been, you have no assurance
> >>that the exploit hasn't been independently discovered by someone else
> >>either before or concurrent with the white hat reporting.
> >
> >
> > Of course I have! It hasn't been exploited!
> Nonsense.
No, perfectly true. You seem somewhat naive about probabilities and
stats ..
> You don't know that..
Of course I do. Bayesian reasoning.
> you can't know it because you don't
> even know that the possibility exists yet!
False deduction. Incorrect logic. I can know plenty of things about
things that haven't occurred yet - the whole science of probability is
devoted to just exactly that.
> But it does exist, and
> someone can know it and use that knowledge against you.
The probability of an exploit against me is as close to zero as one can
get, because use of the vulnerability causes reports to be generated,
which causes people to look for it, which causes the exploit to be
trapped, analysed, and a fix put out, in hours. That's unique to open
source. The resurces dedicated to finding trapping and fixing it are
enourmous.
Even way back when in the days of the Morris internet worm, which shut
down about half the then net, the whole thing was seen, trapped and
rebuffed in about 48h, using just the postmasters. Nowadays the
response is a matter of about 4-8h and people all over the place
contribute, as far as I can tell from the reports I have seen go past
over about the last five years.
(and you are probably confusing the terms "exploit" and "vulnerability"
- a vulnerability may exist without ever being exploited).
So by bayesian logic, the only still undefended vulnerabiliies are the
ones which are not being exploited. Which I am not likely to suffer
from!
> > Look - if a tree falls in the forest with nobody to observe it, has it
> > really fallen?
> If I steal a dollar from your wallet and you don't know it, do I still
> have your dollar?
You stole it from me. But not from everybody. So say there are 100
million people on the internet. Then there is a 1:100000000 chance of
suffering from your exploit. Thanks - but I am much more likely to be
run over by a truck, or struck by a falling star.
If you were to use a technique that was generally applicable and
rapidly effected in multiple places, it would quickly be noticed,
analysed, and a defense concocted, transmitted to the distros, and
passed on to users in updates.
The only vulnerabilities not closed are the ones not exploited. That
means you don't have to worry about them - they are not likely to be
applied to you.
> > If an exploit is not exploited, there is nothing to worry about. You
> > have zero chance of being hit. When it is exploited, te vulnerability
> > will be closed in a matter of hours That is a matter of history, and is
> > perfectly predictable!
> There's a buffer overflow bug in the foobah daemon.
Great!
> Nobody has ever
> noticed it because it is buried in an unusual condition.
Good.
> Hacker xyz
> discovers it and begins using it to get into servers using foobah. He
> leaves no tracks, just steals what he wants and is gone.
Insignificant. A single hacker working away can do maybe 10 breakins a
day, working full speed. That's 1:10000000 per day. Not even that,
since he has to locate targets very carefully and keep himself hidden.
You are more likely to choke to death on your next meal. Worry about
that instead.
And that's only WHEN he comes up with such a breakin, and applies only
to those setups that are vulerable to his approach. Say that 1 in 10
setups are vulnerable (unlikely - there are a dozen major ditros, in
lotsa different configs, not to mention different versions). Now you
get to multiply by the odds of coming up with it.
Forget it. Bayes still applies.
> It may be
> years before anyone ever notices this problem.
No, it would be a couple of months at most (an analogy was the breakin
at gnu - they tk about a month to notice it, deduce the mechanism, fix
it, etc - yes, it as an unknown kernel vulnerability or similar, and
no, the exploit could not be widely used without advertising it, so it
wasn't). And only a limited set of targets could be taken.
> > So your chance of being hit is proportional to
> > that window of a few hours, which is "as close to zero as I care to think
> > about". Or "about my chances of getting Ebola". Exploits satisfy
> > epedemial statistics. The fast response of open source keeps the stats
> > on my side by thousands to one.
> So what? Whatever the odds are, I want to increase them in my favor!
There's no point. Large odds are meaningless. There is no real sense in
which 1:100000000 is better or worse than 1:1000000000. They are both
"once in never" odds. If you want to cover yourself, bet $1 on it
happening. Bookies also are beaten by long odds.
> The odds of my accidentally turning on a service I don't want are even
> lower than that,
They're relatively high. About 90% of all software and hardware problems
are admin-caused for a start!
> but I'm still going to block the port at both
> firewalls. My car is locked, but I don't leave a spare key in the ignition!
Why? You think they will try harder to get in or choose your car first?
Reasonable - but try making the car refuse to work for anyone but you.
Then you won't care.
Peter
Peter T. Breuer
> ?? Peter T. Breuer <p...@lab.it.uc3m.es>:
> > Tony Lawrence <f...@pcunix.com> wrote:
> >> Peter T. Breuer wrote:
> >> > [vulnerabilities] will be taken care of by their distros standard updates page.
> >
> >> Again you seem to assume that there is no window of vulnerability, but
> >
> > There isn't. Precisely none, to a value of none as close to zero as
> > makes no difference at all. Closer than I could mark with a pencil.
> You know pretty well, that this is bull.
Nonsense.
> There are 0 day exploits.
Sure. So?
> There will ALWAYS be a time lapse between the discovery of a hole
> and the time it is fixed by the people who make the software and
> also the time the distributor provides a fix.
Sure. So?
The open source distrs develop and get the fixes to the users in hours.
MS gets it there at the next service pack, in six months. Maybe.
> > I know what the server is intended to do.
> Yep. Provide service to allowed clients.
A successful exploit cannot attack a service that is not universal. It
would be like an illness that only attacks one-legged catholic nuns
with red hair and a lisp. The exploit would never propagate.
Epedmiology governs.
> It's not always the
> case, that *everybody* is supposed to be an allowed client.
It is, for successful exploits. Unsuccessful exploits you don't care
about.
> > If you had a service that you wanted to give to only a special
> > group of people, you would configure it that way.
> Yep. A packet filter or tcp wrappers might be a way to do that.
> But since not every service supports tcp wrappers, a packet
> filter might be the only available choice.
> > And you wouldn't be a
> > newbie.
> Yep.
> > Let's get specific. You want to let some people use mysql, so you
> > run the server, open it to every IP, and give your users a login.
> No. If possible, you would open it only to a certain subset of
> IPs, to limit the source of possible breakins at that layer
> already.
Well, I'm trying to set up an exploit scenario for him.
If you want me to instead consider your scenario, I'll point out that
there is no scope for spread of an exploit in your setup, if it is
generally done that way, therefore you could never (in the statistical
sense) be subjected to the exploit, therefore you don't have to worry
about it.
Peter
Peter T. Breuer
> Bull.
I'm afraid that's the ay CERT works.
Peter
Michael Heiming
> Michael Heiming <michael...@www.heiming.de> wrote:
>> In comp.os.linux.misc Peter T. Breuer <p...@lab.it.uc3m.es>:
>> > Michael Heiming <michael...@www.heiming.de> wrote:
>> >> > Oh, it's safer, but the protection is against your own failings (when
>> >> > you are in charge of the machines on your local net)!
>> >> Or/and new vulnerabilities or whatever. People asking questions
>> > Those will be taken care of by their distros standard updates page.
>> Despite the gap between a vulnerability is announced, the patch
>> ready and someone really applying it.
> The vulnerability will not be announced until the patch is ready. But
> anyway, I said _exploited_. My point was that if a vulnerability is not
> being exploited then you have effectively no chance of getting hit by it
> - when it is exploited (in the sense that you begin to develop a chance
> of being hit by it), then a fix is generated in a big hurry! Hours.
> The number of exploit events required to trigger a response is in the
> order of one or two or three. If it ever hit ten or a hundred or a
> thousand the response would be massive.
Peter, we still see people posting running RH 9.0 which is
officially EOL since >1 year by redhat and they don't even have a
single patch applied.
No question that someone knowledgeable is able to secure his
system without any firewall.
Most users will not be able to configure tcp_wrappers or know if
the service he wants to is compiles using it or/and has own
config files for additional access control. Yeah, I know we both
look in /etc/blah, vi(m) the thing and sighup the service, done.
The distro provided fw tools make it much easier to have a better
security for those users then anything else.
> What worms have we had in the past? I recall some combo attack via ftp
> and lp on rh. Rh fixed that in hours, but no firewall would have helped
> meanwhile - the services were legitimate and hence would have been open
> via the f/w.
>> How often do we read questions from people running an EOL distro
>> without a single patch applied? Guess every second day, even if
>> you don't read anything.
> The same argument applies - they have to update their servers, not have
> a firewall; the firewall would have holes in it to allow
> access to their compromisable servers! An ftp server or whatever.
Again users might only want to offer the service to their home
lan.
[..]
>> Perhaps, with luck, as it came out, but eight weeks later? My
> 8 weeks later it has had the distro updates applied. And if it hasn't,
> the firewall makes no difference, because it has holes in to allow
> access to those services if those services have been made available
> externally. Think ftp - you'd have to let tcpwrappers let it out, then
> open the firewall for it. If you haven't made the service available
> generally, then the firewall has not been opened either, but it makes
> no difference because the service has not been reconfigged t allow
> anyone but localhost.
Same thing, some nice GUI iptables front-end offers an easier way
for people without that knowledge to only provide the service to
their local lan.
> Your argument is probably that they intended to allow access for
> everyone, but entry only for a few. Then a vulnerability appears that
> escalates access into entry.
> Tough - they have to type "apt-get update".
>> point remains, many people have no clue how to apply patches
> They use apt-get update.
Unlikely they start with Debian or kind off. The same dudes have
never applied patches to their dozes systems, what makes you
think they'd do different once they run Linux?
>> or/and fear it would break things and will not apply them. Even
> That's fine - let them fear.
>> if not a really preferred solution, the firewall helps them to
>> keep unwanted stuff out.
> It permits access to services. That's the aim of services - to serve,
> so firewalls are open to them. No net attack is based on an uncommon
> service not running anywahere except locally! There's no point! Worms
> only target generic, open, services. The next wuftpd vulnerability
> please stand up! (aren't we overdue?).
Should be, in addition we are overdue with ssh?
[..]
>> More and more people coming to Linux don't care, they want to
>> surf the web, send a few mails, manage their digi-cams, mp3
> Then they won't be starting services, so they don't need a firewall to
> disallow access to these nonexisting servers.
They might not even know that sshd might be running per default.
Doesn't matter if they took the three seconds during setup to
disallow anything from the outside unrelated to outgoing packets.
[..]
>> Except for all those guys without a single patch applied and
> They type apt-get update. They always do, because how else can they keep
> their gam3s up to date? I bet they do it ten times a day.
You are presuming anyone out there would run Debian, IMO it's
more likely people run suse/mandrake/fedora/redhat or alike.
Still unsure why you don't want people to have this extra layer
of security, the kernel provides to us with this remarkable
features?
--
Michael Heiming (X-PGP-Sig > GPG-Key ID: EDD27B94)
mail: echo zvp...@urvzvat.qr | perl -pe 'y/a-z/n-za-m/'
#bofh excuse 190: Proprietary Information.
Peter T. Breuer
> Alexander Skwar wrote:
> > Yep. Also, how comes that the OpenSSH sshd man page lists
> > /etc/hosts.allow as possible configuartion options? Is
> > the OpenSSH sshd man page against the design of sshd?
My ssh is not compiled against tcpwrappers.
% sudo ldd `which ssh`
libnsl.so.0 => /lib/libnsl.so.0 (0x40011000)
libc.so.5 => /lib/libc.so.5 (0x40041000)
%
> I guess they'll have to change it. Peter says it has to be open to
> everyone - so that must be a mistake.
Kindly do not make strawmen. I did not say that. I pointed out that the
design is to connect unsecured hosts securely on insecure networks. So
who cares what the IP is!
> Peter does have a point in narrow situations, but he ignores reality.
> For example, I probably never want inbound telnet.
Then don't use it. I like having telnetd around myself.
> It's solidly shut
> off,
Why? Telnetd is not a security risk - using telnet from an outside net is!
> so technically Peter is right: adding the two fw's adds nothing to
> that. However, I may want local telnet.
So start telnetd. Don't use telnet from anywhere but locally.
> I'm going to set it only to
> accept the local lan,
Why bother?
> but I can make a mistake.
So what!
> Even if I don't make a
> mistake now, something I do later may accidentally open up telnet or
Fine! Good! There's nothing wrong with running telnetd or having it open
to all!
> some other currently local only service. Peter may never make mistakes,
It doesn't matter. There is no risk involved in running telnetd.
> but I sure do, especially when I'm rushing..
And you don't make mistakes setting up your firewall?
> From another viewpoint, the firewalls are just obvious security policy:
> deny everything by default.
There's nothing wrong with allowing access to your servers - this isn't
ms windows. If there were a vulerability it would be fixed by your daily
updates (or half-hourly, whatever ...). The point of having a server is
to serve - man httpd!
> And as we both agree, if you know where your intended users are coming
> from, there's no point in allowing anyone else.
You don't know. Let them in by ssh and they can tunnel anything
anywhere. Season to taste with rinetd.
Peter
Peter T. Breuer
> ?? Peter T. Breuer <p...@lab.it.uc3m.es>:
> > Tony Lawrence <f...@pcunix.com> wrote:
> >> The point of ssh is not just to give access from wherever I am. As I
> >
> > Yes it is. That is precisely the use of it.
> Not "the use", it is *a* *possible* use.
> For example, I'm "pretty" certain, that I will only ever connect
> to my servers from "german" IPs.
Then why bother allowing ssh? You can simply set up a permanent VPN.
> Or rather, I'll never make a connection
> from a "chinese" IP. Why should I allow connections from China? I'm
For the time you have to go to china at a moment's notice (hey, it's
happened to me!).
But why bother thinking? Ssh is safe - that's the whole point of it.
Refusing to use a safe thing sometimes is silly. Its design makes it
safe! Not the IP you use it from. Are you trying to claim that your
laptop is less safe in china than in france?
> > reveals faults in thinking. There is no hole because ssh is _already_
> > proof against the worst case.
> Well, no. There's *always* the possibility of remotly explotable
> bugs.
No, there isn't. If there were ssh would be fixed so fast you couldn't
say help in time (it almost has happened before). And if there were,
the IP yu used it from would not matter.
> It's possible that they might not yet be fixed. Because
No it isn't. What is your problem with statistics? Please go back to
skool and do not come back until you understand stochastic argument!
Peter
Michael Heiming
> ? Michael Heiming <michael...@www.heiming.de>:
>> Some basic fw as setup by many modern distro provide with easy
>> tools is a good thing[tm] for them.
> No, it's not. It's a rather *BAD* thing. It would be *MUCH*
> better, if the distribution would configure the system in
> such a way, that only the needed services are externally
> connectable - that might be none.
Implemented in most distro, just click desktop as your choice. It
wasn't the point, the point is still the additional security some
distro firewall offers.
> Further, it would be good, if the distribution would offer
> easy ways to dis-/enable needed services.
Almost any distro comes with tools to do that.
--
Michael Heiming (X-PGP-Sig > GPG-Key ID: EDD27B94)
mail: echo zvp...@urvzvat.qr | perl -pe 'y/a-z/n-za-m/'
#bofh excuse 61: not approved by the FCC
Tony Lawrence
> Tony Lawrence <f...@pcunix.com> wrote:
>
>>Peter T. Breuer wrote:
>>
>>>Tony Lawrence <f...@pcunix.com> wrote:
>
>
>>>>always been the case, and even where it has been, you have no assurance
>>>>that the exploit hasn't been independently discovered by someone else
>>>>either before or concurrent with the white hat reporting.
>>>
>>>
>>>Of course I have! It hasn't been exploited!
>
>
>>Nonsense.
>
>
> No, perfectly true. You seem somewhat naive about probabilities and
> stats ..
Ahh, yes. The beginning of ad hominem attacks. I'm "naive" if I don't
agree with your argument.
How is it naive to say that an exploit that is discovered at time X may
have been known and used by someone else at some previous point?
There's nothing "naive" about it - it's simple fact that you cannot know
if it is known by someone who chooses not to reveal it. You also
completely ignore so-called zero day attacks.
>
>
>
>>You don't know that..
>
>
> Of course I do. Bayesian reasoning.
>
>
>
>>you can't know it because you don't
>>even know that the possibility exists yet!
>
>
> False deduction. Incorrect logic. I can know plenty of things about
> things that haven't occurred yet - the whole science of probability is
> devoted to just exactly that.
Oh please. Another typical Peter debate topic. Off on an unrelated
tangent.
>
>
>
>>But it does exist, and
>>someone can know it and use that knowledge against you.
>
>
> The probability of an exploit against me is as close to zero as one can
> get, because use of the vulnerability causes reports to be generated,
> which causes people to look for it, which causes the exploit to be
> trapped, analysed, and a fix put out, in hours. That's unique to open
> source. The resurces dedicated to finding trapping and fixing it are
> enourmous.
You just ignore reality, don't you? The vulnerability doesn't pop into
existence when it is reported - this isn't Schroedinger's cat. Nor does
exploiting a vulnerability always give away the method, especially when
used against "ordinary" systems. Finally, even if by some miracle the
first use was noticed, and perfectly identified as to source, software
does not get fixed instantly.
>
> Even way back when in the days of the Morris internet worm, which shut
> down about half the then net, the whole thing was seen, trapped and
> rebuffed in about 48h, using just the postmasters. Nowadays the
> response is a matter of about 4-8h and people all over the place
> contribute, as far as I can tell from the reports I have seen go past
> over about the last five years.
>
> (and you are probably confusing the terms "exploit" and "vulnerability"
> - a vulnerability may exist without ever being exploited).
And you are ignoring that your vulnerability can be someone else's
exploit. Again, if I steal a dollar from your wallet but you don't
notice it, I still have your dollar and you certainly can't prevent me
from doing it again because you don't even know it happened!
>
> So by bayesian logic, the only still undefended vulnerabiliies are the
> ones which are not being exploited. Which I am not likely to suffer
> from!
That's ostrich logic. If you can't see it, it doesn't mean it doesn't
exist.
>
>
>
>>>Look - if a tree falls in the forest with nobody to observe it, has it
>>>really fallen?
>
>
>>If I steal a dollar from your wallet and you don't know it, do I still
>>have your dollar?
>
>
> You stole it from me. But not from everybody. So say there are 100
> million people on the internet. Then there is a 1:100000000 chance of
> suffering from your exploit. Thanks - but I am much more likely to be
> run over by a truck, or struck by a falling star.
If I steal everything you own but you don't know HOW I stole it, it
hardly matters what the odds against it are.
>
> If you were to use a technique that was generally applicable and
> rapidly effected in multiple places, it would quickly be noticed,
> analysed, and a defense concocted, transmitted to the distros, and
> passed on to users in updates.
>
Small comfort to those affected by it. "Oh yeah, I got hacked, but
fortunately the patches came out before Peter got hit. Boy, I feel good
about that!"
> The only vulnerabilities not closed are the ones not exploited. That
> means you don't have to worry about them - they are not likely to be
> applied to you.
Again, not necessarily true. I can't recall who said this, but some
recent security book suggested that the worst attacks are hand-crafted
against specific targets and don't necessarily have wide application.
They drew a scenario of studying what you are known to be running and
looking for specific and unknown weaknesses in that software.
>
>
>
>>>If an exploit is not exploited, there is nothing to worry about. You
>>>have zero chance of being hit. When it is exploited, te vulnerability
>>>will be closed in a matter of hours That is a matter of history, and is
>>>perfectly predictable!
>
>
>>There's a buffer overflow bug in the foobah daemon.
>
>
> Great!
>
>
>>Nobody has ever
>>noticed it because it is buried in an unusual condition.
>
>
> Good.
>
>
>>Hacker xyz
>>discovers it and begins using it to get into servers using foobah. He
>>leaves no tracks, just steals what he wants and is gone.
>
>
> Insignificant. A single hacker working away can do maybe 10 breakins a
> day, working full speed. That's 1:10000000 per day. Not even that,
> since he has to locate targets very carefully and keep himself hidden.
> You are more likely to choke to death on your next meal. Worry about
> that instead.
So? If I'm the target, I want all the extra protection I can afford.
Deploying iptables costs me an insignificant amount of time, and even a
hardware firewall is less than a hours income for me. Small price..
Tony Lawrence
> A successful exploit cannot attack a service that is not universal. It
> would be like an illness that only attacks one-legged catholic nuns
> with red hair and a lisp. The exploit would never propagate.
> Epedmiology governs.
It doesn't matter whether it's ssh or foobah: if you don't need to be
open to the world, a firewall ahead of it increases your security. You
can babble about probability all you want, but you can't escape the
facts. Probability doesn't mean squat when it happens to you.
In fact, arguing that you have security through probability is not much
different than arguing for security through obscurity. It's the same
concept.
Peter T. Breuer
> Peter, we still see people posting running RH 9.0 which is
> officially EOL since >1 year by redhat and they don't even have a
> single patch applied.
But either they are not running vulnerable services, or they are.
If they are, and they have a f/w, then the f/w has holes in to let
access to the servers through. So the f/w does nothing for them.
> No question that someone knowledgeable is able to secure his
> system without any firewall.
IF they have a f/w, they must make holes in it for their servers, so
the f/w does nothing for them.
> The distro provided fw tools make it much easier to have a better
> security for those users then anything else.
They will make holes in the f/w in order to let the servers work.
One hole for ftp, one for http, one for ssh, one for domain, one for
... whatever.
> > The same argument applies - they have to update their servers, not have
> > a firewall; the firewall would have holes in it to allow
> > access to their compromisable servers! An ftp server or whatever.
> Again users might only want to offer the service to their home
> lan.
That's advanced server usage, and your users are not that savvy.
If they were that savvy, they would not be doing what they are doing, or
they would be using a f/w.
The nonsavvy people are not running servers or they have made
holes in their f/w to allow access to their servers.
> > They use apt-get update.
> Unlikely they start with Debian or kind off.
Whatever it is called in their distro, then..
> > It permits access to services. That's the aim of services - to serve,
> > so firewalls are open to them. No net attack is based on an uncommon
> > service not running anywahere except locally! There's no point! Worms
> > only target generic, open, services. The next wuftpd vulnerability
> > please stand up! (aren't we overdue?).
> Should be, in addition we are overdue with ssh?
We are. And no firewall restricts access to ssh because the whole point
of ssh is to allow communications from insecure remote hosts, securely.
> > Then they won't be starting services, so they don't need a firewall to
> > disallow access to these nonexisting servers.
> They might not even know that sshd might be running per default.
They can see it.
> > They type apt-get update. They always do, because how else can they keep
> > their gam3s up to date? I bet they do it ten times a day.
> You are presuming anyone out there would run Debian, IMO it's
I am not - I am not particular about the name of their update utility.
> more likely people run suse/mandrake/fedora/redhat or alike.
> Still unsure why you don't want people to have this extra layer
> of security, the kernel provides to us with this remarkable
> features?
Because it is a windows defense, against a windows problem. Linux does
not have that problem.
There is no firewall on my machine and never has been (I just checked
and the techs say that they have just lately been screening the ports I
mentioned in my other post, and I have asked them to stop doing it for
my area).
Peter
Tony Lawrence
> Michael Heiming <michael...@www.heiming.de> wrote:
>
>>Peter, we still see people posting running RH 9.0 which is
>>officially EOL since >1 year by redhat and they don't even have a
>>single patch applied.
>
>
> But either they are not running vulnerable services, or they are.
> If they are, and they have a f/w, then the f/w has holes in to let
> access to the servers through. So the f/w does nothing for them.
How many times do you have to be reminded that we may let certain ip's
through while blocking others? Or perhaps we are letting nothing
through from outside, and the app is supposed to be listening only for
local traffic but is broken or misconfigured?
You say "Don't make mistakes". Must be wonderful to be you..
>
>
>>No question that someone knowledgeable is able to secure his
>>system without any firewall.
>
>
> IF they have a f/w, they must make holes in it for their servers, so
> the f/w does nothing for them.
Not trues, as has been shown over and over again. It can provide an
extra layer of protection as in the example of ssh set for key
authentication and the firewall also enforcing ip filtering. That's not
"nothing".
>
>
>>The distro provided fw tools make it much easier to have a better
>>security for those users then anything else.
>
>
> They will make holes in the f/w in order to let the servers work.
> One hole for ftp, one for http, one for ssh, one for domain, one for
> ... whatever.
One FILTER for whatever service..
>
>
>
>>>The same argument applies - they have to update their servers, not have
>>>a firewall; the firewall would have holes in it to allow
>>>access to their compromisable servers! An ftp server or whatever.
>
>
>>Again users might only want to offer the service to their home
>>lan.
>
>
> That's advanced server usage, and your users are not that savvy.
So it's a matter of being savvy?
>
> If they were that savvy, they would not be doing what they are doing, or
> they would be using a f/w.
>
> The nonsavvy people are not running servers or they have made
> holes in their f/w to allow access to their servers.
Savvy isn't binary.
>
> no firewall restricts access to ssh because the whole point
> of ssh is to allow communications from insecure remote hosts, securely.
My firewalls restrict ssh to certain ip's. I don't wish to allow access
from arbitrary hosts.
Peter T. Breuer
> > No, perfectly true. You seem somewhat naive about probabilities and
> > stats ..
> Ahh, yes. The beginning of ad hominem attacks. I'm "naive" if I don't
> agree with your argument.
> How is it naive to say that an exploit that is discovered at time X may
> have been known and used by someone else at some previous point?
It ignores the probabilities, hence is naive. I showed you (via
stochastic argument) that the situation is stochastically negligible -
if the exploit is not generally used then it is improbable that you
will experience it.
And that is the case, because if it were generally exploited, then a
defense would be quickly developed - in hours.
> There's nothing "naive" about it - it's simple fact that you cannot know
> if it is known by someone who chooses not to reveal it.
That's naive, so yes, there is plenty naive about it. Think about the
probabilities.
> You also
> completely ignore so-called zero day attacks.
No, they're negligible, not "ignored".
Peter
Peter T. Breuer
> Peter T. Breuer wrote:
> > A successful exploit cannot attack a service that is not universal. It
> > would be like an illness that only attacks one-legged catholic nuns
> > with red hair and a lisp. The exploit would never propagate.
> > Epedmiology governs.
> It doesn't matter whether it's ssh or foobah:
True. So?
> if you don't need to be
> open to the world, a firewall ahead of it increases your security.
No it doesn't. See the argument you quoted above. For the exploit to
spread it must attack a universal and generally available service.
> can babble about probability all you want, but you can't escape the
You really don't understand probability, do you? Did you do any math at
school?
peter
Michael Heiming
> Michael Heiming <michael...@www.heiming.de> wrote:
>> Again users might only want to offer the service to their home
>> lan.
> That's advanced server usage, and your users are not that savvy.
Really? This is my whole point about the additional fw, regulate
in a way easier to setup for most users access to services from
one central point, the firewall between lan and internet.
IIRC many distro allow setup as router/firewall for a small lan
with a few additional clicks, unsure if this is advanced server
usage or common for people with a pretty small home lan?
Sure if you allow a service from the outside and are dump enough
to forget applying critical security patches for this service, you
are almost dead, there's no firewall for the specified port if
you allow a service. You can read those contributions every other
day in cols: "Help, have I been rooted!?!?!?!?".
> If they were that savvy, they would not be doing what they are doing, or
> they would be using a f/w.
> The nonsavvy people are not running servers or they have made
> holes in their f/w to allow access to their servers.
[..]
>> > only target generic, open, services. The next wuftpd vulnerability
>> > please stand up! (aren't we overdue?).
>> Should be, in addition we are overdue with ssh?
> We are. And no firewall restricts access to ssh because the whole point
> of ssh is to allow communications from insecure remote hosts, securely.
If you want that, others might prefer to only "allow secure
connections over an insecure wire (internet)", (that's what IMHO
ssh is about), from a few specified IPs or even LAN's. If it's
possible for someone to restrict it, why not?
[..]
--
Michael Heiming (X-PGP-Sig > GPG-Key ID: EDD27B94)
mail: echo zvp...@urvzvat.qr | perl -pe 'y/a-z/n-za-m/'
#bofh excuse 57: Groundskeepers stole the root password
Peter T. Breuer
> Peter T. Breuer wrote:
> > Michael Heiming <michael...@www.heiming.de> wrote:
> >
> >>Peter, we still see people posting running RH 9.0 which is
> >>officially EOL since >1 year by redhat and they don't even have a
> >>single patch applied.
> >
> >
> > But either they are not running vulnerable services, or they are.
> > If they are, and they have a f/w, then the f/w has holes in to let
> > access to the servers through. So the f/w does nothing for them.
> How many times do you have to be reminded that we may let certain ip's
> through while blocking others?
None. You may, but you don't. Exploits only attack available services
- they wouldn't spread unless they did.
Peter
Tony Lawrence
> Tony Lawrence <f...@pcunix.com> wrote:
>
>>>No, perfectly true. You seem somewhat naive about probabilities and
>>>stats ..
>
>
>>Ahh, yes. The beginning of ad hominem attacks. I'm "naive" if I don't
>>agree with your argument.
>
>
>>How is it naive to say that an exploit that is discovered at time X may
>>have been known and used by someone else at some previous point?
>
>
> It ignores the probabilities, hence is naive. I showed you (via
> stochastic argument) that the situation is stochastically negligible -
> if the exploit is not generally used then it is improbable that you
> will experience it.
>
You are basing this on cost/beneft then. If the risk is negligible,
there's no reason to take any action.
Actually, security is much more closely related to insurance. As an
instance of that, I can say that I've lived in this town for 57 years,
and during that time I believe there have been two house fires. Neither
were my home. I'd say the risk of my house burning down is pretty
small. Yet, I carry insurance for that. Why bother? Because although
the chance of it happening may be small, it would be disastrous for me,
so I'm willing to pay the premium every year.
Same with adding a firewall for additional protection. The risk may be
small, but the cost to me would be high, so I'll make the small investment.
Tony Lawrence
> Tony Lawrence <f...@pcunix.com> wrote:
>
>>Peter T. Breuer wrote:
>
>
>>>A successful exploit cannot attack a service that is not universal. It
>>>would be like an illness that only attacks one-legged catholic nuns
>>>with red hair and a lisp. The exploit would never propagate.
>>>Epedmiology governs.
>
>
>>It doesn't matter whether it's ssh or foobah:
>
>
> True. So?
>
>
>>if you don't need to be
>>open to the world, a firewall ahead of it increases your security.
>
>
>
> No it doesn't. See the argument you quoted above. For the exploit to
> spread it must attack a universal and generally available service.
Once again I have to remind you that it isn't important that anything
spreads. All that matters to me is that if it happens to me, it costs
me a great deal of time and money.
>
>
>>can babble about probability all you want, but you can't escape the
>
>
> You really don't understand probability, do you? Did you do any math at
> school?
>
> peter
As explained in another post, it's not probability that's important.
It's how much I have to lose vs. what it costs me to add extra protection.
Tony Lawrence
An exploit doesn't have to spread to be an exploit. This is complete
nonsense. As usual, you are trying to drag the dioscussion onto some
other ground. An exploit can be directed at one particular target and
be completely useless against anyone else - it's still an exploit and
it's still important to the person affected.
But beyond that, a service can be available but restricted, as in the
case of ssh only allowing certain access by specific public keys. In
that case, if the usage can also be tied to specific ip's, the firewall
adds additional security.
Alexander Skwar
> Alexander Skwar <alex...@skwar.name> wrote:
>> ?? Peter T. Breuer <p...@lab.it.uc3m.es>:
>
>> > Tony Lawrence <f...@pcunix.com> wrote:
>> >> Peter T. Breuer wrote:
>> >> > [vulnerabilities] will be taken care of by their distros standard updates page.
>> >
>> >> Again you seem to assume that there is no window of vulnerability, but
>> >
>> > There isn't. Precisely none, to a value of none as close to zero as
>> > makes no difference at all. Closer than I could mark with a pencil.
>
>> You know pretty well, that this is bull.
>
> Nonsense.
Too bad for you.
>> There are 0 day exploits.
>
> Sure. So?
The probability is >0, that your servers will be
attacked with this 0 day exploit.
>> There will ALWAYS be a time lapse between the discovery of a hole
>> and the time it is fixed by the people who make the software and
>> also the time the distributor provides a fix.
>
> Sure. So?
Patch doesn't exist and you're running unfixed, vulnarable
software.
> The open source distrs develop and get the fixes to the users in hours.
Not always.
> MS gets it there at the next service pack, in six months. Maybe.
Not always.
>> It's not always the
>> case, that *everybody* is supposed to be an allowed client.
>
> It is, for successful exploits.
No, it isn't.
>> > If you had a service that you wanted to give to only a special
>> > group of people, you would configure it that way.
>
>> Yep. A packet filter or tcp wrappers might be a way to do that.
>> But since not every service supports tcp wrappers, a packet
>> filter might be the only available choice.
>
>> > And you wouldn't be a
>> > newbie.
>
>> Yep.
>
>> > Let's get specific. You want to let some people use mysql, so you
>> > run the server, open it to every IP, and give your users a login.
>
>> No. If possible, you would open it only to a certain subset of
>> IPs, to limit the source of possible breakins at that layer
>> already.
>
> Well, I'm trying to set up an exploit scenario for him.
In "his world", not everybody can connect to a certain daemon.
> If you want me to instead consider your scenario, I'll point out that
> there is no scope for spread of an exploit in your setup,
Bullshit.
>
>
>
>
> Peter
Alexander Skwar
--
You can always pick up your needle and move to another groove.
-- Tim Leary
Alexander Skwar
No, it is not.
Alexander Skwar
--
Hey, waiter! I want a NEW SHIRT and a PONY TAIL with lemon sauce!
Alexander Skwar
> Tony Lawrence <f...@pcunix.com> wrote:
>> > No, perfectly true. You seem somewhat naive about probabilities and
>> > stats ..
>
>> Ahh, yes. The beginning of ad hominem attacks. I'm "naive" if I don't
>> agree with your argument.
>
>> How is it naive to say that an exploit that is discovered at time X may
>> have been known and used by someone else at some previous point?
>
> It ignores the probabilities,
Well, I don't care about probabilities. If I'm hit, there's
a 100% probability that I'm hit. That's the only probability
that I care about.
> hence is naive.
Wrong away around. It's naive to assume that something will
not happen, because there might be a slim chance.
> I showed you (via
> stochastic argument) that the situation is stochastically negligible -
Well, your stochaistik is not important.
Alexander Skwar
--
Don't hit a man when he's down -- kick him; it's easier.
Alexander Skwar
> Michael Heiming <michael...@www.heiming.de> wrote:
>> Peter, we still see people posting running RH 9.0 which is
>> officially EOL since >1 year by redhat and they don't even have a
>> single patch applied.
>
> But either they are not running vulnerable services, or they are.
> If they are, and they have a f/w, then the f/w has holes in to let
> access to the servers through.
Yes - but the holes might be slim. IOW: They might only allow
certain subnets through.
> So the f/w does nothing for them.
Yes, it does. It limits the range of hosts that can successfully
connect.
>> No question that someone knowledgeable is able to secure his
>> system without any firewall.
>
> IF they have a f/w, they must make holes in it for their servers, so
> the f/w does nothing for them.
Wrong. See above.
>
>> The distro provided fw tools make it much easier to have a better
>> security for those users then anything else.
>
> They will make holes in the f/w in order to let the servers work.
Yes, but maybe only "tiny" holes. Eg. I know that I'll never
go to China. Why allow connects from "chinese IP blocks"
to my SSH server? Sure, there's a huge hole in the (possible)
packet filter setup to allow connects from all the "german
IPs". But that hole might still protect me.
And if not - who cares? There are more layers.
> One hole for ftp, one for http, one for ssh, one for domain, one for
> ... whatever.
So?
>> > The same argument applies - they have to update their servers, not have
>> > a firewall; the firewall would have holes in it to allow
>> > access to their compromisable servers! An ftp server or whatever.
>
>> Again users might only want to offer the service to their home
>> lan.
>
> That's advanced server usage, and your users are not that savvy.
Ah, that's what your geting at. Your at the all or nothing
scenario. Yes, in that case a f/w will not help. But that's
not what Tony is talking about.
> If they were that savvy, they would not be doing what they are doing, or
> they would be using a f/w.
They'd be using a packet filter? Interesting.
> The nonsavvy people are not running servers
*LOL*
> We are. And no firewall restricts access to ssh because the whole point
> of ssh is to allow communications from insecure remote hosts, securely.
Again: Bullshit. SSH (or any other service) is there to provide
service to clients that are allowed to connect to it. No Chinese
will ever be allowed access to my SSH server.
SSH is (on my servers) NOT for *EVERYBODY*.
>> Still unsure why you don't want people to have this extra layer
>> of security, the kernel provides to us with this remarkable
>> features?
>
> Because it is a windows defense, against a windows problem. Linux does
> not have that problem.
No, buggy software with remote exploits is *NOT* a Windows problem.
It's a universal problem, totally OS independant.
Alexander Skwar
--
Marry in haste and everyone starts counting the months.
Alexander Skwar
> Alexander Skwar <alex...@skwar.name> wrote:
>> ?? Peter T. Breuer <p...@lab.it.uc3m.es>:
>
>> > Tony Lawrence <f...@pcunix.com> wrote:
>> >> The point of ssh is not just to give access from wherever I am. As I
>> >
>> > Yes it is. That is precisely the use of it.
>
>> Not "the use", it is *a* *possible* use.
>
>> For example, I'm "pretty" certain, that I will only ever connect
>> to my servers from "german" IPs.
>
> Then why bother allowing ssh?
Because *I* need a way to control my servers. The way I've
chosen is to do that with SSH logins.
> You can simply set up a permanent VPN.
Way too much work.
>
>
>> Or rather, I'll never make a connection
>> from a "chinese" IP. Why should I allow connections from China? I'm
>
> For the time you have to go to china at a moment's notice
Won't happen. By definition.
> But why bother thinking?
Because SSH is unsafe. As every software.
> Ssh is safe
Wrong.
> - that's the whole point of it.
> Refusing to use a safe thing sometimes is silly. Its design makes it
> safe! Not the IP you use it from. Are you trying to claim that your
> laptop is less safe in china than in france?
Hä? That's not what I was saying. I was saying, that there's
no point in allowing connections from China if I'm always in
Germany (or not in China).
>
>> > reveals faults in thinking. There is no hole because ssh is _already_
>> > proof against the worst case.
>
>> Well, no. There's *always* the possibility of remotly explotable
>> bugs.
>
> No, there isn't.
Bullshit.
> If there were ssh would be fixed so fast you couldn't
> say help in time
Not always.
>> It's possible that they might not yet be fixed. Because
>
> No it isn't.
Bullshit.
> What is your problem with statistics?
None. Statistics just don't matter. If I'm hit, I'm hit 100%.
> Please go back to
> skool and do not come back until you understand stochastic argument!
*LOL*
Okay, until that time, you should also stop posting, since
you ignore reality.
Alexander Skwar
--
Someone is speaking well of you.
Paul Black
> Tony Lawrence <f...@pcunix.com> wrote:
>
>>Peter T. Breuer wrote:
>>
>>>Tony Lawrence <f...@pcunix.com> wrote:
>
>
>>>>always been the case, and even where it has been, you have no assurance
>>>>that the exploit hasn't been independently discovered by someone else
>>>>either before or concurrent with the white hat reporting.
>>>
>>>
>>>Of course I have! It hasn't been exploited!
>
>
>>Nonsense.
>
>
> No, perfectly true. You seem somewhat naive about probabilities and
> stats ..
You're the one who is naive, your sample of one tells you nothing. If
there are 100 million computers running the same software, how many do
you have to check to have a 95% confidence that there are no exploits?
Hint: it's more than just your machine.
Paul
Peter T. Breuer
> > stochastic argument) that the situation is stochastically negligible -
> > if the exploit is not generally used then it is improbable that you
> > will experience it.
> You are basing this on cost/beneft then.
Well, I was arguing using probability, not expectation (risk), but
"yes". Probability is risk "without taking into account a varying damage
estimate". And yes, this is precisely how one evaluates security.
> If the risk is negligible,
> there's no reason to take any action.
Exactly. One constructs the attack/defense tree, assigns prbabilities
and damage valuations to it, and constructs the expected loss.
> Actually, security is much more closely related to insurance.
That's risk.
> As an
> instance of that, I can say that I've lived in this town for 57 years,
> and during that time I believe there have been two house fires.
So assuming that there are 2000 houses in town, the probability of a
house fire is 2/2000/57 or 1:57000 per year. Assuming that the average
damage is about $50K, you expect to pay just under $1 per year in
insurance. Any more than that you pay is profit to the insurance
company.
> Neither
> were my home. I'd say the risk of my house burning down is pretty
> small. Yet, I carry insurance for that. Why bother?
Well, because it's legally required. I assume. From your point of view,
any long odds bet is a win, since you can't do enough experiements to
make it into a statistic. You should always bet at long odds - you may
get "lucky" once in a lifetime. If not, so what? You're dead.
> Because although
> the chance of it happening may be small, it would be disastrous for me,
> so I'm willing to pay the premium every year.
> Same with adding a firewall for additional protection. The risk may be
> small, but the cost to me would be high, so I'll make the small investment.
Ahhh ... so you think there is a cost. Only effort. No - the cost is
mre subtle: it's the attitude that you don't control what's going on in
your box, and need to control it at the IP level becuase you can't do it
at the application level.
Try controlling it - it's simple. You don't need a firewall to
establish your control.
Peter
Peter T. Breuer
> ?? Peter T. Breuer <p...@lab.it.uc3m.es>:
> > Tony Lawrence <f...@pcunix.com> wrote:
> >> How is it naive to say that an exploit that is discovered at time X may
> >> have been known and used by someone else at some previous point?
> >
> > It ignores the probabilities,
> Well, I don't care about probabilities. If I'm hit, there's
Then that's naive, and betrays a certain incomprehensin of stats, risk,
probability, and hence security, which is based exactly on probability
and risk.
> a 100% probability that I'm hit. That's the only probability
> that I care about.
There you are - stochastically naive.
> > hence is naive.
> Wrong away around. It's naive to assume that something will
> not happen, because there might be a slim chance.
It's like talking to a color-blind person who insists that there is only
black and white, and that it's not naive to say so! Allow me to sell
you some insurance.
Peter
Peter T. Breuer
> [ptb]
> > No, perfectly true. You seem somewhat naive about probabilities and
> > stats ..
> You're the one who is naive, your sample of one tells you nothing.
What "sample of one"? I am talking probabilities, not stats.
> If
> there are 100 million computers running the same software, how many do
> you have to check to have a 95% confidence that there are no exploits?
On my machine? One.
> Hint: it's more than just your machine.
I'm sure you know enough theory to at least formulate a sensible
question. The answer is that you can be confident already - if there
were a successful exploit already in the wild, your own machine would
have it, by definition, with high probability. It's a disease spreading
through a vulnerable population ...
Peter
Peter T. Breuer
> > No it doesn't. See the argument you quoted above. For the exploit to
> > spread it must attack a universal and generally available service.
> Once again I have to remind you that it isn't important that anything
> spreads.
Of course it is. That's what defines an exploit. It it can't spread,
then it isn't to be considered at all.
> All that matters to me is that if it happens to me, it costs
> me a great deal of time and money.
It won't happen to you - the exploit cannot spread to you in the first
place.
Peter
Sasquatch
I ran the following command line...
msec 0
...to change my MandrakeLinux "security level" to 0. I think it was
set to 4 previously. Now, when I change permission setting for files
and folders, they stay that way no matter how foolish the permissions
are. :-)
Thanks for all the help!
- Sasquatch
Sasquatch wrote:
> After setting up Samba, I'm having problems with file permissions
> reverting back to old settings about 1/2 hour after I change them.
Can
> someone please help? Here are the details...
>
> I've set up a simple Samba file share on my MandrakeLinux Special
> Edition 2005 server. Samba was already installed and running because
> of the choices I made when I installed my linux distro. So all I had
> to do (I think) is edit the smb.conf file, which I did. The only
> change I made to smb.conf was to change the workgroup name to match
the
> workgroup on my home LAN, and I added the following section to the
very
> bottom of the smb.conf file:
>
> # This one is useful for people to share files
> [share]
> comment = Shared files
> path = /home/share
> read only = no
> writable = yes
> browseable = yes
> public = yes
>
> Then I ran the Konquerer file manager with root privileges (kdesu
> konqueror) and changed the permissions on the /home/share folder and
> all of its contents so that the one and only user on my Linux system
> has both read and write privileges, as does the group and all
"others."
>
> Once I made these changes, the new Samba share started showing up on
my
> Windows computers just as I suspected. Immediately I was able to
> transfer files to the share from my Windows computers, rename files,
> delete files, copy files, etc. Everything worked perfectly. ...but
> only for about 1/2 hour. When it stopped working, I examined the
> permissions, and they had changed back to "forbidden" for both
"group"
> and "others." I changed the permissions back to read and write,
closed
> Konqueror, and reopened Konqueror to check the privileges, and the
> privilege changes were indeed sticking. But 1/2 hour later they
> changed back AGAIN.
>
> Why are these privileges reverting like this? I should also point
out
> that, a day before, prior to learning about the smb.conf file, I
tried
> setting up some kind of sharing of the same folder using some kind of
> KDE utility, and I can't even remember which utility it was now.
Ever
> since, in Konqueror, the icon for the shared folder has had a
slightly
> different folder icon, as if it has a tiny picture of a power plug,
> cable, or link, or something on it. This was before I even
configured
> Samba. Could this other sharing be conflicting with my Samba
settings?
> What are all the different utilities I can check to make sure this
> share is set up properly and that there are no other sharing settings
> that are conflicting?
>
> Please help. Any assistance is greatly appreciated.
>
> Thanks,
> John
Peter T. Breuer
> An exploit doesn't have to spread to be an exploit.
Of course it does.
Peter
Peter T. Breuer
> Too bad for you.
> >> There are 0 day exploits.
> >
> > Sure. So?
> The probability is >0,
All probabilities are greater than 0 for not-impossible things, so the
statement is meaningless. The probability is >0 that your atoms may
spontaneusly decide to disassociate in 4.3s time and reform themselves
into a crate of beer.
> that your servers will be
> attacked with this 0 day exploit.
So what? The probability is lower than an airliner dropping out
of the sky and on to my server rack.
> >> There will ALWAYS be a time lapse between the discovery of a hole
> >> and the time it is fixed by the people who make the software and
> >> also the time the distributor provides a fix.
> >
> > Sure. So?
> Patch doesn't exist and you're running unfixed, vulnarable
> software.
No I'm not - improbable situation, so neglible. Consider instead the
higher probability that somebody in your company decides to go mad and
wipe the server disks. I'm sure that at least two people in the USA
go screaming mad while employed every year. That would be 1:100000000.
> > The open source distrs develop and get the fixes to the users in hours.
> Not always.
Always.
> > MS gets it there at the next service pack, in six months. Maybe.
> Not always.
That's what I said.
> >> It's not always the
> >> case, that *everybody* is supposed to be an allowed client.
> >
> > It is, for successful exploits.
> No, it isn't.
Yes it is. Epedemiology theory.
> > If you want me to instead consider your scenario, I'll point out that
> > there is no scope for spread of an exploit in your setup,
> Bullshit.
Nope - just observation. Exploits need a medium through which they can
spread, receptors on the cell walls, if you like. Not enough of the
right kind of receptor, and the exploit never spreads through the
population, hence dies out. Successful exploits are those that spread,
and the reason that you aren't already infected by a successful exploit
is because none ever spread.
Consider why.
The answer is that none were able to spread as fast as the immunisation
against them spread, in the open source environment, and that none ever
found sufficient monoculture to be able to spread.
Peter
Alexander Skwar
> Alexander Skwar <alex...@skwar.name> wrote:
>> ?? Peter T. Breuer <p...@lab.it.uc3m.es>:
>
>> > Tony Lawrence <f...@pcunix.com> wrote:
>> >> How is it naive to say that an exploit that is discovered at time X may
>> >> have been known and used by someone else at some previous point?
>> >
>> > It ignores the probabilities,
>
>> Well, I don't care about probabilities. If I'm hit, there's
>
> Then that's naive,
No, it's not. It's naive to assume, that something WILL not
happen because the chances are slim.
>> Wrong away around. It's naive to assume that something will
>> not happen, because there might be a slim chance.
>
> It's like talking to a color-blind person who insists that there is only
> black and white, and that it's not naive to say so!
Yep, that's the way it feels talking to you.
Alexander Skwar
--
My doctor told me to stop having intimate dinners for four. Unless there
are three other people.
-- Orson Welles
Walter Mautner
> On Sat, 07 May 2005 at 21:36 GMT, Sasquatch wrote:
>> After setting up Samba, I'm having problems with file permissions
>> reverting back to old settings about 1/2 hour after I change them. Can
>> someone please help? Here are the details...
>>
>> I've set up a simple Samba file share on my MandrakeLinux Special
>> Edition 2005 server. Samba was already installed and running because
>> of the choices I made when I installed my linux distro. So all I had
>> to do (I think) is edit the smb.conf file, which I did. The only
>> change I made to smb.conf was to change the workgroup name to match the
>> workgroup on my home LAN, and I added the following section to the very
>> bottom of the smb.conf file:
>>
>> # This one is useful for people to share files
>> [share]
>> comment = Shared files
>> path = /home/share
>> read only = no
>> writable = yes
>> browseable = yes
>> public = yes
>>
....
>> permissions, and they had changed back to "forbidden" for both "group"
>> and "others." I changed the permissions back to read and write, closed
>> Konqueror, and reopened Konqueror to check the privileges, and the
>> privilege changes were indeed sticking. But 1/2 hour later they
>> changed back AGAIN.
.....
> The permissions are probably being reset by msec, Mandrake's
> security system. You can change the settings in
> /usr/share/msec/perm.N, where N is your security level.
>
Yeah :). Last noticed that effect on a little server I set up for a branch
office with Mandrake, using a structured home like /home/%G/%U from a ldap.
Since /home/%G should be group writable, I had to alter the msec settings.
--
Longhorn error#4711: TCPA / NGSCP VIOLATION: Microsoft optical mouse
detected penguin patterns on mousepad. Partition scan in progress
to remove offending incompatible products. Reactivate MS software.
Linux woodpecker.homnet.at 2.6.11-mm4[LinuxCounter#295241,ICQ#4918962]
Alexander Skwar
> Alexander Skwar <alex...@skwar.name> wrote:
>> Too bad for you.
>
>> >> There are 0 day exploits.
>> >
>> > Sure. So?
>
>> The probability is >0,
>
> All probabilities are greater than 0 for not-impossible things, so the
> statement is meaningless. The probability is >0 that your atoms may
> spontaneusly decide to disassociate in 4.3s time and reform themselves
> into a crate of beer.
>
>
>> that your servers will be
>> attacked with this 0 day exploit.
>
> So what?
Ah. It doesn't matter to you if your servers get 0wn3d. Well, I disagree.
> The probability is lower than an airliner dropping out
> of the sky and on to my server rack.
>
>> >> There will ALWAYS be a time lapse between the discovery of a hole
>> >> and the time it is fixed by the people who make the software and
>> >> also the time the distributor provides a fix.
>> >
>> > Sure. So?
>
>> Patch doesn't exist and you're running unfixed, vulnarable
>> software.
>
> No I'm not
Yes, you are.
> - improbable situation, so neglible.
Nonesense.
> Consider instead the
> higher probability that somebody in your company decides to go mad and
> wipe the server disks.
So? That doesn't have anything to do with what we're talkin
about.
But, well, it has: I suppose you're also against taking
backups because the probability is low. Correct?
> I'm sure that at least two people in the USA
> go screaming mad while employed every year. That would be 1:100000000.
Backups are bad. Is that it?
That's something where I disagree as well.
>> > The open source distrs develop and get the fixes to the users in hours.
>
>> Not always.
>
> Always.
Bullshit.
>> > MS gets it there at the next service pack, in six months. Maybe.
>
>> Not always.
>
> That's what I said.
No, that's not what you said.
>> >> It's not always the
>> >> case, that *everybody* is supposed to be an allowed client.
>> >
>> > It is, for successful exploits.
>
>> No, it isn't.
>
> Yes it is. Epedemiology theory.
Whatever.
>
>
>
>> > If you want me to instead consider your scenario, I'll point out that
>> > there is no scope for spread of an exploit in your setup,
>
>> Bullshit.
>
> Nope
Yes.
> - just observation.
Hint: It's better to observe things with opened eyes.
Alexander Skwar
--
We are using Linux daily to UP our productivity - so UP yours!
(Adapted from Pat Paulsen by Joe Sloan)
Alexander Skwar
> Tony Lawrence <f...@pcunix.com> wrote:
>> An exploit doesn't have to spread to be an exploit.
>
>
> Of course it does.
No, of course not. If *I* write an exploit and keep it
to myself, its still an exploit.
Alexander Skwar
--
Q: What's the difference between a duck and an elephant?
A: You can't get down off an elephant.
Alexander Skwar
> Peter T. Breuer <p...@lab.it.uc3m.es>:
>
>> Tony Lawrence <f...@pcunix.com> wrote:
>>> An exploit doesn't have to spread to be an exploit.
>>
>>
>> Of course it does.
>
> No, of course not. If *I* write an exploit and keep it
> to myself, its still an exploit.
Or would you define it that way, that I have spread it
to myself?
Alexander Skwar
--
The way to a man's stomach is through his esophagus.