RE: Masquerade hacking problem.
> -Original Message- > From: linux power [mailto:linuxpower2002@;yahoo.no] > Sent: Sunday, 3 November 2002 05:51 > To: redhat mail list > Subject: Masquerade hacking problem. > > > It seems that masqureade use netbios-ns port to broadcast for > the whole world thats its seeking a vacant ip address.That it > a major firewall problem in my computer because I cant close > the netbios ports, and result in hacking attempts all the time. > > Nobody told me that when they recommended masqurade. > In case the other messages did not sink in... 1. There is no reason I can think of why you can't close those ports. In fact there is no good reason why they should be open at all. If you really DO require netbios traffic externally then use a VPN. 2. masquerade does not "use" netbios-ns. Maybe your policy allows it through. In which case your rules are wrong. The netbios-ns is either being forwarded from a local ms-windows box (you should not be allowing this) or else you have samba on your firewall configured wrongly. It should only be allowed on your local network (set in smb.conf). 3. masquerade cannot even handle netbios over tcp/ip. It is one of those nasty packet formats that require helper routines to mangle the header. As far as I know it has never been done for Linux. Certainly not for ipchains/masq. 4. Perhaps you are using a trivial firewall ruleset, which might be OK for testing things out, but not for full-time use. As others have said already, block everything and then only allow what is necessary. 5. BTW, the netbios broadcast is for a name in a workgroup, not an IP number. Cameron. -- redhat-list mailing list unsubscribe mailto:redhat-list-request@;redhat.com?subject=unsubscribe https://listman.redhat.com/mailman/listinfo/redhat-list
Re: Masquerade hacking problem.
At 22:57 02.11.2002, Jason Costomiris said: [snip] >Well, I'll just have to go on ahead and disagree with you. :) :)) that's why I love open source .-) >I've been using the Internet since the late 80s, and I've never once >been the "victim" of a trojan or a virus. As far as I'm concerned, >people who get infected with trojans and virii are generally wearing >the digital equivalent of a "kick me" sign. It's not hard to manage to well, I partly agree with you here - most of them do. But taking into account that people are discovering server code flaws on a nearly daily basis - you know, the "may aquire root access" type - I would not to 100% rule out the opportunity of a malicious guy/girl stepping into my system. Granted, if they had root shell access they could then kill my firewall - nothing is secure except a server that's switched off and grounded into the pacific with a ton of concrete around it. But it may make life harder for those people. That's all I aim for... >not get infected - even my mother can do this. you got a technologically advanced mother - be a good son :) -- >O Ernest E. Vogelsinger/~\ The ASCII (\)ICQ #13394035\ / Ribbon Campaign ^ X Against / \ HTML Email -- redhat-list mailing list unsubscribe mailto:redhat-list-request@;redhat.com?subject=unsubscribe https://listman.redhat.com/mailman/listinfo/redhat-list
Re: Masquerade hacking problem.
On Saturday, November 2, 2002, at 04:04 PM, Ernest E Vogelsinger wrote:
At 21:55 02.11.2002, Jason Costomiris said:
[snip]
# Safe default policies
iptables -P INPUT DROP
iptables -P OUTPUT ACCEPT
iptables -P FORWARD DROP
[snip]
I beg to disagree - using an output default polica of ACCEPT opens a
wide
door for any Trojans that may make it into your network on one way or
the
other. Maybe this is academic - having DROP as rule for fw input SHOULD
leave anything safe at the fw-box itself, but you never know...
Well, I'll just have to go on ahead and disagree with you. :)
I've been using the Internet since the late 80s, and I've never once
been the "victim" of a trojan or a virus. As far as I'm concerned,
people who get infected with trojans and virii are generally wearing
the digital equivalent of a "kick me" sign. It's not hard to manage to
not get infected - even my mother can do this.
--
Jason Costomiris <><
E: jcostom {at} jasons {dot} org / W: http://www.jasons.org/
Quidquid latine dictum sit, altum viditur.
--
redhat-list mailing list
unsubscribe mailto:redhat-list-request@;redhat.com?subject=unsubscribe
https://listman.redhat.com/mailman/listinfo/redhat-list
Re: Masquerade hacking problem.
At 21:55 02.11.2002, Jason Costomiris said: [snip] ># Safe default policies >iptables -P INPUT DROP >iptables -P OUTPUT ACCEPT >iptables -P FORWARD DROP [snip] I beg to disagree - using an output default polica of ACCEPT opens a wide door for any Trojans that may make it into your network on one way or the other. Maybe this is academic - having DROP as rule for fw input SHOULD leave anything safe at the fw-box itself, but you never know... My fw-script simply DROPS everything that's not explicitly allowed. Maybe that's a bit of Austrian mind here - if it's not explicitly allowed, it is forbidden ;-) But I feel a lot safer since I have this rule in effect. -- >O Ernest E. Vogelsinger/~\ The ASCII (\)ICQ #13394035\ / Ribbon Campaign ^ X Against / \ HTML Email -- redhat-list mailing list unsubscribe mailto:redhat-list-request@;redhat.com?subject=unsubscribe https://listman.redhat.com/mailman/listinfo/redhat-list
Re: Masquerade hacking problem.
At 21:30 02.11.2002, fred smith said: [snip] >worm/virus, possibly BUGBEAR, possibly others. You ought to see >the number of hits my firewall gets from people trying to get IN >through it on port 137 I get several dozen a day, all from [snip] *hehh* that's why I call my table SILENTDROP - it doesn't log these attempts, I need my log space for more interesting probes than dummy-SMB's :) -- >O Ernest E. Vogelsinger/~\ The ASCII (\)ICQ #13394035\ / Ribbon Campaign ^ X Against / \ HTML Email -- redhat-list mailing list unsubscribe mailto:redhat-list-request@;redhat.com?subject=unsubscribe https://listman.redhat.com/mailman/listinfo/redhat-list
Re: Masquerade hacking problem.
On Saturday, November 2, 2002, at 02:50 PM, linux power wrote:
It seems that masqureade use netbios-ns port to broadcast for the
whole world thats its seeking a vacant ip address.That it a major
firewall problem in my computer because I cant close the netbios
ports, and result in hacking attempts all the time.
Nobody told me that when they recommended masqurade.
The netbios-ns service uses tcp/137. Masquerading neither uses it, nor
does it "broadcast for the whole world that its seeking a vacant ip
address."
You've posted more than once with stories of your systems being hacked
- I can only assume this means you've had multiple intrusions. Perhaps
you should read some howtos, or read up on securing your systems.
While you're at it, you should also backup data files, and perform a
clean (as in format the drives) installation of your operating systems.
Assuming a simple configuration, eth0 on the inside, eth1 on the
outside, no inbound access, you would be safe with something as simple
as:
# Safe default policies
iptables -P INPUT DROP
iptables -P OUTPUT ACCEPT
iptables -P FORWARD DROP
# allow established and related connections
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
# allow localhost communication
iptables -A INPUT -i lo -j ACCEPT
# allow inbound from internal network, allow internal network to go out
to the Internet
iptables -A INPUT -m state -i eth0 --state NEW -j ACCEPT
iptables -A FORWARD -m state -i eth0 --state NEW -j ACCEPT
# setup NAT
iptables -t nat -A POSTROUTING -o eth1 -j MASQUERADE
There, I've fixed your hacking problems in 9 lines. To save that, run
"service iptables save".
--
Jason Costomiris <><
E: jcostom {at} jasons {dot} org / W: http://www.jasons.org/
Quidquid latine dictum sit, altum viditur.
--
redhat-list mailing list
unsubscribe mailto:redhat-list-request@;redhat.com?subject=unsubscribe
https://listman.redhat.com/mailman/listinfo/redhat-list
Re: Masquerade hacking problem.
On Sat, Nov 02, 2002 at 08:50:33PM +0100, linux power wrote: > > It seems that masqureade use netbios-ns port to broadcast for the whole world thats >its seeking a vacant ip address.That it a major firewall problem in my computer >because I cant close the netbios ports, and result in hacking attempts all the time. > > Nobody told me that when they recommended masqurade. > Nobody told you that because masquerade doesn't do that. I'd venture to guess that you've got some windoze box on your local LAN, inside the "firewall" (masq box) that is infected with some worm/virus, possibly BUGBEAR, possibly others. You ought to see the number of hits my firewall gets from people trying to get IN through it on port 137 I get several dozen a day, all from either script-kiddies, or innocents who are infected and don't know it. -- Fred Smith -- [EMAIL PROTECTED] - But God demonstrates his own love for us in this: While we were still sinners, Christ died for us. --- Romans 5:8 (niv) -- -- redhat-list mailing list unsubscribe mailto:redhat-list-request@;redhat.com?subject=unsubscribe https://listman.redhat.com/mailman/listinfo/redhat-list
Re: Masquerade hacking problem.
At 20:50 02.11.2002, linux power said: [snip] >It seems that masqureade use netbios-ns port to broadcast for the whole >world thats its seeking a vacant ip address.That it a major firewall >problem in my computer because I cant close the netbios ports, and result >in hacking attempts all the time. [snip] I don't think so, this might be a DHCP issue. You're using iptables? Insert something like that into your firewall script: # # the SMB table is executed for all NetBios related traffic # /sbin/iptables -N SMB # allow traffic to/from the specified IP's /sbin/iptables -A SMB -s xxx.xxx.xxx.xxx -j ACCEPT # xxx's machine /sbin/iptables -A SMB -d xxx.xxx.xxx.xxx -j ACCEPT /sbin/iptables -A SMB -s xxx.xxx.xxx.xx -j ACCEPT # yyy's machine /sbin/iptables -A SMB -d xxx.xxx.xxx.xx -j ACCEPT # and kill everything else /sbin/iptables -A SMB -j DROP # # the SILENTDROP table filters out all NetBios traffic # /sbin/iptables -N SILENTDROP /sbin/iptables -A SILENTDROP -p tcp --dport 137 -j SMB /sbin/iptables -A SILENTDROP -p tcp --dport 138 -j SMB /sbin/iptables -A SILENTDROP -p tcp --dport 139 -j SMB /sbin/iptables -A SILENTDROP -p tcp --dport 445 -j SMB /sbin/iptables -A SILENTDROP -p udp --dport 137 -j SMB /sbin/iptables -A SILENTDROP -p udp --dport 138 -j SMB /sbin/iptables -A SILENTDROP -p udp --dport 139 -j SMB /sbin/iptables -A SILENTDROP -p udp --dport 445 -j SMB /sbin/iptables -A SILENTDROP -p tcp --sport 137 -j SMB /sbin/iptables -A SILENTDROP -p tcp --sport 138 -j SMB /sbin/iptables -A SILENTDROP -p tcp --sport 139 -j SMB /sbin/iptables -A SILENTDROP -p tcp --sport 445 -j SMB /sbin/iptables -A SILENTDROP -p udp --sport 137 -j SMB /sbin/iptables -A SILENTDROP -p udp --sport 138 -j SMB /sbin/iptables -A SILENTDROP -p udp --sport 139 -j SMB /sbin/iptables -A SILENTDROP -p udp --sport 445 -j SMB # # insert these at the top for the INPUT, OUTPUT, and FORWARD tables # assuming eth0 is the interface to the internet, and eth1 to internal network # /sbin/iptables -A INPUT -i eth1 -j SILENTDROP /sbin/iptables -A INPUT -i eth0 -j SILENTDROP /sbin/iptables -A OUTPUT -i eth1 -j SILENTDROP /sbin/iptables -A OUTPUT -i eth0 -j SILENTDROP /sbin/iptables -A FORWARD -i eth1 -j SILENTDROP /sbin/iptables -A FORWARD -i eth0 -j SILENTDROP Taken (and shortened) from our firewall script which seems to work perfectly on this issue... -- >O Ernest E. Vogelsinger/~\ The ASCII (\)ICQ #13394035\ / Ribbon Campaign ^ X Against / \ HTML Email -- redhat-list mailing list unsubscribe mailto:redhat-list-request@;redhat.com?subject=unsubscribe https://listman.redhat.com/mailman/listinfo/redhat-list
