the latest suse security announcement for the dhcp packages doesnt list
any pending problems with the kernel packages.
i was wondering if i have missed anything about ths discussion regarding
the freezes and hangs many people experienced when this kernel updates
was released for the floating point exception problem.
how did people work around the freeze when booting this new kernel, or
does suse have any plans on fixing/rereleasing another kernel that fixes
thanks already for any hints.
On Friday 02 July 2004 21:05, you wrote:
> > So let's examine scenario two, with non-reallife IP numbers.
> > Here you have 184.108.40.206 on eth1, 192.168.0.x/24 on eth0 and you choose
> > another net for the DMZ which MUST NOT be the same as on eth0 !
> > So, let's take 192.168.99.0/24 in this example. So eth2 becomes
> > 192.168.99.1
> > >From there on it's simple; you make a series of rules like you had,
> > FW_FORWARD_MASQ="0/0,192.168.99.4,tcp,80" if you have a webserver in the
> > DMZ with IP 192.168.99.4. Add other statements for other ports and/or
> > other servers to that same line, between those quotes, separated with
> > space. You mustn't forget to set the right gateway on your DMZ boxes;
> > they must have the IP you set to eth2 as their default gateway:
> > 192.168.99.1.
> > You may also have to make special arrangements so that internal hosts can
> > connect to the DMZ IIRC, but I don't remember offhand. Just try it.
> > Good luck,
> > Maarten
> I tried this because it looked like what was needed a coulple of days
> ago. it didn't seem to work but maybe I had something set up wrong. if
> this indeed is the setup, it narrows the field of possible remaining
> is the eth on the firewall to the DMZ set as FW_DEV_DMZ or because it's
> technically another masq'd net is it FW_DEV_INT ??
No no, its definitely FW_DEV_DMZ.
Be careful how you test it; you will probably NOT be able to test the
connection from within, so you'll have to have access to another internet
connection to test from (or a remote host). Also, if you know halfway how to
interpret it, a sniffer can be an invalueable help if things do not work from
the start. Even if you can't interpret it, just seeing where the packet gets
sent to (or not) can be enlighting. Tcpdump or Snort are your friends.
You can start multiple sessions, each attached to the different eth's.
Not very relevant now, but:
The caveat I forgot to mention in comparing the first with the second scenario
is that when masquerading as you will do now, you can only have 1 machine in
your DMZ for each service, i.e. one webserver, one mailserver, etc, maximum.
This stems from the fact that you cannot masquerade one port to two systems,
whereas in the real-life IP numbers scenario you don't masquerade, just
route. And that of course works just fine with multiple IP's.
Another thing, if it wasn't already obvious, is that for the outside world,
your server(s) appear to have the IP number your firewall has: the ISP
address. But seen from the inside LAN this isn't so. From there, you just do
plain routing, so you address the DMZ servers by their actual IP.
This is only valid in scenario two, the masquerading one. Otherwise everything
is just addressed by their actual IP number (220.127.116.11 etc.)
Confusing ? Nah. ;-)
One last advice: Keep it simple, and take small steps. For example, never
test it with a browser / webpage. Test it with ping or ssh first and go on
to other, more complex, services from there. Also, never ever use DNS names
(unless it's really setup well, and triple-checked), instead always connect
to the IP numbers. Don't know it this was too obvious but one never knows...
> Thanks!! I'll give it another try.
Yes of course I'm sure it's the red cable. I guarante[^%!/+)F#0c|'NO CARRIER
OK, id did a complete new installation (same box)
with the same disk-configuration:
/dev/hda2 + /dev/hdb2 als raid1: /dev/md0 = / #root (ext3)
/dev/hda1 = /boot
from original CD SuSe 91prof.
minimal System installed.
all works fine until i upgrade the kernel 2.6.4 to 2.6.5 from
the ftp.suse.com with YOU.
The boot aborts with:
waiting for device /dev/900 to appear ...(short delay ) .... not found....
RAIDs never saved me from a "dilemma",
for me, the always created one !
>I've noticed a peculiarity the last couple of times I tried to update the
>kernel of my two SuSE 9.0 Pro machines via Yast.
>I also got a message warning me to run /sbin/SuSEffective (which as
>far as I can tell isn't installed on either of my SuSE computers.)
I actually thought that part of the message was missing (because of
the formatting). I never bothered to figure out what I had to run,
and have not suffered any (direct) problems.
I recently purchased SuSE Linux Pro 9.1.
As usual I copied the DVD to my NFS server so that I can do local minimal
installs using CD1 and then once up and running machines can have extra
packages installed via NFS as required.
However, I find that the DVD bundled with 9.1 is RC1 whereas the CDs are
This means loads of conflicts if one tries to install anything from the DVD
(or network copy thereof) on a machine that was originally installed via
CDROM (and vice versa)!
The only fix I can see is to copy each CD to my NFS server and throw the DVD
in the bin!
I've noticed a peculiarity the last couple of times I tried to update the
kernel of my two SuSE 9.0 Pro machines via Yast.
Yast indicated that a kernel update was available, and downloaded it; but
also advised me I needed to reboot after the update because the kernel might
need to probe for hardware. Not necessarily a problem, but it worried me a
bit, because I've never gotten this message on any of my previous kernel
updates through YaST. I also got a message warning me to run
/sbin/SuSEffective (which as far as I can tell isn't installed on either of
my SuSE computers.)
I would be less worried about all this except for the problems people have
been reporting on this listserv with recent kernel updates. Did anyone else
see these messages? If so, did you run into problems after running the
Running SuSE 9.0 Pro.
O.K. I'm about to give up. I've been messing with the setup for
SuSEfirewall2 which is apparently a niced up front end to IPTABLES. I'm
trying to get a DMZ up so when I have to fix something on our renderfarm
at 3 AM I can do it from home through ssh. currently the firewall works
with 2 NICs dividing my local net from the big bad ugly WWW. it is
functioning properly and dropping everything that it should. now on to
the DMZ. I've read a ton of stuff on how to set up internal DMZ's
through FW_FORWARD_MASQ="0/0,10.0.1.2,tcp,80" which looks like it
Masquerades and uses an inside IP on a third NIC that's not a "real
world" IP. I can't get that working in any way. Then there's the
preferred method of having a second, ISP issued "real world" IP, on the
DMZ and It again resides on the third NIC but there is no masquerading
and it looks like and it uses FW_FORWARD="127.0.0.1,127.0.0.2,tcp,1".
The forelisted FW lines are straight out of the EXAMPLE included with
SuSE so they really don't apply to my network directly. let me sum up
what I have and maybe somebody can point me in the right direction.
the external has my first ISP assigned IP. the internal is the generic
192.168.2.0 network. what I'm not sure of is what IP needs to be on
eth2 real or masq'd and any custom routing. I've tried everything I can
think of. including a same and different internal IP, another of my real
world IP's you name it. routes?? and maybe howto??
eth0 tried internal IP, real world IP......all in pairs because AFAIK if
the subnet isn't the same and the networks are different they wont ping.
the only life out there I get is when I use and internal IP like
192.168.0.1 on eth2 for the firewall and 192.168.0.2 on the DMZ. then I
can ping from firewall to DMZ and vice versa. but when I go from there
to try and use the FW_FORWARD_MASQ, I still can't get in from home on
the outside. the only reason I'm pursuing the masq setup is I can't get
anything else to ping. I'd prefer to do it the other way but it's not
getting anywhere. so here's the snip from the masq field:
# Which services accessed from the internet should be allowed to
# servers (on the internal network or dmz)?
# REQUIRES: FW_ROUTE
# With this option you may allow access to e.g. your mailserver. The
# machines must be in a masqueraded segment and may not have public IP
# Hint: if FW_DEV_MASQ is set to the external interface you have to set
# FW_FORWARD from internal to DMZ for the service as well to allow
# from internal!
# Please note that this should *not* be used for security reasons! You
# opening a hole to your precious internal network. If e.g. the
# is compromised - your full internal network is compromised!!
# Choice: leave empty (good choice!) or use the following explained
# of forward masquerade rules, seperated each by a space.
# A forward masquerade rule consists of 1) source IP/net, 2) destination
# (dmz/intern), 3) a protocol (tcp/udp only!) and 4) destination port,
# seperated by a comma (","), e.g. "18.104.22.168/8,22.214.171.124,tcp,80"
# Optional is a port after the destination port, to redirect the request
# a different destination port on the destination IP, e.g.
FW_FORWARD_MASQ="0/0,10.0.1.2,tcp,80" # Beware to use this!
Any help would be appreciated. I'm feeling beat up by what should be so
Just like the first release of tripwire for SuSE 9.0, the recent security
update, 2.3.1-184 segfaults.
[ root@shadow ] ~# rpm -q tripwire
[ root@shadow ] ~# tripwire --check
Parsing policy file: /etc/tripwire/tw.pol
*** Processing Unix File System ***
Performing integrity check...
Software interrupt forced exit: Segmentation Fault
I get the same results on two separate machines, one 2x/P2-333 and one P4-1.7.
Both systems had been using the previous version of tripwire without any
problems, and both are running 9.0. (I haven't purchased 9.1 due to issues I
have with th 2.6 kernel that are outside SuSE's control) I am not going to
update any of my production servers with this borked version of tripwire, so
those are the only two systems tested.
I have just seen this strange entrys in my apache logs:
126.96.36.199 - - [29/Jun/2004:03:45:42 +0200] "CONNECT 188.8.131.52:25 HTTP/1.0" 200 8307
184.108.40.206 - - [29/Jun/2004:03:45:55 +0200] "PUT http://220.127.116.11:25/ HTTP/1.0" 200 8307
18.104.22.168 - - [29/Jun/2004:03:45:56 +0200] "POST http://22.214.171.124:25/ HTTP/1.0" 200 8307
126.96.36.199 - - [29/Jun/2004:19:10:27 +0200] "CONNECT 188.8.131.52:1337 HTTP/1.0" 200 8307
184.108.40.206 - - [30/Jun/2004:21:05:44 +0200] "POST http://220.127.116.11:25/ HTTP/1.0" 200 8307
18.104.22.168 - - [30/Jun/2004:21:56:04 +0200] "PUT http://22.214.171.124:25/ HTTP/1.0" 200 8307
They were all succesfull!!!!
My snort logs did not detect anything strange, wich seems logical, since they are just smtp accesses.
Is anyone using my web server to send spam?