Re: Pseudo-cluster firewall
> > Now the problem: I have only a cross-over cable from the router to > > the firewall, so I cannot connect the backup firewall. Using > > a switch is pointless: the switch may die too. Switches are relatively easy to set up in failover configuration ( most cisco gear supports it ) (well, the problem would the be, how to connect such setup to router with single ethernet jack ). As far as fail-over firewalls go, they're pretty easy to set up, apt-cache show vrrd (or maybe even better apt-cache show ucarp ) This little daemon makes it easy to set up two firewalls, the only problem would be that in case of failure all nat-ted connections get dropped and you have to reconnect. If you want to avoid that, go for OpenBSD and their firewall sync. ( btw, with ucarp you can create dual firewall with one machine running Debain and the other running OpenBSD ). I used to set up such thingies with debian as primary and freebsd running as backup ( which theoretically 'protects' you from critical failures in debian ). -- Dariush Pietrzak, Key fingerprint = 40D0 9FFB 9939 7320 8294 05E0 BCC7 02C4 75CC 50D9 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: doing an ssh into a compromised host
On Tue, Nov 02, 2004 at 10:14:37AM -0200, Henrique de Moraes Holschuh wrote: > (and if you are as paranoid as you > should, you're using an agent that ASKS before doing any work). Do you have such a thing? I would absolutely love an ssh agent that only asks for pass-phrases as needed, times them out eventually, and can prompt before answering a challenge. Andrew -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Pseudo-cluster firewall
On Tue, Nov 02, 2004 at 08:55:24PM +0100, Raffaele D'Elia wrote:
(...)
I fail to see how this is a Debian-specific security issue, but I'll bite.
> Now the problem: I have only a cross-over cable from the router to the
> firewall, so I cannot connect the backup firewall.
> Using a switch is pointless: the switch may die too.
However, a switch/hub is maybe less prone to issues than the firewall
(depending on what are you using as your firewall platform). So, if you
actually don't trust the switch, why trust the router (which is also a
point of failure) or the proxy?
> Moreover I have a proxy in front of the lan, so I cannot connect 2
> firewalls even on the lan side.
If you want to be fully fault-tolerant you need two switches in the front
and two in the back. You'll get what it's commonly refered to as a
"firewall sandwich". Then you need to use some clustering software (like
the 'vrrpd' package available in Debian) to configure the firewall
failover. Vrrpd will only provide standby-failover (no active-active
cluster unless you use external load-balancing mechanisms)
RouterA SW1 FWA SW2 Proxy A ---\
| | --- Internal LAN
RouterB --- SW3 FWB SW3 Proxy B ---/
That covers all possible failures (Router, Switch, Firewall, Proxy or
even cable). Depending on how you configure it you might be able to sustain
multiple failures (a switch _and_ a firewall die at the same time...) as
long as they are not "crossed" (i.e. SW1 and FWB die at the same time)
If that's just too much hardware for you and the most unreliable point is
your firewall. Then you'll have to stick with:
FWA ___
Router -- Hub /\Hub --- Proxy - Internal LAN
\ FWB ---/
Hubs are probably more resilient to failure that your firewalls, if you
don't go for the cheapest. You could probably have a backup Proxy
plugged in there too (to the same hub) with clustering software to serve as
a backup.
Regards
Javier
signature.asc
Description: Digital signature
Re: Pseudo-cluster firewall
also sprach Raffaele D'Elia <[EMAIL PROTECTED]> [2004.11.02.2055 +0100]: > Now the problem: I have only a cross-over cable from the router to > the firewall, so I cannot connect the backup firewall. Using > a switch is pointless: the switch may die too. The router may die. Setting up a failover config is a lot of pain and costs a lot of money. Do you need it? Instead, have a second machine ready, backups, a second switch, and prepare for an hour or two of downtime. Also, this is not a topic for debian-security, really. debian-firewall, debian-user or maybe debian-isp. -- Please do not send copies of list mail to me; I read the list! .''`. martin f. krafft <[EMAIL PROTECTED]> : :' :proud Debian developer, admin, user, and author `. `'` `- Debian - when you have better things to do than fixing a system Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver! signature.asc Description: Digital signature
Pseudo-cluster firewall
Hi all, I have a firewall with 3 NICs (LAN,DMZ,ROUTER); this is a single point of failure, of course! I've decided to build a backup firewall, with similar hardware (just in case) and the same config. Now the problem: I have only a cross-over cable from the router to the firewall, so I cannot connect the backup firewall. Using a switch is pointless: the switch may die too. Moreover I have a proxy in front of the lan, so I cannot connect 2 firewalls even on the lan side. How to cope with this? Someone have such problems going to sleep? Best regards. Radel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: doing an ssh into a compromised host
also sprach Henrique de Moraes Holschuh <[EMAIL PROTECTED]> [2004.11.02.1314 +0100]: > It should not be possible to retrieve key material from the agent, > ever. And the whole setup should not be vulnerable to replay > attacks when using protocol 2 either. > > Are you *completely* sure of what you are talking about? Yes, although I was not clear: having access to /tmp/ssh* means that you can access all hosts that trust the key used to login to the current host for the duration of the current session. Since only authentication has to be during the current session, an attacker could gain access to other hosts and idle there for as long as the network stays up. Access to key material and replay attacks are not possible. -- Please do not send copies of list mail to me; I read the list! .''`. martin f. krafft <[EMAIL PROTECTED]> : :' :proud Debian developer, admin, user, and author `. `'` `- Debian - when you have better things to do than fixing a system Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver! signature.asc Description: Digital signature
Re: doing an ssh into a compromised host
also sprach Dariush Pietrzak <[EMAIL PROTECTED]> [2004.11.02.1053 +0100]: > hmm, but in /tmp/ssh* there's just a socket... so when agent is gone, what > good is that file? Fine, so the other hosts are only accessible while you are logged in. Should be enough to hijack them... -- Please do not send copies of list mail to me; I read the list! .''`. martin f. krafft <[EMAIL PROTECTED]> : :' :proud Debian developer, admin, user, and author `. `'` `- Debian - when you have better things to do than fixing a system Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver! signature.asc Description: Digital signature
Re: ssh chroot on debian documentation
Regards, Robert Vangel <[EMAIL PROTECTED]> - Tue, Nov 02, 2004: > Can people please be more careful when creating new messages, not to hit > reply to a message then removing everything & starting again. Because it breaks the natural flow of conversation. Why is top-posting so bad? -- Loïc Minier <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: doing an ssh into a compromised host
On Tue, 02 Nov 2004, martin f krafft wrote: > If you forward your agent (-A, or ForwardAgent yes), then the > attacker now probably has access to all machines where the SSH key > you used has access. This goes agaist what I know about the agent. The attacker could *try* to access the agent when it was active (and if you are as paranoid as you should, you're using an agent that ASKS before doing any work). It should not be possible to retrieve key material from the agent, ever. And the whole setup should not be vulnerable to replay attacks when using protocol 2 either. Are you *completely* sure of what you are talking about? -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Recommended firewall package? insubscribe
- Original Message - From: "Marcus Williams" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Tuesday, November 02, 2004 1:05 PM Subject: Re: Recommended firewall package? > > > On 01/11/2004, Daniel Pittman wrote: > > My recommendation is the 'firehol' package, found in testing/unstable, > > and trivial to backport[1] to stable. > > I'd second this - firehol is fantastic. Someone recommended it a while > ago in a lug mail list I was on and I thought I'd give it a once over. > Never gone back to the iptables mess I had (it still generates an > iptables script but I dont have to look at/maintain it, which can only > be good thing IMNSHO). > > Marcus > > -- > Marcus Williams -- http://www.quintic.co.uk > Quintic Ltd, 39 Newnham Road, Cambridge, UK > This message is private [ ] public [*] > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] > > -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Recommended firewall package?
On 01/11/2004, Daniel Pittman wrote: > My recommendation is the 'firehol' package, found in testing/unstable, > and trivial to backport[1] to stable. I'd second this - firehol is fantastic. Someone recommended it a while ago in a lug mail list I was on and I thought I'd give it a once over. Never gone back to the iptables mess I had (it still generates an iptables script but I dont have to look at/maintain it, which can only be good thing IMNSHO). Marcus -- Marcus Williams -- http://www.quintic.co.uk Quintic Ltd, 39 Newnham Road, Cambridge, UK This message is private [ ] public [*] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ssh chroot on debian documentation
Can people please be more careful when creating new messages, not to hit reply to a message then removing everything & starting again. This does play up with clients that follow standards and do threading through headers passed on by other compliant clients, rather than just threading as-per subjects. Thanks. Vincent Tantardini wrote: Hello, I juste write a little documentation about how I create a chrooted environment for ssh, you can find the doc at: http://vince.kerneled.org/files/ssh_chroot.txt Please, give me some comments about the method I adopt here. Regards, -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ssh chroot on debian documentation
-Original Message- From: Vincent Tantardini <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Date: Tue, 2 Nov 2004 08:03:43 +0100 Subject: ssh chroot on debian documentation > Hello, > I juste write a little documentation about how I create a chrooted > environment > for ssh, you can find the doc at: > http://vince.kerneled.org/files/ssh_chroot.txt > > Please, give me some comments about the method I adopt here. > > Regards, Is ssh chrooted useful? The only useful thing I can realize: require an ssh login into a machine with 2 nics and open another ssh session. In this way I have to exploit 2 sshd instead of one to get into... Mah. Am I missing something? Bye. Radel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: doing an ssh into a compromised host
> Nope. It is true. Copy the appropriate /tmp/ssh* directory, chown > it, set SSH_AUTH_SOCKET appropriately, and ssh away. hmm, but in /tmp/ssh* there's just a socket... so when agent is gone, what good is that file? -- Dariush Pietrzak, Key fingerprint = 40D0 9FFB 9939 7320 8294 05E0 BCC7 02C4 75CC 50D9 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: doing an ssh into a compromised host
also sprach Dariush Pietrzak <[EMAIL PROTECTED]> [2004.11.02.0947 +0100]: > > If you forward your agent (-A, or ForwardAgent yes), then the > > attacker now probably has access to all machines where the SSH key > > you used has access. > Is this indeed true? I was under an impression that ForwardAgent works more > in challenge-response fashion? Nope. It is true. Copy the appropriate /tmp/ssh* directory, chown it, set SSH_AUTH_SOCKET appropriately, and ssh away. -- Please do not send copies of list mail to me; I read the list! .''`. martin f. krafft <[EMAIL PROTECTED]> : :' :proud Debian developer, admin, user, and author `. `'` `- Debian - when you have better things to do than fixing a system Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver! signature.asc Description: Digital signature
Re: doing an ssh into a compromised host
> Meanwhile, the only thing I have is looking at some offline backups and > working remotely in the (compromised) environment. Right now I'm looking at > the lsof output there, a curious entry from Apache shown by lsof: > > apache 3170 root memDEL0,5 0 /SYSV000 > > Does it ring the bell for anyone? (The box runs apache 1.3.26-0woody5). belay that. This looks like the apache scoreboard. A sane apache2 machine has similar entries as well: apache2 1318 apache mem DEL 0,6 0 /SYSV0c0deb00 apache2 1926 apache mem DEL 0,6 0 /SYSV0c0deb00 apache2 2432 apache mem DEL 0,6 0 /SYSV0c0deb00 apache2 2502 apache mem DEL 0,6 0 /SYSV0c0deb00 apache2 8538 root mem DEL 0,6 0 /SYSV0c0deb00 apache2 8798 apache mem DEL 0,6 0 /SYSV0c0deb00 apache2 27796 apache mem DEL 0,6 0 /SYSV0c0deb00 apache2 27797 apache mem DEL 0,6 0 /SYSV0c0deb00 apache2 28306 apache mem DEL 0,6 0 /SYSV0c0deb00 G I'll try to nessus the machine remotely, and see if something boils up from it...
Re: doing an ssh into a compromised host
> If you forward your agent (-A, or ForwardAgent yes), then the > attacker now probably has access to all machines where the SSH key > you used has access. Is this indeed true? I was under an impression that ForwardAgent works more in challenge-response fashion? And as far as X-forwarding goes - AFAIK if you're setup is like you describe, then your ssh does not request X-forwarding, thus, there's no way for remote server to force this upon you. -- Dariush Pietrzak, Key fingerprint = 40D0 9FFB 9939 7320 8294 05E0 BCC7 02C4 75CC 50D9 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: doing an ssh into a compromised host
> You could force the SSH client to *not* forward X11 with -x > (the low-caps x char) regardless other client/server-side > specifications. If you do not specify any other special > forwarding (-L or -R) then there will be no forwarding. Good, that was what I was hoping for. (Obviously, my default /etc/ssh/ssh_config doesn't turn on the fwding by default.) Luckily, I am also not using any agent fwding as well. The box is remote, and I'll only have console access in a couple of days. Meanwhile, the only thing I have is looking at some offline backups and working remotely in the (compromised) environment. Right now I'm looking at the lsof output there, a curious entry from Apache shown by lsof: apache 3170 root memDEL0,5 0 /SYSV000 Does it ring the bell for anyone? (The box runs apache 1.3.26-0woody5). chkrootkit (inside the compromised environment, so it is no big surprise) doesn't report anything. V. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: doing an ssh into a compromised host
Greetings! On Tue, 2 Nov 2004 08:59:07 +0200 (IST) Vassilii Khachaturov <[EMAIL PROTECTED]> wrote: > I have been doing ssh into the box. THe client is set up not to > request the X forwarding by the default. When I try "ssh -v" now, I > observe no X forwarding being established, whereas "ssh -X -v" does > establish X. Question is, could the server have forced an X forwarding > on me (w/o my knowledge) having sniffed my local keystrokes? You could force the SSH client to *not* forward X11 with -x (the low-caps x char) regardless other client/server-side specifications. If you do not specify any other special forwarding (-L or -R) then there will be no forwarding. HTH Volker Tanger ITK Security -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: doing an ssh into a compromised host
also sprach Vassilii Khachaturov <[EMAIL PROTECTED]> [2004.11.02.0759 +0100]: > I have been doing ssh into the box. THe client is set up not to > request the X forwarding by the default. When I try "ssh -v" now, > I observe no X forwarding being established, whereas "ssh -X -v" > does establish X. Question is, could the server have forced an > X forwarding on me (w/o my knowledge) having sniffed my local > keystrokes? FWIW, I have been doing "ssh-add" and then ssh w/o > a need to enter any password during the authentication with the > compromised remote host. If you forward your agent (-A, or ForwardAgent yes), then the attacker now probably has access to all machines where the SSH key you used has access. I am unaware of a way to hijack X Forwarding in the way you describe. -- Please do not CC me when replying to lists; I read them! .''`. martin f. krafft <[EMAIL PROTECTED]> : :' :proud Debian developer, admin, and user `. `'` `- Debian - when you have better things to do than fixing a system Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver! signature.asc Description: Digital signature
