schutz vor bundestrojaner: firewall?

Dein Netzwerk-Device in's LAN dürfte diesem Output zufolge eth0.0 sein.
 
Hallo

Lasen wir das mal.

Bekomme jetzt ständig wenn ich das folgende script starte die fehlermweldung (wenn ich bei erstellen neuer Ketten alles auskommentier ist es weg. Eine Fehlermeldung bekomme ich auch zum schluß bei Alle TCP Packete, die bis hier hin kommen, werden
# geloggt und rejected das habe ich jetzt etwas abgeändert -j LOGREJECT habe ich entfernt ---> Fehlermeldung weg):

Starting firewall
Loesche alte Regeln
iptables v1.3.7: Couldn't load target `LOG':File not found

Try `iptables -h' or 'iptables --help' for more information.




#!/bin/bash

echo "Starting firewall"

LOGLIMIT=20
IPTABLES=/usr/sbin/iptables

case "$1" in
start)
# alle alten Regeln entfernen
echo "Loesche alte Regeln"
$IPTABLES -F
$IPTABLES -X
$IPTABLES -t nat -F

### ERSTELLE NEUE KETTEN ###
# Chain to log and reject a port by ICMP port unreachable
$IPTABLES -N LOGREJECT
$IPTABLES -A LOGREJECT -m limit --limit $LOGLIMIT/minute -j LOG \
#--log-prefix "FIREWALL REJECT " --log-level notice --log-ip-options --log-tcp-options
$IPTABLES -A LOGREJECT -j REJECT --reject-with icmp-port-unreachable

### PROC MANIPULATION ###
# auf Broadcast-Pings nicht antworten
echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts
# halt die Klappe bei komischen ICMP Nachrichten
echo 0 > /proc/sys/net/ipv4/icmp_ignore_bogus_error_responses
# Kicke den ganzen IP Spoofing Shit
# (Source-Validierung anschalten)
echo 1 > /proc/sys/net/ipv4/conf/all/rp_filter
# Setze Default-TTL auf 61 (Default fuer Linux ist 64)
echo 61 > /proc/sys/net/ipv4/ip_default_ttl
# sende RST-Pakete wenn der Buffer voll ist
echo 1 > /proc/sys/net/ipv4/tcp_abort_on_overflow
# warte max. 30 secs auf ein FIN/ACK
echo 30 > /proc/sys/net/ipv4/tcp_fin_timeout
# unterbreche Verbindungsaufbau nach 3 SYN-Paketen
# Default ist 6
echo 3 > /proc/sys/net/ipv4/tcp_syn_retries
# unterbreche Verbindungsaufbau nach 3 SYN/ACK-Paketen
# Default ist 6
echo 3 > /proc/sys/net/ipv4/tcp_synack_retries

### MAIN PART ###
$IPTABLES -P INPUT DROP
$IPTABLES -P FORWARD DROP
$IPTABLES -P OUTPUT ACCEPT
$IPTABLES -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
$IPTABLES -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
# im Loopback koennen wir jedem trauen
$IPTABLES -A INPUT -i lo -j ACCEPT

# erlaube Pings
#$IPTABLES -A INPUT -p icmp --icmp-type echo-request -j ACCEPT


# lokale Dienste
# hier könnte Zugriffe von aussen z.B. für Remote-Verwaltung via SSH zugelassen werden, Bsp:
$IPTABLES -A INPUT -p tcp --dport 22 --tcp-flags ALL SYN -j ACCEPT

# Alle TCP Packete, die bis hier hin kommen, werden
# geloggt und rejected
# Der Rest wird eh per Default Policy gedroppt...
$IPTABLES -A INPUT -p tcp
$IPTABLES -A FORWARD -p tcp
;;
*)
echo "Usage: `basename $0` {start}" >&2
exit 64
;;
esac

exit 0
 
Dein Skript ist definitiv falsch, wenn es so ist, wie du es gepostet hast. Da sind zig Fehler drin. Korrekt müsste es so aussehen:

Code:
#!/bin/bash

echo "Starting firewall"

LOGLIMIT=20
IPTABLES=/sbin/iptables

case "$1" in
start)
	# alle alten Regeln entfernen
	echo "Loesche alte Regeln"
	$IPTABLES -F
	$IPTABLES -X
	$IPTABLES -t nat -F
	# Routing
	echo 1 > /proc/sys/net/ipv4/ip_forward
	$IPTABLES -A FORWARD -m state --state ESTABLISHED,RELATED,NEW -j ACCEPT
	$IPTABLES -t nat -A POSTROUTING -o <netzwerk-device-zum-internet> -j MASQUERADE
	### ERSTELLE NEUE KETTEN ###
	# Chain to log and reject a port by ICMP port unreachable 
	$IPTABLES -N LOGREJECT 
	$IPTABLES -A LOGREJECT -m limit --limit $LOGLIMIT/minute -j LOG \
          --log-prefix "FIREWALL REJECT " --log-level notice --log-ip-options --log-tcp-options 
	$IPTABLES -A LOGREJECT -j REJECT --reject-with icmp-port-unreachable 
	
	### PROC MANIPULATION ###
	# auf Broadcast-Pings nicht antworten
	echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts
	# halt die Klappe bei komischen ICMP Nachrichten
	echo 0 > /proc/sys/net/ipv4/icmp_ignore_bogus_error_responses
	# Kicke den ganzen IP Spoofing Shit
	# (Source-Validierung anschalten)
	echo 1 > /proc/sys/net/ipv4/conf/all/rp_filter
	# Setze Default-TTL auf 61 (Default fuer Linux ist 64)
	echo 61 > /proc/sys/net/ipv4/ip_default_ttl
	# sende RST-Pakete wenn der Buffer voll ist
	echo 1 > /proc/sys/net/ipv4/tcp_abort_on_overflow
	# warte max. 30 secs auf ein FIN/ACK
	echo 30 > /proc/sys/net/ipv4/tcp_fin_timeout
	# unterbreche Verbindungsaufbau nach 3 SYN-Paketen
	# Default ist 6
	echo 3 > /proc/sys/net/ipv4/tcp_syn_retries
	# unterbreche Verbindungsaufbau nach 3 SYN/ACK-Paketen
	# Default ist 6
	echo 3 > /proc/sys/net/ipv4/tcp_synack_retries
	
	### MAIN PART ###
	$IPTABLES -P INPUT DROP
	$IPTABLES -P FORWARD DROP
	$IPTABLES -P OUTPUT ACCEPT
	$IPTABLES -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
	$IPTABLES -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
	# im Loopback koennen wir jedem trauen 
	$IPTABLES -A INPUT -i lo -j ACCEPT
	# ebenso im LAN
	$IPTABLES -A INPUT -i <netzwerk-device-zum-lan> -j ACCEPT
	# erlaube Pings
	$IPTABLES -A INPUT -p icmp --icmp-type echo-request -j ACCEPT

	# Alle TCP Packete, die bis hier hin kommen, werden 
        # geloggt und rejected 
        # Der Rest wird eh per Default Policy gedroppt... 
	$IPTABLES -A INPUT -p tcp -j LOGREJECT 
	$IPTABLES -A FORWARD -p tcp -j LOGREJECT
	;;
*)
	echo "Usage: `basename $0` {start}" >&2
	exit 64
	;;
esac

exit 0
 
Dann kommt das :




root@OpenWrt:~# /etc/firewall.user start
Starting firewall
Loesche alte Regeln
iptables v1.3.7: Unknown arg `--log-prefix'
Try `iptables -h' or 'iptables --help' for more information.
/etc/firewall.user: /etc/firewall.user: 71: cannot open eth0: No such file
root@OpenWrt:~# /etc/firewall.user start
Starting firewall
Loesche alte Regeln
iptables v1.3.7: Unknown arg `--log-prefix'
Try `iptables -h' or 'iptables --help' for more information.
root@OpenWrt:~# /etc/firewall.user start
Starting firewall
Loesche alte Regeln
iptables v1.3.7: Couldn't load target `LOGREJECT':File not found

Try `iptables -h' or 'iptables --help' for more information.
iptables v1.3.7: Couldn't load target `LOGREJECT':File not found

Try `iptables -h' or 'iptables --help' for more information.




Habe nach der reihe mal alles auskommentiert damit du siehst was da alles für fehlermeldungen anstehen.
Wenn ich es richtig verstehe passt da was mit log und mit meinen Netzwerrk sowieso was nicht.
Müsste ich da irgendwo ein file haben wo das abgespeichert wird???



Nachtrag: Das Problem mit den log..... habe ich gerade gelöst. Habe alle Packete die mit iptables zu tun haben installiert.

Aber das Netzwerkproblem besteht weiterhin:
/etc/firewall.user: /etc/firewall.user: 71: cannot open eth0: No such file
 
Scheinbar kommt openwrt mit dem Target LOG nicht klar. Nimm mal die Logging-Sachen raus.

Code:
#!/bin/bash

echo "Starting firewall"

LOGLIMIT=20
IPTABLES=/sbin/iptables

case "$1" in
start)
	# alle alten Regeln entfernen
	echo "Loesche alte Regeln"
	$IPTABLES -F
	$IPTABLES -X
	$IPTABLES -t nat -F
	# Routing
	echo 1 > /proc/sys/net/ipv4/ip_forward
	$IPTABLES -A FORWARD -m state --state ESTABLISHED,RELATED,NEW -j ACCEPT
	$IPTABLES -t nat -A POSTROUTING -o <netzwerk-device-zum-internet> -j MASQUERADE
	
	### PROC MANIPULATION ###
	# auf Broadcast-Pings nicht antworten
	echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts
	# halt die Klappe bei komischen ICMP Nachrichten
	echo 0 > /proc/sys/net/ipv4/icmp_ignore_bogus_error_responses
	# Kicke den ganzen IP Spoofing Shit
	# (Source-Validierung anschalten)
	echo 1 > /proc/sys/net/ipv4/conf/all/rp_filter
	# Setze Default-TTL auf 61 (Default fuer Linux ist 64)
	echo 61 > /proc/sys/net/ipv4/ip_default_ttl
	# sende RST-Pakete wenn der Buffer voll ist
	echo 1 > /proc/sys/net/ipv4/tcp_abort_on_overflow
	# warte max. 30 secs auf ein FIN/ACK
	echo 30 > /proc/sys/net/ipv4/tcp_fin_timeout
	# unterbreche Verbindungsaufbau nach 3 SYN-Paketen
	# Default ist 6
	echo 3 > /proc/sys/net/ipv4/tcp_syn_retries
	# unterbreche Verbindungsaufbau nach 3 SYN/ACK-Paketen
	# Default ist 6
	echo 3 > /proc/sys/net/ipv4/tcp_synack_retries
	
	### MAIN PART ###
	$IPTABLES -P INPUT DROP
	$IPTABLES -P FORWARD DROP
	$IPTABLES -P OUTPUT ACCEPT
	$IPTABLES -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
	$IPTABLES -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
	# im Loopback koennen wir jedem trauen 
	$IPTABLES -A INPUT -i lo -j ACCEPT
	# ebenso im LAN
	$IPTABLES -A INPUT -i <netzwerk-device-zum-lan> -j ACCEPT
	# erlaube Pings
	$IPTABLES -A INPUT -p icmp --icmp-type echo-request -j ACCEPT

        # Der Rest wird eh per Default Policy gedroppt... 
	;;
*)
	echo "Usage: `basename $0` {start}" >&2
	exit 64
	;;
esac

exit 0
 
Habs zuerst schon nachgetragen.

das LOG Problem habe ich gelöst in dem ich sämtliche Packete die mit iptables zu tun hatten installiert habe.


Habe jetzt nur noch das netzwerkproblem




Aber noch eine blöde Frage:

Zu was brauche ich das überhaupt??

# ebenso im LAN
$IPTABLES -A INPUT -i <br-lan> -j ACCEPT


Wenn ichs auskommentiere ist die Fehlermeldung weg. Mein internes Netzwerk läuft auch ohne den Befehl


mfg asd1234
 
Schau doch einfach mal mit 'tcpdump' alle Interfaces durch. Dann siehst du ja, über welches Interface die Pakete deiner Verbindung zum Router laufen. Dieses Device nimmst du dann als LAN-Device und ppp0 als Device zum Internet.
 
Hier die Ausgabe mit tcpdump:


tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on br-lan, link-type EN10MB (Ethernet), capture size 96 bytes
00:13:32.249605 IP 192.168.1.1.22 > 192.168.1.15.3663: P 558249927:558249979(52) ack 2498047784 win 9648
00:13:32.250606 IP 192.168.1.1.22 > 192.168.1.15.3663: P 52:168(116) ack 1 win 9648
00:13:32.250882 IP 192.168.1.15.3663 > 192.168.1.1.22: . ack 168 win 64367
00:13:32.251879 IP 192.168.1.1.22 > 192.168.1.15.3663: P 168:220(52) ack 1 win 9648
00:13:32.252894 IP 192.168.1.1.22 > 192.168.1.15.3663: P 220:272(52) ack 1 win 9648
00:13:32.253171 IP 192.168.1.15.3663 > 192.168.1.1.22: . ack 272 win 64263
00:13:32.254127 IP 192.168.1.1.22 > 192.168.1.15.3663: P 272:324(52) ack 1 win 9648
00:13:32.255056 IP 192.168.1.1.22 > 192.168.1.15.3663: P 324:376(52) ack 1 win 9648
00:13:32.255356 IP 192.168.1.15.3663 > 192.168.1.1.22: . ack 376 win 64159
00:13:32.256330 IP 192.168.1.1.22 > 192.168.1.15.3663: P 376:428(52) ack 1 win 9648
 
Du solltest tcpdump schon auf die einzelnen Interfaces anwenden um zu sehen über welches Device die Pakete tatsächlich laufen. Glaubt man nämlich der IP, wäre es die 192.168.1.1 und die ist auf ein Device gemappt, das offenbar nicht in /dev existiert. Also wende tcpdump auf jedes Interface einzeln an um das korrekte Device zu ermitteln.
 
Einfach mit der Option '-i <devicebezeichner>' das Device angeben und das für jedes Netzwerk-Device machen. Auf dem Device, auf dem deine SSH-Pakete ein- und ausgehen ist dein LAN-Interface. Siehe auch 'man tcpdump'.
 
Habe jetzt br-lan eth1 eth0 eth 0.0 eth0.1 und lo durchprobiert. Unten die Ausgabe.

Über die ip 192.168.1.15 bin ich mit sh verbunden.






root@OpenWrt:~# tcpdump -i br-lan
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on br-lan, link-type EN10MB (Ethernet), capture size 96 bytes
00:11:24.733757 IP 192.168.1.1.22 > 192.168.1.15.3936: P 1079686816:1079686868(52) ack 3467009192 win 27872
00:11:24.734221 IP 192.168.1.15.3936 > 192.168.1.1.22: . ack 52 win 65431
00:11:24.735296 IP 192.168.1.1.22 > 192.168.1.15.3936: P 52:168(116) ack 1 win 27872
00:11:24.736454 IP 192.168.1.1.22 > 192.168.1.15.3936: P 168:220(52) ack 1 win 27872
00:11:24.736846 IP 192.168.1.15.3936 > 192.168.1.1.22: . ack 220 win 65263
00:11:24.737880 IP 192.168.1.1.22 > 192.168.1.15.3936: P 220:272(52) ack 1 win 27872

[30] + Stopped tcpdump -i br-lan
root@OpenWrt:~#



root@OpenWrt:~# tcpdump -i eth0
tcpdump: WARNING: eth0: no IPv4 address assigned
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
00:12:09.231803 IP 192.168.1.1.22 > 192.168.1.15.3936: P 1079722368:1079722420(52) ack 3467018648 win 33232
00:12:09.233042 IP 192.168.1.1.22 > 192.168.1.15.3936: P 52:168(116) ack 1 win 33232
00:12:09.233252 IP 192.168.1.15.3936 > 192.168.1.1.22: . ack 168 win 65247
00:12:09.234522 IP 192.168.1.1.22 > 192.168.1.15.3936: P 168:220(52) ack 1 win 33232
00:12:09.235588 IP 192.168.1.1.22 > 192.168.1.15.3936: P 220:272(52) ack 1 win 33232
00:12:09.235769 IP 192.168.1.15.3936 > 192.168.1.1.22: . ack 272 win 65143

[33] + Stopped tcpdump -i eth0
root@OpenWrt:~#

root@OpenWrt:~# tcpdump -i eth0.0
tcpdump: WARNING: eth0.0: no IPv4 address assigned
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0.0, link-type EN10MB (Ethernet), capture size 96 bytes
00:12:56.415463 IP 192.168.1.1.22 > 192.168.1.15.3936: P 1079744420:1079744472(52) ack 3467025112 win 33232
00:12:56.415838 IP 192.168.1.15.3936 > 192.168.1.1.22: . ack 52 win 64991
00:12:56.417106 IP 192.168.1.1.22 > 192.168.1.15.3936: P 52:168(116) ack 1 win 33232
00:12:56.418247 IP 192.168.1.1.22 > 192.168.1.15.3936: P 168:220(52) ack 1 win 33232
00:12:56.418564 IP 192.168.1.15.3936 > 192.168.1.1.22: . ack 220 win 64823
00:12:56.419725 IP 192.168.1.1.22 > 192.168.1.15.3936: P 220:272(52) ack 1 win 33232
[35] + Stopped tcpdump -i eth0.0

root@OpenWrt:~# tcpdump -i eth0.1
tcpdump: WARNING: eth0.1: no IPv4 address assigned
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0.1, link-type EN10MB (Ethernet), capture size 96 bytes
00:14:13.688263 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 00:1b:fc:06:50:15 (oui Unknown), length: 277
00:14:16.712239 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 00:1b:fc:06:50:15 (oui Unknown), length: 277
00:14:19.736237 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 00:1b:fc:06:50:15 (oui Unknown), length: 277
00:14:22.760237 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 00:1b:fc:06:50:15 (oui Unknown), length: 277
[36] + Stopped tcpdump -i eth0.1



root@OpenWrt:~# tcpdump -i lo
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on lo, link-type EN10MB (Ethernet), capture size 96 bytes
 
Wenn tcpdump das Device br-lan findet, sollte iptables das eigentlich auch tun. Trag das mal als LAN-Device in das Skript ein, egal ob es als Datei in /dev/ existiert oder nicht. Ich kann mir irgendwie nicht vorstellen, warum es nicht gehen sollte. Ansonsten würde ich dir raten dich direkt an das openwrt-Projekt zu wenden.
 
Hier noch mal die Fehlermeldung (Habe jetzt das modem auch wieder installiert. Netzwerkverbindung über dem router funktioniert. Das Internet funktioniert bei gestarteten script nicht mehr:

root@OpenWrt:~# /etc/firewall.user start
Starting firewall
Loesche alte Regeln
/etc/firewall.user: /etc/firewall.user: 84: cannot open ppp0: No such file
/etc/firewall.user: /etc/firewall.user: 84: cannot open br-lan: No such file


Schau bitte mal mein script durch nicht das ich einen blöden Fehler drinnen habe:


#!/bin/bash

# Copyright (C) 2006 OpenWrt.org

echo "Starting firewall"

LOGLIMIT=20
IPTABLES=/usr/sbin/iptables



case "$1" in
start)
# alle alten Regeln entfernen
echo "Loesche alte Regeln"
$IPTABLES -F
$IPTABLES -X
$IPTABLES -t nat -F
# Routing
echo 1 > /proc/sys/net/ipv4/ip_forward
$IPTABLES -A FORWARD -m state --state ESTABLISHED,RELATED,NEW -j ACCEPT
$IPTABLES -t nat -A POSTROUTING -o <ppp0> -j MASQUERADE
### ERSTELLE NEUE KETTEN ###
# Chain to log and reject a port by ICMP port unreachable
$IPTABLES -N LOGREJECT
$IPTABLES -A LOGREJECT -m limit --limit $LOGLIMIT/minute -j LOG \
--log-prefix "FIREWALL REJECT " --log-level notice --log-ip-options --log-tcp-options
$IPTABLES -A LOGREJECT -j REJECT --reject-with icmp-port-unreachable

### PROC MANIPULATION ###
# auf Broadcast-Pings nicht antworten
echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts
# halt die Klappe bei komischen ICMP Nachrichten
echo 0 > /proc/sys/net/ipv4/icmp_ignore_bogus_error_responses
# Kicke den ganzen IP Spoofing Shit
# (Source-Validierung anschalten)
echo 1 > /proc/sys/net/ipv4/conf/all/rp_filter
# Setze Default-TTL auf 61 (Default fuer Linux ist 64)
echo 61 > /proc/sys/net/ipv4/ip_default_ttl
# sende RST-Pakete wenn der Buffer voll ist
echo 1 > /proc/sys/net/ipv4/tcp_abort_on_overflow
# warte max. 30 secs auf ein FIN/ACK
echo 30 > /proc/sys/net/ipv4/tcp_fin_timeout
# unterbreche Verbindungsaufbau nach 3 SYN-Paketen
# Default ist 6
echo 3 > /proc/sys/net/ipv4/tcp_syn_retries
# unterbreche Verbindungsaufbau nach 3 SYN/ACK-Paketen
# Default ist 6
echo 3 > /proc/sys/net/ipv4/tcp_synack_retries

### MAIN PART ###
$IPTABLES -P INPUT DROP
$IPTABLES -P FORWARD DROP
$IPTABLES -P OUTPUT ACCEPT
$IPTABLES -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
$IPTABLES -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
# im Loopback koennen wir jedem trauen
$IPTABLES -A INPUT -i lo -j ACCEPT
# ebenso im LAN
$IPTABLES -A INPUT -i <br-lan> -j ACCEPT
# erlaube Pings
$IPTABLES -A INPUT -p icmp --icmp-type echo-request -j ACCEPT


# lokale Dienste
# hier könnte Zugriffe von aussen z.B. für Remote-Verwaltung via SSH zugelassen werden, Bsp:
# $IPTABLES -A INPUT -p tcp --dport 22 --tcp-flags ALL SYN -j ACCEPT

# Alle TCP Packete, die bis hier hin kommen, werden
# geloggt und rejected
# Der Rest wird eh per Default Policy gedroppt...
$IPTABLES -A INPUT -p tcp -j LOGREJECT
$IPTABLES -A FORWARD -p tcp -j LOGREJECT
;;
*)
echo "Usage: `basename $0` {start}" >&2
exit 64
;;
esac

exit 0
 
Die spitzen Klammern in der Skript-Vorlage sind nur als Platzhalter gedacht um anzuzeigen, daß dort ein Wert eingesetzt werden muß. Die haben aber im endgültigen Skript nichts mehr zu suchen. Es heißt also nicht

Code:
$IPTABLES -t nat -A POSTROUTING -o <ppp0> -j MASQUERADE

sondern

Code:
$IPTABLES -t nat -A POSTROUTING -o ppp0 -j MASQUERADE

Evtl. mal einfach die Manpage zu iptables lesen. :P
 
Das war eigene Blödheit.



Also jetzt funkts.

Danke vielmals.

Zur info noch schnell wegen den Fehlermeldungem mit den log habe ich zwei Packete installiert:

iptables-mod-extra_1.3.7-1_mipsel.ipk
iptables-utils_1.3.7-1_mipsel.ipk

Danach waren die Fehlermeldungen weg.
(Falls wer mal das gleiche Problem hat.

@bitmuncher noch ein paar fragen:

1)Ist das ganze jetzt so sicher (Kann ich netbanking usw. ohne Angst betreiben)????
2) Habe vor noch einen USB Drucker an den Router zu hängen. Kommt mir da die Firewall in die Quere???

PS: Danke vielmals das du dir so viel Zeit genommen hast.
 
Original von asd1234
1)Ist das ganze jetzt so sicher (Kann ich netbanking usw. ohne Angst betreiben)????
Zumindest Firewall-technisch ist es sicher. Wenn du jetzt noch dein Gehirn beim Surfen usw. anschaltest, kann zumindest keiner so einfach von außen auf deinen Rechner zugreifen. 100%ige Sicherheit gibt es eh nicht. Wenn jemand einen Trojaner bei dir einschleust (z.B. per Email o.ä.) kann der Angreifer natürlich trotzdem Daten bei dir ausspionieren. In diesem Fall wird dir aber die beste Firewall nicht helfen können. Da heisst es halt vorsicht beim Umgang mit Daten, die von anderen kommen, egal auf welchem Weg. Wenn der geroutete Rechner ein Windows-Rechner ist, sollte dieser defintiv zusätzlich gesichert werden (Anti-Spyware-Tool, Antivirus usw.). Zusätzlich solltest du die Regel für SSH anpassen, damit der Zugriff von außen nicht mehr möglich ist oder ein Tool zum Einsatz bringen, das Bruteforce-Angriffe unterbindet. Die Manpage zu iptables wird dir da weiter helfen. :)

Original von asd1234
2) Habe vor noch einen USB Drucker an den Router zu hängen. Kommt mir da die Firewall in die Quere???
Eigentlich nicht, wenn der Drucker eine IP im LAN nutzt. Schließlich hast du ja mit '$IPTABLES -A INPUT -i br-lan -j ACCEPT' jeglichen Zugriff innerhalb des LANs erlaubt.
 
Ich würde nicht sagen das euch eine firewall hilft, denn genauso wie der "trojaner" reingeschmuggelt wird schmuggelt er seine Daten einfach wieder hinaus. Und zwar über den ganz normalen Datenstrom der über die Sina - Boxen geht. Das heisst der kommt beispielsweise via HTTP rein, und geht auch via HTTP raus. Das einzigste was man da machen könnte ohne direkt einen haufen firlefanz zu veranstalten wäre eine ständige CRC Prüfung. Allerdings könntest du noch eine Möglichkeit pflegen indem du dir im Ausland einen Proxy suchst und nur über ihn surfst. Wichtig hierbei: die Verbindung zwischen Proxy und dir MUSS verschlüsselt ablaufen. Da der "Trojaner" aber die Verschlüsselung nicht abhören kann, kann er sich nicht auf den Datenstrom aufschalten da er ja diesen im Klartext braucht. Sollte es dennoch gemacht werden, schlägt die BCH Kodierung des Transport Layers zu und verwirft die entsprechenden Pakete einfach.
 
Hallo

Ich habe mit shilds UP mal den Router auf offene Ports gescannt.

Hier mei Ergebnis:

Bis auf Port 1 ist alles gefiltert.

Port 1 ist nur geschlossen.


Was kann ich noch mache das Port 1 auch gefiltert wird???
Oder ist das egal bzw. hat das eine speziellen Grund???


mfg asd1234
 
Zurück
Oben