Hello
I have a 8.1 server standing outside my firewall, protected using YAST with
SuSEfirewall. I can reach the server using http and ssh - no problem.
But I would like to get xntpd to update the time - Is it then nessesary to
adjust the firewall configuration?
mejse:~ # ntpdate some.server.dk
3 Mar 21:27:38 ntpdate[2623]: no server suitable for synchronization found
I tried to use yast to adjust the firewall by putting "123" or "ntp" into the
Expert configuration option. Also tried
FW_ALLOW_INCOMING_HIGHPORTS_UDP="ntp"
still no luck :-(
--
Regards
Klaus Vink Slott
Hi John,
first of all thx for your reply. Well, there's nothing wrong with my rules.
Except your remarks on stateful inspection.
I do need the seperate NAT rule for outbound traffic otherwise it would be
natted to eth0 which then would cause errors on senders firewall (packets
are sent to "eth1" (DMZ) address but response will come through "eth0" (FW)
address).
As expected that's all a "nice hidden security feature" of IIS ;-) No, just
kidding.
IIS is set up to look for "index.asp" pages if a directory is requested,
e.g. "http://our.host:50003/directory". It works for requests on port 80 but
not for requests on any other port. Having a detailed look at the packets I
saw that suddenly requests are "mangled" to port 80. And these requests are
not allowed. So if we put "http://our.host:50003/directory/index.asp" it
works as expected. Don't ask me why, I don't mind. I search
support.microsoft.com but found nothing mentioned concerning this treatment.
I know why I like Apache so much, but that's off topic :-)
Have fun,
Oliver
> -----Ursprüngliche Nachricht-----
> Von: John Trickey [mailto:lists@g4rev.supanet.com]
> Gesendet: Dienstag, 4. März 2003 12:59
> An: suse-security(a)suse.com
> Betreff: Re: [suse-security] Port forwarding problem
>
>
> Hi Oliver,
>
> > I have a firewall problem I have resigned on. I hope
> there's someone
> > out there who can help me and explain what's wrong.
>
> I do not see much wrong with this.
>
> > iptables -A PREROUTING -t nat -p tcp -s 0.0.0.0/0 -d IP_DMZHOST
> > --dport PORTFW -j DNAT --to-destination IP_LAN:80
>
> I have used almost identical rules. I do not bother with -s
> "any" as its
> assumed if omitted and I use --to just because its shorter
> :-). So functionally, there is no difference.
>
> There are 2 areas that may be causing you grief.
>
> 1) Have you set up the forward table? You will need
> iptables -A FORWARD -i eth0 -o eth2 -p tcp -d IP_LAN
> --dport 80 -j ACCEPT and also its inverse.
>
> Personally I prefer connection tracking so you can do
> iptables -A FORWARD -i eth0 -o eth2 -p tcp -d IP_LAN --dport 80 \
> -m state --state NEW -j ACCEPT
> with a global
> iptables -A FORWARD -i eth2 -o eth0 -m state --state
> ESTABLISHED -j ACCEPT for the return.
>
> 2) Have you prevented the return packets from being
> masqueraded? If not they
> will be leaving your firewall with a source IP of IP_eth0.
> You need something
> like:
> iptables -t nat -A POSTROUTING -o eth0 -s IP_DMZ -j ACCEPT
> iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
>
> > "firewalled" or "proxied" connections. Therefore I put the
> following
> > rule in place which should SNAT the specific traffic coming
> from IIS.
> >
> > iptables -I POSTROUTING -t nat -s IP_LAN -d !
> 10.0.0.0/8 -j SNAT
> > --to-source IP_DMZHOST
> >
> > I need "-d ! 10.0.0.0/8" option because of our IPSec VPN. But after
> > applying this rule nothing works.
>
> I'm not surprised. By adding this rule you would be creating
> a separate NAT
> entry for the outbound traffic.
>
> > In my opinion there must be a general "design" mistake I have made.
> > But I don't know which
>
> I think its only an omission. If you're still stuck, come
> back to me on the
> list. Don't use direct mail as this address is a spam trap
> which throws non
> list mail straight into /dev/null.
>
> John
>
> --
> Check the headers for your unsubscription address
> For additional commands, e-mail: suse-security-help(a)suse.com
> Security-related bug reports go to security(a)suse.de, not here
>
"A patched sendmail server will drop invalid headers, thus preventing downstream servers from receiving them."
A non-sendmail relay will not be affected by the problem but will pass on messages containing the headers and that may affect downstream sendmail servers.
-----Original Message-----
From: Ulrich Roth [mailto:Roth@impact.de]
Sent: Tue 3/4/2003 2:25 PM
To: suse-security(a)suse.com
Cc:
Subject: AW: [suse-security] SuSE Security Announcement: sendmail (SuSE-SA:2003:013)
Hi Martin,
> > SuSE Security Announcement
> >
> > Package: sendmail, sendmail-tls
> > Announcement-ID: SuSE-SA:2003:013
>
> Does the bugfix "repair" affected messages, so that servers behind a
> patched sendmail are protected? Or are the "bad" headers passed on
> to the next MTA unmodified?
Yes, the bad headers are passed on.
Quote from the announcement:
The vulnerability is triggered by an email message sent through the
sendmail MTA subsystem. In that respect, it is different from commonly
known bugs that occur in the context of an open TCP connection. By
consequence, the vulnerability also exists if email messages get forwarded
over a relay that itself does not run a vulnerable MTA. This specific
detail and the wide distribution of sendmail in the internet causes this
vulnerability to be considered an error of major severity.
Bye
Uli
--
Ulrich Roth
IMPACT Business & Technology Consulting GmbH
Im Mediapark 8 / KölnTurm
D-50670 Koeln
Phone +49-221-93 70 80-29
Fax +49-221-93 70 80-15
E-Mail: roth(a)impact.de
--
Check the headers for your unsubscription address
For additional commands, e-mail: suse-security-help(a)suse.com
Security-related bug reports go to security(a)suse.de, not here
Hi Martin,
> > SuSE Security Announcement
> >
> > Package: sendmail, sendmail-tls
> > Announcement-ID: SuSE-SA:2003:013
>
> Does the bugfix "repair" affected messages, so that servers behind a
> patched sendmail are protected? Or are the "bad" headers passed on
> to the next MTA unmodified?
Yes, the bad headers are passed on.
Quote from the announcement:
The vulnerability is triggered by an email message sent through the
sendmail MTA subsystem. In that respect, it is different from commonly
known bugs that occur in the context of an open TCP connection. By
consequence, the vulnerability also exists if email messages get forwarded
over a relay that itself does not run a vulnerable MTA. This specific
detail and the wide distribution of sendmail in the internet causes this
vulnerability to be considered an error of major severity.
Bye
Uli
--
Ulrich Roth
IMPACT Business & Technology Consulting GmbH
Im Mediapark 8 / KölnTurm
D-50670 Koeln
Phone +49-221-93 70 80-29
Fax +49-221-93 70 80-15
E-Mail: roth(a)impact.de
Hi list members,
I have a firewall problem I have resigned on. I hope there's someone out
there who can help me and explain what's wrong.
First of all our network looks like this
Internet
|
|
Firewall (eth0) NAT for LAN
|
|-- DMZ (eth1)
| |
| |-- HostInDMZ (IP_DMZHOST)
|
|-- LAN (eth2)
|
|-- HostInLAN (IP_LAN)
Firewall is SuSE 7.3, kernel 2.4.16, iptables 1.2.2.60.
HostInLAN is W2K Server, II5.
What I try to do is to port forward all requests on host IP_DMZHOST port
PORTFW to host IP_LAN port 80, meaning forward all request on a special port
to internal IIS. Pretty simple and done a thousand times I guess.
I already do the same for forwarding request on another port to ssh on
another host.
But when setting up port forwarding like given below with PORTFW anything
else than 80 nothing works. All other necessary rules are in place too, e.g.
allow any access from any host/port to IP_DMZHOST:PORTFW etc.
iptables -A PREROUTING -t nat -p tcp -s 0.0.0.0/0 -d IP_DMZHOST
--dport PORTFW -j DNAT --to-destination IP_LAN:80
Any special feature of IIS? I don't see any reason why port forwarding from
port!=80 is different to port=80.
Of course this works for pure Internet connections only, like CallByCall
provides. Due to general NAT of all LAN traffic this doesn't work for
"firewalled" or "proxied" connections. Therefore I put the following rule in
place which should SNAT the specific traffic coming from IIS.
iptables -I POSTROUTING -t nat -s IP_LAN -d ! 10.0.0.0/8 -j SNAT
--to-source IP_DMZHOST
I need "-d ! 10.0.0.0/8" option because of our IPSec VPN. But after applying
this rule nothing works.
In my opinion there must be a general "design" mistake I have made. But I
don't know which
Thx,
Oliver
hey guys
was wondering if anyone could benchmark or if there is a benchmark for SuSE on Sparc/Intel arch's, i have a project i am working on and i got a couple of Sun boxes at my disposal, the first box i choose was this:
http://www.sun.com/servers/entry/lx50/
the kind of load it will have on is basically Mail, and maybe some WWW stuff like webmail. I will have things like Postfix or Exim,Mysql, Apache and some open source stuff from sun e.g iplane ..on this box , i have to explain why i would go for Intel and not sparc i have looked through a couple of benchmarks and Solaris OS is used more as a benchmark on Sparc arch which is kind of biased to me, cause i dont get the results i want has anyone here tested SuSE on both arch's and got good results if so what Apps...where used for the benchmark, and do you guys think the server above can handle about 500-->2000 users who will be popping from this very server. All help is highly appreciated and any suggestions are also welcome.
cheers
---------------------------------
Do you Yahoo!?
Yahoo! Tax Center - forms, calculators, tips, and more
sendmail.org announced availability of sendmail 8.12.8...
Sendmail, Inc., and the Sendmail Consortium announce the availability of
sendmail 8.12.8. It contains a fix for a critical security problem discovered
by Mark Dowd of ISS X-Force; we thank ISS X-Force for bringing this problem
to our attention. Sendmail urges all users to either upgrade to sendmail
8.12.8 or apply a patch for 8.12. Patches for older versions are available.
See http://www.sendmail.org/8.12.8.html
Up to SuSE 8.0 sendmail was the standard MTA and people upgrading to 8.1 may
don't have changed to Postfix.
Are the pached or new packages on their way?
--
Eat, sleep and go running,
David Huecking.
Encrypted eMail welcome!
GnuPG/ PGP-Key: 0x57809216. Fingerprint:
3DF2 CBE0 DFAA 4164 02C2 4E2A E005 8DF7 5780 9216
Hi @ all,
just want to here some of your opinions. Today I found
an entry ein etc/passwd looking like this.
<snip>
+::::::
<snap>
does someone know what this means? Google doesn't enlight me :\
Thanks Daniel
--
"Those who desire to give up Freedom in order to gain Security,
will not have, nor do they deserve, either one."
--Thomas Jefferson
Hello,
I tried to connect a Windows 2000 Client Notebook to my Cipe Gateway.
(SuSE 8.0)
I have downloaded the software packages for windows 2000 and installed it as
described.
But it won´t work.
My Linux Notebook with the same entries in /etc/cipe/options works fine.
Is there somebody with experience concerning cipe and windows 2000 (as
client)?
Mit freundlichen Grüßen
Stefan Junge
Hi!
I use a Linux SuSE 7.2 as a routeur/firewall connected to internet and an internal network behind it. I would like to forward requests to an internal and masqueraded server (ie.Use a second Web server inside my network using http://my.web.adresse:8080/).
I tried FW_FORWARD_MASQ, but it doesn't work (exactly as if I FW_FORWARD_MASQ=""). logs and tcpdump don't see any redirection at all.
Here is my firewall2.rc.config. PS : There nothing special in firewall2-custom.rc.config
Can you help me ?
Thanks,
Byers
-----------------------------------------------
FW_DEV_EXT="ppp0"
FW_DEV_INT="eth1"
FW_DEV_DMZ=""
FW_ROUTE="yes"
FW_MASQUERADE="yes"
FW_MASQ_DEV="ppp0"
FW_MASQ_NETS="192.168.1.0/24"
FW_PROTECT_FROM_INTERNAL="yes"
FW_AUTOPROTECT_SERVICES="yes"
FW_SERVICES_EXT_TCP="80"
FW_SERVICES_EXT_UDP=""
FW_SERVICES_EXT_IP=""
FW_SERVICES_DMZ_TCP=""
FW_SERVICES_DMZ_UDP=""
FW_SERVICES_DMZ_IP=""
FW_SERVICES_INT_TCP="80"
FW_SERVICES_INT_UDP=""
FW_SERVICES_INT_IP=""
FW_TRUSTED_NETS=""
FW_ALLOW_INCOMING_HIGHPORTS_TCP="no"
FW_ALLOW_INCOMING_HIGHPORTS_UDP="DNS"
FW_SERVICE_AUTODETECT="yes"
FW_SERVICE_DNS="yes"
FW_SERVICE_DHCLIENT="no"
FW_SERVICE_DHCPD="no"
FW_SERVICE_SQUID="no"
FW_SERVICE_SAMBA="yes"
FW_FORWARD=""
###################################################
FW_FORWARD_MASQ="0.0.0.0/0,192.168.1.2,tcp,8080,80"
###################################################
FW_REDIRECT=""
FW_LOG_DROP_CRIT="yes"
FW_LOG_DROP_ALL="yes"
FW_LOG_ACCEPT_CRIT="yes"
FW_LOG_ACCEPT_ALL="no"
FW_LOG="--log-level warning --log-tcp-options --log-ip-option --log-prefix SuSE-FW"
FW_KERNEL_SECURITY="yes"
FW_STOP_KEEP_ROUTING_STATE="no"
FW_ALLOW_PING_FW="yes"
FW_ALLOW_PING_DMZ="no"
FW_ALLOW_PING_EXT="yes"
FW_ALLOW_FW_TRACEROUTE="yes"
FW_ALLOW_FW_SOURCEQUENCH="yes"
FW_ALLOW_FW_BROADCAST="no"
FW_IGNORE_FW_BROADCAST="yes"
FW_ALLOW_CLASS_ROUTING="no"
FW_CUSTOMRULES="/etc/rc.config.d/firewall2-custom.rc.config"