On Thu 20 January 2011 15:57:22 Christ Schlacta wrote:
> if ipmi is unfirewalled, any user who can jack into an open port can just
> use ipmi. that's not good. you should segregate ipmi to a dedicated vlan
> at the switch if possible. iptables rules are probably not the best way to
> go about se
On Thu 20 January 2011 17:16:57 Christ Schlacta wrote:
> you might look into amanda for your backups, it's quite nice. also, ask
> yourself "Can I re-rip(download?) this if I lose it?", before you bother
> wasting money on drive space to back it up. that's enough OT for now
> though~~
Not famili
I have a backup server, hex, which also has security cameras on eth2. eth1 is
the LAN.
I want to take a given security camera at IP 10.5.12.40 on eth2 (cam) and
present it to the LAN as 192.168.1.4:80. So in Shorewall rules I have:
DNATnet $FW:10.5.12.40 tcp www
ACCEPT n
On Fri 04 March 2011 05:55:35 Roberto C. Sánchez wrote:
> First, to confirm, do you have ip forwarding enabled?
Well, I have no idea.
> Second, you shouldn't need the ACCEPT rule, since the DNAT creates a
> coresponding ACEPT rule for you already.
If I don't put in that ACCEPT rule I get firewa
Any help?
On Fri 04 March 2011 10:50:57 cac...@quantum-sci.com wrote:
> On Fri 04 March 2011 05:55:35 Roberto C. Sánchez wrote:
> > First, to confirm, do you have ip forwarding enabled?
>
> Well, I have no idea.
>
>
> > Second, you shouldn't need the ACCEPT rule, since the DNAT creates a
> >
On Monday 7 March, 2011 07:55:39 Tom Eastep wrote:
> First of all, your rules are wrong. You want a single rule:
>
> DNAT net cam:10.5.12.40 tcp www
Thanks, but it's not working. Everything's set like you say, but when I try
from another machine:
[515690.154919] Shorewall:FOR
> Your routing is wrong. Note that it is trying to route the packet back
> out of eth0.
>
> How have you configured eth2?
Noticed that, but don't know why. (Debian Testing) I've deinstalled
network-manager and manually edit /etc/network/interfaces like I always have:
allow-hotplug eth2
iface e
On Thursday 17 March, 2011 11:09:56 Tom Eastep wrote:
> The camera is at 10.5.42.40 but your DNAT rule says 10.5.12.40.
Oh, FFS. Don't tell me it's that particular...
OK, so I believe that all the ports the camera presents are now on 192.168.1.4.
Is there a way to map the ports the camera pres
This is a little off topic, but I haven't been able to find an answer
elsewhere. I need to run a command on another machine on my LAN. I have a
backup server which does weekly rsync backups of the other machines. But when
the time comes for it to be backed up I do an rsync push to one of the
I thought it might be something like that, but:
# ssh root@droog '/sbin/btrfs subvolume snapshot
root@droog:///home/backups.hex/hex-root/
root@droog:///home/backups.hex/hex-root-snap-$(date +"%Y-%m-%d")'
ERROR: error accessing 'root@droog:///home/backups.hex/hex-root/'
On Friday 25 March, 20
Tom I don't think I've said this yet, but THANK YOU for the Shoreline Firewall.
This is one of the finest and most important software packages I've ever used,
and it always works.
I'll be making a donation in your name to the Alzheimer's Association as soon
as I make some money on eBay. (very
On Friday 3 June, 2011 16:14:03 you wrote:
> On 6/3/11 2:50 PM, cac...@quantum-sci.com wrote:
> >
> > Hello Tom,
> >
> > Can't make masquerading work for some reason.
> >
> > I have a VirtualBox VM running Debian with network in Host-Only mode. I
> > want to use this rather than Bridging to re
On Sunday 5 June, 2011 06:53:24 cac...@quantum-sci.com wrote:
> On Sunday 5 June, 2011 06:36:47 Tom Eastep wrote:
> > On 06/03/2011 09:01 PM, cac...@quantum-sci.com wrote:
> > > On Friday 3 June, 2011 16:14:03 you wrote:
> >
> > >> martians are a routing problem, not a Shorewall configuration prob
On Monday 6 June, 2011 06:44:39 cac...@quantum-sci.com wrote:
> On Sunday 5 June, 2011 06:53:24 cac...@quantum-sci.com wrote:
> > On Sunday 5 June, 2011 06:36:47 Tom Eastep wrote:
> > > On 06/03/2011 09:01 PM, cac...@quantum-sci.com wrote:
> > > > On Friday 3 June, 2011 16:14:03 you wrote:
> > >
>
On Wednesday 8 June, 2011 12:21:43 Tom Eastep wrote:
> On 06/08/2011 08:13 AM, cac...@quantum-sci.com wrote:
>
> >
> > So everyone is clear, it is not possible to set host-only networking
> > and masquerade/NAT through the Linux host with VirtualBox, to avoid
> > layer 2 attacks possible with bri
On Wednesday 8 June, 2011 13:32:04 Tom Eastep wrote:
> Well, if you are still getting the martian messages, then it is you IP
> configuration.
Yup, tons of martians. No idea why. I'm a real estate developer, not a coder.
No answers in all my searches of The Internets.
---
On Wednesday 8 June, 2011 16:08:12 cac...@quantum-sci.com wrote:
> On Wednesday 8 June, 2011 15:55:14 Tom Eastep wrote:
> > On 6/8/11 2:34 PM, cac...@quantum-sci.com wrote:
> > > On Wednesday 8 June, 2011 13:32:04 Tom Eastep wrote:
> > >> Well, if you are still getting the martian messages, then it
On Wednesday 8 June, 2011 18:09:43 Tom Eastep wrote:
> On 6/8/11 4:18 PM, cac...@quantum-sci.com wrote:
>
> >
> > Oh you meant PREFERENCES. Why didn't you -say- so?
> >
> > Yes there I have the IP set to 192.168.12.1. Don't know whether
> > that's supposed to be the virtual interface or gues
I recently checked my config, and found to my horror that apparently my system
is wide open!
How can this be? What is wrong? Shorewall v4.5.3-1
# iptables -L -n -v -x
Chain INPUT (policy DROP 0 pac
On Wednesday, June 27, 2012 12:25:35 PM Tom Eastep wrote:
> Please explain to us why you believe that your system is 'wide open'. If
> you are looking at the ACCEPT rule, notice that the 'in' column contains
> 'lo'; that simply allows the firewall to connect to itself.
Sure that's what the rule
On Wednesday, June 27, 2012 12:42:57 PM Tom Eastep wrote:
> > Doesn't this say to allow all from the net to the firewall? And isn't it
> > the first rule?
>
> No -- it says to jump to the net2fw chain for all packets coming from
> the net.
That's a relief. I saw all those packets getting caug
On Wednesday, June 27, 2012 01:49:25 PM Tom Eastep wrote:
> That says to ACCEPT any packet that is part of an established connection
> and to accept new connections that are related to an existing connection.
Sure, but that's just necessary for TCP.
I'm wondering about the firewall -tracking-
On Wednesday, June 27, 2012 02:22:19 PM Tom Eastep wrote:
> But if you don't have that sort of rule, then if the packet matches an
> ACCEPT rule, it will be accepted by Netfilter and the TCP stack will
> discard it. Otherwise, it will end up in the 'Drop' chain which contains
> this rule:
OK,
Strangely today I tried to get a DHCP lease when I know 68 is closed, yet there
was no complaint from Shorewall.
My last policy is:
net all DROPinfo
all all DROPinfo
... and yet there was nothing in dmesg.
--
On Thursday, June 28, 2012 03:57:22 PM Tom Eastep wrote:
> DHCP uses raw sockets which are independent of the IP stack (and hence
> independent of Netfilter).
Meh? So I don't need bootpc in my rules at all?
Wonder why it couldn't get a lease...
This may not necessarily be the best place to ask this, but I've tried the
Admin Guide, LinuxQuestions and Debian forums and no one knows.
Running Debian Testing, and I need to set up two profiles for my wifi adapter,
one for home and one for any open AP. I'm using the manual method of
config
On Friday, July 13, 2012 05:57:56 PM Paul Gear wrote:
> This is definitely not the right place to ask, but i can tell you this:
> NetworkManager definitely supports the 5 GHz channels. In fact,
> NetworkManager seems to be completely channel-agnostic, and the
> underlying card/driver is responsibl
On Saturday, July 14, 2012 02:19:47 AM Paul Gear wrote:
> On 14/07/12 15:15, cac...@quantum-sci.com wrote:
> > On Friday, July 13, 2012 05:57:56 PM Paul Gear wrote:
> >> This is definitely not the right place to ask, but i can tell you this:
> >> NetworkManager definitely supports the 5 GHz channel
I see that my machine is trying to send out mysterious packets frequently, and
this is disturbing (Debian Testing, SW 4.5.5.3-1):
[33989.889255] Shorewall:fw2net:DROP:IN= OUT=wlan0 SRC=192.168.1.1
DST=208.67.220.220 LEN=56 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=53577
DPT=443 LEN=36
[
On Wednesday, 15 August, 2012 07:56:06 Tom Eastep wrote:
> Are you an OpenDNS subscriber by chance?
Thanks. I do not subscribe to OpenDNS, but I do use their dnscrypt-proxy.
I've just installed it and haven't gotten it working yet. I find in the man
page: "By default, dnscrypt-proxy sends ou
Just a point of order here, and I'm sure I'm misinterpreting this, but it looks
like my firewall is wide open. I'd understood that the first matching rule it
comes to, it accepts for a given packet.
Is it the policy DROP that's calling the shots for each chain??
# iptables -L
Chain INPUT (pol
On Friday, 17 August, 2012 10:41:40 Tom Eastep wrote:
> shorewall show
>
> instead. That uses 'iptables -L -n -v' which is the only way to see what
> your ruleset is really doing.
OK. But if the DROP policy is applied to each chain, and that rule is come to
first, why are all my packets
I know someone who for the past 4 days has been having the heck ddosed out of
him. He runs a gaming server, and ran a report on the ddos; he has 8 pages of
that and a few hours ago there were 16 pages. They're attacking his machine on
random ports and he blocks UDP traffic on those ports, bu
On Monday, 20 August, 2012 00:07:43 Simon Hobson wrote:
> The other issue if it's UDP traffic is that the source addresses are
> probably spoofed anyway. It depends on the network infrastructure at
> the attacking end, but it's often easy to send traffic with spoofed
> source addresses. Even if
Just installed psad and am testing it. This morning I awoke to an email saying:
[-] You may just need to add a default logging rule to the /sbin/ip6tables
'filter' 'INPUT' chain on hydra. For more information,
see the file "FW_HELP" in the psad sources directory or visit:
http://www
On Tuesday, 28 August, 2012 09:31:31 cac...@quantum-sci.com wrote:
>
> Just installed psad and am testing it. This morning I awoke to an email
> saying:
>
> [-] You may just need to add a default logging rule to the /sbin/ip6tables
> 'filter' 'INPUT' chain on hydra. For more information,
>
Today I noticed to my horror that my firewall was ACCEPTing EVERYTHING. It was
like this for a couple of weeks. I found the reason was I'd removed 'tor' from
the services file and so Shorewall failed to start. I've removed tor from the
rules file now, and of course it works.
But routestopp
I have a Tor gateway set up, and would like to route all traffic through it.
For security, different functions should use different Tor ports, so they have
different virtual circuits.
I've assigned port 9110 to be the port for email. My mail client uses SSL for
email (POP3s: 995, sSMTP: 465
>> Anyone know how I would do this in Shorewall?
>mangling ssl/tls is a stupid solution to tor problems, like realname is
>not a email
Thanks for the input.
But you are just a foolish Hater when you criticize and do not offer a solution.
Fact is, this was recommended on #tor because there i
On Tuesday, May 07, 2013 09:04:42 AM Tom Eastep wrote:
> Another thing here is to be sure to use 'shorewall show' (or 'iptables -L
> -n -v') when looking at the Netfilter filter table configuration. You
> can't tell what the state of the ruleset is by simply issuing 'Iptables
> -L' -- it's output i
On Tuesday, May 07, 2013 05:15:09 PM Tom Eastep wrote:
> > Chain INPUT (policy DROP 0 packets, 0 bytes)
> > pkts bytes target prot opt in out source
> > destination
> > 104 10002 ACCEPT all -- * * 0.0.0.0/0
> > 0.0.0.0/0
On Sunday, May 05, 2013 06:57:49 AM cac...@quantum-sci.com wrote:
>
> I have a Tor gateway set up, and would like to route all traffic through it.
> For security, different functions should use different Tor ports, so they
> have different virtual circuits.
>
> I've assigned port 9110 to be t
On Tuesday, May 07, 2013 06:19:01 PM Tom Eastep wrote:
> Then your firewall was *NOT* open from the net.
Well then why does it *say* everything is open?
--
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Datab
On Tuesday, May 07, 2013 06:58:50 PM Terry Gilsenan wrote:
> Firstly, Is the mail client socks aware? If it is not then that is the issue
> you need to fix. If it is, then tell it to use the socks proxy on port 9110
>
> Shorewall is an IPTables configurator, it is NOT a proxy. Shorewall isn't a
On Tuesday, May 07, 2013 06:58:50 PM Terry Gilsenan wrote:
> Firstly, Is the mail client socks aware? If it is not then that is the issue
> you need to fix. If it is, then tell it to use the socks proxy on port 9110
>
> Shorewall is an IPTables configurator, it is NOT a proxy. Shorewall isn't a
On Tuesday, May 07, 2013 11:59:49 PM Paul Gear wrote:
> On 05/08/2013 02:50 PM, cac...@quantum-sci.com wrote:
> > On Tuesday, May 07, 2013 06:19:01 PM Tom Eastep wrote:
> >> Then your firewall was *NOT* open from the net.
> >
> > Well then why does it *say* everything is open?
>
> It doesn't. The
On Tuesday, May 07, 2013 10:24:10 PM Terry Gilsenan wrote:
> I tried to explain this..: SSL and to some extent TLS will object to
> transparent proxying.
>
> The problem is that Kmail doesn't know how to do socks, and that is what you
> need to fix, either by changing to an email client that CAN
On Tuesday, May 07, 2013 11:20:11 PM Dominic Benson wrote:
> You might want to look at something like TransSocks, which, I understand, is
> intended to allow exactly this kind of tunnelling. I think you would set it
> up to forward over the SOCKS proxy on 9110 and listen on some other port, and
For some reason my ftp no longer works. (Ubuntu Raring, kernel
3.14-1-amd64, Sw 4.6.1.2-1)
I can clearly see that Shorewall is blocking passive ftp attempts, but I
don't know what to do about it. Connexion tracking doesn't seem to be
working.
I've gone through http://www.shorewall.net/FTP.html
Tom Eastep wrote:
> On 8/12/2014 12:53 PM, cac...@quantum-sci.com wrote:
>> For some reason my ftp no longer works. (Ubuntu Raring, kernel
>> 3.14-1-amd64, Sw 4.6.1.2-1)
>>
>> I can clearly see that Shorewall is blocking passive ftp attempts, but I
>> don't know what to do about it. Connexion trac
Tom Eastep wrote:
> On 8/12/2014 6:30 PM, cac...@quantum-sci.com wrote:
>> Tom Eastep wrote:
>>> On 8/12/2014 12:53 PM, cac...@quantum-sci.com wrote:
For some reason my ftp no longer works. (Ubuntu Raring, kernel
3.14-1-amd64, Sw 4.6.1.2-1)
I can clearly see that Shorewall is b
Tom Eastep wrote:
> On 8/12/2014 8:38 PM, cac...@quantum-sci.com wrote:
>> Tom Eastep wrote:
>>> So you felt that your setting of AUTOHELPERS was irrelevant because your
>>> kernel is earlier that 3.5?
>> I don't understand what you're saying. That page says, "By making
>> AUTOHELPERS=Yes the def
Attached.
Tom Eastep wrote:
> On 8/13/2014 6:58 AM, cac...@quantum-sci.com wrote:
>> Tom Eastep wrote:
>>> On 8/12/2014 8:38 PM, cac...@quantum-sci.com wrote:
Tom Eastep wrote:
> So you felt that your setting of AUTOHELPERS was irrelevant because your
> kernel is earlier that 3.5?
>>
Tom Eastep wrote:
> On 8/13/2014 8:16 AM, cac...@quantum-sci.com wrote:
>> Attached.
>>
> Hmmm -- that's not good.
>
> Please forward:
>
> - the setting of HELPERS in shorewall.conf
HELPERS=
as from the factory.
> - the output of 'shorewall show -f capabilities'
Attached.
> - the contents of /et
Tom Eastep wrote:
> You need one. There is a populated file included with Shorewall; which
> distro are you running and how did you install Shorewall? Which
> Shorewall version (command: shorewall version -a). -Tom
Ok I'cw installed the one fron /usr/share/shorewall:
?FORMAT 3
#ACTION
Anyone know why Shorewall settings seem to have no effect on allowing
SMTP out? I'm getting:
# dmesg
[181685.067416] Shorewall:fw-net:ACCEPT:IN= OUT=eth0 SRC=72.251.231.102
DST=199.127.58.3 LEN=48 TOS=0x00 PREC=0x00 TTL=64 ID=53282 DF PROTO=TCP
SPT=17554 DPT=25 WINDOW=29200 RES=0x00 SYN URGP=0 UI
>> I'm getting:
>>
>> # dmesg
>> [181685.067416] Shorewall:fw-net:ACCEPT:IN= OUT=eth0 SRC=72.251.231.102
>> DST=199.127.58.3 LEN=48 TOS=0x00 PREC=0x00 TTL=64 ID=53282 DF PROTO=TCP
>> SPT=17554 DPT=25 WINDOW=29200 RES=0x00 SYN URGP=0 UID=89 GID=89
> That looks like it's passing the traffic to me
On 10/27/2017 09:24 AM, PGNet Dev wrote:
> On 10/27/17 8:48 AM, cac...@quantum-sci.com wrote:
>> In fact half the time, REJECTs and DROPs are -not- logged, and I have
>> to figure out why without the aid of informational messages.
>
> Shorewall does a great job of doing exactly what it's told to do
> Well, so far, all you have given us is a log message, one rule, and a
> "It works sometimes".
>
> Given that the rule you posted doesn't include a log level, but a log
> message is being produced, I am wondering if the fw->net policy is
> ACCEPT with a log level specified. If that is the case, t
On 10/27/2017 10:27 AM, cac...@quantum-sci.com wrote:
>
>> Well, so far, all you have given us is a log message, one rule, and a
>> "It works sometimes".
>>
>> Given that the rule you posted doesn't include a log level, but a log
>> message is being produced, I am wondering if the fw->net policy i
On 10/27/2017 10:56 AM, Simon Hobson wrote:
> cac...@quantum-sci.com wrote:
>
>> Eh, except I got bounced with:
>>
>> SMTP error from remote mail server after RCPT TO:
>> :
>> 504 5.5.2 : Helo command rejected: need fully-qualified hostname
> You would sending mail direct to me as well - your m
On 11/13/2017 12:07 PM, Simon Hobson wrote:
> Johannes Graumann wrote:
>
>> 1) Are there any nice, comprehensive interfaces to sort through the
>> plethora of switches available with filters for more than the bare
>> bones protocol requirements usually present?
> Not that I know of - PITA isn't i
I'm setting up IPSec (LibreSwan) to come into my router. (a CentOS VM)
At 127.0.0.1 in the router are ports 500 and 4500 (which are reverse SSH
tunneled from another machine).
Rather than flanging those ports directly to the outside interface in
the router, I'm hoping for a little added protectio
On 12/12/2017 03:22 PM, cac...@quantum-sci.com wrote:
>
> I'm setting up IPSec (LibreSwan) to come into my router. (a CentOS VM)
>
> At 127.0.0.1 in the router are ports 500 and 4500 (which are reverse
> SSH tunneled from another machine).
>
> Rather than flanging those ports directly to the outsid
On 12/13/2017 08:55 AM, Tom Eastep wrote:
> On 12/13/2017 08:47 AM, cac...@quantum-sci.com wrote:
>> On 12/12/2017 03:22 PM, cac...@quantum-sci.com wrote:
>>> I'm setting up IPSec (LibreSwan) to come into my router. (a CentOS VM)
>>>
>>> At 127.0.0.1 in the router are ports 500 and 4500 (which are
On 12/13/2017 09:44 AM, Bill Shirley wrote:
> I don't see that SSH tunneling or running IPSEC in a VM as a security
> gain. It
> would be very complex with multiple points of failure. If you don't
> trust the traffic
> from the other endpoint, filter it with Shorewall after it's
> decrypted. Aft
On 12/14/2017 02:50 PM, Tom Eastep wrote:
> On 12/14/2017 02:28 PM, Colony.three via Shorewall-users wrote:
>> I have a VM which is the LAN router, and another VM in the LAN which
>> is the ipsec gateway. (strongswan)
>>
>> I'm not fully understanding the guide here;
>> http://www.shorewall.net/IP
I'll look at what you say below Bill.
But keep in mind that the attacks I'm concerned about are typically
buffer overflows and other sideband attacks. Directness rarely succeeds
in hacking these days. There are always unknown vulns.
I'm suspicioning that the reason Tom says that only the router
/run is cleared on every boot so a restorecon wouldn't last. If a
reboot doesn't fix it, it's likely a problem in a script of the repo.
OP doesn't say how he's pulling these messages, but I can't find them in
CentOS7.
On 12/15/2017 03:12 AM, Bill Shirley wrote:
> Perhaps /run/lock/subsys/shore
69 matches
Mail list logo
