Incoming from Wanda Round:
> "s. keeling" <[EMAIL PROTECTED]> wrote in message news:<[EMAIL PROTECTED]>...
> > Incoming from Wanda Round:
> > >
> > > Aug 12 04:36:53 towern kernel: |iptables -- IN=ppp0 OUT= MAC=
> > > SRC=201.129.122.85 DST=12.65.24.43 LEN=48 TOS=0x00 PREC=0x00 TTL=115
> > > ID=40023 DF PROTO=TCP SPT=4346 DPT=445 WINDOW=16384 RES=0x00 SYN URGP=0
> >
> > - It came in over ppp0.
>
> Many thanks for the clear, tiny-bite answer! Which specific item
> tells you that it "didn't get back out"?
I spoke too soon on that. Sorry. :-P
> You're saying that as long as the incoming doesn't get back out
> I'm ok, correct?
It all depends on whether you have services running on your machine
that listen on DPT (445 in this case). If something is there to "pick
up the phone" so to speak, anything can happen. That service could
answer on another port altogether.
The trick is, don't run services that you don't need to run. Go into
/etc/inetd.conf and comment out anything that you don't like; things
like ftpd, telnetd, rsh (remote shell), portmap, identd.
If you never need to ssh _into_ your box, tell it not to run sshd.
You'll still be able to ssh out.
> thing only with different MAC addresses. Does this mean, FROM
> THE LITTLE YOU'VE SEEN, that the iptables is doing a good job?
It _may_ be, but if you're running services you don't need to, you
will have opened the door and iptables can't solve that. All a
firewall does is _break connectivity_. Unix was designed to listen to
a lot of ports and respond to requests appropriately. iptables just
slaps duct tape over those ports.
I'd get one of the firewall management tools (fwbuilder, shorewall,
etc.) and play with it. It'll build you your iptables rules for you.
That's the best way to wrap your head around this stuff.
My theory on iptables rules, for a personal workstation, is:
anything outgoing NEW,ESTABLISHED,RELATED is allowed
anything incoming NOT from localhost that's NEW - log and drop
anything incoming over ppp0 that's ESTABLISHED,RELATED to existing
connections - accept
then you can add exceptions; I allow tcp 113 because I run something
called fauxident. some cvs servers demand it.
groups.google.com for comp.os.linux.security can be a lot of help.
--
Any technology distinguishable from magic is insufficiently advanced.
(*) http://www.spots.ab.ca/~keeling
- -
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
