> I dont know if this script is secure
>
> Can someone check this script and say me something about it??

In order to evaluate it, one has to know more about it. The purpose is
most important in the first place.

> is this an secure solution???

It depends on what you want to achieve with it. Solutions are always bound
to the problem or task. Everything is a solution if there's no problem.

>
> if not please send my messages why not

I'll just add a few comments.

>
>
> #!/bin/sh
> ipchains -F
> ipchains -P input ACCEPT
> ipchains -P forward ACCEPT
> ipchains -P output ACCEPT

This is a bit messy. During the time when the following rules get poked
into the kernel, there are some time windows where packets can get
through. Better _first_ change the default policy to DENY, then flush all
rules, and _after_ adding the last rule, change the default policy to the
intended value.
If you keep your default policy like this, a non-matching ruleset would
probably make packets slip through. You should consider changing this to
DENY to only let traffic through that you are sure it should.
Anyway, I like the approach to have an all-matching rule in the end that
logs what came through the ruleset. :-)

> #internes lan angeben (eigenes lan)
> intlan=10.10.10.0/24
> intip=10.10.10.254
> #externe ip angeben (chello)
> extip=212.186.XXX.XXX
>
> #masqrechner angeben
> rechner1=10.10.10.26
> rechner2=10.10.10.25
> rechner3=10.10.10.27
>
> #aussenstellen angeben
> aussen1=212.17.xxx.xxx #firma
> aussen2=212.186.xxx.xxx #helmut
>
> ######## Totales Verbot für chello proxies wegen des Masq ################
> # man könnte ja was merken +hehe+ durch surfanalysen frechheit aber auch ###
> ipchains -A input -b -i eth1 -s $extip -d 195.34.133.60 -j DENY
> ipchains -A input -b -i eth1 -s $extip -d 195.34.133.61 -j DENY
> ipchains -A input -b -i eth1 -s $extip -d 195.34.133.62 -j DENY
> ipchains -A input -b -i eth1 -s $extip -d 195.34.133.63 -j DENY
> ipchains -A input -b -i eth1 -s $extip -d 195.34.133.64 -j DENY
> ipchains -A input -b -i eth1 -s $extip -d 195.34.133.65 -j DENY
> ipchains -A input -b -i eth1 -s $extip -d 195.34.133.66 -j DENY
> ############################################################################

In English: prohibit access to the proxies so that they can't see that we
masquerade/NAT. :-) They would have enough hints for the use of
masquerading mechanisms because of the port range that is being used. :-)

> ######################### #loopback ########################################
> ipchains -A input -b -i lo -s $extip -d 127.0.0.0/24 -j ACCEPT
> #loopback
> ipchains -A input -b -i lo -s $intip -d 127.0.0.0/24 -j ACCEPT
> #loopback
> ipchains -A input -i lo -s $intip -d $intip -j ACCEPT
> #loopback loopback
> ipchains -A input -i lo -s $extip -d $extip -j ACCEPT
> #loopback loopback
> ipchains -A input -i lo -s 127.0.0.0/24 -d 127.0.0.0/24 -j ACCEPT
> #loopback loopback

Packets matching these rules shouldn't actually reach the machine in the
first place because of the routing. Good idea, though, for the cases
where you have a nameserver sitting bound on lo but nothing else and a
n insecure router just in front of your nose. Rule 3 and 4 don't make
sense since iface lo wouldn't be used because of our local routing table.

Please note that the netmask of the loopback interface address is /8, not
/24.
          inet addr:127.0.0.1 Mask:255.0.0.0

> ############################################################################
>
>
> ipmasqadm portfw -a -P tcp -R $extip 3333 -L 10.10.10.26 3333
> ipmasqadm portfw -a -P udp -R $rechner2 5900 -L $extip 5900
> ipmasqadm portfw -a -P tcp -R $rechner2 5900 -L $extip 5900
>
> ######################### TEST #############################################
> ######################### TESTENDE #########################################
>
> ######### battlecom für gamers #############################################
> ipmasqadm autofw -A -r udp 2300 2400 -h $rechner1
> ipmasqadm autofw -A -r tcp 2300 2400 -h $rechner1
> ipmasqadm autofw -A -r tcp 47624 47634 -h $rechner1
> ipmasqadm autofw -A -r udp 47624 47634 -h $rechner1
> ipmasqadm autofw -A -r udp 28800 28900 -h $rechner1

I guess you know what these ports are good for and that you can estimate
the risk. :-)

>
> ######### generell #########################################################
> ipchains -A input -b -i eth1 -p tcp -s $extip 1024:65532 -d
> 0.0.0.0/0 -j ACCEPT
> ipchains -A input -b -i eth1 -p udp -s $extip 1024:65532 -d
> 0.0.0.0/0 -j ACCEPT

These two don't make sense: 1) (2^16)-1 = 65535, not 65532.

2) Then, you restrict traffic (no matter of connection state) so that the
remote box can't use the port range starting at 0-1023. Why this? It's up
to the remote side to decide about the ports they use.

> ipchains -A input -b -i eth1 -p tcp -s $extip 113 -d 0.0.0.0/0 -j
> ACCEPT
>

I'd discourage the use of the -b option if it's not the forward chain, for
the following reasons. These are actually two rules:

ipchains -A input -i eth1 -p tcp -s $extip 113 -d 0/0 -j ACCEPT
This doesn't make sense: A packet to the world and from your external
interface doesn't hit your input chain.

ipchains -A input -i eth1 -p tcp -d $extip 113 -s 0/0 -j ACCEPT
This one accepts packets to your ident service. You might want to think
this over - the ident service is useless if you don't trust the server you
ask with it. In this particular case, I'd even REJECT the packets since
blackholing them with a DENY rule might cause delays when you connect to
the outside.
You can't hide that you run a linux box anyway...

> ######### interne berechtigungen ###########################################
> ipchains -A input -b -i eth1 -s $extip -d $aussen1 -j ACCEPT
> ipchains -A input -b -i eth1 -s $extip -d $aussen2 -j ACCEPT
> ipchains -A input -b -i eth0 -s $extip -d $intip -j ACCEPT
>
>
> ######### SSH ##############################################################
> ipchains -A input -b -i eth1 -p tcp -s $extip 22 -d $aussen2 -j
> ACCEPT
> ######### FTP ##############################################################
> # ipchains -A input -b -i eth1 -p tcp -s $extip 21 -d 0.0.0.0/0 -j
> ACCEPT
>
> ######### HTTP #############################################################
> ipchains -A input -b -i eth1 -p tcp -s $extip 80 -d 0.0.0.0/0 -j
> ACCEPT
> ipchains -A input -b -i eth1 -p tcp -s $extip -d 0.0.0.0/0 80 -j
> ACCEPT
> ######### DNS ##############################################################
> ipchains -A input -b -i eth1 -p 17 -s $extip -d 0.0.0.0/0 53 -j
> ACCEPT
> ipchains -A input -b -i eth0 -p 17 -s $intlan -d 0.0.0.0/0 53 -j
> ACCEPT
> ######### SENDMAIL #########################################################
> ipchains -A input -b -i eth1 -p tcp -s $extip -d 0.0.0.0/0 25 -j
> ACCEPT
> ipchains -A input -b -i eth1 -p tcp -s $extip 25 -d 0.0.0.0/0 -j
> ACCEPT
> ######### 10erlan ##########################################################
> ipchains -A input -b -i eth0 -s $intlan -d $intip -j ACCEPT
> ipchains -A input -b -i eth0 -s $intlan -d 0.0.0.0/0 -j ACCEPT

Same thing with the -b option all over the place. In the forward chain it
makes sense, if you use the ACCEPT, DENY or REJECT targets.
Think these rules over again after fiddling them into seperate rules.

> ######### masqueradin ######################################################
> # ipchains -A forward -s $rechner3 -d 0.0.0.0/0 -j MASQ
> ipchains -A forward -s $rechner2 -d 0.0.0.0/0 -j MASQ
> ipchains -A forward -s $rechner1 -d 0.0.0.0/0 -j MASQ
> ######### ping #############################################################
> ipchains -A input -b -p icmp -i eth1 -s $extip -d 0.0.0.0/0 -j
> ACCEPT
> ######### Der rest ist verboten ############################################
> ipchains -A input -b -p 17 -d 0.0.0.0/0 -s $extip 520 -j DENY #der
> rechner will immer ins chello lan auf XXX.XXX.XXX.255 verbinden. eigene
> chain, damit nix geloggt wird hängt mit dem nfs zusammen denk ich mal
> ipchains -A input -l -i eth1 -s 0.0.0.0/0 -d $extip -j DENY #wird
> sicherheitshalber mitgeloggt
> ipchains -A input -l -i eth1 -s 0.0.0.0/0 -d 0.0.0.0/0 -j DENY
> #falls chello an problem bei den regeln hat hehe

You should think about a mechanism that makes sure that eth1 _always_ is
your external interface.

Thanks,
Roman.

-- 
 -                                                                      -
| Roman Drahtmüller      <drahtsuse.de> //          "Caution: Cape does |
  SuSE GmbH - Security           Phone: //       not enable user to fly."
| Nürnberg, Germany     +49-911-740530 // (Batman Costume warning label) |
 -                                                                      -
---------------------------------------------------------------------
To unsubscribe, e-mail: suse-security-unsubscribesuse.com
For additional commands, e-mail: suse-security-helpsuse.com

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]