From kens at kensnet.org Tue Oct 2 16:20:07 2018 From: kens at kensnet.org (Ken Smith) Date: Tue, 02 Oct 2018 16:20:07 -0000 Subject: [GLLUG] PERL Advice Message-ID: <9db67453-5f4c-f91c-24d0-422f62920293@kensnet.org> Hi all I have a colleague who needs some help with a legacy Perl/Linux system. Would appreciate a private e-mail from anyone willing to spend 1/2 a day understanding the legacy situation and advising on options to move forward. Thanks Ken -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From jason at ukpost.com Tue Oct 2 16:24:59 2018 From: jason at ukpost.com (Jason Clifford) Date: Tue, 02 Oct 2018 16:24:59 -0000 Subject: [GLLUG] PERL Advice In-Reply-To: <9db67453-5f4c-f91c-24d0-422f62920293@kensnet.org> References: <9db67453-5f4c-f91c-24d0-422f62920293@kensnet.org> Message-ID: <1663598b8ad.e7ce705f108278.3888028763277677027@ukpost.com> Are you able to provide a little more context. I've worked with fairly large and complex Perl codebases and, as with code in any language, I would be wary of offering to do as you ask without a better idea of what I might be getting into ---- On Tue, 02 Oct 2018 17:19:48 +0100 gllug at mailman.lug.org.uk wrote ---- Hi all I have a colleague who needs some help with a legacy Perl/Linux system. Would appreciate a private e-mail from anyone willing to spend 1/2 a day understanding the legacy situation and advising on options to move forward. Thanks Ken -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. -- GLLUG mailing list GLLUG at mailman.lug.org.uk https://mailman.lug.org.uk/mailman/listinfo/gllug -------------- next part -------------- An HTML attachment was scrubbed... URL: From martin at hinterlands.org Tue Oct 2 16:25:04 2018 From: martin at hinterlands.org (Martin A. Brooks) Date: Tue, 02 Oct 2018 16:25:04 -0000 Subject: [GLLUG] PERL Advice In-Reply-To: <9db67453-5f4c-f91c-24d0-422f62920293@kensnet.org> References: <9db67453-5f4c-f91c-24d0-422f62920293@kensnet.org> Message-ID: <3fb2ea96c6828321344b064903d3f536@hinterlands.org> On 2018-10-02 17:19, Ken Smith via GLLUG wrote: > Hi all > > I have a colleague who needs some help with a legacy Perl/Linux system. > > Would appreciate a private e-mail from anyone willing to spend 1/2 a > day understanding the legacy situation and advising on options to move > forward. Sure, happy to have a chat, please have him mail me offlist. Mart. From kens at kensnet.org Wed Oct 24 22:52:52 2018 From: kens at kensnet.org (Ken Smith) Date: Wed, 24 Oct 2018 22:52:52 -0000 Subject: [GLLUG] Sendmail DoS Question Message-ID: <0159836e-3c7b-3b8e-d7e1-a93967ffffb5@kensnet.org> Hi All I've been noticing what looks like an attempt at a DoS on my mail server. Various hosts open sets of SSL sessions to port 465 and then sit there not exchanging any traffic. The server is set to allow 20 sendmail processes and the miscreant gets that number of session going effectively DoSing the service. Easily remedied by killing it all and restarting the daemon. I've adjusted sendmail's timeouts to drop these malicious sessions. The session processes get stuck looking like this in ps. sendmail: server [178.128.158.113] startup I've also set a connection limit to port 465 in iptables to reject these multiple sessions that appear to originate in batches from the same IP and then from another IP and so on. Anyone else seeing this and out of interest what mode is sendmail in when its shows "startup". I've tried manually connecting and sending e-mail either in plain text or via ssl and don't see that status. Thanks Ken -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From john at cornerstonelinux.co.uk Wed Oct 24 23:22:14 2018 From: john at cornerstonelinux.co.uk (John Edwards) Date: Wed, 24 Oct 2018 23:22:14 -0000 Subject: [GLLUG] Sendmail DoS Question In-Reply-To: <0159836e-3c7b-3b8e-d7e1-a93967ffffb5@kensnet.org> References: <0159836e-3c7b-3b8e-d7e1-a93967ffffb5@kensnet.org> Message-ID: <20181024232208.GE20845@cornerstonelinux.co.uk> Hi On Wed, Oct 24, 2018 at 11:52:31PM +0100, Ken Smith via GLLUG wrote: > Hi All > > I've been noticing what looks like an attempt at a DoS on my mail server. > Various hosts open sets of SSL sessions to port 465 and then sit there not > exchanging any traffic. The server is set to allow 20 sendmail processes and > the miscreant gets that number of session going effectively DoSing the > service. Easily remedied by killing it all and restarting the daemon. I've > adjusted sendmail's timeouts to drop these malicious sessions. > > The session processes get stuck looking like this in ps. > > sendmail: server [178.128.158.113] startup > > I've also set a connection limit to port 465 in iptables to reject these > multiple sessions that appear to originate in batches from the same IP and > then from another IP and so on. > > Anyone else seeing this and out of interest what mode is sendmail in when > its shows "startup". I've tried manually connecting and sending e-mail > either in plain text or via ssl and don't see that status. I don't run sendmail, but that sounds like a variant on the old trick of opening lots of network connections and then communicating very slowly over each one. Example: https://en.wikipedia.org/wiki/Slowloris_(computer_security) Most web servers will have some sort of connection control to stop this, such as Apache's mod_reqtimeout, but I've not seen anything similar for most SMTP or IMAP servers beyond the basic limits of the number of connection per IP (happy to be proved wrong in that). So I think you are probably right in falling back on iptables to limit connections. Of course DoS is still possible if the attack has a wide enough range of IP addresses. I've seen plenty of examples on limiting the maximum transfer rate for a network connection, but not for a minimum. Tangentially, could hooking failures into something like fail2ban help in the long term? -- #---------------------------------------------------------# | John Edwards Email: john at cornerstonelinux.co.uk | #---------------------------------------------------------# From t at woodall.me.uk Thu Oct 25 20:26:34 2018 From: t at woodall.me.uk (Tim Woodall) Date: Thu, 25 Oct 2018 20:26:34 -0000 Subject: [GLLUG] Sendmail DoS Question In-Reply-To: <0159836e-3c7b-3b8e-d7e1-a93967ffffb5@kensnet.org> References: <0159836e-3c7b-3b8e-d7e1-a93967ffffb5@kensnet.org> Message-ID: On Wed, 24 Oct 2018, Ken Smith via GLLUG wrote: > Hi All > > I've been noticing what looks like an attempt at a DoS on my mail server. > Various hosts open sets of SSL sessions to port 465 and then sit there not > exchanging any traffic. The server is set to allow 20 sendmail processes and > the miscreant gets that number of session going effectively DoSing the > service. Easily remedied by killing it all and restarting the daemon. I've > adjusted sendmail's timeouts to drop these malicious sessions. > > The session processes get stuck looking like this in ps. > > sendmail: server [178.128.158.113] startup > > I've also set a connection limit to port 465 in iptables to reject these > multiple sessions that appear to originate in batches from the same IP and > then from another IP and so on. > > Anyone else seeing this and out of interest what mode is sendmail in when its > shows "startup". I've tried manually connecting and sending e-mail either in > plain text or via ssl and don't see that status. > > Thanks > > Ken > I'm seeing similar - although it doesn't seem to be causing me any issues other than rather large logs. Just added another /24 to my evil.cidr list. Tim. > > > > From cheese at cheesetalks.net Wed Oct 31 14:35:39 2018 From: cheese at cheesetalks.net (Cheeseness) Date: Wed, 31 Oct 2018 14:35:39 -0000 Subject: [GLLUG] November Meetup? Message-ID: <564390fa9f37a2c49279b7dd202642538c48a05d.camel@cheesetalks.net> Hi! My name is Cheese and I'm a Linux based game developer/Linux porter from Australia. I am travelling to London on the 6th and will be around for a week or so. I enjoy discovering new LUGs/communities, and would love to have the opportunity to get to know my fellow Linux users on the other side of the world. I don't know how frequently you meet, or whether you have talks at meetings, but if that's something of interest, I would be happy to give a talk on my experiences with making games on/porting games to Linux. In my game related career, I have: * Worked on existing F/OSS games like Neverball[1] * Released my own games as F/OSS FLAT[2] * Contracted on proprietary games like Hand of Fate 2[3] and The Away Team[4] * Ported classic games like Day of the Tentacle Remastered[5] and Full Throttle Remastered[6] to Linux Currently I am focused on developing my own text adventure/first person hybrid game called In the Snowy Winter's Wake[7], and an engine for creating similar experiences[8]. So far as my talk history goes, in addition to running and regularly speaking at my local LUG[9] since 2008, I've also given talks at the Ottawa Canada LUG[10][11], have spoken at linux.conf.au[12]. Apologies for the short notice. I had planned to try to reach out sooner, but 2018 has been a very full year for me. Cheese [1] http://neverball.org [2] http://flat.jbushproductions.com/ [3] https://store.steampowered.com/app/456670/Hand_of_Fate_2/ [4] http://awayteam.space/ [5] http://cheesetalks.net/porting_dott.php [6] http://fullthrottle.doublefine.com/ [7] http://winterswake.com/[8] http://icicle-engine.org/ [9] https://taslug.org.au/ [10] https://wiki.linux-ottawa.org/doku.php?id=history:meeting:26 [11] https://wiki.linux-ottawa.org/doku.php?id=history:meeting:40 [12] https://www.youtube.com/watch?v=d8kfva6G0c4 From grantpe at gmail.com Wed Oct 31 16:45:14 2018 From: grantpe at gmail.com (Peter Grant) Date: Wed, 31 Oct 2018 16:45:14 -0000 Subject: [GLLUG] VPNs (nearly off topic) Message-ID: Hi all, This is nearly off topic, but since the VPNs are between two PFSense firewalls, I guess it might just squeeze in. I have two PFSense firewalls, one in the UK and one in Thailand. I have a need encrypted networking between them (to protect communication between Windows boxes). I've managed to get an IPSec tunnel established, but with major packet loss over it (30% or so), which is obviously unworkable. Any suggestions to either reduce the packet loss or a different VPN technology that will cope better with the distance/latency involved? Ideally something PFSense will support, we have several OpenVPN tunnels and IPSec tunnels running already for other uses, so might slightly prefer one of those. I did disable the Dead peer detection system which improved the performance, but it's still not good enough for use. Thanks for reading and for any advice you might have, Peter From james.dutton at gmail.com Wed Oct 31 22:21:47 2018 From: james.dutton at gmail.com (James Courtier-Dutton) Date: Wed, 31 Oct 2018 22:21:47 -0000 Subject: [GLLUG] VPNs (nearly off topic) In-Reply-To: References: Message-ID: On Wed, 31 Oct 2018 at 16:46, Peter Grant via GLLUG < gllug at mailman.lug.org.uk> wrote: > Hi all, > This is nearly off topic, but since the VPNs are between two PFSense > firewalls, I guess it might just squeeze in. > > I have two PFSense firewalls, one in the UK and one in Thailand. I > have a need encrypted networking between them (to protect > communication between Windows boxes). > > I've managed to get an IPSec tunnel established, but with major packet > loss over it (30% or so), which is obviously unworkable. > > Any suggestions to either reduce the packet loss or a different VPN > technology that will cope better with the distance/latency involved? > Ideally something PFSense will support, we have several OpenVPN > tunnels and IPSec tunnels running already for other uses, so might > slightly prefer one of those. > > I did disable the Dead peer detection system which improved the > performance, but it's still not good enough for use. > > Thanks for reading and for any advice you might have, > Peter > Hi, I agree that this is off topic for Linux, but I also have some 20 years TCP/IP networking experience, so I thought I would suggest some ideas. With VPNs, then configured wrongly, can cause something called "black hole packets". This is where packets of particular sizes get dropped. E.g. Packets of sizes up until 1000 bytes pass OK, bytes of size 1001-1010 fail, and then bytes larger than 1011 are fine. Which size packet that gets lost varies depending on the configuration, but it is normally around between 1400 and 1500. A way to test this is to send ICMP ping packets though the link, starting small size, and progressively getting larger, until about 2000 Bytes. Then see if ones of a particular size fail to get through. On a properly working link, all the packets should get through. On a link with the "black hole" problem, some packets of particular sizes will never get through. If your link has a "black hole" problem, one possible solution is lowering the MTU on the ethernet interfaces. Sometimes this fixes the problem, sometimes, all it does is move the "black hole" to a different size. So, have a test, and tell me what you find. On linux, you can use "ping -s ..." to set the packet size. -------------- next part -------------- An HTML attachment was scrubbed... URL: