Re: strange iptables/bridge behaviour

On Fri, 03 Feb 2006 13:30:52 -0800, beau wrote:

I've noticed some very strange behaviour in my firewall lately. If I
do a port scan on my desktop machine (XP) from a site like
security.symantec.com then I get some open ports listed, such as
25,80,110... These ports aren't open on my machine, fport even says
so. If I explicitly block 110 on my firewall the scan still reports it
as being open. I'm using Fedora Core 4 with 2.6.11-1 kernel and
iptables to filter traffic over a bridge. When I block 110 I insert a
rule like this:

iptables -I FORWARD 1 -p tcp --dport 110 -j DROP

the packet counters for this rule are incrementing when I port scan, so
packets are matching. Has anyone seen anything like this before??? Is
it possible that something upstream from my firewall is causing this???

Beau

Personally I wouldn't trust port scanning sites like that. Between you and
them there are probably ISP firewalls that filter stuff out like SMTP and
other services. For instance, if I scan myself with nmap from my Linux
server out on the net to my cable modem (which only has a router behind
it with no open ports) I get the following results:

PORT STATE SERVICE
135/tcp filtered msrpc
139/tcp filtered netbios-ssn
445/tcp filtered microsoft-ds
593/tcp filtered http-rpc-epmap
1433/tcp filtered ms-sql-s
1521/tcp filtered oracle
3306/tcp filtered mysql
4444/tcp filtered krb524
6106/tcp filtered isdninfo

My ISP filters those ports so they show up in the scan (albeit as filtered
in nmap) but perhaps symantec sees them as open?

I would try having a friend on the same ISP scan you, or perhaps scan
yourself from work using nmap or some other port scanner to get better
results. This way you can avoid any firewall filtering except for your own
ISP's filters (if they have any).

You could always just scan yourself internally from behind your router.

You'll probably notice from each scan (friend on ISP, work, internally
behind your router) you will get different results depending on
the different filters you encounter along the way.

So go ahead and experiment on your own, don't trust those web based scans.
There is only one web based scan that I do slightly trust a little
more than symantec and that's at GRC.com, it's called "shields up", but I
prefer the manual way (nmap).

--
Nick DePetrillo
Network Security Engineer
OSHEAN
PGP Key: http://pgp.mit.edu:11371/pks/lookup?op=vindex&search=0x121245B5

.

Relevant Pages

  • Re: Netbios Port 137 Outbound
    ... you probably want to block outgoing port 137 using the router's ... filters or software firewall filters on the computer running ... To determine whether the outbound 137's are caused by WallWatcher, ...
    (microsoft.public.windows.server.sbs)
  • Re: Disabling ISA Server 2000
    ... If you require outbound port ... Right click on IP Packet Filters and choose New->Filter. ... Go to Monitoring\Services and restart the Firewall service. ...
    (microsoft.public.windows.server.sbs)
  • Re: Configure ISA for emails
    ... Packet Filters in ISA 2000 to allow internal clients access external POP3 ... Based on my research, after you run the CEICW, the POP3 and SMTP IP Packet ... Local port: All ports ...
    (microsoft.public.windows.server.sbs)
  • Re: Question for BizTYalk Developers: Filters in ports:
    ... The filters for Send Ports(SP) and Send Port Groups located ... The filters for Receive Ports are located inside Receive shapes in ... The filter is defined in the *orchestration* because it is the orchestration ...
    (microsoft.public.biztalk.general)
  • Re: prevent infinite loop in orchestration using bts.operation in
    ... we don't have an "not exists" predicate to use in filters. ... using direct bound ports are a nice and beautiful ... So by NOT USING a direct bound port on the ... Private blog: http://blog.eliasen.dk ...
    (microsoft.public.biztalk.general)