 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> As far as I know, getting X to actually work remotely is extremely
>> difficult, whereas I know from experience that getting VNC to work
>> remotely is trivial.
>
> VNC is also trivially compromised unless you tunnel it over ssh or wrap
> it in ssl.
If the two machines are on the same LAN, this probably isn't a problem.
(And presumably the same applies to X as well anyway...)
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>>> So I'm lying, then, is that it?
>>
>> OK, let me put it this way: I've never seen any manpage which is
>> anything more than a terse summary of command switches with an
>> incomplete description of what they do. The most in-depth manpage I've
>> seen is for Bash, which is still only a reference document, not an
>> introductory tutorial.
>
> Man pages are not intended to be tutorials. They're manual pages.
...which is the point I'm trying to make, yes.
>> Then again, sometimes the manpage just says "use info". And then you had
>> /another/ problem...
>
> Well, no, it's not *another* problem - you just need to use the info
> command instead.
Have /you/ tried navigating the thing?
Since I'm guessing the answer is probably "yes", then I don't need to
explain to you how hard it is...
>>> It doesn't say anything about CHAP. I'm pretty sure it also doesn't
>>> change the password encryption method from AES to Triple-DES as well.
>>> It's not likely to document everything it *doesn't* do, just what it
>>> *does* do.
>>
>> So even with this line, people can *still* authenticate by password.
>
> Not to the best of my knowledge.
I'm fairly sure I tested it, and discovered that I needed to turn off
multiple things to stop it accepting my password as a valid login. But
since that was then and this is now, I guess I might be incorrect.
>>>> I thought the host key is how the server identifies itself to you, not
>>>> how you identify yourself to the server?
>>>
>>> Host keys aren't very commonly used AFAIK.
>>
>> All three of the SFTP systems we use commercially have them.
>
> A sample size of 3 isn't exactly data supporting "commonly used".
It's infinity times larger than a sample size of zero. ;-)
Then again, one of these systems is set up to use PK authentication, and
the server administrators emailled /us/ with the private key to use to
get access. *facepalm*
Imagine it: Going to all the trouble of setting up a secure system, and
not even knowing how to secure it properly...
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le 15/09/2011 20:46, Orchid XP v8 nous fit lire :
>>>> It doesn't say anything about CHAP. I'm pretty sure it also doesn't
>>>> change the password encryption method from AES to Triple-DES as well.
>>>> It's not likely to document everything it *doesn't* do, just what it
>>>> *does* do.
>>>
>>> So even with this line, people can *still* authenticate by password.
>>
>> Not to the best of my knowledge.
>
> I'm fairly sure I tested it, and discovered that I needed to turn off
> multiple things to stop it accepting my password as a valid login. But
> since that was then and this is now, I guess I might be incorrect.
>
Did you at least refresh (aka reload) sshd when updating the configuration ?
Updating the configuration is not enough, the daemon must be flushed to
reload it.
SSH password authentication is just delegating the password to the OS
system... (bad! IMNSHO)
>>>>> I thought the host key is how the server identifies itself to you, not
>>>>> how you identify yourself to the server?
>>>>
>>>> Host keys aren't very commonly used AFAIK.
>>>
>>> All three of the SFTP systems we use commercially have them.
>>
>> A sample size of 3 isn't exactly data supporting "commonly used".
>
> It's infinity times larger than a sample size of zero. ;-)
Host key are kind of mandatory for server. Unless you want to use ssh
without encryption at all.
>
> Then again, one of these systems is set up to use PK authentication, and
> the server administrators emailled /us/ with the private key to use to
> get access. *facepalm*
>
> Imagine it: Going to all the trouble of setting up a secure system, and
> not even knowing how to secure it properly...
>
That's the issue with wrong administrators: they assume people do not
have their own public key, and generate a pair for them... they need a
clue (and some users too!).
From my bad memory, there is at least 5 kinds of attacks that must be
covered. If you cannot understand them all, you're out of the trusted.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> I'm fairly sure I tested it, and discovered that I needed to turn off
>> multiple things to stop it accepting my password as a valid login. But
>> since that was then and this is now, I guess I might be incorrect.
>>
>
> Did you at least refresh (aka reload) sshd when updating the configuration ?
Is rebooting the machine sufficient to do that?
If so, yes...
>> Imagine it: Going to all the trouble of setting up a secure system, and
>> not even knowing how to secure it properly...
>
> That's the issue with wrong administrators: they assume people do not
> have their own public key, and generate a pair for them... they need a
> clue (and some users too!).
The most mystifying part is, the first time we set it up, they did it
right. Only the second time around did they insist that we use their key...
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>>> First thing, typing ? at any point will list all the available commands
>>> at that point.
>>
>> So... it's some kind of hierarchical menu system? (I had assumed that
>> all commands are available all the time.)
>
> Yes and no.
>
> there are multiple modes. Normal display mode, "enable" mode, where you
> can make some changes such as clear counters, logs or set certain
> parameters, and "Configure" mode where you make ... configuration changes.
>
> The available commands vary for each mode, however what I meant whas that
>
> ? by itself will list all the commands you can type, while
>
> show ?
>
> will list all the stuff the show command can display, and
>
> show interface ?
>
> will list all the types of interfaces that can be displayed
>
> etc...
Oh, right, I see. Well that seems logical enough...
>> I'm guessing that unless you do this kind of thing all day, you'll
>> quickly forget what the name for each command is, and so you'll need the
>> manual open constantly. (I really hope the manuals contain more than
>> just a reference list of every command name and what it does...)
>
> Configuration guides, command references, hardware installation
> checklists, etc... they're all in there.
That's very reassuring.
>>> Routing for the multiple lans actually comes straigh out of the box. You
>>> confiugre an ip address on all the interfaces and it will know that any
>>> packets it receives whose destination is on another lan interface, it
>>> will forward it (let's disregard security rules, for the moment!).
>>
>> Even though there's only one connection from the firewall to the
>> (multiple) switches?
>
> Then, there are mulitple "VLAN" interfaces created, so the above still
> stands.
I see. (I think...)
>>> On Windows, you'd type:
>>>
>>> route add 192.168.200.0 mask 255.255.255.0 192.168.1.1
>>
>> 1. I didn't know you could do that.
>> 2. What does it do?
>>
>
> It tells your PC that there's a network called 192.168.200.0 somewhere
> voer there, and that to get ot it, you must forward the packets to
> 192.168.1.1 and he'll take care of them.
Interesting. I didn't know Windows was actually capable of doing that.
Usually when I need a router in a hurry, I load up Linux and read some
manpages...
Hmm, I wonder... If my VPN client doesn't route all the subnets I want,
can I get it to dump the packets onto the wrong LAN segment, and then
trust the router at that end to take it to the correct place?
>> Incidentally, I gather that there's two ways to control the ASA. One
>> involves telnet. The other involves a serial cable...
>
> Serial cable is required to give the machine its initial barebones
> config, after that, it's telnet or preferably ssh. Since anyone could
> sniff the telnet password.
It's neat that you can configure it via IP. Then again, if you configure
the IP stuff wrong, you need to connect somehow so you can reconfigure
it. :-}
I wonder what authentication options there are for SSH...
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>>>> On Windows, you'd type:
>>>>
>>>> route add 192.168.200.0 mask 255.255.255.0 192.168.1.1
>>>
>>> 1. I didn't know you could do that.
>>> 2. What does it do?
>>>
>>
>> It tells your PC that there's a network called 192.168.200.0 somewhere
>> voer there, and that to get ot it, you must forward the packets to
>> 192.168.1.1 and he'll take care of them.
>
> Interesting. I didn't know Windows was actually capable of doing that.
> Usually when I need a router in a hurry, I load up Linux and read some
> manpages...
>
> Hmm, I wonder... If my VPN client doesn't route all the subnets I want,
> can I get it to dump the packets onto the wrong LAN segment, and then
> trust the router at that end to take it to the correct place?
>
Assuming your router knows the way and there are no filters or
restrictions in place, yes.
>>> Incidentally, I gather that there's two ways to control the ASA. One
>>> involves telnet. The other involves a serial cable...
>>
>> Serial cable is required to give the machine its initial barebones
>> config, after that, it's telnet or preferably ssh. Since anyone could
>> sniff the telnet password.
>
> It's neat that you can configure it via IP. Then again, if you configure
> the IP stuff wrong, you need to connect somehow so you can reconfigure
> it. :-}
>
> I wonder what authentication options there are for SSH...
>
Userid / password. Either local or via an external authentication
system (TACACS, Radius, Kerberos, RSA SecurID, etc...)
--
/*Francois Labreque*/#local a=x+y;#local b=x+a;#local c=a+b;#macro P(F//
/* flabreque */L)polygon{5,F,F+z,L+z,L,F pigment{rgb 9}}#end union
/* @ */{P(0,a)P(a,b)P(b,c)P(2*a,2*b)P(2*b,b+c)P(b+c,<2,3>)
/* gmail.com */}camera{orthographic location<6,1.25,-6>look_at a }
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le 2011-09-14 04:40, Invisible a écrit :
>>> So how do you prevent somebody connecting to your server a thousand
>>> times per second and feeding it duff credentials, thereby preventing any
>>> legitimate users logging in, and wasting lots of CPU power?
>>>
>>> See, security isn't so simple...
>>>
>>
>> by having a real firewall (such as the aforementioned Cisco ASA)
>> configured to throttle individual connections. ;)
>
> I'm sorry, I thought we were still talking about "why the average home
> user can't easily send a file to another average home user". :-) I doubt
> many home users will pay hundreds of pounds for a Cisco ASA and spend
> god-knows how long learning what "tee sea pee eye pee" is in order to
> set this up.
The average user will not get DDOSed unless he pissed off the person
DDoSing him. Even the morons of 4Chan don't DDoS random people for the
lulz.
If you are afraid of a denial of service attack, it means you have
something worth attacking. Therefore the few thousand dollars spent on
a decent security appliance will be worth it. How long can your
business withstand being offline before your loses are more than the
price of the firewall?
>
>> Now the /b/tard in question would have to use zombie PCs to do his DOS
>> against your machine.
>
> Yeah, because none of the script kiddies have figured out how to do
> that. ;-)
>
Most of them still ask how to download LOIC and act all surprised when
they get a knock on their door.
> Then again, if somebody decides to DDoS you, it doesn't matter if you
> have *no* ports exposed to the Internet... You still get no service.
>
> Sometimes I think it would be nice if there was a widely-supported
> standard for configuring the firewall at the /other end/ of the last
> mile to drop certain packets. But anyway...
A DDoS needs to be extremely big for an ISP to notice one of its
customers is under attack. And you need a special business relationship
to be able to call them up and ask that they block a certain type of
traffic at the head end.
--
/*Francois Labreque*/#local a=x+y;#local b=x+a;#local c=a+b;#macro P(F//
/* flabreque */L)polygon{5,F,F+z,L+z,L,F pigment{rgb 9}}#end union
/* @ */{P(0,a)P(a,b)P(b,c)P(2*a,2*b)P(2*b,b+c)P(b+c,<2,3>)
/* gmail.com */}camera{orthographic location<6,1.25,-6>look_at a }
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le 2011-09-14 16:52, Orchid XP v8 a écrit :
>>>> Yep. You still need a computer for each user, tho.
>>>
>>> Sure. But I mean, you can set up an application server that more than
>>> one
>>> person can access, without doing anything particularly special.
>>
>> You can do exactly the same thing on Windows that you do on Unix.
>>
>> Log into the windows box remotely. Start an X client and point it at
>> your display. Disconnect without logging out. Someone else logs into the
>> windows box remotely. They start an X client and points it at their
>> display. They disconnect without logging out. Guess what? Windows
>> running X clients talking to two different X servers.
>
> Does anyone, anywhere on Earth, actually run X on Windows?
>
> I mean, I gather that you *can*. But does anybody actually *do* this?
>
Yes.
For two reasons.
1) One of the network monitoring software suite I use is an ugly Windows
port of something that was developped for Solaris. Most of the
configuration tools were written for Motif, and many of the command line
utilities are ksh scripts. So the 5 servers that run this particular
tool all run not only X11, but a "unix environment for Windows" as well.
2) Other servers I manages ARE running AIX, Solaris or Linux. so the
only way to run their GUI utilities is by tunnelling X through ssh back
to my PC. Just like about 100,000 of my coworkers do.
--
/*Francois Labreque*/#local a=x+y;#local b=x+a;#local c=a+b;#macro P(F//
/* flabreque */L)polygon{5,F,F+z,L+z,L,F pigment{rgb 9}}#end union
/* @ */{P(0,a)P(a,b)P(b,c)P(2*a,2*b)P(2*b,b+c)P(b+c,<2,3>)
/* gmail.com */}camera{orthographic location<6,1.25,-6>look_at a }
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le 2011-09-15 15:29, Orchid XP v8 a écrit :
>>> I'm fairly sure I tested it, and discovered that I needed to turn off
>>> multiple things to stop it accepting my password as a valid login. But
>>> since that was then and this is now, I guess I might be incorrect.
>>>
>>
>> Did you at least refresh (aka reload) sshd when updating the
>> configuration ?
>
> Is rebooting the machine sufficient to do that?
>
> If so, yes...
>
Heathen! Linux machines do not need to be rebooted. Ever.
To quote Yoda: Unlearn everything you must.
--
/*Francois Labreque*/#local a=x+y;#local b=x+a;#local c=a+b;#macro P(F//
/* flabreque */L)polygon{5,F,F+z,L+z,L,F pigment{rgb 9}}#end union
/* @ */{P(0,a)P(a,b)P(b,c)P(2*a,2*b)P(2*b,b+c)P(b+c,<2,3>)
/* gmail.com */}camera{orthographic location<6,1.25,-6>look_at a }
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le 2011-09-15 13:15, Orchid XP v8 a écrit :
>>> 1995? Jesus, that's WITHIN MY OWN LIFETIME! Compared to Unix, which
>>> almost pre-dates binary computers, that's ultra-modernist!
>>
>> Not only, but current ssh is version 2, which leave the status of draft
>> only in 2006; (1.99 is drafted version 2)
>>
>> ssh of 1995 was version 1 and limited to remote shell (with very limited
>> inband file transfer).
>
> I'm told v1 isn't as secure either. I don't know if that's actually true...
>
ssh 1.0's insecurity was a major plot point of the Matrix II or III.
--
/*Francois Labreque*/#local a=x+y;#local b=x+a;#local c=a+b;#macro P(F//
/* flabreque */L)polygon{5,F,F+z,L+z,L,F pigment{rgb 9}}#end union
/* @ */{P(0,a)P(a,b)P(b,c)P(2*a,2*b)P(2*b,b+c)P(b+c,<2,3>)
/* gmail.com */}camera{orthographic location<6,1.25,-6>look_at a }
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
