Hi,
On Tue, May 23, 2006 at 03:40:58PM +0200, Michel Messerschmidt wrote:
> LeVA said:
> > If I set up my firewall to accept only my local network (eg.
> > -s 192.168.0.0/255.255.255.0) connecting to a port (eg. smtp), then
> > anyone can spoof that too. So what's the point of creating rules? :)
even if one can spoof the IP, he (= the attacker) can't do very much more
(assuming, he can't read local traffic), at least with TCP connection.
First, he has to guess the initial sequence number the server (e. g. SMTP)
would send for that connection. If the TCP stack is patched properly (maybe
this is already added to Linux mainline), then this guess is 1 out of 2**32.
(If it isn't patched, with a bit of investigating the traffic of that server
-- valid connections from your computer are probably enough -- the ISN is
much easier to guess.)
After that, the attacker must exactly know how many bytes the servers sends
within each TCP packet (the attacker usually won't see the packets sent by
the server), so he can send the the right ACK number.
Also, if the attacker uses an IP address that is active, the SYN+ACK from
the server to that IP will trigger a TCP RESET AFAIUI from that station and
the connection won't be opened. (In case of UDP that station might send a
ICMP "destination unreachable" and the server won't "open" that connection,
also.)
So what can happen? {SYN,ICMP} floods, TCP RST attacks, but the last one is
then just guesswork (assuming the attacker can't see the real traffic at
192.168.0.0/24 else you already have a big problem). Am I missing something?
> This is ok. You simply need some more "anti-spoofing" rules.
> You can allow packets from 127.0.0.1 only if they come from the loopback
> interface. And you may want to discard packets coming from the internal
> network card, if they don't have an appropriate IP address.
I have a rule for spoofed localhost addresses, I took from someone else some
time ago at top of my INPUT chain:
iptables -A INPUT -d 127.0.0.0/8 -i ! lo -j DROP
Thinking about it, I wonder, whether I should add the same rule for source =
127.0.0.0/8. What can happen, if someone sends me a packet with
src=127.x.x.x and dst=x.x.x.x (!=127.x.x.x) over iface!=lo?
If dst!=one of my_ip_addresses it won't go into INPUT. FORWARD has DROP
policy and it's not (on my router) from a local network address (192.*) nor
state related/established -> drop.
But what if dst==one of my_ip_addresses? Assuming kernel generates some
package with src and dst exchanged. I think it can't interfere with
processes running locally and communicating over some IP based protocol,
since there is no valid 127.x.x.x<->129.168.x.x (or other private subnets)
or 127.x.x.x<->3.3.3.3 (<- some valid, official assigned IP address)
connection.
Something bad could happen, if kernel builds the new package with
dst=old_source and src=127.y.y.y. Does someone know what the kernel will do
in such a case when I get a packet with src=127.x.x.x and dst=x.x.x.x?
> Here is an example: http://www.sns.ias.edu/~jns/files/iptables_ruleset
Hm, I often see people first cleaning/flushing/deleting the rules and then
setting the default policy. If the policy was for some reason set to ACCEPT,
you have a small time window when packets will be accepted, that got dropped
or rejected before by the rules you just deleted. Why not first set the
policy to DROP and then deleting rules?
# set policy to drop, flush the tables' chains and delete user chains
# --------------------------------------------------------------------
for CHAIN in INPUT OUTPUT FORWARD; do
#true
iptables -P $CHAIN DROP
done
for TABLE in filter nat mangle; do #filter is default (if -t is omitted)
iptables -t $TABLE -F
iptables -t $TABLE -X
done
(From reading iptables' man page and/or experimenting you need to
flush/delete the chains in different tables manually. I hadn't found a
"general reset" option back then.)
For TCP, if a packet got dropped in that time window, it will be resent
eventually. For UDP your application is required to deal with dropped
packages gracefully (it could have been dropped elsewhere) and I think ICMP
is not so much important (and could be dropped elsewhere, too). If you run
other protocols on top of IP (maybe BGP or something), you probably shut
down that service beforehand (if it can't deal with some few packages being
dropped).
Something different I saw at various iptables scripts, that I don't quite
understand: Why do people put so much rules into the OUTPUT chain? For
single user workstation/notebooks it hinders yourself a lot. E. g. you allow
access to some services like HTTP or SSH on other hosts. But what if you
want to connect to host that has that service running on an unusual port?
You then need to tweak you iptables script as root...
Is it because you don't trust the software that is running? Especially since
this is a Debian mailing list here: You have the sources. If a service can't
bind to only 127.0.0.1, change it!
Or is it because you don't trust the other users there? Why do they have an
account then or a computer that is connected to the internet (assuming you
don't want them to surf or run some file exchange/p2p service)? Once you
allow a user to just connect to a single port "out there", he might start to
tunnel stuff if he really wants to do something else... (ssh over HTTP
someone?) I think telling them (or not) that you do monitor the traffic (at
the gateways) is far better. At least tell them, what you _not_ want them to
do but don't block output. You know, they might have found a (HTTP) server
running on port 6881, that tells them how to do their work ten times more
efficient. :)
Maybe blocking something in OUTPUT is reasonable for servers as a stumbling
block if a service got taken over but then it probably won't be long until
the intruder got root access there and removes the rules anyway.
Greetings,
Mike Dornberger
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
